<?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>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Contents</UNITNAME>
    <CNTNTS>
        <AGCY>
            <EAR>
                Agricultural Marketing
                <PRTPAGE P="iii"/>
            </EAR>
            <HD>Agricultural Marketing Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>25381-25382</PGS>
                    <FRDOCBP>2020-09350</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Agriculture</EAR>
            <HD>Agriculture Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Agricultural Marketing Service</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Agricultural Statistics Service</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Office of Partnerships and Public Engagement</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>25382-25383</PGS>
                    <FRDOCBP>2020-09278</FRDOCBP>
                </DOCENT>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Beginning Farmers and Ranchers, </SJDOC>
                    <PGS>25384</PGS>
                    <FRDOCBP>2020-09292</FRDOCBP>
                </SJDENT>
            </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>25404-25405</PGS>
                    <FRDOCBP>2020-09269</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Consumer Financial Protection</EAR>
            <HD>Bureau of Consumer Financial Protection</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Compliance Bulletin and Policy Guidance:</SJ>
                <SJDENT>
                    <SJDOC>Handling of Information and Documents during Mortgage Servicing Transfers, </SJDOC>
                    <PGS>25279-25283</PGS>
                    <FRDOCBP>2020-09151</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Fiscal</EAR>
            <HD>Bureau of the Fiscal Service</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Management of Federal Agency Disbursements, </DOC>
                    <PGS>25285-25291</PGS>
                    <FRDOCBP>2020-08058</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Centers Disease</EAR>
            <HD>Centers for Disease Control and Prevention</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Hazardous Drugs:</SJ>
                <SJDENT>
                    <SJDOC>Draft National Institute for Occupational Safety and Health List of Hazardous Drugs in Healthcare Settings, 2020; Procedures; and Risk Management Information, </SJDOC>
                    <PGS>25437-25449</PGS>
                    <FRDOCBP>2020-09332</FRDOCBP>
                </SJDENT>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee on Breast Cancer in Young Women; Cancellation, </SJDOC>
                    <PGS>25450</PGS>
                    <FRDOCBP>2020-09305</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Mine Safety and Health Research Advisory Committee, </SJDOC>
                    <PGS>25449-25450</PGS>
                    <FRDOCBP>2020-09306</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Proposed Update of the 2006 Revised Recommendations for HIV Testing of Adults, Adolescents, and Pregnant Women in Health-Care Settings, </DOC>
                    <PGS>25450-25451</PGS>
                    <FRDOCBP>2020-09348</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Centers Medicare</EAR>
            <HD>Centers for Medicare &amp; Medicaid Services</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Medicare and Medicaid Programs:</SJ>
                <SJDENT>
                    <SJDOC>Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-facilitated Exchanges, and Health Care Providers, </SJDOC>
                    <PGS>25508-25638</PGS>
                    <FRDOCBP>2020-05050</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Commerce</EAR>
            <HD>Commerce Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>International Trade Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Oceanic and Atmospheric Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Committee for Purchase</EAR>
            <HD>Committee for Purchase From People Who Are Blind or Severely Disabled</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Procurement List; Additions and Deletions, </DOC>
                    <PGS>25402-25404</PGS>
                    <FRDOCBP>2020-09326</FRDOCBP>
                      
                    <FRDOCBP>2020-09327</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>Engineers Corps</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>25405-25407</PGS>
                    <FRDOCBP>2020-09267</FRDOCBP>
                      
                    <FRDOCBP>2020-09268</FRDOCBP>
                </DOCENT>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>Board of Visitors, National Defense University, </SJDOC>
                    <PGS>25406</PGS>
                    <FRDOCBP>2020-09343</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Education Department</EAR>
            <HD>Education Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Grant Reallotment, </SJDOC>
                    <PGS>25409</PGS>
                    <FRDOCBP>2020-09303</FRDOCBP>
                </SJDENT>
                <SJ>Application for New Awards:</SJ>
                <SJDENT>
                    <SJDOC>Competitive Grants for State Assessments Program, </SJDOC>
                    <PGS>25420-25426</PGS>
                    <FRDOCBP>2020-09336</FRDOCBP>
                </SJDENT>
                <SJ>Final Priorities:</SJ>
                <SJDENT>
                    <SJDOC>Competitive Grants for State Assessment Program, </SJDOC>
                    <PGS>25416-25420</PGS>
                    <FRDOCBP>2020-09335</FRDOCBP>
                </SJDENT>
                <SJ>Request for Applications:</SJ>
                <SJDENT>
                    <SJDOC>FY 2020 Education Stabilization Fund—Rethink K-12 Education Models Discretionary Grant Program, </SJDOC>
                    <PGS>25409-25415</PGS>
                    <FRDOCBP>2020-09274</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>PROPOSED RULES</HD>
                <SJ>Energy Conservation Program:</SJ>
                <SJDENT>
                    <SJDOC>Energy Conservation Standards for General Service Fluorescent Lamps and Incandescent Reflector Lamps, </SJDOC>
                    <PGS>25324-25338</PGS>
                    <FRDOCBP>2020-08851</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>National Environmental Policy Act Implementing Procedures, </DOC>
                    <PGS>25338-25342</PGS>
                    <FRDOCBP>2020-08511</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Orders:</SJ>
                <SJDENT>
                    <SJDOC>Ovintiv Marketing, Inc.; Irving Oil Commercial GP; Northwest Natural Gas Co., et. al, </SJDOC>
                    <PGS>25426-25427</PGS>
                    <FRDOCBP>2020-09271</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Engineers</EAR>
            <HD>Engineers Corps</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Proposals by Non-Federal Interests, for Feasibility Studies, Proposed Modifications to Authorized Water Resources Development Projects and Feasibility Studies, and Proposed Modifications for an Environmental Infrastructure Program for Inclusion in the Annual Report to Congress on Future Water Resources Development, </DOC>
                    <PGS>25407-25409</PGS>
                    <FRDOCBP>2020-09338</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Environmental Protection</EAR>
            <HD>Environmental Protection Agency</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Air Quality State Implementation Plans; Approvals and Promulgations:</SJ>
                <SJDENT>
                    <SJDOC>California; Mojave Desert Air Quality Management District, </SJDOC>
                    <PGS>25291-25293</PGS>
                    <FRDOCBP>2020-08290</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Delaware; Infrastructure Requirements for the 2015 Ozone Standard and Revisions to Modeling Requirements, </SJDOC>
                    <PGS>25305-25309</PGS>
                    <FRDOCBP>2020-08241</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <PRTPAGE P="iv"/>
                    <SJDOC>Florida; 2010 1-Hour Sulfur Dioxide National Ambient Air Quality Standards Transport Infrastructure, </SJDOC>
                    <PGS>25293-25299</PGS>
                    <FRDOCBP>2020-08501</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Missouri; Removal of Control of Emissions from the Application of Automotive Underbody Deadeners, </SJDOC>
                    <PGS>25299-25300</PGS>
                    <FRDOCBP>2020-08421</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Washington; Wallula Second 10-Year Maintenance Plan, </SJDOC>
                    <PGS>25301-25305</PGS>
                    <FRDOCBP>2020-08123</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Air Quality State Implementation Plans; Approvals and Promulgations:</SJ>
                <SJDENT>
                    <SJDOC>Arizona; Maricopa County Air Quality Department and Pima County Department of Environmental Quality, </SJDOC>
                    <PGS>25377-25379</PGS>
                    <FRDOCBP>2020-08667</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Georgia: Air Quality Control, VOC Definition, </SJDOC>
                    <PGS>25379-25380</PGS>
                    <FRDOCBP>2020-08903</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Environmental Impact Statements; Availability, etc.:</SJ>
                <SJDENT>
                    <SJDOC>Weekly Receipt, </SJDOC>
                    <PGS>25434</PGS>
                    <FRDOCBP>2020-09275</FRDOCBP>
                </SJDENT>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>Science Advisory Board Economic Guidelines Review Panel, </SJDOC>
                    <PGS>25433-25434</PGS>
                    <FRDOCBP>2020-09286</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Aviation</EAR>
            <HD>Federal Aviation Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Amendment of VOR Federal Airways V-17, V-18, V-62, V-94, V-163, and V-568:</SJ>
                <SJDENT>
                    <SJDOC>Vicinity of Glen Rose, TX, </SJDOC>
                    <PGS>25283-25284</PGS>
                    <FRDOCBP>2020-09226</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Airworthiness Directives:</SJ>
                <SJDENT>
                    <SJDOC>Airbus SAS Airplanes, </SJDOC>
                    <PGS>25343-25346, 25354-25357</PGS>
                    <FRDOCBP>2020-09139</FRDOCBP>
                      
                    <FRDOCBP>2020-09140</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>AVOX System Inc. (formerly Scott Aviation) Oxygen Cylinder and Valve Assemblies; and Oxygen Valve Assemblies, </SJDOC>
                    <PGS>25351-25354</PGS>
                    <FRDOCBP>2020-09115</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>The Boeing Company Airplanes, </SJDOC>
                    <PGS>25346-25350</PGS>
                    <FRDOCBP>2020-09114</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Communications</EAR>
            <HD>Federal Communications Commission</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Commercial Operations in the 3550-3650 MHz Band; Promoting Investment in the 3550-3700 MHz Band, </DOC>
                    <PGS>25309-25313</PGS>
                    <FRDOCBP>2020-07582</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Petitions for Reconsideration of Action in Proceedings, </DOC>
                    <PGS>25380</PGS>
                    <FRDOCBP>2020-08721</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Emergency</EAR>
            <HD>Federal Emergency Management Agency</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Final Flood Hazard Determinations, </DOC>
                    <PGS>25456-25457</PGS>
                    <FRDOCBP>2020-09279</FRDOCBP>
                </DOCENT>
                <DOCENT>
                    <DOC>Flood Hazard Determinations; Proposals, </DOC>
                    <PGS>25457-25460</PGS>
                    <FRDOCBP>2020-09277</FRDOCBP>
                      
                    <FRDOCBP>2020-09280</FRDOCBP>
                </DOCENT>
                <SJ>Flood Hazard Determinations; Proposals:</SJ>
                <SJDENT>
                    <SJDOC>Fremont County, Iowa and Incorporated Areas; Withdrawal, </SJDOC>
                    <PGS>25457</PGS>
                    <FRDOCBP>2020-09276</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Energy</EAR>
            <HD>Federal Energy Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Application:</SJ>
                <SJDENT>
                    <SJDOC>Great River Hydro, LLC, </SJDOC>
                    <PGS>25431-25432</PGS>
                    <FRDOCBP>2020-09320</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Green Mountain Power Corp., </SJDOC>
                    <PGS>25430</PGS>
                    <FRDOCBP>2020-09319</FRDOCBP>
                </SJDENT>
                <DOCENT>
                    <DOC>Combined Filings, </DOC>
                    <PGS>25427-25429, 25431</PGS>
                    <FRDOCBP>2020-09312</FRDOCBP>
                      
                    <FRDOCBP>2020-09313</FRDOCBP>
                      
                    <FRDOCBP>2020-09318</FRDOCBP>
                </DOCENT>
                <SJ>Initial Market-Based Rate Filings Including Requests for Blanket Section 204 Authorizations:</SJ>
                <SJDENT>
                    <SJDOC>Inter-Power/AhlCon Partners, L.P., </SJDOC>
                    <PGS>25432-25433</PGS>
                    <FRDOCBP>2020-09316</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Little Bear Master Tenant, LLC, </SJDOC>
                    <PGS>25431</PGS>
                    <FRDOCBP>2020-09315</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Western Spirit Transmission, LLC, </SJDOC>
                    <PGS>25429</PGS>
                    <FRDOCBP>2020-09317</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Highway</EAR>
            <HD>Federal Highway Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Final Federal Agency Actions:</SJ>
                <SJDENT>
                    <SJDOC>Proposed Highway in Utah, </SJDOC>
                    <PGS>25502-25503</PGS>
                    <FRDOCBP>2020-09283</FRDOCBP>
                </SJDENT>
                <SJ>Record of Decision:</SJ>
                <SJDENT>
                    <SJDOC>Mountain View Corridor Project in Utah and Final Federal Agency Actions, </SJDOC>
                    <PGS>25503-25504</PGS>
                    <FRDOCBP>2020-09282</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Railroad</EAR>
            <HD>Federal Railroad Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Program Approval:</SJ>
                <SJDENT>
                    <SJDOC>Union Pacific Railroad, </SJDOC>
                    <PGS>25504-25505</PGS>
                    <FRDOCBP>2020-09281</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Federal Reserve</EAR>
            <HD>Federal Reserve System</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>25434-25437</PGS>
                    <FRDOCBP>2020-09342</FRDOCBP>
                </DOCENT>
                <SJ>Change in Bank Control:</SJ>
                <SJDENT>
                    <SJDOC>Acquisitions of Shares of a Bank or Bank Holding Company, </SJDOC>
                    <PGS>25434</PGS>
                    <FRDOCBP>2020-09347</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Fish</EAR>
            <HD>Fish and Wildlife Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Application for an Incidental Take Permit:</SJ>
                <SJDENT>
                    <SJDOC>Low-Effect Habitat Conservation Plan for the Four Corners Water Development Project, Pueblo of Santa Clara, Rio Arriba County, NM, </SJDOC>
                    <PGS>25469-25470</PGS>
                    <FRDOCBP>2020-09262</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Health and Human</EAR>
            <HD>Health and Human Services Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Centers for Disease Control and Prevention</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Centers for Medicare &amp; Medicaid Services</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Health Resources and Services Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>National Institutes of Health</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Substance Abuse and Mental Health Services Administration</P>
            </SEE>
            <CAT>
                <HD>RULES</HD>
                <SJ>21st Century Cures Act:</SJ>
                <SJDENT>
                    <SJDOC>Interoperability, Information Blocking, and the ONC Health IT Certification Program, </SJDOC>
                    <PGS>25639</PGS>
                    <FRDOCBP>2020-07419</FRDOCBP>
                </SJDENT>
                <SJ>Medicare and Medicaid Programs:</SJ>
                <SJDENT>
                    <SJDOC>Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-facilitated Exchanges, and Health Care Providers, </SJDOC>
                    <PGS>25508-25638</PGS>
                    <FRDOCBP>2020-05050</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Health Resources</EAR>
            <HD>Health Resources and Services Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Bureau of Health Workforce Substance Use Disorder Evaluation, </SJDOC>
                    <PGS>25451-25452</PGS>
                    <FRDOCBP>2020-09254</FRDOCBP>
                </SJDENT>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>National Advisory Council on the National Health Service Corps, </SJDOC>
                    <PGS>25452-25453</PGS>
                    <FRDOCBP>2020-09264</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Homeland</EAR>
            <HD>Homeland Security Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Emergency Management Agency</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Transportation Security Administration</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agreement Between the Government of the United States of America and the Government of the Republic of Honduras for Cooperation in the Examination of Protection Claims, </DOC>
                    <PGS>25460-25466</PGS>
                    <FRDOCBP>2020-09322</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Housing</EAR>
            <HD>Housing and Urban Development Department</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Family Unification Program/Family Self-Sufficiency Demonstration Evaluation, </SJDOC>
                    <PGS>25468-25469</PGS>
                    <FRDOCBP>2020-09321</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>
                Interior
                <PRTPAGE P="v"/>
            </EAR>
            <HD>Interior Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Fish and Wildlife Service</P>
            </SEE>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>National Environmental Policy Act Implementing Procedures for the Bureau of Land Management, </DOC>
                    <PGS>25470-25473</PGS>
                    <FRDOCBP>2020-09301</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Internal Revenue</EAR>
            <HD>Internal Revenue Service</HD>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <DOCENT>
                    <DOC>Guidance Related to the Allocation and Apportionment of Deductions and Foreign Taxes, Financial Services Income, Foreign Tax Redeterminations, Foreign Tax Credit Disallowance Under Section 965(g), and Consolidated Groups; Hearing, </DOC>
                    <PGS>25376</PGS>
                    <FRDOCBP>2020-08842</FRDOCBP>
                </DOCENT>
            </CAT>
        </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>Advance Notification of Sunset Review, </SJDOC>
                    <PGS>25392</PGS>
                    <FRDOCBP>2020-09329</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Certain Quartz Surface Products from India, </SJDOC>
                    <PGS>25396-25398</PGS>
                    <FRDOCBP>2020-09409</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Certain Quartz Surface Products from the Republic of Turkey, </SJDOC>
                    <PGS>25398-25400</PGS>
                    <FRDOCBP>2020-09408</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Initiation of Five-Year (Sunset) Reviews, </SJDOC>
                    <PGS>25384-25386</PGS>
                    <FRDOCBP>2020-09330</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Opportunity to Request Administrative Review, </SJDOC>
                    <PGS>25392-25395</PGS>
                    <FRDOCBP>2020-09331</FRDOCBP>
                </SJDENT>
                <SJ>Determination of Sales at Less Than Fair Value:</SJ>
                <SJDENT>
                    <SJDOC>Certain Quartz Surface Products from India, </SJDOC>
                    <PGS>25389-25392</PGS>
                    <FRDOCBP>2020-09407</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Certain Quartz Surface Products from the Republic of Turkey, </SJDOC>
                    <PGS>25387-25389</PGS>
                    <FRDOCBP>2020-09328</FRDOCBP>
                </SJDENT>
                <SJ>Request for Panel Review:</SJ>
                <SJDENT>
                    <SJDOC>Binational Panel Review, </SJDOC>
                    <PGS>25386-25387</PGS>
                    <FRDOCBP>2020-09314</FRDOCBP>
                      
                    <FRDOCBP>2020-09341</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>Citric Acid and Certain Citrate Salts from Canada and China, </SJDOC>
                    <PGS>25473-25475</PGS>
                    <FRDOCBP>2020-09288</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Maritime</EAR>
            <HD>Maritime Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Deepwater Port License Application:</SJ>
                <SJDENT>
                    <SJDOC>SPOT Terminal Services LLC; Correction and Comment Period Extension, </SJDOC>
                    <PGS>25505-25506</PGS>
                    <FRDOCBP>2020-09302</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Agricultural</EAR>
            <HD>National Agricultural Statistics Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>25383-25384</PGS>
                    <FRDOCBP>2020-09272</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Institute</EAR>
            <HD>National Institutes of Health</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>Center for Scientific Review, </SJDOC>
                    <PGS>25453-25454</PGS>
                    <FRDOCBP>2020-09307</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Human Genome Research Institute, </SJDOC>
                    <PGS>25453</PGS>
                    <FRDOCBP>2020-09308</FRDOCBP>
                      
                    <FRDOCBP>2020-09309</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>National Institute of Allergy and Infectious Diseases, </SJDOC>
                    <PGS>25454</PGS>
                    <FRDOCBP>2020-09310</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Oceanic</EAR>
            <HD>National Oceanic and Atmospheric Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>Pacific Halibut Fisheries:</SJ>
                <SJDENT>
                    <SJDOC>Catch Sharing Plan, </SJDOC>
                    <PGS>25315-25323</PGS>
                    <FRDOCBP>2020-09231</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>PROPOSED RULES</HD>
                <SJ>Proposed Expansion:</SJ>
                <SJDENT>
                    <SJDOC>Flower Garden Banks National Marine Sanctuary, </SJDOC>
                    <PGS>25357-25376</PGS>
                    <FRDOCBP>2020-08128</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>25400-25401</PGS>
                    <FRDOCBP>2020-09351</FRDOCBP>
                </DOCENT>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>North Pacific Fishery Management Council, </SJDOC>
                    <PGS>25401-25402</PGS>
                    <FRDOCBP>2020-09383</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Ocean Exploration Advisory Board, </SJDOC>
                    <PGS>25401</PGS>
                    <FRDOCBP>2020-09270</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>National Science</EAR>
            <HD>National Science Foundation</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Meetings:</SJ>
                <SJDENT>
                    <SJDOC>Advisory Committee for Computer and Information Science and Engineering, </SJDOC>
                    <PGS>25475-25476</PGS>
                    <FRDOCBP>2020-09333</FRDOCBP>
                </SJDENT>
            </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>Manual License Verification Report/License Verification System, </SJDOC>
                    <PGS>25477-25478</PGS>
                    <FRDOCBP>2020-09325</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Occupational Dose Record for a Monitoring Period, </SJDOC>
                    <PGS>25476-25477</PGS>
                    <FRDOCBP>2020-09323</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Report of Proposed Activities in Non-Agreement States, Areas of Exclusive Federal Jurisdiction, or Offshore Waters, </SJDOC>
                    <PGS>25478-25479</PGS>
                    <FRDOCBP>2020-09324</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Postal Regulatory</EAR>
            <HD>Postal Regulatory Commission</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>New Postal Product, </DOC>
                    <PGS>25479</PGS>
                    <FRDOCBP>2020-09339</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Postal Service</EAR>
            <HD>Postal Service</HD>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>25479-25480</PGS>
                    <FRDOCBP>2020-09402</FRDOCBP>
                </DOCENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Presidential Documents</EAR>
            <HD>Presidential Documents</HD>
            <CAT>
                <HD>EXECUTIVE ORDERS</HD>
                <SJ>Committees; Establishment, Renewal, Termination, etc.:</SJ>
                <SJDENT>
                    <SJDOC>United States-Mexico-Canada Agreement Implementation Act, Interagency Labor Committee for Monitoring and Enforcement Under Section 711; Establishment (EO 13918), </SJDOC>
                    <PGS>26313-26314</PGS>
                    <FRDOCBP>2020-09537</FRDOCBP>
                </SJDENT>
                <SJ>Defense and National Security:</SJ>
                <SJDENT>
                    <SJDOC>Defense Production Act of 1950; Delegation of Authority Respecting Food Supply Chain Resources During National Emergency Caused by COVID-19 Outbreak (EO 13917), </SJDOC>
                    <PGS>26309-26312</PGS>
                    <FRDOCBP>2020-09536</FRDOCBP>
                </SJDENT>
            </CAT>
            <CAT>
                <HD>ADMINISTRATIVE ORDERS</HD>
                <SJ>Health and Human Services:</SJ>
                <SJDENT>
                    <SJDOC>COVID-19 Response and Economic Recovery Facilitation in North Dakota; Federal Support for Governors' Use of National Guard (Memorandum of April 28, 2020), </SJDOC>
                    <PGS>26315-26316</PGS>
                    <FRDOCBP>2020-09540</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Securities</EAR>
            <HD>Securities and Exchange Commission</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Updated Disclosure Requirements and Summary Prospectus for Variable Annuity and Variable Life Insurance Contracts, </DOC>
                    <PGS>25962-26307</PGS>
                    <FRDOCBP>2020-05526</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <DOCENT>
                    <DOC>Agency Information Collection Activities; Proposals, Submissions, and Approvals, </DOC>
                    <PGS>25483-25485, 25487-25488, 25494-25495, 25497-25498, 25501</PGS>
                    <FRDOCBP>2020-09293</FRDOCBP>
                      
                    <FRDOCBP>2020-09294</FRDOCBP>
                      
                    <FRDOCBP>2020-09295</FRDOCBP>
                      
                    <FRDOCBP>2020-09297</FRDOCBP>
                      
                    <FRDOCBP>2020-09299</FRDOCBP>
                      
                    <FRDOCBP>2020-09300</FRDOCBP>
                      
                    <FRDOCBP>2020-09290</FRDOCBP>
                      
                    <FRDOCBP>2020-09291</FRDOCBP>
                </DOCENT>
                <DOCENT>
                    <DOC>Meetings; Sunshine Act, </DOC>
                    <PGS>25497</PGS>
                    <FRDOCBP>2020-09449</FRDOCBP>
                </DOCENT>
                <SJ>Self-Regulatory Organizations; Proposed Rule Changes:</SJ>
                <SJDENT>
                    <SJDOC>Cboe BZX Exchange, Inc., </SJDOC>
                    <PGS>25488-25491</PGS>
                    <FRDOCBP>2020-09248</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>Nasdaq PHLX, LLC, </SJDOC>
                    <PGS>25498-25501</PGS>
                    <FRDOCBP>2020-09249</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>New York Stock Exchange, LLC, </SJDOC>
                    <PGS>25485-25487</PGS>
                    <FRDOCBP>2020-09250</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>NYSE American, LLC, </SJDOC>
                    <PGS>25480-25483, 25495-25497</PGS>
                    <FRDOCBP>2020-09252</FRDOCBP>
                      
                    <FRDOCBP>2020-09253</FRDOCBP>
                </SJDENT>
                <SJDENT>
                    <SJDOC>NYSE Arca, Inc., </SJDOC>
                    <PGS>25491-25494</PGS>
                    <FRDOCBP>2020-09251</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>
                Small Business
                <PRTPAGE P="vi"/>
            </EAR>
            <HD>Small Business Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Major Disaster Declaration:</SJ>
                <SJDENT>
                    <SJDOC>North Dakota, </SJDOC>
                    <PGS>25501-25502</PGS>
                    <FRDOCBP>2020-09340</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>State Department</EAR>
            <HD>State Department</HD>
            <CAT>
                <HD>RULES</HD>
                <SJ>International Traffic in Arms Regulations:</SJ>
                <SJDENT>
                    <SJDOC>Temporary Suspension, Modification, or Exception to Regulations, </SJDOC>
                    <PGS>25285</PGS>
                    <FRDOCBP>2020-08839</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Substance</EAR>
            <HD>Substance Abuse and Mental Health Services Administration</HD>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Certified Laboratories and Instrumented Initial Testing Facilities:</SJ>
                <SJDENT>
                    <SJDOC>List of Facilities that Meet Minimum Standards to Engage in Urine and Oral Fluid Drug Testing for Federal Agencies, </SJDOC>
                    <PGS>25454-25455</PGS>
                    <FRDOCBP>2020-09296</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Transportation Department</EAR>
            <HD>Transportation Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Aviation Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Highway Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Federal Railroad Administration</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Maritime Administration</P>
            </SEE>
        </AGCY>
        <AGCY>
            <EAR>Security</EAR>
            <HD>Transportation Security Administration</HD>
            <CAT>
                <HD>RULES</HD>
                <DOCENT>
                    <DOC>Security Training for Surface Transportation Employees, </DOC>
                    <PGS>25313-25315</PGS>
                    <FRDOCBP>2020-08528</FRDOCBP>
                </DOCENT>
            </CAT>
            <CAT>
                <HD>NOTICES</HD>
                <SJ>Agency Information Collection Activities; Proposals, Submissions, and Approvals:</SJ>
                <SJDENT>
                    <SJDOC>Security Appointment Center Visitor Request Form and Foreign National Vetting Request, </SJDOC>
                    <PGS>25467-25468</PGS>
                    <FRDOCBP>2020-09349</FRDOCBP>
                </SJDENT>
                <SJ>Request for Applicants:</SJ>
                <SJDENT>
                    <SJDOC>Aviation Security Advisory Committee, </SJDOC>
                    <PGS>25466-25467</PGS>
                    <FRDOCBP>2020-09304</FRDOCBP>
                </SJDENT>
            </CAT>
        </AGCY>
        <AGCY>
            <EAR>Treasury</EAR>
            <HD>Treasury Department</HD>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Bureau of the Fiscal Service</P>
            </SEE>
            <SEE>
                <HD SOURCE="HED">See</HD>
                <P>Internal Revenue Service</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>Status of Loan Account—Foreclosure or Other Liquidation, </SJDOC>
                    <PGS>25506</PGS>
                    <FRDOCBP>2020-09334</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, Centers for Medicare &amp; Medicaid Services, </DOC>
                <PGS>25508-25638</PGS>
                <FRDOCBP>2020-05050</FRDOCBP>
            </DOCENT>
            <DOCENT>
                <DOC>Health and Human Services Department, </DOC>
                <PGS>25508-25638</PGS>
                <FRDOCBP>2020-05050</FRDOCBP>
            </DOCENT>
            <HD>Part III</HD>
            <DOCENT>
                <DOC>Health and Human Services Department, </DOC>
                <PGS>25639</PGS>
                <FRDOCBP>2020-07419</FRDOCBP>
            </DOCENT>
            <HD>Part IV</HD>
            <DOCENT>
                <DOC>Securities and Exchange Commission, </DOC>
                <PGS>25962-26307</PGS>
                <FRDOCBP>2020-05526</FRDOCBP>
            </DOCENT>
            <HD>Part V</HD>
            <DOCENT>
                <DOC>Presidential Documents, </DOC>
                <PGS>26309-26316</PGS>
                <FRDOCBP>2020-09537</FRDOCBP>
                  
                <FRDOCBP>2020-09536</FRDOCBP>
                  
                <FRDOCBP>2020-09540</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>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <RULES>
        <RULE>
            <PREAMB>
                <PRTPAGE P="25281"/>
                <AGENCY TYPE="F">BUREAU OF CONSUMER FINANCIAL PROTECTION</AGENCY>
                <CFR>12 CFR Part 1024</CFR>
                <SUBJECT>Bulletin 2020-02—Compliance Bulletin and Policy Guidance: Handling of Information and Documents During Mortgage Servicing Transfers</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Bureau of Consumer Financial Protection.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Compliance bulletin and policy guidance.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Bureau of Consumer Financial Protection (Bureau) is issuing a compliance bulletin and policy guidance (Bulletin) entitled, “Compliance Bulletin and Policy Guidance: Handling of Information and Documents During Mortgage Servicing Transfers.” The purpose of the policy statement is to provide guidance to residential mortgage servicers regarding the transfer of mortgage loans, including examples of practices that the Bureau may consider as contributing to policies and procedures that are reasonably designed to achieve the objectives of the regulatory requirements.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This Bulletin is applicable on May 1, 2020.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Eric Lum, Analyst, Office of Supervision Policy, at 202-435-9783 or Allison I. Brown, Deputy Assistant Director, Office of Supervision Policy, at 202-435-7107. If you require this document in an alternative electronic format, please contact 
                        <E T="03">CFPB_Accessibility@cfpb.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Introduction</HD>
                <P>The Bureau of Consumer Financial Protection (Bureau) is issuing this Bulletin to residential mortgage servicers and subservicers (collectively, servicers), in light of potential risks to consumers that may arise in connection with transfers of residential mortgage servicing rights. This bulletin covers: (A) Transfer-related policies and procedures, and (B) loan information and documents for ensuring accuracy.</P>
                <HD SOURCE="HD1">II. Compliance Bulletin and Policy Guidance</HD>
                <HD SOURCE="HD2">A. Background</HD>
                <P>A mortgage servicer, among other things, collects and processes loan payments on behalf of the owner of the mortgage note, conducts escrow related processes and handles loss mitigation as appropriate. Servicing transfers are common and may occur in several ways. The mortgage owner may sell the rights to service the loan, called the Mortgage Servicing Rights (MSR), separately from the note ownership. The owner of the loan or MSR may, rather than servicing the loan itself, hire a vendor-typically called a subservicer-to take on the servicing duties or aspects of such servicing. MSR owners frequently sell MSR outright as an asset. Servicing transfers may also occur through whole loan servicing transfers or whole loan portfolio transfers, rather than through sales of MSR. In this document, we use the term “transfer” broadly to cover transfers of servicing rights as well as transfers of servicing responsibilities, in total or in part, through subservicing or whole loan servicing arrangements. The term “transferor” servicer means a servicer who transfers or will transfer the right to perform servicing functions pursuant to an agreement or understanding. The term “transferee” servicer means a servicer who obtains or who will obtain the right to perform servicing functions pursuant to an agreement or understanding.</P>
                <P>
                    As consumers do not have a choice with respect to the transfer of servicing, seamless and accurate transfers are important to prevent consumer harm. In 2014, the Bureau issued CFPB Bulletin 2014-01.
                    <SU>1</SU>
                    <FTREF/>
                     The Bulletin discussed the servicing transfer requirements in the Regulation X mortgage servicing rules.
                    <SU>2</SU>
                    <FTREF/>
                     The Bulletin also addressed frequently asked questions, the focus areas for Bureau examinations, and the other Federal consumer financial laws applicable to servicing transfers.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Bulletin 2014-01 was published in the 
                        <E T="04">Federal Register</E>
                         as 
                        <E T="03">Compliance Bulletin and Policy Guidance—Mortgage Servicing Transfers,</E>
                         79 FR 63295 (Oct. 29, 2014). Bulletin 2014-01 replaced the earlier Bulletin 2013-01 (Mortgage Servicing Transfers), released in February 2013, which addressed servicing transfers before the effective date of 12 CFR 1024.38(a), (b)(4).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         12 CFR 1024.38(a), (b)(4).
                    </P>
                </FTNT>
                <P>
                    In supervisory examinations conducted since 2014, the Bureau has continued to find weaknesses in compliance management systems and violations of Regulation X related to mortgage servicing transfers.
                    <SU>3</SU>
                    <FTREF/>
                     Specifically, the Bureau has seen inadequacies in servicers' policies and procedures for transferring all the loan information and documents to the new servicer in a timely and accurate manner. It is also important that servicing functions continue on an uninterrupted basis during servicing transfers-such as the payment of taxes and insurance from escrow accounts or continuing to exercise reasonable diligence in obtaining documents and information to complete a loss mitigation application. Recent economic conditions and structural changes to the mortgage servicing market, including the growth of nonbank servicers that are not subject to the same capital standards as banks, contribute to these risks.
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         In addition to the requirements discussed in this bulletin, State laws and regulations may impose additional requirements applicable to servicers.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         Kim, You Suk, Steven M. Laufer, Karen Pence, Richard Stanton, and Nancy Wallace. 2018. “Liquidity Crises in the Mortgage Market.” BPEA Conference Draft, Spring, and Goodman, Laurie, and Karan Kaul. 2016. “Nonbank Servicer Regulation: New Capital and Liquidity Requirements Don't Offer Enough Loss Protection” Urban Institute Brief.
                    </P>
                </FTNT>
                <P>
                    Taking into consideration the coronavirus pandemic that led to the President's declaration of a national emergency on March 13, 2020 (National Emergency), and the economic and social dislocations caused by the pandemic, for the duration of the National Emergency and for 120 days thereafter, if a servicing transfer is requested or required by a Federal regulator or by the security issuer of “Government Loans” (as defined in the CARES Act), the Bureau intends, for activity during this period, to consider the challenges that entities may face as a result, including operational and time constraints related to the transfer, and to be sensitive to good-faith efforts demonstrably designed to transfer the servicing without adverse impact to consumers. The Bureau intends to focus supervisory feedback for institutions, if needed, on identifying issues, correcting deficiencies, and ensuring appropriate remediation to consumers.
                    <PRTPAGE P="25282"/>
                </P>
                <HD SOURCE="HD2">B. General Transfer-Related Policies and Procedures</HD>
                <P>
                    In its supervisory examinations, the Bureau reviews mortgage servicers for compliance with Regulation X servicing transfer requirements, which among other things, require servicers to maintain certain policies and procedures related to facilitating the transfer of information during mortgage servicing transfers.
                    <SU>5</SU>
                    <FTREF/>
                     Specifically, Regulation X requires transferor servicers to maintain policies and procedures that are reasonably designed to achieve the objective of the timely transfer of all information and documents in the possession or control of the servicer relating to a transferred mortgage loan to a transferee servicer in a form and manner that ensures the accuracy of the information and documents transferred and that enables a transferee servicer to comply with the terms of the transferee servicer's obligations to the owner or assignee of the mortgage loan and applicable law.
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         “Small servicers” as defined in Regulation Z, 12 CFR 1026.41(e)(4), do not have to comply with the policies and procedures requirements described in this Bulletin. Regulation X, 12 CFR 1024.30(b)(1).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         12 CFR 1024.38(b)(4)(i). 12 CFR 1024.38(b)(4) does not prescribe any specific policies or procedures that a servicer must implement; the rule says that the policies and procedures must be “reasonably designed” to achieve the goal of facilitating the transfer of information during servicing transfers. The Bureau will consider a servicer's transfer-related policies and procedures as a whole, in light of the servicer's particular facts and circumstances, in determining whether they are reasonably designed to achieve the rule's objectives. Title 12 CFR part 1024, Supplement I, Comment 38(a)-1 also states that a servicer may determine the specific policies and procedures it will adopt and the methods by which it will implement those policies and procedures so long as they are reasonably designed to achieve the objectives set forth in § 1024.38(b). And a servicer has flexibility to determine such policies and procedures and methods in light of the size, nature, and scope of the servicer's operations, including, for example, the volume and aggregate unpaid principal balance of mortgage loans serviced, the credit quality, including the default risk, of the mortgage loans serviced, and the servicer's history of consumer complaints.
                    </P>
                </FTNT>
                <P>
                    Regulation X also requires transferee servicers to maintain policies and procedures that are reasonably designed to ensure that the servicer can identify necessary documents or information that may not have been transferred by a transferor servicer and obtain such documents from the transferor servicer.
                    <SU>7</SU>
                    <FTREF/>
                     The following are examples of servicer practices that the Bureau may consider as contributing to policies and procedures that are reasonably designed to achieve the objectives of these transfer requirements:
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         12 CFR 1024.38(b)(4)(ii).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Planning and Pre-Transfer Testing</HD>
                <P>• For each transfer of mortgage servicing that occurs, developing a servicing transfer plan that includes a communications plan, testing plan (for system conversion), a timeline with key milestones and an escalation plan for potential problems.</P>
                <P>• Conducting meetings to discuss and clarify issues with counterparties in a timely manner; for large transfers, this could occur months in advance of the transfer for the purposes of developing transfer plans and the obligations of all involved parties, including service providers and investors.</P>
                <P>• Recognizing if the transfer cannot be implemented successfully in a single batch of all accounts and implementing alternative protocols, such as splitting the transfer into several smaller bundles of accounts to be transferred in subsequent months to ensure that the transferee can comply with its servicing obligations for every loan transferred.</P>
                <P>• Determining servicing responsibilities for legacy accounts including tax reporting, credit bureau reporting and other questions that may arise.</P>
                <P>• Using tailored testing protocols to evaluate the compatibility of the transferred data with the transferee servicer's systems and data mapping protocols.</P>
                <P>• Proactively identifying material issues that potentially impact the accuracy or completeness of the loan data or documentation to be transferred as well as each servicer's ability to comply with the law or investor guidelines with respect to the transferred loans.</P>
                <P>• Identifying any loans in default, active foreclosure and bankruptcy. Where applicable, include documentation regarding loss mitigation activity for each loan, including status and notes pertaining to the loss mitigation action, copies of agreements entered into with a borrower on a loss mitigation option, and any analysis by a servicer with respect to potential recovery from a non-performing mortgage loan.</P>
                <P>• Engaging in quality control work after a transfer of preliminary data to validate that the data on the transferee's system matches the data submitted by the transferor. Prioritizing data mapping errors that occurred during de-boarding or on-boarding process for resolution.</P>
                <HD SOURCE="HD3">Post-Transfer Monitoring</HD>
                <P>• Conducting a post-transfer review or de-brief to determine effectiveness of the transfer plan and whether any gaps have arisen that require resolution.</P>
                <P>• Monitoring consumer complaints and loss mitigation performance metrics including borrower engagement rate, approvals of trial modifications, repayment plans, non-home retention options, and completed workouts for at least four to six months post-transfer. Also monitoring for delinquencies, foreclosures and bankruptcies to detect trends, including for month-to-month increases after transfer.</P>
                <P>
                    As the composition and complexity of servicer portfolios vary, servicers may not need to implement all the example policies and procedures listed above in order to meet the objectives outlined in Regulation X. However, the Bureau emphasizes the importance of post-transfer monitoring to ensure that transferred data is complete, accurate and functional for the transferee. For example, the Bureau found at least one servicer that did not engage in adequate post-transfer validation with its transferee, which contributed to its failure to identify that it had not transmitted all the loss mitigation documents in its possession. Only after a borrower complained to the transferee did either servicer become aware that the transferor failed to send an executed loan modification agreement to the transferee.
                    <SU>8</SU>
                    <FTREF/>
                     Generally, transferees must have policies and procedures reasonably designed to ensure, in connection with a servicing transfer, that the transferee receives copies of any loss mitigation applications and agreements, finds out about the status of any prior discussions with borrowers, and retrieves missing loss mitigation documents and information from the transferor servicer before asking the borrower for such information.
                    <SU>9</SU>
                    <FTREF/>
                     These obligations apply to any accounts for which the servicer's determination of the borrower's eligibility for loss mitigation is in process, including any short-term payment forbearance program or a short-term repayment plan that the servicer may offer based on an evaluation of an incomplete loss mitigation application.
                    <SU>10</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         The Bureau published supervisory findings related to mortgage servicing transfers in the June 2016 edition of 
                        <E T="03">Supervisory Highlights,</E>
                         available here: 
                        <E T="03">https://files.consumerfinance.gov/f/documents/Mortgage_Servicing_Supervisory_Highlights_11_Final_web_.pdf.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         Comment 38(b)(4)(ii)-1.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         
                        <E T="03">See</E>
                         12 CFR 1024.41(c)(2)(iii) (describing requirements for servicers offering certain short-term loss mitigation options based on an evaluation of an incomplete loss mitigation application); 
                        <E T="03">see also</E>
                         comments 41(b)(1)-4.iii and 41(c)(2)(iii).
                    </P>
                </FTNT>
                <P>
                    The Bureau also emphasizes the importance of maintaining the transferred data after receipt. Under Regulation X, servicers must maintain certain documents and data on each 
                    <PRTPAGE P="25283"/>
                    mortgage loan account serviced by the servicer in a manner that facilitates compiling such documents and data into a servicing file within five days.
                    <SU>11</SU>
                    <FTREF/>
                     A servicing file includes, among other things, a schedule of all transactions credited or debited to the mortgage loan account (including to any escrow or suspense account), a copy of the security instrument, copies of any loan modifications, any notes created by servicer personnel reflecting communications with the borrower about the mortgage loan account, and to the extent applicable, a report of the data fields relating to the borrower's mortgage loan account.
                    <SU>12</SU>
                    <FTREF/>
                     Transferors must also retain records that document actions taken with respect to a borrower's mortgage loan account until one year after the date a mortgage loan is discharged or servicing of a mortgage loan is transferred by the servicer to a transferee servicer.
                    <SU>13</SU>
                    <FTREF/>
                     The Bureau encourages servicers to adopt strong policies and procedures for maintaining documents and information received in a transfer as part of an overall compliance program.
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         12 CFR 1024.38(c)(2).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         12 CFR 1024.38(c)(2)(i) through (v).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         12 CFR 1024.38(c)(1).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Loan Information and Documents To Be Transferred or Received</HD>
                <P>Regulation X requires transferor servicers to maintain policies and procedures that are reasonably designed to achieve the objectives of timely transferring all information and documents in the possession or control of the servicer relating to a transferred mortgage loan to a transferee servicer in a form and manner that:</P>
                <P>• Ensures the accuracy of the information and documents transferred, and</P>
                <P>
                    • Enables a transferee servicer to comply with the terms of the transferee servicer's obligations to the owner or assignee of the mortgage loan and applicable law.
                    <SU>14</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         12 CFR 1024.38(b)(4)(i).
                    </P>
                </FTNT>
                <P>Use of a uniform data standard like the Mortgage Industry Standards Maintenance Organization (MISMO) standard would increase data compatibility and strengthen compliance across the servicing industry by fostering more consistency in the data fields used by servicers. The Bureau encourages servicers to adopt a common data standard and data dictionary to facilitate these goals.</P>
                <P>Other practices that could contribute to compliance include having contracts that require transferors to provide all the necessary information and documents at loan boarding to a transferee servicer's systems. Necessary information and documents could include foundational information for servicing the loan, but not limited to, a unique identifier for each loan, the terms of the loan (including the rate and term), current unpaid principal balance (UPB) as of a specific date, information concerning any escrow accounts (including balances, distribution history, and future obligations), payment histories, the terms of any loss mitigation that was offered to a borrower under which the borrower is performing, and any other modifications or other information needed to adequately service the loan.</P>
                <P>
                    Certain information and documents present heightened compliance risk. For example, failure to transfer private mortgage insurance cancellation and mid-point dates may contribute to violations of the Homeowners Protection Act.
                    <SU>15</SU>
                    <FTREF/>
                     Likewise, loss mitigation-related documents, including incomplete applications and executed modification agreements are critical for compliance. Regulation X requires transferor servicers to maintain policies and procedures with respect to the transfer of any information reflecting the current status of discussions with a borrower regarding loss mitigation options, any agreements entered into with a borrower on a loss mitigation option, and any analysis done with respect to potential recovery from a non-performing mortgage loan, as appropriate.
                    <SU>16</SU>
                    <FTREF/>
                     Because borrowers may continue to provide loss mitigation-related documents and information to the transferor servicer after their loans have transferred, transferors must work with transferees to ensure that the new information and documents are transferred and that borrowers are not adversely affected.
                    <SU>17</SU>
                    <FTREF/>
                     A borrower that submits a facially complete or complete application to the transferor servicer after the transfer date has the same rights and protections that would have applied if the borrower had submitted the complete application to the transferee servicer.
                    <SU>18</SU>
                    <FTREF/>
                     An application that was facially complete under § 1024.41(c)(2)(iv) with respect to the transferor servicer remains facially complete under the transferee servicer as of the date it was facially complete with respect to the transferor servicer. And if an application was complete with respect to the transferor servicer, but is not complete with respect to the transferee servicer, the transferee servicer must treat the application as facially complete as of the date the application was complete with respect to the transferor servicer.
                    <SU>19</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         
                        <E T="03">See</E>
                         CFPB Bulletin 2015-03. “Compliance Bulletin: Private Mortgage Insurance Cancellation and Termination”.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         Comment 38(b)(4)(i)-2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         
                        <E T="03">See</E>
                         Amendments to the 2013 Mortgage Rules Under the Real Estate Settlement Procedures Act (Regulation X) and the Truth in Lending Act (Regulation Z), 81 FR 72160, 72273-76 (Oct. 19, 2016); comments 38(b)(4)(i)-2 and 41(k)(1)(i)-1.iii.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         
                        <E T="03">See</E>
                         12 CFR 1024.41(k)(1)(i); Comment 41(k)(1)(i)-2.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         Comment 41(k)(1)(i)-2.
                    </P>
                </FTNT>
                <P>Appendix A provides examples of information and documents grouped by subject area which the Bureau intends to use to assess compliance with Regulation X. The appendix is provided as a guide and focuses on common data elements essential to the servicing of mortgage loans. Servicers may use the appendix to assess the baseline appropriateness of their transfer-related policies and procedures. Some listed documents and information may be not applicable to certain loans. Other loans may require documents and information not listed in Appendix A. The overall composition and complexity of a servicer's portfolio is important in determining whether its policies and procedures meet the objectives outlined in Regulation X. For example, servicers with very few adjustable rate mortgages might have relatively simple policies and procedures for ensuring documents and information related to interest rate adjustments are timely transferred and accounted for. And servicers with large default portfolios might have robust policies and procedures for ensuring that loss mitigation documents and information pertaining to defaulted accounts are timely transferred.</P>
                <HD SOURCE="HD3">Regulatory Requirements</HD>
                <P>
                    This Bulletin is a non-binding general statement of policy articulating considerations relevant to the Bureau's exercise of its supervisory authority under Regulation X and RESPA and reciting certain requirements of Regulation X and other Federal consumer financial laws applicable to servicing transfers. It is therefore exempt from the notice and comment rulemaking requirements under the Administrative Procedure Act pursuant to 5 U.S.C. 553(b).
                    <SU>20</SU>
                    <FTREF/>
                     Because no notice of proposed rulemaking is required, the Regulatory Flexibility Act does not require an initial or final regulatory flexibility analysis. 5 U.S.C. 603(a), 604(a). The Bureau has determined that this Bulletin does not impose any new or revise any existing recordkeeping, reporting, or disclosure requirements on 
                    <PRTPAGE P="25284"/>
                    covered entities or members of the public that would be collections of information requiring OMB approval under the Paperwork Reduction Act, 44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         However, this is not a “statement of policy” as that term is specifically used in Regulation X, 12 CFR 1024.4(a)(1)(ii).
                    </P>
                </FTNT>
                <P>
                    Pursuant to the Congressional Review Act, 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     the Bureau will submit a report containing this Bulletin and other required information to the United States Senate, the United States House of Representatives, and the Comptroller General of the United States prior to its applicability date. The Office of Information and Regulatory Affairs has designated this Bulletin as not a “major rule” as defined by 5 U.S.C. 804(2).
                </P>
                <HD SOURCE="HD1">
                    Appendix A—Examples of Information and Data To Be Transferred or Received 
                    <E T="0731">21</E>
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         This is not an exhaustive list of documents and information that may be necessary for the transfer.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Foundational Loan Information</HD>
                <FP SOURCE="FP-2">• Name and version of servicing systems of record for each product type serviced</FP>
                <FP SOURCE="FP-2">• Loan number and MIN</FP>
                <FP SOURCE="FP-2">• Principal balance</FP>
                <FP SOURCE="FP1-2">○ Original principal balance</FP>
                <FP SOURCE="FP1-2">○ Modified principal balance</FP>
                <FP SOURCE="FP-2">• Periodic payment due</FP>
                <FP SOURCE="FP1-2">○ Amount of interest due</FP>
                <FP SOURCE="FP1-2">○ Amount of principal due</FP>
                <FP SOURCE="FP1-2">○ Next payment due date</FP>
                <FP SOURCE="FP1-2">○ Amount of any overdue payment</FP>
                <FP SOURCE="FP-2">• Amount of any principal prepayments</FP>
                <FP SOURCE="FP-2">• Amount of funds in suspense account</FP>
                <FP SOURCE="FP-2">• Balloon payment data</FP>
                <FP SOURCE="FP-2">• Origination date</FP>
                <FP SOURCE="FP-2">• Property address</FP>
                <FP SOURCE="FP-2">• Borrower mailing address</FP>
                <FP SOURCE="FP-2">• Name of originator, NMLS ID if available</FP>
                <FP SOURCE="FP-2">• Original loan to value</FP>
                <FP SOURCE="FP-2">• Purchase loan/refinance</FP>
                <FP SOURCE="FP-2">• Loan term</FP>
                <FP SOURCE="FP-2">• Maturity date</FP>
                <FP SOURCE="FP-2">• Successor-in-interest</FP>
                <FP SOURCE="FP1-2">○ If yes</FP>
                <FP SOURCE="FP1-2">○ Address and identity</FP>
                <FP SOURCE="FP1-2">○ Confirmed?</FP>
                <FP SOURCE="FP-2">
                    • Occupancy code (
                    <E T="03">i.e.</E>
                     primary residence, second home, investment property)
                </FP>
                <FP SOURCE="FP-2">• Interest rate</FP>
                <FP SOURCE="FP-2">
                    • Interest calculation method (
                    <E T="03">i.e.</E>
                     30/360, DSI)
                </FP>
                <FP SOURCE="FP-2">• ARM loan</FP>
                <FP SOURCE="FP1-2">○ Index</FP>
                <FP SOURCE="FP1-2">○ Margin</FP>
                <FP SOURCE="FP1-2">○ Next change date</FP>
                <FP SOURCE="FP-2">• Loan Type</FP>
                <FP SOURCE="FP1-2">○ FHA</FP>
                <FP SOURCE="FP1-2">○ VA</FP>
                <FP SOURCE="FP1-2">○ USDA</FP>
                <FP SOURCE="FP1-2">○ Conventional</FP>
                <FP SOURCE="FP1-2">○ State bond program</FP>
                <FP SOURCE="FP-2">• Fees owed and whether reimbursable/collectible from borrower or investor</FP>
                <FP SOURCE="FP1-2">○ Late fees</FP>
                <FP SOURCE="FP1-2">○ Broker price opinion fees owed</FP>
                <FP SOURCE="FP1-2">○ Property inspection fees owed</FP>
                <FP SOURCE="FP1-2">○ Attorney fees owed</FP>
                <FP SOURCE="FP1-2">○ Publication fees owed</FP>
                <FP SOURCE="FP1-2">○ Fees owed for copies of documents</FP>
                <FP SOURCE="FP1-2">○ Corporate advances owed</FP>
                <FP SOURCE="FP1-2">○ Prior bankruptcy</FP>
                <FP SOURCE="FP1-2"> Discharge date</FP>
                <FP SOURCE="FP1-2"> Dismissal date</FP>
                <HD SOURCE="HD1">II. Investor Information</HD>
                <FP SOURCE="FP-2">• Name</FP>
                <FP SOURCE="FP-2">• Contact Information</FP>
                <FP SOURCE="FP-2">• Disbursement Information</FP>
                <FP SOURCE="FP-2">• Reporting Requirements</FP>
                <FP SOURCE="FP-2">• Remittance type (Scheduled/scheduled, scheduled/actual, actual/actual)</FP>
                <HD SOURCE="HD1">III. Escrow Accounts</HD>
                <FP SOURCE="FP-2">• Amount of escrow payment due with periodic payment</FP>
                <FP SOURCE="FP-2">• Date of last escrow analysis</FP>
                <FP SOURCE="FP-2">• Tax agency code for each applicable agency</FP>
                <FP SOURCE="FP-2">• Date of last tax payment to local agency</FP>
                <FP SOURCE="FP-2">• Estimated total tax payments for next cycle</FP>
                <FP SOURCE="FP-2">• Next tax due date(s)</FP>
                <FP SOURCE="FP-2">• Parcel number (if multiple parcels include all)</FP>
                <FP SOURCE="FP-2">• Date of last insurance payment</FP>
                <FP SOURCE="FP-2">• Identity of insurer</FP>
                <FP SOURCE="FP-2">• Confirmation of proof of adequate insurance received</FP>
                <FP SOURCE="FP-2">• Historic escrow records (to address borrower questions and disputes)</FP>
                <FP SOURCE="FP-2">• Tax service contracts that will stay in effect</FP>
                <FP SOURCE="FP-2">• For any items paid from the escrow account other than taxes or insurance,</FP>
                <FP SOURCE="FP1-2">○ Identity of the payee</FP>
                <FP SOURCE="FP1-2">○ Due date(s) of payment</FP>
                <FP SOURCE="FP1-2">○ Date of last payment and date of next payment</FP>
                <FP SOURCE="FP1-2">○ Estimated payments for the next cycle, and other information necessary to maintain payment of such item pursuant to the escrow account agreement.</FP>
                <HD SOURCE="HD1">IV. Private Mortgage Insurance</HD>
                <FP SOURCE="FP-2">• Amount last paid</FP>
                <FP SOURCE="FP-2">• Name and address of insurer</FP>
                <FP SOURCE="FP-2">• Amount due</FP>
                <FP SOURCE="FP-2">• Date due</FP>
                <FP SOURCE="FP-2">• Original value of the property</FP>
                <FP SOURCE="FP-2">• The date based on amortization schedule(s) when a borrower may request cancellation</FP>
                <FP SOURCE="FP-2">• Date on which monthly premiums are no longer required for 78% loan to original value</FP>
                <FP SOURCE="FP-2">• Date on which monthly premiums are no longer required based on loan midpoint</FP>
                <HD SOURCE="HD1">V. FHA Insurance</HD>
                <FP SOURCE="FP-2">• MIP amount</FP>
                <FP SOURCE="FP-2">• MIP last paid</FP>
                <FP SOURCE="FP-2">• MIP due</FP>
                <FP SOURCE="FP-2">• MIP due date</FP>
                <FP SOURCE="FP-2">• Loan origination date</FP>
                <FP SOURCE="FP-2">• Loan term</FP>
                <FP SOURCE="FP-2">• Partial claim amount, if any</FP>
                <FP SOURCE="FP-2">• FHA case number assignment date</FP>
                <FP SOURCE="FP-2">• MIP cancellation date based on original amortization</FP>
                <HD SOURCE="HD1">VI. Hazard Insurance/Flood Insurance</HD>
                <FP SOURCE="FP-2">• Policy numbers</FP>
                <FP SOURCE="FP-2">• Name and address of insurer (voluntary and lender placed)</FP>
                <FP SOURCE="FP-2">• Expiration/renewal date(s)</FP>
                <FP SOURCE="FP-2">• Premium amount(s)</FP>
                <FP SOURCE="FP-2">• Frequency of payment</FP>
                <FP SOURCE="FP-2">• Coverage levels</FP>
                <FP SOURCE="FP-2">• Original value of property</FP>
                <FP SOURCE="FP-2">• Flood zone determination certificate</FP>
                <FP SOURCE="FP-2">• Prior completed insurance claims</FP>
                <FP SOURCE="FP-2">• Open insurance claims</FP>
                <FP SOURCE="FP1-2">○ Claim amount</FP>
                <FP SOURCE="FP1-2">○ Loss draft funds held</FP>
                <FP SOURCE="FP1-2">○ Inspection dates and completion estimates</FP>
                <HD SOURCE="HD1">VII. Loss Mitigation (Including Short-Term Options)</HD>
                <FP SOURCE="FP-2">• Current status of discussions with a borrower on a loss mitigation option</FP>
                <FP SOURCE="FP-2">• Any agreements made with a borrower on a loss mitigation option</FP>
                <FP SOURCE="FP-2">• Any analysis by a servicer with respect to potential recovery from a non-performing mortgage loan</FP>
                <FP SOURCE="FP-2">• Copies of complete and incomplete loss mitigation application(s) and information and documents submitted in conjunction with the application, including acknowledgment notices and denial notices</FP>
                <FP SOURCE="FP1-2">○ Date of forbearance, modification or other loss mitigation option</FP>
                <FP SOURCE="FP1-2">○ New loan amount</FP>
                <FP SOURCE="FP1-2">○ New payment amount (show Principal and Interest as well as taxes and insurance, if applicable.)</FP>
                <FP SOURCE="FP1-2">○ Term</FP>
                <FP SOURCE="FP1-2">○ Due date of plan</FP>
                <FP SOURCE="FP1-2">○ Denial date</FP>
                <FP SOURCE="FP1-2">○ Denial reason</FP>
                <FP SOURCE="FP1-2">○ New gross modification amount</FP>
                <FP SOURCE="FP1-2">○ Modified appraisal value</FP>
                <HD SOURCE="HD1">VIII. Foreclosure</HD>
                <FP SOURCE="FP-2">• Status of foreclosure</FP>
                <FP SOURCE="FP-2">• Date referred to attorney</FP>
                <FP SOURCE="FP-2">
                    • Attorney name and contact information
                    <PRTPAGE P="25285"/>
                </FP>
                <FP SOURCE="FP-2">• Publication date</FP>
                <FP SOURCE="FP-2">• Anticipated or scheduled sale date</FP>
                <FP SOURCE="FP-2">• All time line step and events</FP>
                <FP SOURCE="FP-2">• Borrower contact information</FP>
                <FP SOURCE="FP-2">• All phones numbers on file</FP>
                <FP SOURCE="FP-2">• Email addresses for all borrowers</FP>
                <HD SOURCE="HD1">IX. Bankruptcy</HD>
                <FP SOURCE="FP-2">• Notice of bankruptcy/court and case number</FP>
                <FP SOURCE="FP-2">• Bankruptcy chapter and filing date</FP>
                <FP SOURCE="FP-2">• Status of case</FP>
                <FP SOURCE="FP-2">• Proof of Claim filing date</FP>
                <FP SOURCE="FP-2">• Next prepetition and post-petition payment due dates</FP>
                <FP SOURCE="FP-2">• Motion for Relief filing date</FP>
                <FP SOURCE="FP-2">• Plan conversion date, if applicable</FP>
                <FP SOURCE="FP-2">• Attorney acknowledgement of bankruptcy</FP>
                <FP SOURCE="FP-2">• Other bankruptcy documents</FP>
                <HD SOURCE="HD1">X. Signing Authority</HD>
                <P>
                    The Director of the Bureau, having reviewed and approved this document is delegating the authority to electronically sign this document to Laura Galban, a Bureau Federal Register Liaison, for purposes of publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <DATED>Dated: April 24, 2020.</DATED>
                    <NAME>Laura Galban,</NAME>
                    <TITLE>Federal Register Liaison, Bureau of Consumer Financial Protection.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09151 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 4810-AM-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 71</CFR>
                <DEPDOC>[Docket No. FAA-2020-0006; Airspace Docket No. 17-ASW-26]</DEPDOC>
                <RIN>RIN 2120-AA66</RIN>
                <SUBJECT>Amendment of VOR Federal Airways V-17, V-18, V-62, V-94, V-163, and V-568 in the Vicinity of Glen Rose, TX</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 action amends VHF Omnidirectional Range (VOR) Federal airways V-17, V-18, V-62, V-94, V-163, and V-568 in the vicinity of Glen Rose, TX. The modifications are necessary due to the planned decommissioning of the VOR portion of the Glen Rose, TX, VOR/Tactical Air Navigation (VORTAC) navigation aid (NAVAID), which provides navigation guidance for portions of the affected airways. The Glen Rose VOR is being decommissioned as part of the FAA's VOR Minimum Operational Network (MON) program.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Effective date 0901 UTC, July 16, 2020. The Director of the Federal Register approves this incorporation by reference action under Title 1 Code of Federal Regulations part 51, subject to the annual revision of FAA Order 7400.11 and publication of conforming amendments.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        FAA Order 7400.11D, Airspace Designations and Reporting Points, and subsequent amendments can be viewed online at 
                        <E T="03">https://www.faa.gov/air_traffic/publications/.</E>
                         For further information, you can contact the Rules and Regulations Group, Federal Aviation Administration, 800 Independence Avenue SW, Washington, DC 20591; telephone: (202) 267-8783. The Order is also available for inspection at the National Archives and Records Administration (NARA). For information on the availability of FAA Order 7400.11D at NARA, email: 
                        <E T="03">fedreg.legal@nara.gov</E>
                         or go to 
                        <E T="03">https://www.archives.gov/federal-register/cfr/ibr-locations.html.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Colby Abbott, Rules and Regulations Group, Office of Policy, Federal Aviation Administration, 800 Independence Avenue SW, Washington, DC 20591; telephone: (202) 267-8783.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <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 the airspace necessary to ensure the safety of aircraft and the efficient use of airspace. This regulation is within the scope of that authority as it would modify the route structure as necessary to preserve the safe and efficient flow of air traffic within the National Airspace System.</P>
                <HD SOURCE="HD1">History</HD>
                <P>
                    The FAA published a notice of proposed rulemaking (NPRM) for Docket No. FAA-2020-0006 in the 
                    <E T="04">Federal Register</E>
                     (85 FR 3288; January 21, 2020), amending VOR Federal airways V-17, V-18, V-62, V-94, V-163, and V-568 in the vicinity of Glen Rose, TX, due to the planned decommissioning of the VOR portion of the Glen Rose, TX, VORTAC. Interested parties were invited to participate in this rulemaking effort by submitting written comments on the proposal. No comments were received.
                </P>
                <P>
                    Subsequent to the NPRM, the FAA published a rule for Docket No. FAA-2018-1028 in the 
                    <E T="04">Federal Register</E>
                     (85 FR 13731; March 10, 2020), amending VOR Federal airway V-18 by removing the airway segment between the Vulcan, AL, VORTAC and the Colliers, SC, VORTAC. That airway amendment was effective May 21, 2020, and is included in this rule.
                </P>
                <P>VOR Federal airways are published in paragraph 6010(a) of FAA Order 7400.11D dated August 8, 2019, and effective September 15, 2019, which is incorporated by reference in 14 CFR 71.1. The VOR Federal airways listed in this document will be subsequently published in the Order.</P>
                <P>FAA Order 7400.11, Airspace Designations and Reporting Points, is published yearly and effective on September 15.</P>
                <HD SOURCE="HD1">Availability and Summary of Documents for Incorporation by Reference</HD>
                <P>
                    This document amends FAA Order 7400.11D, Airspace Designations and Reporting Points, dated August 8, 2019, and effective September 15, 2019. FAA Order 7400.11D is publicly available as listed in the 
                    <E T="02">ADDRESSES</E>
                     section of this document. FAA Order 7400.11D lists Class A, B, C, D, and E airspace areas, air traffic service routes, and reporting points.
                </P>
                <HD SOURCE="HD1">The Rule</HD>
                <P>The FAA is amending Title 14 Code of Federal Regulations (14 CFR) part 71 by modifying VOR Federal airways V-17, V-18, V-62, V-94, V-163, and V-568. The planned decommissioning of the VOR portion of the Glen Rose, TX, VORTAC NAVAID has made this action necessary. The VOR Federal airway changes are outlined below.</P>
                <P>
                    <E T="03">V-17:</E>
                     V-17 extends between the Brownsville, TX, VORTAC and the Goodland, KS, VORTAC. The airway segment overlying the Glen Rose, TX, VORTAC between the Waco, TX, VORTAC and the Millsap, TX, VORTAC is removed. The unaffected portions of the existing airway remain as charted.
                </P>
                <P>
                    <E T="03">V-18:</E>
                     V-18 extends between the Millsap, TX, VORTAC and the Vulcan, AL, VORTAC; and between the Colliers, SC, VORTAC and the Charleston, SC, VORTAC. The airway segment overlying the Glen Rose, TX, VORTAC between the Millsap, TX, VORTAC and the Cedar Creek, TX, VORTAC is removed. The unaffected portions of the existing airway remain as charted.
                    <PRTPAGE P="25286"/>
                </P>
                <P>
                    <E T="03">V-62:</E>
                     V-62 extends between the Gallup, NM, VORTAC and the Glen Rose, TX, VORTAC. The airway segment overlying the Glen Rose, TX, VORTAC between the Abilene, TX, VORTAC and the Glen Rose, TX, VORTAC is removed. The unaffected portions of the existing airway remain as charted.
                </P>
                <P>
                    <E T="03">V-94:</E>
                     V-94 extends between the Blythe, CA, VORTAC and the Holly Springs, MS, VORTAC. The airway segment overlying the Glen Rose, TX, VORTAC between the Tuscola, TX, VOR/DME and the Cedar Creek, TX, VORTAC is removed. The unaffected portions of the existing airway remain as charted.
                </P>
                <P>
                    <E T="03">V-163:</E>
                     V-163 extends between the Matamoros, Mexico, VOR/DME and the Glen Rose, TX, VORTAC. The airway segment overlying the Glen Rose, TX, VORTAC between the Gooch Springs, TX, VORTAC and the Glen Rose, TX, VORTAC is removed. Additionally, exclusionary language is added to reflect the airspace within Mexico is excluded. The unaffected portions of the existing airway remain as charted.
                </P>
                <P>
                    <E T="03">V-568:</E>
                     V-568 extends between the Corpus Christi, TX, VORTAC and the Wichita Falls, TX, VORTAC. The airway segment overlying the Glen Rose, TX, VORTAC between the Llano, TX, VORTAC and the Millsap, TX, VORTAC is removed. The unaffected portions of the existing airway remain as charted. There are no concurrent changes to other portions of the airway as was noted in the NPRM.
                </P>
                <P>All radials in the VOR Federal airway descriptions below are unchanged and stated in True degrees.</P>
                <HD SOURCE="HD1">Regulatory Notices and Analyses</HD>
                <P>The FAA has determined that this proposed regulation only involves an established body of technical regulations for which frequent and routine amendments are necessary to keep them operationally current. It, therefore: (1) Is not a “significant regulatory action” under Executive Order 12866; (2) is not a “significant rule” under Department of Transportation (DOT) Regulatory Policies and Procedures (44 FR 11034; February 26, 1979); and (3) does not warrant preparation of a regulatory evaluation as the anticipated impact is so minimal. Since this is a routine matter that will only affect air traffic procedures and air navigation, it is certified that this 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>The FAA has determined that this action of modifying VOR Federal airways V-17, V-18, V-62, V-94, V-163, and V-568 due to the planned decommissioning of the VOR portion of the Glen Rose, TX, VORTAC NAVAID qualifies for categorical exclusion under the National Environmental Policy Act and its implementing regulations at 40 CFR part 1500, and in accordance with FAA Order 1050.1F, Environmental Impacts: Policies and Procedures, paragraph 5-6.5a, which categorically excludes from further environmental impact review rulemaking actions that designate or modify classes of airspace areas, airways, routes, and reporting points (see 14 CFR part 71, Designation of Class A, B, C, D, and E Airspace Areas; Air Traffic Service Routes; and Reporting Points). As such, this action is not expected to result in any potentially significant environmental impacts. In accordance with FAA Order 1050.1F, paragraph 5-2 regarding Extraordinary Circumstances, the FAA has reviewed this action for factors and circumstances in which a normally categorically excluded action may have a significant environmental impact requiring further analysis. The FAA has determined that no extraordinary circumstances exist that warrant preparation of an environmental assessment or environmental impact study.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 14 CFR Part 71</HD>
                    <P>Airspace, Incorporation by reference, Navigation (air).</P>
                </LSTSUB>
                <HD SOURCE="HD1">Adoption of the Amendment</HD>
                <P>In consideration of the foregoing, the Federal Aviation Administration amends 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>
                <REGTEXT TITLE="14" PART="71">
                    <AMDPAR>1. The authority citation for 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>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 71.1 </SECTNO>
                    <SUBJECT> [Amended] </SUBJECT>
                </SECTION>
                <REGTEXT TITLE="14" PART="71">
                    <AMDPAR>2. The incorporation by reference in 14 CFR 71.1 of FAA Order 7400.11D, Airspace Designations and Reporting Points, dated August 8, 2019 and effective September 15, 2019, is amended as follows: </AMDPAR>
                    <EXTRACT>
                        <HD SOURCE="HD2">Paragraph 6010(a) Domestic VOR Federal Airways.</HD>
                        <STARS/>
                        <HD SOURCE="HD1">V-17 [Amended]</HD>
                        <P>From Brownsville, TX; Harlingen, TX; McAllen, TX; 29 miles, 12 AGL, 34 miles, 25 MSL, 37 miles, 12 AGL; Laredo, TX; Cotulla, TX; INT Cotulla 046° and San Antonio, TX, 198° radials; San Antonio; Centex, TX; to Waco, TX. From Millsap, TX; Bowie, TX; Ardmore, OK; Will Rogers, OK; Mitbee, OK; Garden City, KS; to Goodland, KS.</P>
                        <STARS/>
                        <HD SOURCE="HD1">V-18 [Amended]</HD>
                        <P>From Cedar Creek, TX; Quitman, TX; Belcher, LA; Monroe, LA; Magnolia, MS; Meridian, MS; Crimson, AL; to Vulcan, AL. From Colliers, SC; to Charleston, SC.</P>
                        <STARS/>
                        <HD SOURCE="HD1">V-62 [Amended]</HD>
                        <P>From Gallup, NM; INT Gallup 089° and Santa Fe, NM, 268° radials; Santa Fe; Anton Chico, NM; Texico, NM; Lubbock, TX; to Abilene, TX.</P>
                        <STARS/>
                        <HD SOURCE="HD1">V-94 [Amended]</HD>
                        <P>From Blythe, CA; INT Blythe 094°and Gila Bend, AZ, 299° radials; Gila Bend; Stanfield, AZ; 55 miles, 74 miles, 95 MSL, San Simon, AZ; Deming, NM; Newman, TX; Salt Flat, TX; Wink, TX; Midland, TX; to Tuscola, TX. From Cedar Creek, TX; Gregg County, TX; Elm Grove, LA; Monroe, LA; Greenville, MS; to Holly Springs, MS.</P>
                        <STARS/>
                        <HD SOURCE="HD1">V-163 [Amended]</HD>
                        <P>From Matamoros, Mexico; Brownsville, TX; 27 miles standard width, 37 miles 7 miles wide (3 miles E. and 4 miles W. of centerline); Corpus Christi, TX; Three Rivers, TX; INT Three Rivers 345° and San Antonio, TX, 168° radials; San Antonio; to Gooch Springs, TX. The airspace within Mexico is excluded.</P>
                        <STARS/>
                        <HD SOURCE="HD1">V-568 [Amended]</HD>
                        <P>From Corpus Christi, TX; INT Corpus Christi 296° and Three Rivers, TX, 165° radials; Three Rivers; INT Three Rivers 327° and San Antonio, TX, 183° radials; San Antonio; Stonewall, TX; to Llano, TX. From Millsap, TX; to Wichita Falls, TX.</P>
                        <STARS/>
                    </EXTRACT>
                </REGTEXT>
                <SIG>
                    <NAME>Scott M. Rosenbloom,</NAME>
                    <TITLE>Acting Manager, Rules and Regulations Group.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09226 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 4910-13-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <PRTPAGE P="25287"/>
                <AGENCY TYPE="N">DEPARTMENT OF STATE</AGENCY>
                <CFR>22 CFR Parts 120, 122, 123, 124, and 129</CFR>
                <DEPDOC>[Public Notice: 11094]</DEPDOC>
                <SUBJECT>International Traffic in Arms Regulations: Notification of Temporary Suspension, Modification, or Exception to Regulations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of State.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Temporary suspensions, modifications, and exceptions.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of State is issuing this document to inform the public of certain temporary suspensions, modifications, and exceptions for the durations described herein to several provisions of the International Traffic in Arms Regulations (ITAR). These actions are taken in order to ensure continuity of operations within the Directorate of Defense Trade Controls (DDTC) and among entities registered with DDTC pursuant to the ITAR during the current SARS-COV2 public health emergency.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This document is issued May 1, 2020.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Sarah Heidema, Office of Defense Trade Controls Policy, U.S. Department of State, telephone (202) 663-1282, or email 
                        <E T="03">DDTCResponseTeam@state.gov.</E>
                         ATTN: Notice of Suspension, Modification, or Exception.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    In order to ensure continuity of operations within the Directorate of Defense Trade Controls (DDTC) and among entities registered with DDTC pursuant to part 122 of the International Traffic in Arms Regulations (ITAR), DDTC provides notice of the temporary suspension, modification, or exception to several ITAR provisions. These actions are being taken pursuant to ITAR § 126.2, which allows for the temporary suspension or modification of provisions of the ITAR, and ITAR § 126.3, which allows for exceptions to provisions of the ITAR. These actions are in the interest of the security and foreign policy of the United States. Further, they are warranted as a result of the exceptional and undue hardships and risks to safety caused by the public health emergency related to the SARS-COV2 pandemic. The President declared a national emergency on March 13, 2020, as a result of this public health crisis.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Proclamation 9994 of March 13, 2020, 85 FR 15337 (Mar. 18, 2020).
                    </P>
                </FTNT>
                <P>1. As of February 29, 2020, a temporary suspension, modification, and exception to the requirement in ITAR parts 122 and 129 to renew registration as a manufacturer, exporter, and/or broker and pay a fee on an annual basis by extending ITAR registrations with an expiration date of February 29, March 31, April 30, May 31, or June 30, 2020—for two (2) months from the original date of expiration.</P>
                <P>2. As of March 13, 2020, a temporary suspension, modification, and exception to the limitations on the duration of ITAR licenses and agreements contained in ITAR parts 120 through 130, including but not necessarily limited to ITAR §§ 123.5(a), 123.21(a), and 129.6(e), to extend any license or agreement that expires between March 13, 2020 and May 31, 2020—for six (6) months from the original date of expiration so long as there is no change to the scope or value of the authorization and no Name/Address changes are required. This six (6) month extension is warranted in light of the unique challenges applicants face in the current environment when attempting to coordinate with U.S. and foreign business partners regarding the scope of applications.</P>
                <P>3. As of March 13, 2020, a temporary suspension, modification, and exception to the requirement that a regular employee, for purposes of ITAR § 120.39(a)(2), work at the company's facilities, to allow the individual to work at a remote work location, so long as the individual is not located in Russia or a country listed in ITAR § 126.1. This suspension, modification, and exception shall terminate on July 31, 2020, unless otherwise extended in writing.</P>
                <P>4. As of March 13, 2020, a temporary suspension, modification, and exception to authorize regular employees of licensed entities who are working remotely in a country not currently authorized by a technical assistance agreement, manufacturing license agreement, or exemption to send, receive, or access any technical data authorized for export, reexport, or retransfer to their employer via a technical assistance agreement, manufacturing license agreement, or exemption so long as the regular employee is not located in Russia or a country listed in ITAR § 126.1. This suspension, modification, and exception shall terminate on July 31, 2020, unless otherwise extended in writing.</P>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>22 CFR 126.2 and 126.3</P>
                </AUTH>
                <SIG>
                    <NAME>Zachary A. Parker,</NAME>
                    <TITLE>Director, Office of Directives Management, U.S. Department of State.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08839 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 4710-25-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Fiscal Service</SUBAGY>
                <CFR>31 CFR Part 208</CFR>
                <DEPDOC>[Docket No.: FISCAL-2018-0001]</DEPDOC>
                <RIN>RIN 1510-AB26</RIN>
                <SUBJECT>Management of Federal Agency Disbursements</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Bureau of the Fiscal Service, Fiscal Service, Treasury.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Department of the Treasury (Treasury), Bureau of the Fiscal Service (Fiscal Service or “we”), is adopting the changes proposed in its Notice of Proposed Rulemaking for its regulation that requires electronic delivery of all Federal payments aside from tax payments. The final rule eliminates obsolete references in the regulation, including references to the Electronic Transfer Account (ETA
                        <SU>SM</SU>
                        ). In addition, the final rule provides for the disbursement of non-benefit payments, including tax payments, through Treasury-sponsored accounts, such as the U.S. Debit Card. The final rule does not mandate the electronic delivery of tax payments or affect the Direct Express® program, which will continue to be available to recipients of benefit payments.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Effective June 1, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        You can download this final rule at the following internet address: 
                        <E T="03">https://fiscal.treasury.gov/fsservices/gov/pmt/eft/regulations.htm.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Brett Smith, Director, EFT Strategy Division, at (202) 874-6666 or 
                        <E T="03">brett.smith@fiscal.treasury.gov;</E>
                         Natalie H. Diana, Senior Counsel, at (202) 874-6680 or 
                        <E T="03">natalie.diana@fiscal.treasury.gov;</E>
                         or Caitlin Gehring, Attorney Advisor, at (202) 874-5710 or 
                        <E T="03">caitlin.gehring@fiscal.treasury.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    On October 16, 2019, we published a Notice of Proposed Rulemaking (NPRM) at 84 FR 55267, requesting comment on proposed amendments to 31 CFR part 208 (part 208), which implements the requirements of 31 U.S.C. 3332 (Section 3332). Section 3332 generally requires that all Federal nontax payments be made by electronic funds transfer (EFT), unless waived by the Secretary of the Treasury. The Secretary must ensure that individuals required to receive Federal payments by EFT have access to an account at a financial institution “at 
                    <PRTPAGE P="25288"/>
                    a reasonable cost” and with “the same consumer protections with respect to the account as other account holders at the same financial institution.” 
                    <E T="03">See</E>
                     31 U.S.C. 3332(f), (i)(2). Direct deposit is the primary method used to make EFT Federal payments. We are updating part 208 to reflect the evolution of Fiscal Service's payment technologies and to eliminate obsolete ETA references and expired EFT waiver categories. The waiver categories that have not expired remain in place without change. We are adopting as final all of the amendments proposed in the NPRM.
                </P>
                <P>Fiscal Service has had great success in reducing check payments, but still must print and mail more than 50 million checks each year. More than half of these are for non-benefit payments, especially tax payments. Over the years, Fiscal Service has implemented multiple solutions to facilitate electronic payments.</P>
                <HD SOURCE="HD2">A. ETA</HD>
                <P>
                    In conjunction with the 1998 publication of part 208, Fiscal Service developed the ETA, a low-cost account offered by participating financial institutions for those individuals who wish to receive their Federal payments by direct deposit. 
                    <E T="03">See</E>
                     Notice of Electronic Transfer Account Features, 64 FR 38510 (July 16, 1999). Fiscal Service determined to end the program in 2017 and as of September 2018 all ETA accounts were closed.
                </P>
                <HD SOURCE="HD2">B. Direct Express® Card</HD>
                <P>In 2008, Fiscal Service introduced the Direct Express® Debit MasterCard® card. The Direct Express card is a low-cost prepaid debit card account developed for Federal benefit recipients (initially, for Social Security and Supplemental Security Income payment recipients). In 2010, Fiscal Service amended part 208 to establish the Direct Express card as an account that meets the requirements of Section 3332(i), which ensures that payment recipients have access to an account at a reasonable cost and with the same consumer protections as other account holders at the financial institution that issues the card.</P>
                <HD SOURCE="HD2">C. U.S. Debit Card</HD>
                <P>Since 2008, Fiscal Service has also sponsored another prepaid card account, the U.S. Debit Card, to support our efforts to reduce the number of non-benefit payments made by cash or check. The U.S. Debit Card program enables agencies to make Federal non-benefit payments to recipients through prepaid debit cards instead of through checks or cash. The accounts are issued, and the program is operated, by a financial institution designated as Fiscal Service's financial agent. Federal entities and programs use the U.S. Debit Card to make payments for a variety of purposes, including stipends, awards, grants, and travel reimbursements for local visitors and international guests.</P>
                <P>In recent years, Fiscal Service has engaged in testing and developing payment methods to facilitate the electronic delivery of Federal non-benefit payments, in order to reduce check payments and provide more options for payment recipients. In particular, Fiscal Service is testing the delivery of payments to virtual accounts (which are accessed online or through a mobile device rather than a plastic card), as well as implementing capabilities to enable payment recipients to receive payments in real-time by providing a debit card number. The U.S. Debit Card program now includes this functionality.</P>
                <HD SOURCE="HD1">II. Public Comment and Fiscal Service Response</HD>
                <P>Fiscal Service sought public comment on the proposed rule for 60 days to assist the agency in giving full consideration to the matters discussed in the proposed rule. We received comments from one company, Visa, Inc. Visa supported the proposed changes and suggested one clarification. We appreciate Visa's support of the changes and Fiscal Service's efforts to embrace innovative payment technologies.</P>
                <P>
                    Visa recommended clarifying the definition of “electronic funds transfer” to include disbursements to Treasury-sponsored accounts made through any electronic payment method, including but not limited to debit and credit networks, push payments, and mobile payments. Currently, Part 208 defines “electronic funds transfer” as a transfer “that is initiated through an electronic terminal, telephone, computer, or magnetic tape,” and gives examples of “Automated Clearing House transfers, Fedwire transfers, and transfers made at automated teller machines and point-of-sale terminals.” As Visa noted in its comment, the definition of “electronic funds transfer” is taken from the statute that Part 208 implements. 
                    <E T="03">See</E>
                     31 U.S.C. 3332(j)(1). (Note that the definition is also substantially the same definition used in the Electronic Fund Transfer Act. See 12 U.S.C. 1693a(7).)
                </P>
                <P>We believe that departing from the statutory definition in the rule could cause confusion by implying that the regulation covers transfers that the statute does not. Accordingly, we are not revising the definition of “electronic funds transfer” in the final rule. However, disbursements to Treasury-sponsored accounts may be made using any kind of electronic funds transfer, including mobile payments, push payments and payment over debit and credit card networks, whether these payment methods are expressly referenced in the wording of the definition or not.</P>
                <HD SOURCE="HD1">III. Summary of Final Rule</HD>
                <P>In the Final Rule we are adopting all of the amendments to part 208 that were proposed in the NPRM, as follows:</P>
                <P>We are removing now-obsolete references to the ETA from the regulation. The ETA program ended in September 2018.</P>
                <P>We are eliminating waiver provisions that have expired due to the passage of time. When part 208 was promulgated in 2010, it included a provision stating that individuals receiving Federal payments by check on March 1, 2011, could continue to do so through February 28, 2013. In addition, the rule provides that individuals who file claims for Federal benefits before March 1, 2011, and who request check payments when they file, may receive payments by check through February 28, 2013. Since the February 28, 2013 deadline has expired, these provisions no longer have any effect and there is no purpose in retaining them in the rule. All other waiver provisions remain unchanged.</P>
                <P>We are amending the definition of “Federal payment” for purposes of part 208 to include payments made under the Internal Revenue Code of 1986, to support the delivery of tax payments via Treasury-sponsored accounts. Tax payments continue to be excluded from the electronic payment mandate that applies to other Federal payments, consistent with Section 3332. However, the definitional change provides flexibility to offer taxpayers Treasury-sponsored accounts as an electronic payment alternative for the receipt of tax payments on a voluntary basis.</P>
                <P>
                    Lastly, we are revising part 208 to provide for the use of other “Treasury-sponsored accounts” for the delivery of Federal payments. The revisions provide flexibility to implement new methods of making payments, with the ultimate goal of reducing check payments, modernizing Fiscal Service's payment capabilities, and offering payment recipients electronic alternatives to checks or direct deposit to a traditional bank account. We are not changing the regulatory treatment of Direct Express accounts or making any changes to the Direct Express program. The concept of Treasury-sponsored accounts and the features of the U.S. 
                    <PRTPAGE P="25289"/>
                    Debit Card program are discussed immediately below.
                </P>
                <HD SOURCE="HD2">A. Treasury-Sponsored Accounts</HD>
                <P>In order to support existing and emerging methods of paying individuals, Fiscal Service is adding a new term, “Treasury-sponsored account,” to the regulation. A Treasury-sponsored account is defined as an account that a Treasury-designated financial agent establishes and administers for an individual for the disbursement of Federal payments, upon terms and conditions that Treasury considers appropriate. The term “Treasury-sponsored account” includes, but is not limited to, Direct Express and U.S. Debit Cards. Although Fiscal Service does not have current plans to develop Treasury-sponsored accounts other than Direct Express and U.S. Debit Cards, this terminology provides flexibility for the future.</P>
                <P>Currently the regulation only addresses the use of accounts established by financial agents to accomplish disbursement of benefit payments and accounts established for disaster victims. The final rule broadens the uses of accounts established by financial agents for disbursement purposes, including to disburse not just benefit payments but also miscellaneous, vendor, expense reimbursement and tax payments. Treasury-sponsored accounts are required to be made available at a reasonable cost and with the same consumer protections provided to other account holders at the financial institution, thereby meeting the requirements of Section 3332.</P>
                <HD SOURCE="HD2">B. U.S. Debit Card</HD>
                <P>Historically, Fiscal Service structured the U.S. Debit Card program as a conventional general purpose prepaid card program, which provides payment recipients with access to their funds via a plastic card. Recently, Fiscal Service expanded the U.S. Debit Card program to include a new virtual account option, which allows payment recipients to establish a prepaid account accessible through their mobile devices or online without the use of a plastic card. Payment recipients who open a virtual U.S. Debit Card account have the capability to move their funds in real-time through Direct to Debit functionality, which allows the cardholder to transfer funds on the basis of a debit card number. They may also opt to have a plastic U.S. Debit Card to access funds in the account if they so choose.</P>
                <P>In the NPRM, Fiscal Service described the features and fees of the U.S. Debit Card and requested comment on our view that the U.S. Debit Card meets the statutory “reasonable cost” and “same consumer protection” requirements of Section 3332. One comment was received in support of that view. No comments were received in opposition of that view.</P>
                <P>
                    As discussed in the NPRM, a 2014 study by the Federal Reserve Bank of Kansas City found that prepaid cardholders pay, on average, $11 per month in fees. Some of the fees included in that amount are monthly, account maintenance, IVR and ATM balance inquiry, ATM withdrawal, PIN and signature transaction, and declined transaction fees. 
                    <E T="03">See</E>
                     General Purpose Reloadable Cards: Penetration, Use, Fees and Fraud Risks, The Federal Reserve Bank of Kansas City, RWP 14-01, February 2017. In contrast, the U.S. Debit Card carries no monthly fee and can be used at no cost in many cases. There are no fees for cardholders to sign up for or activate the card; receive deposits; make purchases at retail locations, online or by telephone; or get cash at retail locations and financial institutions. Cardholders can check their balances and sign up for alerts via the mobile app, text, telephone or email. If desired, a cardholder may receive a monthly paper statement. There are no fees for declined transactions. Cardholders may close their card account at any time without a fee.
                </P>
                <P>
                    Cardholders may make purchases anywhere VISA® is accepted, including millions of retail locations worldwide, online, or by telephone. Similarly, cardholders may make unlimited free cash withdrawals and check their account balances at Allpoint ATMs as well as one free out-of-network ATM cash withdrawal for every Federal payment the cardholder receives. There are also other means by which cardholders may access their funds for free. Cardholders can transfer funds for free to a bank account and have free use of Money Network
                    <SU>TM</SU>
                     checks to access their funds. The free services and minimal fees are fully disclosed in materials that are provided to new U.S. Debit Card account holders, as shown in the following chart:
                </P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s200,r50">
                    <TTITLE>Fee Schedule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Transaction type</CHED>
                        <CHED H="1">Fees</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            Inactivity Fee *
                            <SU>1</SU>
                             (3 consecutive months of no activity)
                        </ENT>
                        <ENT>$1.50.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Money Network
                            <SU>TM</SU>
                             Check (use, order, or stop payment; cash at participating check-cashing locations)
                        </ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Signature Point-of-Sale Transactions (for purchases, declines and returns) | U.S. and Non-U.S</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PIN Point-of-Sale Transactions—with or without Cash Back (for purchases and declines) | U.S. and Non-U.S</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PIN Point-of-Sale Transactions—with or without Cash Back (for returns) | U.S. and Non-U.S</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ATM Withdrawals | U.S. In-Network ATMs including AllPoint Network ATMs (Unlimited)</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ATM Withdrawals | U.S. Out-of-Network ATMs (First Free per deposit)</ENT>
                        <ENT>2.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ATM Withdrawals | Non-U.S. ATMs</ENT>
                        <ENT>3.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ATM Inquiries | U.S. and Non-U.S</ENT>
                        <ENT>0.25.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Declined Point-of-Sale (POS) Transaction</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Bank Teller Over-the-Counter Cash Withdrawal (at any bank that displays the logo shown on your card)</ENT>
                        <ENT>7.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Third-party wallet tokenization (load, transfer, or ACH) *</ENT>
                        <ENT>0.01.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Transfer Funds to a Bank Account via ACH transfer *</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Monthly Paper Statement by Mail *</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Periodic Monthly Paper Statement Expedited Mail *</ENT>
                        <ENT>N/A.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Balance Inquiries and Alerts | via Mobile App, Automated Phone System, Customer Service, Online Access, or Notifications (push, email or text) *</ENT>
                        <ENT>0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Customer Service 24/7 *</ENT>
                        <ENT>$0.00.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">* Disbursement or funds transfer via Direct to Debit</ENT>
                        <ENT>* 0.15 + Network Costs.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replacement Card with Standard Delivery</ENT>
                        <ENT>$7.50.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Replacement Card with Expedited Delivery</ENT>
                        <ENT>24.50.</ENT>
                    </ROW>
                </GPOTABLE>
                <PRTPAGE P="25290"/>
                <P>U.S. Debit Card cardholders are protected by Regulation E (12 CFR part 1005), which generally provides certain protections to a cardholder whose card is lost or stolen, as well as VISA's Zero Liability protection. Card balances are covered by deposit insurance by the Federal Deposit Insurance Corporation (FDIC) to the extent allowed by law.</P>
                <HD SOURCE="HD1">IV. Section-by-Section Analysis</HD>
                <HD SOURCE="HD2">§ 208.1 </HD>
                <P>We are amending §  208.1 by removing the statement that part 208 does not apply to tax payments. In the final rule, part 208 allows for the delivery of tax payments to Treasury-sponsored accounts, but does not mandate that tax payments be made by EFT.</P>
                <HD SOURCE="HD2">§ 208.2 </HD>
                <P>The definition of “disbursement” in the context of electronic benefit transfer, is broadened into a definition of disbursement for not just benefit payments but also non-benefit payments. The final rule substitutes the phrase “payments electronically delivered to Treasury-sponsored accounts” for the existing phrase “electronic benefit transfer.”</P>
                <P>The definition of “electronic benefits transfer” (EBT), substitutes the phrase “Treasury-sponsored account” for the existing phrase “a Direct Express card” and removes the reference to the ETA. Thus, the definition of electronic benefits transfer includes Direct Express but not be limited to Direct Express. A reference to Public Law 104-208 has been added to make it clear that the definition of “electronic benefits transfer” applies to the various references in the public law to electronic benefits transfer.</P>
                <P>We are eliminating the definition of ETA.</P>
                <P>We are amending the definition of Federal payment to include payments made under the Internal Revenue Code of 1986, which are currently excluded from the definition.</P>
                <P>The definition of Financial Agent is revised to include a financial institution that has been designated by Treasury as a Financial Agent for the provision of electronic funds transfer services as well. Currently, the definition of Financial Agent for purposes of part 208 is limited to a financial agent that provides electronic benefit transfer (EBT) services.</P>
                <P>We added a new term, “Treasury-sponsored account,” defined as a Direct Express card account, a U.S. Debit Card account, or another account established pursuant to § 208.5 or § 208.11.</P>
                <P>We added a definition of U.S. Debit Card to part 208.</P>
                <HD SOURCE="HD2">§ 208.3</HD>
                <P>Section 208.3 currently states that, subject to § 208.4, and notwithstanding any other provision of law, all Federal payments made by an agency shall be made by electronic funds transfer. Section 208.3 added a sentence stating that this requirement does not apply to payments under the Internal Revenue Code of 1986. The sentence is necessary because the change to the definition of Federal payment includes payments made under the Internal Revenue Code of 1986.</P>
                <HD SOURCE="HD2">§ 208.4 </HD>
                <P>Section 208.4 contains waivers from the requirement that a Federal payment be made electronically. We are eliminating the text of current paragraphs (a)(1)(i) and (ii). Those provisions provide, respectively, (i) that payment recipients who were receiving their payments from an agency by check before March 1, 2011, may to continue to receive those payments by check through February 28, 2013 and (ii) that individuals who filed claims for Federal payments before March 1, 2011, and who requested check payments when they filed, are permitted to receive payments by check through February 28, 2013. Because those time periods have expired, the waivers are no longer needed in the regulation. The remaining paragraphs of § 208.4(a)(1) are unchanged except that references to Direct Express accounts are replaced by references to “Treasury-sponsored accounts.”</P>
                <P>Section 208.4(a)(2) through (7) are unchanged. Section 208.4(b) is unchanged except to reflect the renumbering of § 208.4(a)(1) resulting from the deletion of the obsolete waivers.</P>
                <HD SOURCE="HD2">§ 208.5</HD>
                <P>Current § 208.5 addresses the provision of ETA accounts. We are eliminating the text of § 208.5 in its entirety and replacing it with a provision stating that Treasury may designate a Financial Agent to establish and administer accounts for individuals for the disbursement of Federal payments. Federal payments, as defined in § 208.2, include not only benefit payments but also miscellaneous, vendor, expense reimbursement and tax payments. Section 208.5 provides that such accounts may be established upon terms and conditions that the Secretary considers appropriate or necessary and that they shall be made available at a reasonable cost and with the same consumer protections provided to other account holders at the financial institution. These requirements reflect that Treasury may deliver payments to such accounts and the maintenance of accounts and the provision of account-related services under this section shall constitute reasonable duties of a Financial Agent of the United States.</P>
                <HD SOURCE="HD2">§ 208.6</HD>
                <P>Currently § 208.6 provides that an individual who receives a benefit payment is eligible to open a Direct Express account, under terms and conditions established by Treasury. This section also provides that the offering of a Direct Express account constitutes the provision of EBT services within the meaning of Public Law 104-208. In the final rule, § 208.6 is broadened to provide that an individual who receives a Federal payment is eligible to open a Treasury-sponsored account, under terms and conditions established by Treasury. The sentence referring to Public Law 104-208 has been deleted as unnecessary in light of revisions to the definition of “electronic benefit transfer.”</P>
                <HD SOURCE="HD2">§ 208.7</HD>
                <P>Section 208.7 is unchanged except that the reference to a Direct Express account is replaced by a reference to a “Treasury-sponsored account.”</P>
                <HD SOURCE="HD2">§ 208.8</HD>
                <P>We are adding a sentence to current § 208.8 that states that for recipients who do not designate a bank account for the receipt of payments, Treasury may disburse payments to a Treasury-sponsored account or to an account to which the recipient is receiving other Federal payments.</P>
                <HD SOURCE="HD2">§ 208.9-11</HD>
                <P>We are not changing § 208.9, § 208.10, or § 208.11.</P>
                <HD SOURCE="HD1">V. Procedural Analysis</HD>
                <HD SOURCE="HD2">Regulatory Planning and Review</HD>
                <P>The final rule does not meet the criteria for a “significant regulatory action” as defined in Executive Order 12866. Therefore, the regulatory review procedures contained therein do not apply.</P>
                <HD SOURCE="HD2">Regulatory Flexibility Act</HD>
                <P>
                    It is hereby certified that the final rule will not have a significant economic impact on a substantial number of small entities. The rule provisions being amended apply to individuals who receive Federal payments, and do not have any direct impact on small entities.
                    <PRTPAGE P="25291"/>
                </P>
                <HD SOURCE="HD2">Unfunded Mandates Act of 1995</HD>
                <P>Section 202 of the Unfunded Mandates Reform Act of 1995, 2 U.S.C. 1532 (Unfunded Mandates Act), requires that the agency prepare a budgetary impact statement before promulgating any rule likely to result in a Federal mandate that may result in the expenditure by State, local, and tribal governments, in the aggregate, or by the private sector, of $100 million or more in any one year. If a budgetary impact statement is required, section 205 of the Unfunded Mandates Act also requires the agency to identify and consider a reasonable number of regulatory alternatives before promulgating the rule. We have determined that the final rule will not result in expenditures by State, local, and tribal governments, in the aggregate, or by the private sector, of $100 million or more in any one year. Accordingly, we have not prepared a budgetary impact statement or specifically addressed any regulatory alternatives.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 31 CFR Part 208</HD>
                    <P>Banks, banking, Debit card, Disbursement, Electronic funds transfer, Federal payment, Treasury-sponsored account.</P>
                </LSTSUB>
                <REGTEXT TITLE="31" PART="208">
                    <AMDPAR> For the reasons set out in the preamble, 31 CFR part 208 is revised to read as follows:</AMDPAR>
                    <PART>
                        <HD SOURCE="HED">PART 208—MANAGEMENT OF FEDERAL AGENCY DISBURSEMENTS</HD>
                        <CONTENTS>
                            <SECHD>Sec.</SECHD>
                            <SECTNO>208.1 </SECTNO>
                            <SUBJECT>Scope and application.</SUBJECT>
                            <SECTNO>208.2 </SECTNO>
                            <SUBJECT>Definitions.</SUBJECT>
                            <SECTNO>208.3 </SECTNO>
                            <SUBJECT>Payment by electronic funds transfer.</SUBJECT>
                            <SECTNO>208.4 </SECTNO>
                            <SUBJECT>Waivers.</SUBJECT>
                            <SECTNO>208.5 </SECTNO>
                            <SUBJECT>Accounts for disbursement of Federal payments.</SUBJECT>
                            <SECTNO>208.6 </SECTNO>
                            <SUBJECT>Availability of Treasury-sponsored accounts.</SUBJECT>
                            <SECTNO>208.7 </SECTNO>
                            <SUBJECT>Agency responsibilities.</SUBJECT>
                            <SECTNO>208.8 </SECTNO>
                            <SUBJECT>Recipient responsibilities.</SUBJECT>
                            <SECTNO>208.9 </SECTNO>
                            <SUBJECT>Compliance.</SUBJECT>
                            <SECTNO>208.10 </SECTNO>
                            <SUBJECT>Reservation of rights.</SUBJECT>
                            <SECTNO>208.11 </SECTNO>
                            <SUBJECT>Accounts for disaster victims.</SUBJECT>
                        </CONTENTS>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>5 U.S.C. 301; 12 U.S.C. 90, 265, 266, 1767, 1789a; 31 U.S.C. 321, 3122, 3301, 3302, 3303, 3321, 3325, 3327, 3328, 3332, 3335, 3336, 6503.</P>
                        </AUTH>
                        <SECTION>
                            <SECTNO>§ 208.1 </SECTNO>
                            <SUBJECT>Scope and application.</SUBJECT>
                            <P>This part applies to all Federal payments made by an agency. Except as specified in § 208.4, this part requires payments, other than payments made under the Internal Revenue Code of 1986, to be made by electronic funds transfer.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§ 208.2 </SECTNO>
                            <SUBJECT>Definitions.</SUBJECT>
                            <P>The following definitions apply to this part:</P>
                            <P>
                                <E T="03">Agency</E>
                                 means any department, agency, or instrumentality of the United States Government, or a corporation owned or controlled by the Government of the United States.
                            </P>
                            <P>
                                <E T="03">Authorized payment agent</E>
                                 means any individual or entity that is appointed or otherwise selected as a representative payee or fiduciary, under regulations of the Social Security Administration, the Department of Veterans Affairs, the Railroad Retirement Board, or other agency making Federal payments, to act on behalf of an individual entitled to a Federal payment.
                            </P>
                            <P>
                                <E T="03">Direct Express® card</E>
                                 means the prepaid debit card issued to recipients of Federal benefits by a Financial Agent pursuant to requirements established by Treasury.
                            </P>
                            <P>
                                <E T="03">Disbursement</E>
                                 means, in the context of payments delivered to Treasury-sponsored accounts, the performance of the following duties by a Financial Agent acting as agent of the United States:
                            </P>
                            <P>(1) The establishment of an account for the recipient that meets the requirements of the Federal Deposit Insurance Corporation or the National Credit Union Administration Board for deposit or share insurance;</P>
                            <P>(2) The maintenance of such an account;</P>
                            <P>(3) The receipt of Federal payments through the Automated Clearing House system or other electronic means and crediting of Federal payments to the account; and</P>
                            <P>(4) The provision of recipient access to funds in the account on the terms specified by Treasury.</P>
                            <P>
                                <E T="03">Electronic benefits transfer (EBT)</E>
                                 means the provision of Federal benefit, wage, salary, and retirement payments electronically, through disbursement by a financial institution acting as a Financial Agent. For purposes of this part and Public Law 104-208, EBT includes, but is not limited to, disbursement through a Treasury-sponsored account or a Federal/State EBT program.
                            </P>
                            <P>
                                <E T="03">Electronic funds transfer</E>
                                 means any transfer of funds, other than a transaction originated by cash, check, or similar paper instrument that is initiated through an electronic terminal, telephone, computer, or magnetic tape, for the purpose of ordering, instructing, or authorizing a financial institution to debit or credit an account. The term includes, but is not limited to, Automated Clearing House transfers, Fedwire transfers, and transfers made at automated teller machines and point-of-sale terminals. For purposes of this part only, the term electronic funds transfer includes a credit card transaction.
                            </P>
                            <P>
                                <E T="03">Federal payment</E>
                                 means any payment made by an agency. The term includes, but is not limited to:
                            </P>
                            <P>(1) Federal wage, salary, and retirement payments;</P>
                            <P>(2) Vendor and expense reimbursement payments;</P>
                            <P>(3) Benefit payments;</P>
                            <P>(4) Miscellaneous payments including, but not limited to: Interagency payments; grants; loans; fees; principal, interest, and other payments related to U.S. marketable and nonmarketable securities; overpayment reimbursements; and payments under Federal insurance or guarantee programs for loans; and</P>
                            <P>(5) Payments under the Internal Revenue Code of 1986 (26 U.S.C.).</P>
                            <P>
                                <E T="03">Federal/State EBT program</E>
                                 means any program that provides access to Federal benefit, wage, salary, and retirement payments and to State-administered benefits through a single delivery system and in which Treasury designates a Financial Agent to disburse the Federal payments.
                            </P>
                            <P>
                                <E T="03">Federally-insured financial institution</E>
                                 means any financial institution, the deposits of which are insured by the Federal Deposit Insurance Corporation under 12 U.S.C. Chapter 16 or, in the case of a credit union, the member accounts of which are insured by the National Credit Union Share Insurance Fund under 12 U.S.C. Chapter 14, Subchapter II.
                            </P>
                            <P>
                                <E T="03">Financial Agent</E>
                                 means a financial institution that has been designated by Treasury as a Financial Agent for the provision of electronic funds transfer or EBT services under any provision of Federal law, including 12 U.S.C. 90, 265, 266, 1767, and 1789a, and 31 U.S.C. 3122 and 3303, as amended by the Omnibus Consolidated Appropriations Act, 1997, Section 664, Public Law 104-208.
                            </P>
                            <P>
                                <E T="03">Financial institution</E>
                                 means:
                            </P>
                            <P>(1) Any insured bank as defined in section 3 of the Federal Deposit Insurance Act (12 U.S.C. 1813) or any bank which is eligible to make application to become an insured bank under section 5 of such Act (12 U.S.C. 1815);</P>
                            <P>(2) Any mutual savings bank as defined in section 3 of the Federal Deposit Insurance Act (12 U.S.C. 1813) or any bank which is eligible to make application to become an insured bank under section 5 of such Act (12 U.S.C. 1815);</P>
                            <P>
                                (3) Any savings bank as defined in section 3 of the Federal Deposit Insurance Act (12 U.S.C. 1813) or any bank which is eligible to make application to become an insured bank 
                                <PRTPAGE P="25292"/>
                                under section 5 of such Act (12 U.S.C. 1815);
                            </P>
                            <P>(4) Any insured credit union as defined in section 101 of the Federal Credit Union Act (12 U.S.C. 1752) or any credit union which is eligible to make application to become an insured credit union under section 201 of such Act (12 U.S.C. 1781);</P>
                            <P>
                                (5) Any savings association as defined in section 3 of the Federal Deposit Insurance Act (12 U.S.C. 1813) which is an insured depository institution (as defined in such Act) (12 U.S.C. 1811 
                                <E T="03">et seq.</E>
                                ) or is eligible to apply to become an insured depository institution under the Federal Deposit Insurance Act (12 U.S.C. 1811 
                                <E T="03">et seq.</E>
                                ); and
                            </P>
                            <P>(6) Any agency or branch of a foreign bank as defined in section 1(b) of the International Banking Act, as amended (12 U.S.C. 3101).</P>
                            <P>
                                <E T="03">Individual</E>
                                 means a natural person.
                            </P>
                            <P>
                                <E T="03">Recipient</E>
                                 means an individual, corporation, or other public or private entity that is authorized to receive a Federal payment from an agency.
                            </P>
                            <P>
                                <E T="03">Secretary</E>
                                 means Secretary of the Treasury.
                            </P>
                            <P>
                                <E T="03">Treasury</E>
                                 means the United States Department of the Treasury.
                            </P>
                            <P>
                                <E T="03">Treasury-sponsored account</E>
                                 means a Direct Express card account, a U.S. Debit Card account, or another account established pursuant to §  208.5 or §  208.11.
                            </P>
                            <P>
                                <E T="03">U.S. Debit Card</E>
                                 means the prepaid debit card issued to recipients of certain Federal payments by a Financial Agent pursuant to requirements established by Treasury.
                            </P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.3 </SECTNO>
                            <SUBJECT>Payment by electronic funds transfer.</SUBJECT>
                            <P>Subject to §  208.4, and notwithstanding any other provision of law, all Federal payments made by an agency shall be made by electronic funds transfer. This requirement does not apply to payments under the Internal Revenue Code of 1986.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.4 </SECTNO>
                            <SUBJECT>Waivers.</SUBJECT>
                            <P>(a) Payment by electronic funds transfer is not required in the following cases:</P>
                            <P>(1) Where an individual:</P>
                            <P>(i) Was born prior to May 1, 1921, and was receiving payment by check on March 1, 2013;</P>
                            <P>(ii) Receives a type of payment for which Treasury does not offer delivery to a Treasury-sponsored account. In such cases, those payments are not required to be made by electronic funds transfer, unless and until such payments become eligible for deposit to a Treasury-sponsored account;</P>
                            <P>(iii) Is ineligible for a Treasury-sponsored account because of suspension or cancellation of the individual's Treasury-sponsored account by the Financial Agent;</P>
                            <P>(iv) Has filed a waiver request with Treasury certifying that payment by electronic funds transfer would impose a hardship because of the individual's inability to manage an account at a financial institution or a Treasury-sponsored account due to a mental impairment, and Treasury has not rejected the request; or</P>
                            <P>(v) Has filed a waiver request with Treasury certifying that payment by electronic funds transfer would impose a hardship because of the individual's inability to manage an account at a financial institution or a Treasury-sponsored account due to the individual living in a remote geographic location lacking the infrastructure to support electronic financial transactions, and Treasury has not rejected the request;</P>
                            <P>(2) Where the political, financial, or communications infrastructure in a foreign country does not support payment by electronic funds transfer;</P>
                            <P>(3) Where the payment is to a recipient within an area designated by the President or an authorized agency administrator as a disaster area. This waiver is limited to payments made within 120 days after the disaster is declared;</P>
                            <P>(4) Where either:</P>
                            <P>(i) A military operation is designated by the Secretary of Defense in which uniformed services undertake military actions against an enemy; or</P>
                            <P>(ii) A call or order to, or retention on, active duty of members of the uniformed services is made during a war or national emergency declared by the President or Congress;</P>
                            <P>(5) Where a threat may be posed to national security, the life or physical safety of any individual may be endangered, or a law enforcement action may be compromised;</P>
                            <P>(6) Where the agency does not expect to make payments to the same recipient within a one-year period on a regular, recurring basis and remittance data explaining the purpose of the payment is not readily available from the recipient's financial institution receiving the payment by electronic funds transfer; and</P>
                            <P>(7) Where an agency's need for goods and services is of such unusual and compelling urgency that the Government would be seriously injured unless payment is made by a method other than electronic funds transfer; or, where there is only one source for goods or services and the Government would be seriously injured unless payment is made by a method other than electronic funds transfer.</P>
                            <P>(b) An individual who requests a waiver under paragraphs (a)(1)(iv) and (v) of this section shall provide, in writing, to Treasury a certification supporting that request, in such form that Treasury may prescribe. The individual shall attest to the certification before a notary public, or otherwise file the certification in such form that Treasury may prescribe.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.5 </SECTNO>
                            <SUBJECT>Accounts for disbursement of Federal payments.</SUBJECT>
                            <P>Treasury may designate a Financial Agent to establish and administer Treasury-sponsored accounts for individuals for the disbursement of Federal payments, including benefit, retirement, salary, miscellaneous, vendor, expense reimbursement and tax payments. Such accounts may be established upon terms and conditions that the Secretary considers appropriate or necessary and shall be made available at a reasonable cost and with the same consumer protections provided to other account holders at the financial institution. Treasury may deliver payments to such accounts and the maintenance of accounts and the provision of account-related services under this section shall constitute reasonable duties of a Financial Agent of the United States.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.6 </SECTNO>
                            <SUBJECT>Availability of Treasury-sponsored accounts.</SUBJECT>
                            <P>An individual who receives a Federal payment shall be eligible to open a Treasury-sponsored account under terms and conditions established by Treasury.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.7 </SECTNO>
                            <SUBJECT>Agency responsibilities.</SUBJECT>
                            <P>An agency shall put into place procedures that allow recipients to provide the information necessary for the delivery of payments to the recipient by electronic funds transfer to an account at the recipient's financial institution or to a Treasury-sponsored account.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.8 </SECTNO>
                            <SUBJECT>Recipient responsibilities.</SUBJECT>
                            <P>Each recipient who is required to receive payment by electronic funds transfer shall provide the information necessary to effect payment by electronic funds transfer. For recipients who do not designate a bank account for the receipt of payments, Treasury may disburse payments to a Treasury-sponsored account or to an account to which the recipient is receiving other Federal payments.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.9 </SECTNO>
                            <SUBJECT>Compliance.</SUBJECT>
                            <P>
                                (a) Treasury will monitor agencies' compliance with this part. Treasury may require agencies to provide information 
                                <PRTPAGE P="25293"/>
                                about their progress in converting payments to electronic funds transfer.
                            </P>
                            <P>(b) If an agency fails to make payment by electronic funds transfer, as prescribed under this part, Treasury may assess a charge to the agency pursuant to 31 U.S.C. 3335.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.10 </SECTNO>
                            <SUBJECT>Reservation of rights.</SUBJECT>
                            <P>The Secretary reserves the right, in the Secretary's discretion, to waive any provision(s) of this part in any case or class of cases.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§  208.11 </SECTNO>
                            <SUBJECT>Accounts for disaster victims.</SUBJECT>
                            <P>
                                Treasury may establish and administer accounts at any financial institution designated as a Financial Agent for disaster victims in order to allow for the delivery by electronic funds transfer of one or more Federal payments. Such accounts may be established upon terms and conditions that the Secretary considers appropriate or necessary in light of the circumstances. Treasury may deliver payments to these accounts notwithstanding any other payment instructions from the recipient and without regard to the requirements of §§  208.4 and 208.7 and §  210.5 of this chapter. For purposes of this section, “disaster victim” means an individual or entity located within an emergency area, or an individual or entity that has relocated or been displaced from an emergency area as a result of a major disaster or emergency. “Emergency area” means a geographical area in which there exists an emergency or disaster declared by the President pursuant to the National Emergencies Act (50 U.S.C. 1601 
                                <E T="03">et seq.</E>
                                ) or the Robert T. Stafford Disaster Relief and Emergency Assistance Act (42 U.S.C. 5121 
                                <E T="03">et seq.</E>
                                ). The maintenance of accounts and the provision of account-related services under this section shall constitute reasonable duties of a Financial Agent of the United States.
                            </P>
                        </SECTION>
                    </PART>
                </REGTEXT>
                <SIG>
                    <NAME>David A. Lebryk,</NAME>
                    <TITLE>Fiscal Assistant Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08058 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 52</CFR>
                <DEPDOC>[EPA-R09-OAR-2019-0564; FRL-10006-63-Region 9]</DEPDOC>
                <SUBJECT>Air Plan Approval; California; Mojave Desert Air Quality Management District</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>The Environmental Protection Agency (EPA) is taking final action to approve revisions to the Mojave Desert Air Quality Management District (MDAQMD) portion of the California State Implementation Plan (SIP). These revisions concern emissions of volatile organic compounds (VOCs) from organic liquid and gasoline transfer and storage operations. We are approving local rules that regulate these emission sources under the Clean Air Act (CAA or the Act). We are also converting the conditional approval of the MDAQMD's reasonably available control technology (RACT) SIPs for the 1997 and 2008 ozone standards, as it applies to these rules, to a full approval.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule will be effective on June 1, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The EPA has established a docket for this action under Docket ID No. EPA-R09-OAR-2019-0564. All documents in the docket are listed on the 
                        <E T="03">https://www.regulations.gov</E>
                         website. Although listed in the index, some information is not publicly available, 
                        <E T="03">e.g.,</E>
                         Confidential Business Information or other information whose disclosure is restricted by statute. Certain other material, such as copyrighted material, is not placed on the internet and will be publicly available only in hard copy form. Publicly available docket materials are available through 
                        <E T="03">https://www.regulations.gov,</E>
                         or please contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section for additional availability information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Rebecca Newhouse, EPA Region IX, 75 Hawthorne St., San Francisco, CA 94105. By phone: (415) 972-3004 or by email at 
                        <E T="03">newhouse.rebecca@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Throughout this document, “we,” “us” and “our” refer to the EPA.</P>
                <HD SOURCE="HD1">Table of Contents </HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Proposed Action</FP>
                    <FP SOURCE="FP-2">II. Public Comments and EPA Responses</FP>
                    <FP SOURCE="FP-2">III. EPA Action</FP>
                    <FP SOURCE="FP-2">IV. Incorporation by Reference</FP>
                    <FP SOURCE="FP-2">V. Statutory and Executive Order Reviews</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Proposed Action</HD>
                <P>On November 20, 2019 (84 FR 64035), the EPA proposed to approve the following rules into the California SIP.</P>
                <GPOTABLE COLS="5" OPTS="L2,tp0,i1" CDEF="s50,10,r75,12,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">
                            Local 
                            <LI>agency</LI>
                        </CHED>
                        <CHED H="1">Rule No.</CHED>
                        <CHED H="1">Rule title</CHED>
                        <CHED H="1">Amended</CHED>
                        <CHED H="1">Submitted</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">MDAQMD</ENT>
                        <ENT>461</ENT>
                        <ENT>Gasoline Transfer and Dispensing</ENT>
                        <ENT>01/22/2018</ENT>
                        <ENT>05/23/2018</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">MDAQMD</ENT>
                        <ENT>462</ENT>
                        <ENT>Organic Liquid Loading</ENT>
                        <ENT>01/22/2018</ENT>
                        <ENT>05/23/2018</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">MDAQMD</ENT>
                        <ENT>463</ENT>
                        <ENT>Storage of Organic Liquids</ENT>
                        <ENT>01/22/2018</ENT>
                        <ENT>05/23/2018</ENT>
                    </ROW>
                </GPOTABLE>
                <P>We proposed to approve these rules because we determined that they comply with the relevant CAA requirements. We also proposed to find that the rule revisions fulfill commitments made by the District and the California Air Resources Board (CARB) necessary for the EPA to convert the partial conditional approval of the District's RACT demonstrations for the 1997 8-hr ozone National Ambient Air Quality Standards (NAAQS) and the 2008 8-hr ozone NAAQS (also referred to as the 2006 and 2015 RACT SIPs) with respect to Rules 461, 462, and 463 (83 FR 5921, February 12, 2018), to a full approval. Our proposed action contains more information on the rules and our evaluation.</P>
                <HD SOURCE="HD1">II. Public Comments and EPA Responses</HD>
                <P>The EPA's proposed action provided a 30-day public comment period. During the comment period, we received seventeen anonymous comments. Ten commenters supported EPA's proposal. Two commenters discussed the impacts of air pollution generally, and the importance of clean air and regulating emissions from gasoline in the Mojave Desert, without expressing either support or opposition to the EPA's proposal. We thank these commenters for their input.</P>
                <P>
                    The issues raised by the five remaining commenters are described below, followed by the EPA's response. One commenter asked why the EPA proposed to enforce the updated regulations only in the Mojave Desert, and not in the remainder of the United States, and two more wrote that although the proposed rule is a “great” revision to the Mojave AQMD rules, “the EPA needs to use their power of regulating emission sources under the Clean Air Act on a wider scope of the 
                    <PRTPAGE P="25294"/>
                    United States.” The EPA notes that the Clean Air Act establishes a system of cooperative federalism, in which the federal government sets air quality standards, and the states have the responsibility to develop a plan “which provides for implementation, maintenance, and enforcement” of such standards.
                    <SU>1</SU>
                    <FTREF/>
                     The states then submit these State Implementation Plans to the EPA. Under section 110(k)(3) of the Act, the EPA “shall approve such submittal as a whole if it meets all of the applicable requirements” of the Act. In this instance, the MDAQMD has modified its local rules, and CARB has submitted these changes as a State Implementation Plan revision. These rules are applicable only within the District. The EPA does not have the authority to expand the applicability of these rules beyond the boundaries of the MDAQMD. Because the EPA proposed to determine that the SIP submission meets the requirements of the Act applicable to a SIP revision, and these commenters have not suggested that the submittal does not meet the necessary requirements for approval, the comments have not changed the EPA's view on the approvability of the submitted rules.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         42 U.S.C. 7401(a).
                    </P>
                </FTNT>
                <P>
                    Another commenter wrote that “[w]hen environmental issues grow worse, it should not be an appropriate action to approve what is already in place rather than creating measures to improve state work against local pollutants.” The EPA notes that as ozone pollution worsens in a nonattainment area, the area can be reclassified, resulting in additional requirements becoming applicable under the Act.
                    <SU>2</SU>
                    <FTREF/>
                     In its proposal, the EPA proposed to find that the submitted rules met the stringency requirements currently applicable within the MDAQMD. The commenter has not suggested that the submission does not meet the requirements of the Act. Accordingly, the comment has not changed the EPA's view on the approvability of the submitted rules. To the extent that the commenter suggests that the EPA should create its own pollution control measures, any such request is outside the scope of the current action.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         42 U.S.C. 7511a.
                    </P>
                </FTNT>
                <P>
                    One commenter expressed concerns about the impacts of pollution, and wrote that “organic compounds should be considered a pollution and the polluter should be charged with either a fine or a criminal offense.” In its proposal the EPA proposed to find that the submitted rules met the SIP criteria for stringency and enforceability. This means that the rules as submitted are as stringent as the Act requires, and can be effectively enforced in the event of a violation. Under the Act, a violation of a SIP rule can be enforced by the EPA, resulting in penalties, injunctive relief, and in some instances, criminal penalties.
                    <SU>3</SU>
                    <FTREF/>
                     Members of the public may also bring citizen suits to enforce emission standards or limitations under the Act.
                    <SU>4</SU>
                    <FTREF/>
                     Accordingly, the enforcement options mentioned by the commenter may be available to address those who violate the rule. To the extent that the commenter suggests that all emissions of organic compounds should lead to a fine or a criminal offense, the EPA does not agree. The EPA proposed to find that the submitted rules met the stringency requirements of the Act, including the requirement to implement RACT. The commenter has not indicated that the rules do not meet the requirements of the Act.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         42 U.S.C. 7413.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         42 U.S.C. 7604.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">III. EPA Action</HD>
                <P>No comments were submitted that change our assessment of the rules as described in our proposed action. Therefore, as authorized in section 110(k)(3) of the Act, the EPA is fully approving these rules into the California SIP. The EPA is also converting the partial conditional approval of the District's 2006 and 2015 RACT SIPs with respect to Rules 461, 462 and 463 into a full approval.</P>
                <HD SOURCE="HD1">IV. Incorporation by Reference</HD>
                <P>
                    In this rule, the EPA is finalizing regulatory text that includes incorporation by reference. In accordance with requirements of 1 CFR 51.5, the EPA is finalizing the incorporation by reference of the MDAQMD rules described in the amendments to 40 CFR part 52 set forth below. The EPA has made, and will continue to make, these documents available through 
                    <E T="03">www.regulations.gov</E>
                     and at the EPA Region IX Office (please contact the person identified in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this preamble for more information).
                </P>
                <HD SOURCE="HD1">V. Statutory and Executive Order Reviews</HD>
                <P>Under the Clean Air Act, the Administrator is required to approve a SIP submission that complies with the provisions of the Act and applicable Federal regulations. 42 U.S.C. 7410(k); 40 CFR 52.02(a). Thus, in reviewing SIP submissions, the EPA's role is to approve state choices, provided that they meet the criteria of the Clean Air Act. Accordingly, this action merely approves state law as meeting Federal requirements and does not impose additional requirements beyond those imposed by state law. For that reason, this action:</P>
                <P>• Is not a significant regulatory action subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);</P>
                <P>• Is not an Executive Order 13771 (82 FR 9339, February 2, 2017) regulatory action because SIP approvals are exempted under Executive Order 12866;</P>
                <P>
                    • Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    • Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);</P>
                <P>• Does not have Federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);</P>
                <P>• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);</P>
                <P>• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);</P>
                <P>• Is not subject to requirements of Section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because application of those requirements would be inconsistent with the Clean Air Act; and</P>
                <P>• Does not provide the EPA with the discretionary authority to address, as appropriate, disproportionate human health or environmental effects, using practicable and legally permissible methods, under Executive Order 12898 (59 FR 7629, February 16, 1994).</P>
                <P>In addition, the SIP is not approved to apply on any Indian reservation land or in any other area where the EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rule does not have tribal implications and will not impose substantial direct costs on tribal governments or preempt tribal law as specified by Executive Order 13175 (65 FR 67249, November 9, 2000).</P>
                <P>
                    The Congressional Review Act, 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     as added by the Small Business Regulatory Enforcement 
                    <PRTPAGE P="25295"/>
                    Fairness Act of 1996, generally provides that before a rule may take effect, the agency promulgating the rule must submit a rule report, which includes a copy of the rule, to each House of the Congress and to the Comptroller General of the United States. The EPA will submit a report containing this action 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>
                    . A major rule cannot take effect until 60 days after it is published in the 
                    <E T="04">Federal Register</E>
                    . This action is not a “major rule” as defined by 5 U.S.C. 804(2).
                </P>
                <P>Under section 307(b)(1) of the Clean Air Act, petitions for judicial review of this action must be filed in the United States Court of Appeals for the appropriate circuit by June 30, 2020. Filing a petition for reconsideration by the Administrator of this final rule does not affect the finality of this action for the purposes of judicial review nor does it extend the time within which a petition for judicial review may be filed, and shall not postpone the effectiveness of such rule or action. This action may not be challenged later in proceedings to enforce its requirements. (See section 307(b)(2).)</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 52</HD>
                    <P>Environmental protection, Air pollution control, Incorporation by reference, Intergovernmental relations, Ozone, Reporting and recordkeeping requirements, Volatile organic compounds.</P>
                </LSTSUB>
                <SIG>
                    <DATED>Dated: April 14, 2020.</DATED>
                    <NAME>John Busterud,</NAME>
                    <TITLE>Regional Administrator, Region IX. </TITLE>
                </SIG>
                <P>Part 52, Chapter I, Title 40 of the Code of Federal Regulations is amended as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 52—APPROVAL AND PROMULGATION OF IMPLEMENTATION PLANS</HD>
                </PART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>1. The authority citation for Part 52 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                            42 U.S.C. 7401 
                            <E T="03">et seq.</E>
                        </P>
                    </AUTH>
                </REGTEXT>
                <SUBPART>
                    <HD SOURCE="HED">Subpart F—California</HD>
                </SUBPART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>
                        2. Section 52.220 is amended by adding paragraphs (c)(156)(vii)(C), (c)(191)(i)(C)(
                        <E T="03">2</E>
                        ), (c)(198)(i)(E)(
                        <E T="03">3</E>
                        ), (c)(518)(i)(A)(
                        <E T="03">3</E>
                        ), (
                        <E T="03">4</E>
                        ), and (
                        <E T="03">5</E>
                        ) to read as follows:
                    </AMDPAR>
                    <SECTION>
                        <SECTNO>§ 52.220 </SECTNO>
                        <SUBJECT>Identification of plan-in part.</SUBJECT>
                        <STARS/>
                        <P>(c) * * *</P>
                        <P>(156) * * *</P>
                        <P>(vii) * * *</P>
                        <P>(C) Previously approved on January 15, 1987 in paragraph (c)(156)(vii)(A) of this section, and now deleted with replacement in the Mojave Desert Air Quality Management District in paragraph (c)(518)(i)(A)(5), Rule 463.</P>
                        <STARS/>
                        <P>(191) * * *</P>
                        <P>(i) * * *</P>
                        <P>(C) * * *</P>
                        <P>
                            (
                            <E T="03">2</E>
                            ) Previously approved on May 3, 1995 in paragraph (c)(191)(i)(C)(
                            <E T="03">1</E>
                            ) of this section, and now deleted with replacement in the Mojave Desert Air Quality Management District in paragraph (c)(518)(i)(A)(
                            <E T="03">5</E>
                            ), Rule 463.
                        </P>
                        <STARS/>
                        <P>(198) * * *</P>
                        <P>(i) * * *</P>
                        <P>(E) * * *</P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Previously approved on May 3, 1995 in paragraph (c)(198)(i)(E)(
                            <E T="03">1</E>
                            ) of this section, and now deleted with replacement in paragraphs (c)(518)(i)(A)(
                            <E T="03">3</E>
                            ) and (
                            <E T="03">4</E>
                            ), respectively, Rules 461 and 462.
                        </P>
                        <STARS/>
                        <P>(518) * * *</P>
                        <P>(i) * * *</P>
                        <P>(A) * * *</P>
                        <P>
                            (
                            <E T="03">3</E>
                            ) Rule 461, “Gasoline Transfer and Dispensing,” amended on January 22, 2018.
                        </P>
                        <P>
                            (
                            <E T="03">4</E>
                            ) Rule 462, “Organic Liquid Loading,” amended on January 22, 2018.
                        </P>
                        <P>
                            (
                            <E T="03">5</E>
                            ) Rule 463, “Storage of Organic Liquids,” amended on January 22, 2018.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 52.248 </SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>3. Section 52.248 is amended by removing and reserving paragraphs (d)(1)(i), (ii), and (iii).</AMDPAR>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08290 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 52</CFR>
                <DEPDOC>[EPA-R04-OAR-2019-0008; FRL-10007-99P—Region 4]</DEPDOC>
                <SUBJECT>
                    Air Plan Approval; Florida; 2010 1-Hour SO
                    <E T="52">2</E>
                     NAAQS Transport Infrastructure
                </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>
                        The Environmental Protection Agency (EPA) is approving Florida's September 18, 2018, State Implementation Plan (SIP) submission pertaining to the “good neighbor” provision of the Clean Air Act (CAA or Act) for the 2010 1-hour sulfur dioxide (SO
                        <E T="52">2</E>
                        ) National Ambient Air Quality Standard (NAAQS). The good neighbor provision requires each state's implementation plan to address the interstate transport of air pollution in amounts that contribute significantly to nonattainment, or interfere with maintenance, of a NAAQS in any other state. In this action, EPA has determined that Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                        <E T="52">2</E>
                         NAAQS in any other state. Therefore, EPA is approving the September 18, 2018, SIP revision as meeting the requirements of the good neighbor provision for the 2010 1-hour SO
                        <E T="52">2</E>
                         NAAQS.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule will be effective June 1, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        EPA has established a docket for this action under Docket Identification No. EPA-R04-OAR-2019-0008. All documents in the docket are listed on the 
                        <E T="03">www.regulations.gov</E>
                         website. Although listed in the index, some information may not be publicly available, 
                        <E T="03">i.e.,</E>
                         Confidential Business Information or other information whose disclosure is restricted by statute. Certain other material, such as copyrighted material, is not placed on the internet and will be publicly available only in hard copy form. Publicly available docket materials are available either electronically through 
                        <E T="03">www.regulations.gov</E>
                         or in hard copy at the Air Regulatory Management Section, Air Planning and Implementation Branch, Air and Radiation Division, U.S. Environmental Protection Agency, Region 4, 61 Forsyth Street, SW, Atlanta, Georgia 30303-8960. EPA requests that if at all possible, you contact the person listed in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section to schedule your inspection. The Regional Office's official hours of business are Monday through Friday 8:30 a.m. to 4:30 p.m., excluding Federal holidays.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Michele Notarianni, Air Regulatory Management Section, Air Planning and Implementation Branch, Air and Radiation Division, U.S. Environmental Protection Agency, Region 4, 61 Forsyth Street SW, Atlanta, Georgia 30303-8960. Ms. Notarianni can be reached via phone number (404) 562-9031 or via electronic mail at 
                        <E T="03">notarianni.michele@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    On June 2, 2010, EPA promulgated a revised primary SO
                    <E T="52">2</E>
                     NAAQS with a 
                    <PRTPAGE P="25296"/>
                    level of 75 parts per billion (ppb), based on a 3-year average of the annual 99th percentile of 1-hour daily maximum concentrations. 
                    <E T="03">See</E>
                     75 FR 35520 (June 22, 2010). Pursuant to section 110(a)(1) of the CAA, states are required to submit SIPs meeting the applicable requirements of section 110(a)(2) within three years after promulgation of a new or revised NAAQS or within such shorter period as EPA may prescribe. These SIPs, which EPA has historically referred to as “infrastructure SIPs,” are to provide for the “implementation, maintenance, and enforcement” of such NAAQS, and the requirements are designed to ensure that the structural components of each state's air quality management program are adequate to meet the state's responsibility under the CAA. Section 110(a) of the CAA requires states to make a SIP submission to EPA for a new or revised NAAQS, but the contents of individual state submissions may vary depending upon the facts and circumstances. The content of the changes in such SIP submissions may also vary depending upon what provisions the state's approved SIP already contains. Section 110(a)(2) requires states to address basic SIP elements such as requirements for monitoring, basic program requirements, and legal authority that are designed to assure attainment and maintenance of the NAAQS.
                </P>
                <P>Section 110(a)(2)(D)(i)(I) of the CAA requires SIPs to include provisions prohibiting any source or other type of emissions activity in one state from emitting any air pollutant in amounts that will contribute significantly to nonattainment, or interfere with maintenance, of the NAAQS in another state. The two clauses of this section are referred to as prong 1 (significant contribution to nonattainment) and prong 2 (interference with maintenance of the NAAQS).</P>
                <P>
                    On September 18, 2018, the Florida Department of Environmental Protection (FDEP) submitted a revision to the Florida SIP addressing prongs 1 and 2 of CAA section 110(a)(2)(D)(i)(I) for the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS. EPA is approving FDEP's September 18, 2018, SIP submission because the State demonstrated that Florida will not contribute significantly to nonattainment, or interfere with maintenance, of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in any other state. All other elements related to the infrastructure requirements of section 110(a)(2) for the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS for Florida are addressed in separate rulemakings.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         EPA acted on the other elements of Florida's June 3, 2013, infrastructure SIP submission, as supplemented on January 8, 2014, for the 2010 1-hour SO
                        <E T="52">2</E>
                         NAAQS on September 30, 2016 (81 FR 67179).
                    </P>
                </FTNT>
                <P>
                    In a notice of proposed rulemaking (NPRM) published on February 10, 2020 (85 FR 7480), EPA proposed to approve Florida's September 18, 2018, SIP revision for the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS (“Florida NPRM”). The details of the SIP revision and the rationale for EPA's action is explained in the Florida NPRM. Comments on the proposed rulemaking were due on or before March 11, 2020.
                </P>
                <HD SOURCE="HD1">II. Response to Comments</HD>
                <P>EPA received five sets of adverse comments from anonymous commenters (collectively referred to as the “Commenter”). These comments are included in the docket for this final action. EPA has summarized the comments and provided responses below.</P>
                <P>
                    <E T="03">Comment 1:</E>
                     The Commenter states that EPA has not demonstrated that Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in any other state. The Commenter claims this is “best evidenced” in Escambia County, Alabama, which borders the Florida panhandle counties of Escambia 
                    <SU>2</SU>
                    <FTREF/>
                     and Santa Rosa. As summarized below, the Commenter raises specific concerns regarding several aspects of EPA's analysis of Florida's SIP revision as it relates to interstate transport of SO
                    <E T="52">2</E>
                     emissions into Alabama.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         All subsequent references to “Escambia County” in this notice are to Escambia County, Alabama.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Comment 1.a:</E>
                     The Commenter quotes the following statement from the Florida NPRM: “Regarding three out-of-state DRR 
                    <SU>3</SU>
                    <FTREF/>
                     sources within 50 km 
                    <SU>4</SU>
                    <FTREF/>
                     of the Florida border which are located in Alabama, the information available to the Agency does not indicate there are violations of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in Alabama to which Florida sources could contribute.” The Commenter then asserts that the opposite is also true—that the available information does not indicate that there are no violations of the NAAQS.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         On August 21, 2015 (80 FR 51052), EPA separately promulgated air quality characterization requirements for the 2010 1-hour SO
                        <E T="52">2</E>
                         NAAQS in the Data Requirements Rule (DRR).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         The Commenter's use of “km” in this instance refers to kilometers (km).
                    </P>
                </FTNT>
                <P>
                    <E T="03">Comment 1.b:</E>
                     The Commenter notes that Escambia County is currently designated unclassifiable for the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS and claims that EPA has not provided information to change this designation, and therefore should not approve the September 18, 2018, Florida SIP submission because the State may be contributing to a NAAQS violation in that county. The Commenter states that the absence of evidence of a violation does not mean that there is no violation of the NAAQS, which is why EPA designated the county as unclassifiable, and that the SIP revision should not be approved until EPA or Florida demonstrates that there is no violation. The Commenter then asserts that without evidence that there is not a NAAQS violation in Escambia County, EPA cannot say that Florida is not contributing to a downwind NAAQS violation or is not interfering with maintenance in Escambia County and further asserts that EPA cannot approve Florida's SIP revision until the “NAAQS status” of that county is resolved.
                </P>
                <P>
                    <E T="03">Comment 1.c:</E>
                     The Commenter notes that, contrary to EPA's statement in the notice, Table 5 in the Florida NPRM does not show a decline in SO
                    <E T="52">2</E>
                     emissions from 2012 to 2017/2018 for the Alabama sources listed therein. The Commenter points out that if the reference is to Table 6, there is a decrease in emissions relative to 2012 and an increase in emissions relative to 2017. The Commenter states that EPA should explain why there is an upward trend and include 2019 emissions to be more complete.
                </P>
                <P>
                    <E T="03">Comment 1.d:</E>
                     The Commenter references “similar concerns” that it raised regarding EPA's December 31, 2019, NPRM (84 FR 72278) (“Alabama NPRM”) proposing to approve Alabama's good neighbor SIP revision for the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS and asks that EPA consider those comments in evaluating the Florida NPRM.
                    <SU>5</SU>
                    <FTREF/>
                     The Commenter then broadly restates some of these comments as summarized below.
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         The docket for EPA's action on Alabama's August 20, 2018, SIP submission is located at 
                        <E T="03">www.regulations.gov</E>
                         with Docket ID: EPA-R04-OAR-2018-0792.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         On March 10, 2020 (85 FR 13755), EPA responded to adverse comments received and finalized approval of Alabama's August 20, 2018, SIP submission.
                    </P>
                </FTNT>
                <P>
                    The Commenter refers to its comments on the Alabama NPRM regarding the unmodeled flare emissions at the Escambia Operating Company—Big Escambia Creek Plant (Big Escambia) facility in Alabama.
                    <SU>7</SU>
                    <FTREF/>
                     With respect to the Florida SIP submission, the Commenter urges EPA or the state to correct the modeling for 
                    <PRTPAGE P="25297"/>
                    Big Escambia to account for missing emissions from a flare at the facility.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         Regarding Big Escambia, the Alabama Department of Environmental Management (ADEM) provided supplemental information in September and December of 2019 to address the issues with the original modeling for this source performed under the DRR for the purposes of evaluating interstate transport of SO
                        <E T="52">2</E>
                         from Alabama into Florida.
                    </P>
                </FTNT>
                <P>
                    The Commenter also refers to its comments on the Alabama NPRM regarding the need for additional modeling receptors in the unmodeled area in Florida between a Florida source, Breitburn Operating, L.P. (Breitburn), and Big Escambia.
                    <SU>8</SU>
                    <FTREF/>
                     With respect to the Florida NPRM, the Commenter urges EPA or the state to include more receptors in the modeling for Big Escambia and references Breitburn in its discussion noting that EPA is proposing to approve Florida's SIP revision but does not have evidence that there is not a NAAQS violation in Escambia County.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         EPA notes that Big Escambia is located 8 km from the Florida border and 21 km northwest from Breitburn, the nearest SO
                        <E T="52">2</E>
                         source in Florida. Breitburn is located less than 5 km from the Alabama-Florida border.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Comment 1.e:</E>
                     The Commenter believes that, in the absence of air quality monitors, the best way to assess air quality is through modeling. The Commenter predicts that EPA will not model in response to the comments but will offer some rationale for why omitting the flare emissions at Big Escambia and leaving a gap in the receptor grid between Breitburn and Big Escambia are a sufficient and conservative substitute for modeling. The Commenter conducted simple modeling runs via AERSCREEN 
                    <SU>9</SU>
                    <FTREF/>
                     and claims that the results show that SO
                    <E T="52">2</E>
                     emissions are being transported across state lines from Alabama into Florida and Florida into Alabama based on simulations from Big Escambia and Breitburn. The Commenter acknowledges that AERSCREEN is a “simple screening model” which is “not capable or sophisticated enough to unequivocally answer the question of whether there are NAAQS violations around Breitburn (particularly in the unmodeled receptor gap) in Florida, or at the unclassifiable receptors in Escambia County, Alabama, or whether the prong 1 and prong 2 requirements of both Alabama and Florida have been satisfied.” The Commenter explains that it did not submit the modeling results due to only being able to estimate the hourly emissions and release characteristics of the flare at Big Escambia, which the Commenter believes EPA would use to discredit the results as invalid. The Commenter asks why EPA does not “run the modeling properly instead of making unsubstantiated technical assumptions that run counter to why modeling is used in the first place?” The Commenter notes that EPA could provide AERSCREEN runs to supplement the Agency's weight of evidence (WOE) and to evaluate the potential for transport issues “rather than speculating on what the concentrations might look like in the absence of adequate modeling.”
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         AERSCREEN is EPA's recommended screening model based on AERMOD, a steady-state plume model that incorporates air dispersion based on planetary boundary layer turbulence structure and scaling concepts, including treatment of both surface and elevated sources, and both simple and complex terrain. AERSCREEN will produce estimates of “worst-case” 1-hour concentrations for a single source, without the need for hourly meteorological data, and also includes conversion factors to estimate “worst-case” 3-hour, 8-hour, 24-hour, and annual concentrations. AERSCREEN is intended to produce concentration estimates that are equal to or greater than the estimates produced by AERMOD with a fully developed set of meteorological and terrain data, but the degree of conservatism will vary depending on the application. EPA recommends AERSCREEN and AERMOD for certain applications. See 
                        <E T="03">https://www.epa.gov/scram/air-quality-dispersion-modeling-screening-models.</E>
                    </P>
                </FTNT>
                <P>
                    <E T="03">Response 1:</E>
                     EPA disagrees with the Commenter's claim that EPA has not demonstrated that Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in any other state. EPA continues to believe that the WOE approach applied in the NPRM provides a sufficient technical justification for approving Florida's transport SIP. EPA's WOE analysis evaluated the following factors: (1) Potential ambient air quality impacts of SO
                    <E T="52">2</E>
                     emissions from certain facilities in Florida on neighboring states based on available air dispersion modeling results; (2) SO
                    <E T="52">2</E>
                     emissions from Florida sources; (3) SO
                    <E T="52">2</E>
                     ambient air quality for Florida and neighboring states; (4) SIP-approved Florida regulations that address SO
                    <E T="52">2</E>
                     emissions; and (5) federal regulations that reduce SO
                    <E T="52">2</E>
                     emissions at Florida sources. EPA's response to the Commenter's specific concerns are outlined below.
                </P>
                <P>
                    <E T="03">Response 1.a:</E>
                     EPA disagrees with the Commenter's statement that the available information “does not indicate that there are no violations of the NAAQS.” EPA's statement regarding the three out-of-state DRR sources within 50 km of Florida (Akzo Nobel Functional Chemicals—LeMoyne Site (AkzoNobel); Alabama Power Company—James M. Barry Electric Generating Plant (Plant Barry); and Big Escambia) cited by the Commenter, and EPA's determination that Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in another state, is based on EPA's WOE analysis of Florida's SIP revision.
                </P>
                <P>EPA's WOE evaluation described in Response 1 includes the information summarized in Sections III.C.1.b (Big Escambia) and III.C.2.b (Plant Barry and AkzoNobel) of the Florida NPRM. Although Plant Barry and AkzoNobel are not located in Escambia County, Alabama, EPA addresses these facilities in this response.</P>
                <P>
                    Regarding AkzoNobel and Plant Barry, these sources are both located in Mobile County, Alabama, approximately 41 km and 36 km from the Florida border, respectively. For these sources, EPA evaluated 2017 SO
                    <E T="52">2</E>
                     emissions data along with the distances to the closest neighboring state's non-DRR sources emitting over 100 tons per year (tpy) of SO
                    <E T="52">2</E>
                    . Table 5 in the Florida NPRM shows that the distances between each facility and the nearest state's source to each facility which emits over 100 tpy of SO
                    <E T="52">2</E>
                     exceed 50 km, the distance threshold Florida used to reflect the transport properties of SO
                    <E T="52">2</E>
                    .
                    <SU>10</SU>
                    <FTREF/>
                     Further, the closest sources in another state to AkzoNobel and Plant Barry are located in Mississippi. Due to the magnitude of their SO
                    <E T="52">2</E>
                     emissions and the distance to the facilities in Alabama, EPA believes that there are no Florida sources which emit SO
                    <E T="52">2</E>
                     within 50 km of AkzoNobel and Plant Barry which could interact with SO
                    <E T="52">2</E>
                     emissions from these Alabama sources in such a way as to contribute significantly to nonattainment in Alabama. In addition, EPA evaluated SO
                    <E T="52">2</E>
                     emissions trends for AkzoNobel and Plant Barry in the Florida NPRM and assessed more recent SO
                    <E T="52">2</E>
                     emissions data that has become available for Plant Barry for 2019. See Response 1.c. for additional information on the emissions data for these sources.
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         In the Florida NPRM, EPA concurred with Florida's application of the 50-km threshold as a reasonable distance to evaluate emission source impacts into neighboring states and to assess air quality monitors within 50 km of the State's border. 
                        <E T="03">See</E>
                         85 FR 7482 (February 10, 2020). The Commenter did not raise concerns with this determination.
                    </P>
                </FTNT>
                <P>
                    EPA also evaluated data from the Agency's Air Quality System (AQS) 
                    <SU>11</SU>
                    <FTREF/>
                     from the SO
                    <E T="52">2</E>
                     monitors in the surrounding areas of AkzoNobel and Plant Barry. The only monitor within 50 km of these sources is located in Mobile County, Alabama (AQS ID: 01-097-0003), and is approximately 23 km from AkzoNobel. The 2018 design value (DV) 
                    <SU>12</SU>
                    <FTREF/>
                     for this monitor is 11 ppb. As 
                    <PRTPAGE P="25298"/>
                    stated in the Florida NPRM, EPA believes that the information evaluated for AkzoNobel and Plant Barry, as part of the Agency's WOE analysis, support the Agency's conclusion that sources in Florida will not contribute significantly to nonattainment of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in a nearby state.
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         EPA's AQS contains ambient air pollution data collected by EPA, state, local, and tribal air pollution control agencies. This data is available at 
                        <E T="03">https://www.epa.gov/air-trends/air-quality-design-values.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         A “Design Value” is a statistic that describes the air quality status of a given location relative to the level of the NAAQS. The DV for the primary 2010 1-hour SO
                        <E T="52">2</E>
                         NAAQS is the 3-year average of annual 99th percentile daily maximum 1-hour values for a monitoring site. For example, the 2017 DV is calculated based on the three-year average from 2015-2017. The interpretation of the primary 
                        <PRTPAGE/>
                        2010 1-hour SO
                        <E T="52">2</E>
                         NAAQS including the data handling conventions and calculations necessary for determining compliance with the NAAQS can be found in Appendix T to 40 CFR part 50.
                    </P>
                </FTNT>
                <P>
                    Regarding Big Escambia, which is located approximately 8 km from the Florida border, EPA considered the supplemental information and modeling results provided by ADEM.
                    <SU>13</SU>
                    <FTREF/>
                     The modeling included Breitburn, the nearest SO
                    <E T="52">2</E>
                     source in Florida to Big Escambia, which is located less than 5 km from the Alabama-Florida border. As noted in the Florida NPRM and Response 1.d, Florida's submittal indicates that Breitburn's 2017 SO
                    <E T="52">2</E>
                     emissions are 1,491 tons. Due to its proximity to Big Escambia, Alabama's modeling analysis included Breitburn as a modeled nearby source using a conservative maximum potential-to-emit emissions rate of 2,181 pounds per hour (lb/hr) (9,553 tpy).
                    <SU>14</SU>
                    <FTREF/>
                     This modeling indicates that the impact of SO
                    <E T="52">2</E>
                     emissions from Breitburn do not result in Alabama's air quality exceeding the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS. EPA believes that the modeling provides a conservative estimate of Breitburn's SO
                    <E T="52">2</E>
                     impacts at locations in Alabama near the Alabama-Florida border because the Big Escambia modeling used allowable emissions of SO
                    <E T="52">2</E>
                     for Breitburn, which are approximately 6.4 times higher than Breitburn's actual annual SO
                    <E T="52">2</E>
                     emissions for 2017 (1,491 tpy). In addition, as shown in the Florida NPRM, Breitburn's 2014-2018 emissions profile demonstrates that Breitburn has consistently operated well below its permitted allowable emission rate. Thus, EPA continues to believe that Breitburn's actual contribution to SO
                    <E T="52">2</E>
                     concentrations in Alabama would likely be much less than the predicted concentrations in the Big Escambia modeling, which provides further assurances that air quality in the portion of Alabama covered in the modeling grid would remain below the level of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS.
                </P>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         See footnote 7.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         Breitburn has two sulfur recovery units that each have SO
                        <E T="52">2</E>
                         permit limits of approximately 1,000 lb/hr that were both included in the modeling performed by Alabama. However, Brietburn operates only one of the two sulfur recovery units at any given time. Therefore, the maximum allowable emissions rate in reality is approximately half of the 2,181 lb/hr modeled by Alabama. Additionally, based upon Breitburn's actual operations in 2017 and 2018, the maximum hourly SO
                        <E T="52">2</E>
                         emissions rate during that time was approximately 396 lb/hr, which is approximately 18% of the emissions rate included in Alabama's modeling.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Response 1.b:</E>
                     EPA disagrees with the Commenter. EPA's determination that Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in another state is not reliant on Escambia County's unclassifiable designation. As stated in Response 1.a, this determination is based on a WOE analysis that includes information regarding Florida SO
                    <E T="52">2</E>
                     emission sources and surrounding states' sources, including sources in Escambia County, Alabama. EPA continues to believe that the WOE analysis provided in the NPRM, which includes as one of several factors the absence of any information demonstrating a potential violation in Alabama, is adequate to determine the potential downwind impact from Florida to neighboring states.
                </P>
                <P>
                    <E T="03">Response 1.c:</E>
                     EPA acknowledges that the quoted sentence from the Florida NPRM should have referenced Table 6 instead of Table 5. Table 6 provides annual SO
                    <E T="52">2</E>
                     emissions for two Alabama sources, AkzoNobel and Plant Barry, for the years 2012-2017 (AkzoNobel) and 2012-2018 (Plant Barry).
                </P>
                <P>
                    Regarding the comment that there is an increase in SO
                    <E T="52">2</E>
                     emissions relative to 2017, annual SO
                    <E T="52">2</E>
                     emissions increased at Plant Barry from 4,218 tons in 2017 to 5,257 tons in 2018. SO
                    <E T="52">2</E>
                     emissions data are now available from Plant Barry for 2019. The data show that SO
                    <E T="52">2</E>
                     emissions from Plant Barry decreased by 1,762 tons from 2018 to 2019 (from 5,257 tons in 2018 down to 3,495 tons in 2019). Thus, the 2019 SO
                    <E T="52">2</E>
                     emissions data for Plant Barry demonstrates there is not a continued upward trend in emissions at this facility as the commenter suggests.
                </P>
                <P>
                    Emissions of SO
                    <E T="52">2</E>
                     at AkzoNobel increased relative to the year 2014 (2,320 tons) in 2015 (3,587 tons) and 2016 (3,646 tons) but decreased in 2017 (2,201 tons) to below 2014 levels. Emissions data remain unavailable from AkzoNobel for 2018 or 2019. The decrease in emissions for AkzoNobel reported in 2017 demonstrate that there is not a continued upward trend in emissions at this facility as the Commenter suggests.
                </P>
                <P>
                    EPA believes that the data in Table 6 of the NPRM, as supplemented by the 2019 SO
                    <E T="52">2</E>
                     emissions data for Plant Barry provided in this response, and the changes in controls or operations at these two sources described in the NPRM, support the Agency's conclusion that sources in Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in a nearby state.
                </P>
                <P>
                    <E T="03">Response 1.d:</E>
                     The Commenter's broad request that EPA consider all of its comments on the Alabama NPRM in this action on Florida's SIP revision is not a valid comment. Merely referring to a comment presented elsewhere does not provide EPA with sufficient information to evaluate that comment in the context of this action. Therefore, EPA is only responding to the comments from the Alabama NPRM that are restated by the Commenter in the context of the Florida NPRM.
                </P>
                <P>
                    The Commenter does not explain the relevance of its comment on the Alabama NPRM concerning flare emissions from Big Escambia to the transport of SO
                    <E T="52">2</E>
                     emissions from Florida into Alabama. EPA's evaluation of the flare characteristics in the Alabama NPRM and final rule relate specifically to the transport of SO
                    <E T="52">2</E>
                     emissions from Alabama into Florida, and thus, does not directly relate to the evaluation of Florida's SIP revision regarding the transport of SO
                    <E T="52">2</E>
                     emissions from Florida into Alabama. Regarding the influence of Big Escambia's flare emissions on Escambia County when impacts from Florida are factored in, EPA has no evidence to suggest that the emissions from Breitburn in Florida, when combined with the SO
                    <E T="52">2</E>
                     emissions at Big Escambia, including the flare emissions, will significantly contribute to nonattainment or interfere with maintenance of the NAAQS in Alabama.
                </P>
                <P>
                    The Commenter does not explain the relevance of its comment on the Alabama NPRM concerning the receptor grid to the transport of SO
                    <E T="52">2</E>
                     emissions from Florida into Alabama. Regarding the transport of SO
                    <E T="52">2</E>
                     emissions from Florida into Alabama, EPA disagrees with the Commenter's assertion that the receptor grid needs to be expanded to include modeling receptors to cover the unmodeled area between Breitburn 
                    <SU>15</SU>
                    <FTREF/>
                     and Big Escambia before EPA can approve Florida's SIP submittal. Modeling this area in Florida is not relevant to whether Florida will contribute to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in Alabama. Regarding an assessment of Breitburn's impacts in Alabama, Alabama's modeling analysis includes Breitburn as a modeled source due to its proximity to Big Escambia. 
                    <PRTPAGE P="25299"/>
                    This modeling indicates that the impact of SO
                    <E T="52">2</E>
                     emissions from Breitburn do not result in Alabama's air quality exceeding the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS. EPA continues to believe that the modeling provides a conservative estimate of Breitburn's SO
                    <E T="52">2</E>
                     impacts at locations in Alabama because the Big Escambia modeling used allowable emissions of SO
                    <E T="52">2</E>
                     for Breitburn, which are approximately 6.4 times Breitburn's actual SO
                    <E T="52">2</E>
                     emissions for 2017 (9,533 tons/1,491 tons = 6.4). Also as noted in the Florida NPRM, Breitburn's 2014-2018 emissions profile demonstrates that Breitburn has consistently operated well below its permitted allowable emission rate. Thus, Breitburn's actual impact on SO
                    <E T="52">2</E>
                     concentrations in Alabama would likely be much less than the predicted concentrations in the Big Escambia modeling.
                </P>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         Breitburn is located 4 km due south of the Alabama-Florida border but is located 21 km Southeast of Big Escambia. Big Escambia is located 8 km due north of the Alabama-Florida border. The Big Escambia modeling grid extends 15 km from Big Escambia in all directions and approximately 7 km into Florida in the direction due south of Big Escambia.
                    </P>
                </FTNT>
                <P>
                    EPA continues to believe that the WOE analysis provided in the Florida NPRM is adequate to determine the potential downwind impact from Florida to neighboring states and that the inclusion of Breitburn (at its allowable emission levels) indicates that air quality at the Alabama-Florida border is likely characterized conservatively. Thus, EPA finds that SO
                    <E T="52">2</E>
                     emissions from Breitburn will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in Alabama.
                </P>
                <P>
                    <E T="03">Response 1.e:</E>
                     Regarding the Commenter's suggestion that EPA should rely on its own resources and expertise to model whether or not Florida sources significantly contribute to nonattainment or interfere with maintenance in Escambia County, Alabama, EPA does not believe that the issues identified by the Commenter related to the Big Escambia modeling invalidate consideration of the modeling for transport purposes as part of a WOE analysis. EPA does not believe that modeling is required in all cases under CAA section 110(a)(2)(D)(i)(I) to evaluate good neighbor obligations, particularly where other available information can be used to qualitatively and quantitatively assess the potential for downwind impacts from upwind state emission sources. Here, EPA has evaluated a number of different factors in a WOE analysis based on available information, which includes the available modeling of Big Escambia, and found no basis to conclude that Florida emissions will have an adverse impact on downwind states. Therefore, EPA has concluded that Florida emissions will not significantly contribute to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in neighboring states. Therefore, as stated in our response to Comment 1.a, EPA continues to believe that the WOE analysis provided in the Florida NPRM is adequate to evaluate the potential downwind impact from Florida to neighboring states.
                </P>
                <P>
                    Regarding AERSCREEN, without the modeling input and output data used and produced by the Commenter, EPA cannot evaluate the modeling results to which the Commenter refers showing that there is transport of SO
                    <E T="52">2</E>
                     from Alabama into Florida and Florida into Alabama. Further, as the Commenter acknowledges, AERSCREEN has limitations in terms of making any definitive assessments. AERSCREEN is intended to produce pollutant concentration estimates that are conservative, for screening purposes, relative to refined modeling with AERMOD. AERSCREEN conservatively assumes that every receptor is located along the plume centerline (area of highest concentration across the plume) and worst-case meteorological conditions. Thus, the Commenter's unsupported assertions regarding the results of its AERSCREEN runs do not provide a basis for the EPA to reconsider its WOE analysis of Florida's SIP revision.
                </P>
                <P>
                    As noted earlier, the available information indicates that modeling and emissions data provide a conservative estimate of the predicted SO
                    <E T="52">2</E>
                     impacts in Alabama that may be due to transport of SO
                    <E T="52">2</E>
                     from Florida sources. EPA continues to believe that the Agency's WOE analysis of Florida's SIP revision, as supplemented with additional data discussed in the Florida NPRM, provides a sufficient basis for the Agency's assessment as to whether sources in Florida will contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in a nearby state.
                </P>
                <P>
                    <E T="03">Comment 2:</E>
                     The Commenter notes that EPA consistently uses the words “will not” when discussing the potential for significant contribution or interference with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS and asks why EPA is not using the present tense when evaluating the SIP submission from Florida. The Commenter asks whether EPA thinks a particular source is currently contributing to nonattainment or interfering with maintenance of another state's NAAQS, and if so, asserts that EPA must redo its evaluation for the present tense and repropose.
                </P>
                <P>
                    <E T="03">Response 2:</E>
                     EPA disagrees with the Commenter that the Agency must repropose using the present tense. EPA's use of the phrase “will not” is consistent with the verb tense in the good neighbor provision of the CAA, which requires SIPs to include provisions prohibiting any source or other type of emissions activity in one state from emitting any air pollutant in amounts that “will” contribute significantly to nonattainment, or interfere with maintenance, of the NAAQS in another state. 
                    <E T="03">See</E>
                     CAA section 110(a)(2)(D)(i)(I). Accordingly, EPA's evaluation and conclusion are consistent with the statutory standard in the good neighbor provision. In the NPRM, EPA evaluated data regarding historic, current, and future source activity and air quality to determine whether emissions from Florida are likely to be impacting downwind air quality, either presently or in the future, and are thus in violation of the good neighbor provision. EPA's WOE analysis of this information did not find any indication that such an impact was likely occuring currently or would be likely to occur in the future. Accordingly, EPA concluded that emissions from Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in any other state.
                </P>
                <P>
                    <E T="03">Comment 3</E>
                    : The Commenter asserts that EPA should disapprove Florida's SIP submission because the DRR modeling EPA relies on inappropriate receptor grids. Specifically, the Commenter states that “one of those geometries was not appropriate for many regions in Florida, including the Gulf of Mexico.” The Commenter claims that the National Oceanic and Atmospheric Administration (NOAA) utilizes “this same SAU modeling” and that EPA never requested or solicited input from NOAA about how EPA might improve its monitoring and forecasting of SO
                    <E T="52">2</E>
                     emissions in Florida. In addition, the Commenter believes that EPA should also disapprove the SIP submission “because the AER uses `worst case' grid cells for SO
                    <E T="52">2</E>
                     emissions measurements in Figure 3, which are also the grid cells used by the EPA in its AER standard.” The Commenter states that EPA should “reassess the grid cells used in the DRR modeling for a more refined receptor grid in areas beyond the state's borders.”
                </P>
                <P>
                    <E T="03">Response 3:</E>
                     It is unclear how the comment relates to EPA's proposal. As the comment may broadly relate to the DRR modeling referenced in sections III.C.1.a and III.C.1.b of the Florida NPRM and to the receptor grids used in that modeling, EPA believes that the modeling results support EPA's WOE determination as discussed in that notice and in Response 1.d, above. EPA 
                    <PRTPAGE P="25300"/>
                    is unable to respond any further because the Commenter did not explain, and the Agency does not understand, the meaning of the terms “geometries,” “SAU modeling,” or “AER,” in this context, and despite the Commenter's reference to “Figure 3,” the Florida NPRM does not contain any figures.
                </P>
                <P>
                    <E T="03">Comment 4:</E>
                     The Commenter states that EPA cannot approve the SIP revision because it is inconsistent with “Florida's Clean Air Act.” The Commenter claims that EPA's proposed determination confirms that Florida does not have a “meaningful permitting process for the transportation of SO
                    <E T="52">2</E>
                    ” out of Florida, because the State has not established a procedure for a “subject air-quality permit application to be transferred to the federal permit authority.” The Commenter also claims that the proposal is inconsistent with Florida's “administrative procedures for approval of the transport of pollutants that are of significant public health concern.”
                </P>
                <P>
                    <E T="03">Response 4:</E>
                     It is unclear how the comment relates to EPA's proposal. The Commenter has not explained how “Florida's Clean Air Act” and the State's administrative procedures are relevant to this rulemaking or provided any basis for its assertion that the State must establish a procedure for a “subject air-quality permit application to be transferred to the federal permit authority” before EPA can approve the SIP revision as meeting the requirements of section 110(a)(2)(D)(i)(I). To the extent that the Commenter may be referring to EPA's discussion of Florida's SIP-approved permitting programs in section III.C.4 of the Florida NPRM, EPA reiterates its position that Florida's major and minor new source review rules are designed to ensure that SO
                    <E T="52">2</E>
                     emissions due to major modifications at existing major stationary sources, modifications at minor stationary sources, and the construction of new major and minor sources subject to these rules will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in neighboring states.
                </P>
                <P>
                    <E T="03">Comment 5:</E>
                     The Commenter claims that EPA should disapprove Florida's SIP revision because it “will negatively affect the provision of electricity to residential customers in the region.” According to the Commenter, the “two most active engines in SO
                    <E T="52">2</E>
                     production are burned in utility equipment, and that equipment now accounts for the majority of production” and “EPA argues that reversing the decision would trigger an emergency rulemaking and delay the inevitable phase-out of vehicles that emit emissions.” The Commenter believes that it “would also raise costs and delay purchases, ultimately raising the cost of electricity, which would result in higher electric rates for consumers and businesses.” The Commenter also claims that EPA should disapprove the SIP revision because of the “large short-term costs of complying with an additional facility and business planning requirements and because of the adverse effect of a lawsuit on the SO
                    <E T="52">2</E>
                     manufacturers and the health and welfare of the general public.”
                </P>
                <P>
                    <E T="03">Response 5:</E>
                     EPA disagrees that approval of Florida's SIP revision will negatively affect the provision of electricity to residential customers or raise the cost of electricity. EPA's action does not create any new regulatory requirements nor does it revise any regulations or source-specific permits. Therefore, it does not impact the electric utility sector. Regarding the statements concerning a lawsuit and the reversal of an EPA decision that would trigger an emergency rulemaking, EPA cannot provide a substantive response because it is unclear what decision and lawsuit the Commenter is referencing or how they relate to Florida's good neighbor SIP revision.
                </P>
                <HD SOURCE="HD1">III. Final Action</HD>
                <P>
                    EPA is approving Florida's September 18, 2018, SIP submission as demonstrating that emissions from Florida will not contribute significantly to nonattainment or interfere with maintenance of the 2010 1-hour SO
                    <E T="52">2</E>
                     NAAQS in another state.
                </P>
                <HD SOURCE="HD1">IV. Statutory and Executive Order Reviews</HD>
                <P>
                    Under the CAA, the Administrator is required to approve a SIP submission that complies with the provisions of the Act and applicable Federal regulations. 
                    <E T="03">See</E>
                     42 U.S.C. 7410(k); 40 CFR 52.02(a). Thus, in reviewing SIP submissions, EPA's role is to approve state choices, provided that they meet the criteria of the CAA. This action merely approves state law as meeting Federal requirements and does not impose additional requirements beyond those imposed by state law. For that reason, this action:
                </P>
                <P>• Is not a significant regulatory action subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);</P>
                <P>• Is not an Executive Order 13771 (82 FR 9339, February 2, 2017) regulatory action because SIP approvals are exempted under Executive Order 12866;</P>
                <P>
                    • Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    • Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);</P>
                <P>• Does not have Federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);</P>
                <P>• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);</P>
                <P>• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);</P>
                <P>• Is not subject to requirements of Section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because application of those requirements would be inconsistent with the CAA; and</P>
                <P>• Does not provide EPA with the discretionary authority to address, as appropriate, disproportionate human health or environmental effects, using practicable and legally permissible methods, under Executive Order 12898 (59 FR 7629, February 16, 1994).</P>
                <P>The SIP is not approved to apply on any Indian reservation land or in any other area where EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rule does not have tribal implications as specified by Executive Order 13175 (65 FR 67249, November 9, 2000), nor will it impose substantial direct costs on tribal governments or preempt tribal law.</P>
                <P>
                    The Congressional Review Act, 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     as added by the Small Business Regulatory Enforcement Fairness Act of 1996, generally provides that before a rule may take effect, the agency promulgating the rule must submit a rule report, which includes a copy of the rule, to each House of the Congress and to the Comptroller General of the United States. EPA will submit a report containing this action 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>
                    . A major rule cannot take effect until 60 days after it is published in the 
                    <E T="04">Federal Register</E>
                    . This action is not a “major rule” as defined by 5 U.S.C. 804(2).
                    <PRTPAGE P="25301"/>
                </P>
                <P>
                    Under section 307(b)(1) of the CAA, petitions for judicial review of this action must be filed in the United States Court of Appeals for the appropriate circuit by June 30, 2020. Filing a petition for reconsideration by the Administrator of this final rule does not affect the finality of this action for the purposes of judicial review nor does it extend the time within which a petition for judicial review may be filed, and shall not postpone the effectiveness of such rule or action. This action may not be challenged later in proceedings to enforce its requirements. 
                    <E T="03">See</E>
                     section 307(b)(2).
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 52</HD>
                    <P>Environmental protection, Air pollution control, Incorporation by reference, Intergovernmental relations, Particulate matter, Reporting and recordkeeping requirements, Sulfur oxides.</P>
                </LSTSUB>
                <SIG>
                    <NAME>Mary Walker,</NAME>
                    <TITLE>Regional Administrator, Region 4.</TITLE>
                </SIG>
                <PART>
                    <HD SOURCE="HED">PART 52—APPROVAL AND PROMULGATION OF IMPLEMENTATION PLANS</HD>
                </PART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>1. The authority citation for part 52 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7401 
                            <E T="03">et seq.</E>
                        </P>
                    </AUTH>
                </REGTEXT>
                <SUBPART>
                    <HD SOURCE="HED">Subpart K—Florida</HD>
                </SUBPART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>
                        2. Section 52.520(e) is amended by adding a new entry for “110(a)(1) and (2) Infrastructure Requirements for the 2010 1-hour SO
                        <E T="52">2</E>
                         NAAQS” at the end of the table to read as follows:
                    </AMDPAR>
                    <SECTION>
                        <SECTNO>§ 52.520</SECTNO>
                        <SUBJECT> Identification of plan.</SUBJECT>
                        <STARS/>
                        <P>(e) * * *</P>
                        <GPOTABLE COLS="5" OPTS="L1,i1" CDEF="s50,r50,r50,r50,r50">
                            <TTITLE>EPA-Approved Florida Non-Regulatory Provisions</TTITLE>
                            <BOXHD>
                                <CHED H="1">Provision</CHED>
                                <CHED H="1">State effective date</CHED>
                                <CHED H="1">EPA approval date</CHED>
                                <CHED H="1">
                                    <E T="04">Federal Register</E>
                                    , notice
                                </CHED>
                                <CHED H="1">Explanation</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">
                                    110(a)(1) and (2) Infrastructure Requirements for the 2010 1-hour SO
                                    <E T="52">2</E>
                                     NAAQS
                                </ENT>
                                <ENT>9/18/2018</ENT>
                                <ENT>5/1/2020</ENT>
                                <ENT>[Insert citation of publication]</ENT>
                                <ENT>Addressing Prongs 1 and 2 of section 110(a)(2)(D)(i) only.</ENT>
                            </ROW>
                        </GPOTABLE>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08501 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 52</CFR>
                <DEPDOC>[EPA-R07-OAR-2020-0039; FRL-10008-22—Region 7]</DEPDOC>
                <SUBJECT>Air Plan Approval; Missouri; Removal of Control of Emissions From the Application of Automotive Underbody Deadeners</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>The Environmental Protection Agency (EPA) is taking final action to approve a revision to the State Implementation Plan (SIP) revision submitted by the State of Missouri on December 3, 2018, and supplemented by letter on May 22, 2019. Missouri requests that the EPA remove a rule related to control of emissions from the application of automotive underbody deadeners in the Kansas City, Missouri area from its SIP. This removal does not have an adverse effect on air quality. The EPA's approval of this rule revision is in accordance with the requirements of the Clean Air Act (CAA).</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This final rule is effective on June 1, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The EPA has established a docket for this action under Docket ID No. EPA-R07-OAR-2020-0039. All documents in the docket are listed on the 
                        <E T="03">https://www.regulations.gov</E>
                         website. Although listed in the index, some information is not publicly available, 
                        <E T="03">i.e.,</E>
                         CBI or other information whose disclosure is restricted by statute. Certain other material, such as copyrighted material, is not placed on the internet and will be publicly available only in hard copy form. Publicly available docket materials are available through 
                        <E T="03">https://www.regulations.gov</E>
                         or please contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section for additional information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Will Stone, Environmental Protection Agency, Region 7 Office, Air Quality Planning Branch, 11201 Renner Boulevard, Lenexa, Kansas 66219; telephone number (913) 551-7714; email address 
                        <E T="03">stone.william@epa.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Throughout this document “we,” “us,” and “our” refer to the EPA.</P>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. What is being addressed in this document?</FP>
                    <FP SOURCE="FP-2">II. Have the requirements for approval of a SIP revision been met?</FP>
                    <FP SOURCE="FP-2">III. The EPA's Response to Comments</FP>
                    <FP SOURCE="FP-2">IV. What action is the EPA taking?</FP>
                    <FP SOURCE="FP-2">V. Incorporation by Reference</FP>
                    <FP SOURCE="FP-2">VI. Statutory and Executive Order Reviews</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. What is being addressed in this document?</HD>
                <P>
                    The EPA is approving the removal of 10 Code of State Regulations (CSR) 10-2.310, 
                    <E T="03">Control of Emissions from the Application of Automotive Underbody Deadeners,</E>
                     from the Missouri SIP. As explained in detail in the EPA's proposed rule, Missouri has demonstrated that removal of 10 CSR 10-2.310 will not interfere with attainment of the NAAQS, reasonable further progress 
                    <SU>1</SU>
                    <FTREF/>
                     or any other applicable requirement of the CAA because the single source subject to the rule has permanently ceased operations and removal of the rule will not cause VOC emissions to increase. 85 FR 8230, February 13, 2020. Therefore the EPA is finalizing its proposal to remove 10 CSR 10-2.310 from the SIP.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Reasonable further progress is not applicable to the Kansas City Area because the area is in attainment of all applicable ozone standards.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">II. Have the requirements for approval of a SIP revision been met?</HD>
                <P>
                    The State submission has met the public notice requirements for SIP submissions in accordance with 40 CFR 51.102. The submission also satisfied the completeness criteria of 40 CFR part 51, appendix V. The State provided public notice on this SIP revision from February 28, 2018, to April 5, 2018 and received five comments from the EPA that related to Missouri's lack of an adequate demonstration that the rule could be removed from the SIP in 
                    <PRTPAGE P="25302"/>
                    accordance with section 110(l) of the CAA. Missouri's May 22, 2019 letter addressed the EPA's comments. In addition, the revision meets the substantive SIP requirements of the CAA, including section 110 and implementing regulations.
                </P>
                <HD SOURCE="HD1">III. The EPA's Response to Comments</HD>
                <P>
                    The public comment period on the EPA's proposed rule opened February 13, 2020, the date of its publication in the 
                    <E T="04">Federal Register</E>
                     and closed on March 16, 2020. During this period, the EPA received three comments. Two comments were not substantive and do not require a response from the EPA. The remaining comment is addressed in this document.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     How has the EPA confirmed that the facility that was subject to this rule is decommissioned and is no longer subject to 10 CSR 10-2.310?
                </P>
                <P>
                    <E T="03">Response:</E>
                     The EPA confirmed that the facility subject to this rule was decommissioned based on a publicly available source of information that confirms that General Motors no longer owns the automotive manufacturing facility. EPA has concluded that General Motors is no longer subject to 10 CSR 10-2.310. A copy of the August 2000 remedial action report in support of this statement is added to the docket.
                </P>
                <HD SOURCE="HD1">IV. What action is the EPA taking?</HD>
                <P>The EPA is taking final action to approve Missouri's request to remove 10 CSR 10-2.310 from the SIP.</P>
                <HD SOURCE="HD1">V. Incorporation by Reference</HD>
                <P>In this document, the EPA is amending regulatory text that includes incorporation by reference. As described in the amendments to 40 CFR part 52 set forth below, the EPA is removing provisions of the EPA-Approved Missouri Regulation from the Missouri State Implementation Plan, which is incorporated by reference in accordance with the requirements of 1 CFR part 51.</P>
                <HD SOURCE="HD1">VI. Statutory and Executive Order Reviews</HD>
                <P>Under the CAA, the Administrator is required to approve a SIP submission that complies with the provisions of the Act and applicable Federal regulations. 42 U.S.C. 7410(k); 40 CFR 52.02(a). Thus, in reviewing SIP submissions, EPA's role is to approve state choices, provided that they meet the criteria of the CAA. Accordingly, this action merely approves state law as meeting Federal requirements and does not impose additional requirements beyond those imposed by state law. For that reason, this action:</P>
                <P>• Is not a significant regulatory action subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);</P>
                <P>• Is not an Executive Order 13771 (82 FR 9339, February 2, 2017) regulatory action because SIP approvals are exempted under Executive Order 12866.</P>
                <P>
                    • Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    • Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);</P>
                <P>• Does not have Federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);</P>
                <P>• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);</P>
                <P>• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);</P>
                <P>• Is not subject to requirements of the National Technology Transfer and Advancement Act (NTTA) because this rulemaking does not involve technical standards; and</P>
                <P>• Does not provide EPA with the discretionary authority to address, as appropriate, disproportionate human health or environmental effects, using practicable and legally permissible methods, under Executive Order 12898 (59 FR 7629, February 16, 1994).</P>
                <P>The SIP is not approved to apply on any Indian reservation land or in any other area where EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rule does not have tribal implications and will not impose substantial direct costs on tribal governments or preempt tribal law as specified by Executive Order 13175 (65 FR 67249, November 9, 2000).</P>
                <P>
                    The Congressional Review Act, 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     as added by the Small Business Regulatory Enforcement Fairness Act of 1996, generally provides that before a rule may take effect, the agency promulgating the rule must submit a rule report, which includes a copy of the rule, to each House of the Congress and to the Comptroller General of the United States. EPA will submit a report containing this action 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>
                    <E T="03">.</E>
                     A major rule cannot take effect until 60 days after it is published in the 
                    <E T="04">Federal Register</E>
                    <E T="03">.</E>
                     This action is not a “major rule” as defined by 5 U.S.C. 804(2).
                </P>
                <P>Under section 307(b)(1) of the CAA, petitions for judicial review of this action must be filed in the United States Court of Appeals for the appropriate circuit by March 24, 2020. Filing a petition for reconsideration by the Administrator of this final rule does not affect the finality of this action for the purposes of judicial review nor does it extend the time within which a petition for judicial review may be filed and shall not postpone the effectiveness of such rule or action. This action may not be challenged later in proceedings to enforce its requirements. (See section 307(b)(2)).</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 52</HD>
                    <P>Environmental protection, Air pollution control, Incorporation by reference, Reporting and recordkeeping requirements, Volatile organic compounds.</P>
                </LSTSUB>
                <SIG>
                    <DATED>Dated: April 16, 2020.</DATED>
                    <NAME>James Gulliford,</NAME>
                    <TITLE>Regional Administrator, Region 7.</TITLE>
                </SIG>
                <P>For the reasons stated in the preamble, the EPA amends 40 CFR part 52 as set forth below:</P>
                <PART>
                    <HD SOURCE="HED">PART 52—APPROVAL AND PROMULGATION OF IMPLEMENTATION PLANS</HD>
                </PART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>1. The authority citation for part 52 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7401 
                            <E T="03">et seq.</E>
                        </P>
                    </AUTH>
                </REGTEXT>
                <SUBPART>
                    <HD SOURCE="HED">Subpart-AA Missouri</HD>
                    <SECTION>
                        <SECTNO>§ 52.1320 </SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                </SUBPART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>2. In § 52.1320, the table in paragraph (c) is amended by removing the entry “10-2.310” under the heading “Chapter 2—Air Quality Standards and Air Pollution Control Regulations for the Kansas City Metropolitan Area”.</AMDPAR>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08421 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <PRTPAGE P="25303"/>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 52</CFR>
                <DEPDOC>[EPA-R10-OAR-2019-0669, FRL-10007-28-Region 10]</DEPDOC>
                <SUBJECT>Air Plan Approval; Washington; Wallula Second 10-Year Maintenance Plan</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>
                        The Environmental Protection Agency (EPA) is approving a plan for the Wallula area in Washington State that addresses the second 10-year maintenance period for particulate matter with an aerodynamic diameter less than or equal to a nominal 10 micrometers (PM
                        <E T="52">10</E>
                        ). This plan relies upon the control measures contained in the first 10-year maintenance plan, with revisions to reflect updated permits and agreements, also approved in this action. Concurrently, we are taking final agency action on high wind and wildfire exceptional events associated with the Wallula area.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This final rule is effective June 1, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The EPA has established a docket for this action under Docket ID No. EPA-R10-OAR-2019-0669. All documents in the docket are listed on the 
                        <E T="03">https://www.regulations.gov</E>
                         website. Although listed in the index, some information is not publicly available, 
                        <E T="03">e.g.,</E>
                         Confidential Business Information or other information the disclosure of which is restricted by statute. Certain other material, such as copyrighted material, is not placed on the internet and will be publicly available only in hard copy form. Publicly available docket materials are available at 
                        <E T="03">https://www.regulations.gov,</E>
                         or please contact the person listed in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section for additional availability information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jeff Hunt, EPA Region 10, 1200 Sixth Avenue, Suite 155, Seattle, WA 98101, at (206) 553-0256, or 
                        <E T="03">hunt.jeff@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Throughout this document, wherever “we,” “us,” or “our” is used, it means the EPA.</P>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    The Wallula area was designated nonattainment for the 24-hour PM
                    <E T="52">10</E>
                     national ambient air quality standards (NAAQS) and classified as a Moderate area upon enactment of the Clean Air Act Amendments of 1990 (56 FR 56694, November 6, 1991). The Washington Department of Ecology (Ecology) submitted a Moderate area attainment plan for the Wallula area on November 13, 1991, and a Serious area plan on November 30, 2004. The EPA acted on the plans on January 27, 1997 and May 2, 2005, respectively (62 FR 3800 and 83 FR 22597). During the planning process, the EPA determined that the area attained the PM
                    <E T="52">10</E>
                     NAAQS based on 1999 through 2001 air quality monitoring data (67 FR 64815, October 22, 2002).
                </P>
                <P>
                    The PM
                    <E T="52">10</E>
                     emissions inventory for the Wallula area has remained relatively consistent over time, with agricultural dust and point sources contributing the bulk of anthropogenic impact within the area. As discussed in more detail in the proposal and later in this preamble, high wind events carrying dust from both within and outside the Wallula area play a significant role on days that exceed the PM
                    <E T="52">10</E>
                     NAAQS. On-road motor vehicles make up only approximately 1% of the overall inventory. The transportation conformity rule at 40 CFR 93.109(f) allows areas to forego establishment of motor vehicle emissions budgets where it is demonstrated that the regional motor vehicle emissions for a particular pollutant or precursor are an insignificant contributor to the air quality problem in an area. The EPA's rationale for providing for insignificance determinations may be found in the July 1, 2004, revision to the Transportation Conformity Rule (69 FR 40004). As provided in 40 CFR 93.109(f), the general criteria for insignificance determinations are based on a number of factors, including the percentage of motor vehicle emissions in the context of the total SIP inventory; the current state of air quality as determined by monitoring data for the relevant NAAQS; the absence of SIP motor vehicle control measures; and the historical trends and future projections of the growth of motor vehicle emissions in the area. Using these regulatory criteria, the EPA granted Washington's request for an exemption from conducting a regional emissions analysis for transportation conformity because motor vehicles were an insignificant source of PM
                    <E T="52">10</E>
                     emissions (70 FR 5085, 5092, February 1, 2005 (proposed action); 70 FR 22597, May 2, 2005 (final action)).
                </P>
                <P>
                    Under the Clean Air Act (CAA), specific exceedances due to natural events, such as unusually high winds, may be discounted or excluded entirely from decisions regarding an area's air quality status in appropriate circumstances. From 1996 to 2007, EPA's Natural Events Policy 
                    <SU>1</SU>
                    <FTREF/>
                     governed the process by which states could request exclusion of monitored values that exceeded the NAAQS due to “natural events” in making attainment determinations. As part of the EPA's finding of attainment for the Wallula area in 2002, the EPA determined that all exceedances that occurred in 1999 through 2001 qualified as high wind natural events under the EPA's Natural Events Policy. (67 FR 64815, October 22, 2002).
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Memorandum from the EPA's Assistant Administrator for Air and Radiation to EPA Regional Air Directors entitled “Areas Affected by Natural Events,” dated May 30, 1996 (EPA's Natural Events Policy), in effect at that time.
                    </P>
                </FTNT>
                <P>
                    Subsequently, Ecology conducted a final review of high wind natural events for the area. Ecology found that there had been nine reported PM
                    <E T="52">10</E>
                     exceedances in the Wallula area since January 1, 1995, and all but one was reasonably attributed to dust raised by unusually high winds.
                    <SU>2</SU>
                    <FTREF/>
                     On March 29, 2005, Ecology submitted the state's plan to maintain the PM
                    <E T="52">10</E>
                     NAAQS in the Wallula area for 10 years, in accordance with section 175A of the CAA, and requested that the EPA redesignate the Wallula area to attainment for the PM
                    <E T="52">10</E>
                     NAAQS. The EPA approved Ecology's submitted maintenance plan and redesignation request on August 26, 2005 (70 FR 50212).
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         The one exceedance not attributed to high winds occurred on July 3, 1997, and was attributed to an unusual and nonrecurring activity involving the transport of multiple loads of composting material near the monitor.
                    </P>
                </FTNT>
                <P>
                    On November 22, 2019, Ecology submitted a maintenance plan to cover the second 10-year maintenance period, asserting that existing control measures were adequate to maintain the PM
                    <E T="52">10</E>
                     NAAQS, after excluding specific exceptional events documented in the submission. On December 20, 2019, we proposed to approve the second 10-year maintenance plan as satisfying the requirements of section 175A of the CAA (84 FR 70130).
                </P>
                <HD SOURCE="HD1">II. Response to Comments</HD>
                <P>
                    The public comment period for our proposed rule ended on January 21, 2020. We received one comment letter from the J.R. Simplot Company (Simplot), the owner and operator of the Simplot Feeders cattle feedlot, a facility located in the Wallula area and identified in the state's second 10-year maintenance plan. The comment letter generally supported approval of the State Implementation Plan (SIP) revision for the Wallula area. However, Simplot's letter also requested clarification on the following three 
                    <PRTPAGE P="25304"/>
                    issues: The feedlot Fugitive Dust Control Plan (FDCP), the emissions inventory, and the projected future design value concentrations used in the maintenance demonstration.
                </P>
                <P>
                    <E T="03">Comment 1:</E>
                     “Simplot offers clarifications to EPA's summary of the FDCP provided in the FR notice (84 FR 70132). Simplot's FDCP does not `prevent dust from any fugitive or point source from crossing the Simplot property line,' nor does it `require road dust suppression, better staff training, etc.' The FDCP meets the WAC requirements for fugitive dust and `fall-out' and identifies best management practices (BMPs) that have been found to be the most effective in minimizing fugitive dust emissions from the facility. Examples of those BMPs that are implemented as appropriate include water application to pens and roads, application of dust suppression on facility roads, as well as pen cleaning and maintenance. The FDCP also identifies the training provided to facility employees who have responsibility with implementing BMPs.”
                </P>
                <P>
                    <E T="03">Response 1:</E>
                     The EPA disagrees with the commenter. The Simplot Feeders' cattle feedlot is subject to a federally-enforceable new source review permit (Approval Order No. 18AQ-E018, issued March 5, 2018) that specifically requires Simplot to have and implement a fugitive dust control plan. Specifically, facility-wide permit condition 2.2.1. states, “During operation of the feedlot, Simplot shall follow the fugitive dust control plan submitted to Ecology, and modified annually in accordance with the facility Operations and Maintenance (O&amp;M) Plan. Fugitive dust control measures shall be sufficient to prevent dust from any fugitive or point sources from crossing the Simplot property line.” Additionally, permit condition 9 states, “A site-specific O&amp;M manual for the hay processing filters, any feedlot sprinklers or cross fencing systems or other feedlot Best Management Practices (BMPs), monitoring equipment, monitoring procedures, and monitoring schedules for the feedlot control (BMPs) measures shall be developed and followed . . . The O&amp;M manual shall at a minimum include: . . .9.4 The current Fugitive Dust Control Plan (FDCP).” Simplot's FDCP, in turn, specifically provides for road dust suppression, better staff training, daily observations, and daily adaptive best management practices to control fugitive dust.
                    <SU>3</SU>
                    <FTREF/>
                     Therefore, the language in the proposal accurately reflects Simplot's legal obligations with respect to Simplot's FDCP and no clarification is required.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Road dust suppression (see FDCP “Water Trucks” and “Road Treatment” page 7); staff training (see FDCP “Training” page 9); daily observations (see FDCP “Sprinkler System” page 6, “Water Trucks” page 7, “Daily Adaptive Management” pages 8-9); and daily adaptive management (see FDCP “Daily Adaptive Management” pages 8-9).
                    </P>
                </FTNT>
                <P>
                    <E T="03">Comment 2:</E>
                     “Simplot appreciates EPA's recognition that Ecology's revised emission factor for the cattle feedlots is a conservative approach (84 FR 70132); however, Simplot believes use of Ecology's updated emission factor mischaracterizes the change in emissions between baseline years presented in the SIP.
                </P>
                <P>Specifically, Ecology failed to provide context regarding the effect of the new emission factor with respect to the 2002 emission inventory in the SIP. During the public comment period of the draft SIP, Simplot provided comments to Ecology (Attachment 2) that the activity levels, including cattle headcount was higher at the feedlot in 2002 than in 2014. As such, the relative emissions for the feedlot were higher in 2002 than in 2014. Simplot identified that applying the updated emission factor to the 2002 data would show a relative decrease rather than the increase Ecology presented in Table 7 of the SIP.”</P>
                <P>
                    <E T="03">Response 2:</E>
                     Simplot's clarification is noted. However, we believe this issue was already adequately addressed in our proposed rulemaking when we stated, “The overall source mix and emissions levels are generally consistent with the 2002 attainment emissions inventory contained in the first 10-year maintenance plan. While there has been some increase in emissions activity since 2002, Ecology explained and the EPA verified that much of the difference between the 2002 and 2014 inventories is due to revised emissions inventory methodology. For example, Ecology revised the emissions factor for cattle feedlots by increasing it approximately eightfold, a conservative approach.” See page 70131.
                </P>
                <P>
                    We note two factors related to Simplot's comment. First, it is not unusual for emissions inventory methodologies or emissions factors to change over time at the state or federal level with additional research or source test data. Second, the conservative methodology used by Ecology yielded a 2025 projected design value concentration of 145 μg/m
                    <SU>3</SU>
                    , below the 150 μg/m
                    <SU>3</SU>
                     threshold for demonstrating continued attainment the PM
                    <E T="52">10</E>
                     NAAQS in the Wallula area. Any argument for using a less conservative approach, yielding a lower projected design value concentration, would therefore not change the EPA's approval of Ecology's maintenance demonstration because the worst-case scenario is already below 150 μg/m
                    <SU>3</SU>
                    .
                </P>
                <P>
                    <E T="03">Comment 3:</E>
                     “Simplot agrees with EPA's position that Ecology took a conservative approach for emission projections (years 2025 and 2030) by including highest actual emissions, potential to emit, and maximum permitted capacity (84 FR 70132). EPA discusses that Ecology used the most conservative methodology in determining the 2025 design concentration, where the design concentration was determined to be 145 μg/m
                    <SU>3</SU>
                    , below the 24-hour PM
                    <E T="52">10</E>
                     NAAQS of 150 ug/m
                    <SU>3</SU>
                    . EPA goes on to state that using `a less conservative methodology factoring the natural events and using maximum 5-year actual rather than maximum allowable permit limits, the projected 2025 design concentration would be 82 μg/m
                    <SU>3</SU>
                    ' (84 FR 70132) . . . There is no additional value to including an analysis of Simplot's actual maximum head count for an alternative 2025 Design Value. Simplot recommends that EPA, in its final action on the Wallula SIP, drop the alternative 2025 Design Value based on Simplot's actual maximum heat count.”
                </P>
                <P>
                    <E T="03">Response 3:</E>
                     As discussed previously, Ecology used a generally conservative, worst-case scenario methodology in projecting potential future emissions and PM
                    <E T="52">10</E>
                     concentrations. Specifically, as it relates to Simplot, the 2025 projected future design concentration of 145 μg/m
                    <SU>3</SU>
                     represented no consideration of potential natural events and assumed the Simplot facility would be operating at maximum permitted capacity (80,000 head of cattle). Because of concerns that the general public might not understand the worst-case scenario methodology, Ecology provided supplemental future design concentrations using less conservative methodologies for informational, rather than regulatory purposes. These supplementary projected concentrations ranged from 71 μg/m
                    <SU>3</SU>
                     to 132 μg/m
                    <SU>3</SU>
                    , more consistent with historical and current concentrations monitored in the Wallula area if potential natural events are considered. However, the EPA's proposed approval was based on our determination that the 2025 projected future design concentration of 145 μg/m
                    <SU>3</SU>
                    , calculated in the maintenance demonstration, was below the 150 μg/m
                    <SU>3</SU>
                     threshold for demonstrating continued attainment the PM
                    <E T="52">10</E>
                     NAAQS in the Wallula area.
                </P>
                <P>
                    We have determined the commenter's requested clarifications are not warranted at this time because we have explained our rationale for approval in 
                    <PRTPAGE P="25305"/>
                    our proposed rule and in the response to comments provided in this preamble, and the additional analysis is not necessary in light of our approval at the higher projected emissions levels. Therefore, we are finalizing our action as proposed.
                </P>
                <HD SOURCE="HD1">III. Final Action</HD>
                <P>
                    The EPA is approving Ecology's second 10-year maintenance plan for the Wallula area as satisfying the requirements of section 175A of the CAA. We are taking final agency action on Ecology's request to exclude wildfire and high wind event-influenced data from August 14, 2015, and September 5 and 6, 2017, with the determination that the PM
                    <E T="52">10</E>
                     exceedances on the identified dates were due to exceptional events and can be excluded in determining the attainment status of the area.
                </P>
                <P>
                    We are also approving and incorporating by reference into the SIP at 40 CFR 52.2470(d), updated source-specific requirements for Tyson Fresh Meats, Boise White Paper, now known as Packaging Corporation of America (Wallula Mill),
                    <SU>4</SU>
                    <FTREF/>
                     and Simplot Feeders. In addition, we are updating the list of supplementary documents in 40 CFR 52.2470(e) to include the 2003 “Columbia Plateau Windblown Dust Natural Events Action Plan” and Ecology's 2018 update of the “Fugitive Dust Control Guidelines for Beef Cattle Feedlots and Best Management Practices.”
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         Note that, subsequent to EPA's proposed action, Ecology submitted a modified air operating permit for the Wallula Mill, which was issued on December 9, 2019. The only changes to the permit relevant for purposes of this action are that the name of the permittee was changed from Boise White Paper L.L.C. to Packaging Corporation of America and that Permit Condition Q.1, which we had proposed to approve into the SIP, is now numbered Condition P.1. No substantive changes have been made to the provision proposed for incorporation by reference into the SIP.
                    </P>
                </FTNT>
                <P>
                    In taking final action to approve Ecology's second 10-year maintenance plan for the Wallula area, we note, as discussed previously, that the first 10-year maintenance plan for the area did not contain any control measures on direct PM
                    <E T="52">10</E>
                     emissions from on-road vehicles because the emissions inventory was so heavily dominated by direct PM
                    <E T="52">10</E>
                     emissions from agricultural dust sources and a small set of point sources. In comparing the 2002 inventory used in the first 10-year maintenance plan to the 2014 inventory used in the second 10-year maintenance plan, mobile source emissions continued to remain steady at 1% of the overall emissions inventory. Because on-road emissions of direct PM
                    <E T="52">10</E>
                     continue to be insignificant, a regional emissions analysis is not required as part future transportation conformity determinations. However, a conformity determination that meets other applicable criteria in Table 1 of 40 CFR 93.109(b) is still required (
                    <E T="03">e.g.,</E>
                     consultation). Hot-spot requirements for projects in PM
                    <E T="52">10</E>
                     areas in 40 CFR 93.116 must also be satisfied, subject to certain exceptions. 
                    <E T="03">See</E>
                     40 CFR 93.109(f). In 2017, the boundaries of the Walla Walla Valley Metropolitan Planning Organization were modified to include the Wallula PM
                    <E T="52">10</E>
                     maintenance area. As such, the area is now considered to be a metropolitan area for transportation conformity purposes and must meet the applicability requirements in 40 CFR 93.102(a) and the frequency requirements in 40 CFR 93.104.
                </P>
                <HD SOURCE="HD1">IV. Incorporation by Reference</HD>
                <P>
                    In this rule, the EPA is finalizing regulatory text that includes incorporation by reference. In accordance with requirements of 1 CFR 51.5, we are finalizing the incorporation by reference as described in the amendments to 40 CFR part 52 set forth below. The EPA has made, and will continue to make, these materials generally available through 
                    <E T="03">https://www.regulations.gov</E>
                     and at the EPA Region 10 Office (please contact the person identified in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this preamble for more information). Therefore, these materials have been approved by the EPA for inclusion in the SIP, have been incorporated by reference by the EPA into that plan, are fully federally-enforceable under sections 110 and 113 of the CAA as of the effective date of the final rulemaking of the EPA's approval, and will be incorporated by reference in the next update to the SIP compilation.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         62 FR 27968 (May 22, 1997).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">V. Statutory and Executive Order Review</HD>
                <P>Under the CAA, the Administrator is required to approve a SIP submission that complies with the provisions of the CAA and applicable federal regulations. 42 U.S.C. 7410(k); 40 CFR 52.02(a). Thus, in reviewing SIP submissions, the EPA's role is to approve State choices, provided that they meet the criteria of the CAA. Accordingly, this action merely approves State law as meeting federal requirements and does not impose additional requirements beyond those imposed by State law. For that reason, this action:</P>
                <P>• Is not a “significant regulatory action” subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);</P>
                <P>• Is not an Executive Order 13771 (82 FR 9339, February 2, 2017) regulatory action because SIP approvals are exempted under Executive Order 12866;</P>
                <P>
                    • Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    • Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);</P>
                <P>• Does not have federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);</P>
                <P>• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);</P>
                <P>• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);</P>
                <P>• Is not subject to requirements of section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because it does not address technical standards; and</P>
                <P>• Does not provide the EPA with the discretionary authority to address, as appropriate, disproportionate human health or environmental effects, using practicable and legally permissible methods, under Executive Order 12898 (59 FR 7629, February 16, 1994).</P>
                <P>The SIP is not approved to apply on any Indian reservation land in Washington or any other area where the EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rule does not have tribal implications and will not impose substantial direct costs on tribal governments or preempt tribal law as specified by Executive Order 13175 (65 FR 67249, November 9, 2000).</P>
                <P>
                    The Congressional Review Act, 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     as added by the Small Business Regulatory Enforcement Fairness Act of 1996, generally provides that before a rule may take effect, the agency promulgating the rule must submit a rule report, which includes a copy of the rule, to each House of the Congress and to the Comptroller General of the United States. The EPA will submit a report containing this action and other required information to the U.S. Senate, the U.S. House of 
                    <PRTPAGE P="25306"/>
                    Representatives, and the Comptroller General of the United States prior to publication of the rule in the 
                    <E T="04">Federal Register</E>
                    . A major rule cannot take effect until 60 days after it is published in the 
                    <E T="04">Federal Register</E>
                    . This action is not a “major rule” as defined by 5 U.S.C. 804(2).
                </P>
                <P>Under section 307(b)(1) of the CAA, petitions for judicial review of this action must be filed in the United States Court of Appeals for the appropriate circuit by June 30, 2020. Filing a petition for reconsideration by the Administrator of this final rule does not affect the finality of this action for the purposes of judicial review nor does it extend the time within which a petition for judicial review may be filed, and shall not postpone the effectiveness of such rule or action. This action may not be challenged later in proceedings to enforce its requirements. (See section 307(b)(2)).</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 52</HD>
                    <P>Environmental protection, Air pollution control, Carbon monoxide, Incorporation by reference, Intergovernmental relations, Lead, Nitrogen dioxide, Ozone, Particulate matter, Reporting and recordkeeping requirements, Sulfur oxides, Volatile organic compounds.</P>
                </LSTSUB>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                         42 U.S.C. 7401 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <SIG>
                    <DATED>Dated: April 10, 2020.</DATED>
                    <NAME>Christopher Hladick,</NAME>
                    <TITLE>Regional Administrator, Region 10.</TITLE>
                </SIG>
                <P>For the reasons set forth in the preamble, 40 CFR part 52 is amended as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 52—APPROVAL AND PROMULGATION OF IMPLEMENTATION PLANS</HD>
                </PART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>1. The authority citation for part 52 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7401 
                            <E T="03">et seq.</E>
                        </P>
                    </AUTH>
                </REGTEXT>
                <SUBPART>
                    <HD SOURCE="HED">Subpart WW—Washington</HD>
                </SUBPART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>2. In § 52.2470:</AMDPAR>
                    <AMDPAR>a. Amend the table in paragraph (d) by:</AMDPAR>
                    <AMDPAR>i. Removing the entries “IBP (now known as Tyson Foods, Inc.)”, “Boise White Paper LLC Permit”, and “Fugitive Dust Control Plan for Simplot Feeders Limited Partnership”; and</AMDPAR>
                    <AMDPAR>ii. Adding the entries “Tyson Fresh Meats, Inc.”, “Packaging Corporation of America, Wallula Mill”, and “Simplot Feeders Limited Partnership” at the end of the table; and</AMDPAR>
                    <AMDPAR>b. In paragraph (e) amend Table 2 by:</AMDPAR>
                    <AMDPAR>
                        i. Adding a fourth entry for “Particulate Matter (PM
                        <E T="52">10</E>
                        ) 2nd 10-Year Maintenance Plan” immediately below the entry “Particulate Matter (PM
                        <E T="52">10</E>
                        ) 2nd 10-Year Limited Maintenance Plan”, “Spokane” and
                    </AMDPAR>
                    <AMDPAR>ii. Adding the entries “2003 Columbia Plateau Windblown Dust Natural Events Action Plan” and “2018 Fugitive Dust Control Guidelines for Beef Cattle Feedlots and Best Management Practices” at the end of the table.</AMDPAR>
                    <P>The additions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 52.2470</SECTNO>
                        <SUBJECT> Identification of plan.</SUBJECT>
                        <STARS/>
                        <P>(d) * * *</P>
                        <GPOTABLE COLS="5" OPTS="L1,p7,7/8,i1" CDEF="s50,r50,10,r50,r100">
                            <TTITLE>
                                EPA-Approved State of Washington Source-Specific Requirements 
                                <SU>1</SU>
                            </TTITLE>
                            <BOXHD>
                                <CHED H="1">Name of source</CHED>
                                <CHED H="1">
                                    Order/permit 
                                    <LI>No.</LI>
                                </CHED>
                                <CHED H="1">
                                    State
                                    <LI>effective </LI>
                                    <LI>date</LI>
                                </CHED>
                                <CHED H="1">
                                    EPA approval 
                                    <LI>date</LI>
                                </CHED>
                                <CHED H="1">Explanations</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">Tyson Fresh Meats, Inc</ENT>
                                <ENT>13AQ-E526</ENT>
                                <ENT>4/16/2014</ENT>
                                <ENT>
                                    5/1/2020, [Insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                                <ENT>
                                    Except:
                                    <LI>1. Decontamination Cabinets;</LI>
                                    <LI>2. Meat Cutting/Packing;</LI>
                                    <LI>6. Wastewater Floatation;</LI>
                                    <LI>8. Utility Equipment;</LI>
                                    <LI>10. Other;</LI>
                                    <LI>References to “WAC 173-460-040” in Determinations”;</LI>
                                    <LI>The portion of Approval Condition 2.a which states, “and consumption of no more than 128 million cubic feet/of natural gas per year. Natural gas consumption records for the dryer shall be maintained for the most recent 24 month period and be available to Ecology for inspection. An increase in natural gas consumption that exceeds the above level may require a Notice of Construction.”; Approval Condition 3; Approval Condition 4; Approval Condition 5; Approval Condition 6.e; Approval Condition 9.a.ii; Approval Condition 9.a.iv; Approval Condition 9.a.v; Approval Condition 9.a.vi; Approval Condition 10.a.ii; Approval Condition 10.b; Approval Condition 11.a; Approval Condition 11.b; Approval Condition 11.e; Approval Condition 12; Approval Condition 15; The section titled “Your Right to Appeal”; and The section titled “Address and Location Information.”</LI>
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">Packaging Corporation of America (Wallula Mill)</ENT>
                                <ENT>0003697</ENT>
                                <ENT>4/1/2018</ENT>
                                <ENT>
                                    5/1/2020, [Insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                                <ENT>Condition P.1 only.</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">Simplot Feeders Limited Partnership</ENT>
                                <ENT>Fugitive Dust Control Plan</ENT>
                                <ENT>3/1/2018</ENT>
                                <ENT>
                                    5/1/2020, [Insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                            </ROW>
                            <TNOTE>
                                <SU>1</SU>
                                 The EPA does not have the authority to remove these source-specific requirements in the absence of a demonstration that their removal would not interfere with attainment or maintenance of the NAAQS, violate any prevention of significant deterioration increment or result in visibility impairment. Washington Department of Ecology may request removal by submitting such a demonstration to the EPA as a SIP revision.
                            </TNOTE>
                        </GPOTABLE>
                        <P>
                            (e) * * *
                            <PRTPAGE P="25307"/>
                        </P>
                        <GPOTABLE COLS="5" OPTS="L1,i1" CDEF="s75,r40,10,r50,r50">
                            <TTITLE>Table 2—Attainment, Maintenance, and Other Plans</TTITLE>
                            <BOXHD>
                                <CHED H="1">Name of SIP provision</CHED>
                                <CHED H="1">
                                    Applicable 
                                    <LI>geographic or </LI>
                                    <LI>nonattainment </LI>
                                    <LI>area</LI>
                                </CHED>
                                <CHED H="1">
                                    State 
                                    <LI>submittal </LI>
                                    <LI>date</LI>
                                </CHED>
                                <CHED H="1">
                                    EPA approval
                                    <LI>date</LI>
                                </CHED>
                                <CHED H="1">Explanations</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW RUL="s">
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW EXPSTB="04" RUL="s">
                                <ENT I="21">
                                    <E T="02">Attainment and Maintenance Planning—Particulate Matter (PM</E>
                                    <E T="0735">10</E>
                                    <E T="02">)</E>
                                </ENT>
                            </ROW>
                            <ROW EXPSTB="00">
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">
                                    Particulate Matter (PM
                                    <E T="0732">10</E>
                                    ) 2nd 10-Year Maintenance Plan
                                </ENT>
                                <ENT>Wallula</ENT>
                                <ENT>11/22/19</ENT>
                                <ENT>
                                    5/1/2020, [Insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW RUL="s">
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW EXPSTB="04" RUL="s">
                                <ENT I="21">
                                    <E T="02">Supplementary Documents</E>
                                </ENT>
                            </ROW>
                            <ROW EXPSTB="00">
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">2003 Columbia Plateau Windblown Dust Natural Events Action Plan</ENT>
                                <ENT/>
                                <ENT>11/22/19</ENT>
                                <ENT>
                                    5/1/2020, [Insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">2018 Fugitive Dust Control Guidelines for Beef Cattle Feedlots and Best Management Practices</ENT>
                                <ENT/>
                                <ENT>11/22/19</ENT>
                                <ENT>
                                    5/1/2020, [Insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                            </ROW>
                        </GPOTABLE>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08123 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 52</CFR>
                <DEPDOC>[EPA-R03-OAR-2019-0663; FRL-10007-98-Region 3]</DEPDOC>
                <SUBJECT>Approval and Promulgation of Air Quality Implementation Plans; Delaware; Infrastructure Requirements for the 2015 Ozone Standard and Revisions to Modeling Requirements</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>The Environmental Protection Agency (EPA) is approving two state implementation plan (SIP) submissions submitted by the State of Delaware. The first submission addresses the basic program elements, including, but not limited to, regulatory structure, monitoring, modeling, legal authority, and adequate resources necessary to assure attainment and maintenance of the National Ambient Air Quality Standards (NAAQS). This type of SIP submission is referred to as an infrastructure SIP submission. Delaware made this submission in order to address the infrastructure requirements for the 2015 ozone NAAQS. EPA is approving Delaware's infrastructure SIP submission in accordance with the requirements of Clean Air Act (CAA) section 110(a). EPA is also approving a second submission from Delaware which updates a reference to the current version of EPA's modeling guidance.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This final rule is effective on June 1, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        EPA has established a docket for this action under Docket ID Number EPA-R03-OAR-2019-0663. All documents in the docket are listed on the 
                        <E T="03">https://www.regulations.gov</E>
                         website. Although listed in the index, some information is not publicly available, 
                        <E T="03">e.g.,</E>
                         confidential business information (CBI) or other information whose disclosure is restricted by statute. Certain other material, such as copyrighted material, is not placed on the internet and will be publicly available only in hard copy form. Publicly available docket materials are available through 
                        <E T="03">https://www.regulations.gov,</E>
                         or please contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section for additional availability information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Joseph Schulingkamp, Planning &amp; Implementation Branch (3AD30), Air &amp; Radiation Division, U.S. Environmental Protection Agency, Region III, 1650 Arch Street, Philadelphia, Pennsylvania 19103. The telephone number is (215) 814-2021. Mr. Schulingkamp can also be reached via electronic mail at 
                        <E T="03">schulingkamp.joseph@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Background</HD>
                <P>On February 10, 2020 (85 FR 7494), EPA published a notice of proposed rulemaking (NPRM) for the State of Delaware. In the NPRM, EPA proposed approval of two SIP submissions submitted on behalf of the State of Delaware by the Delaware Department of Natural Resources (DNREC).</P>
                <P>DRNEC submitted the first SIP submission on October 11, 2018 to address the infrastructure SIP requirements of CAA section 110(a)(2) for the 2015 ozone NAAQS. This submission addressed the following elements of CAA section 110(a)(2): (A), (B), (C), (D)(i)(I), (D)(i)(II), (E), (F), (G), (H), (J), (K), (L), and (M). On November 4, 2019, DNREC submitted a letter identifying outdated references in its October 11, 2018 submission and committing to submit a future SIP revision in order to address the deficiency. With this letter, Delaware requested that EPA conditionally approve the State's submission with respect to CAA section 110(a)(2)(K), based on the commitment to submit a future SIP revision to update a State regulation to reflect current requirements with respect to modeling.</P>
                <P>
                    On December 16, 2019, however, DNREC submitted a second SIP submission to amend Title 7 of the Delaware Administrative Code (DE Admin. Code), Regulation 1125, 
                    <E T="03">Requirements for Preconstruction Review</E>
                     in the current EPA-approved SIP for Delaware. The State intended this submission to meet the commitment described in the State's November 4, 2019 letter as previously described. This second submission revises a section of Regulation 1125 to incorporate by reference the most recent revision to 
                    <PRTPAGE P="25308"/>
                    EPA's Guideline on Air Quality Models into State regulation. Specifically, the revision changes Delaware's regulation that references the “Guideline on Air Quality Models” as published by EPA's Office of Air Quality Planning and Standards in July 1986 and supplemented in July 1987 to the “Guideline on Air Quality Models (40 CFR part 51, Appendix W, July 1, 2019 ed.).” Because Delaware has submitted the intended SIP revision outlined in the State's November 4, 2019 letter, EPA considered CAA section 110(a)(2)(K) of Delaware's October 11, 2018 SIP submission for full approval instead of the November 4, 2019 request for conditional approval.
                </P>
                <HD SOURCE="HD1">II. EPA Analysis</HD>
                <P>
                    EPA has analyzed Delaware's October 11, 2018 infrastructure SIP submission for the 2015 ozone NAAQS and has determined that it meets the applicable requirements of CAA section 110(a)(2). EPA also reviewed Delaware's revisions to 7 DE Admin. Code 1125 and concludes that the revised references to 40 CFR part 51, Appendix W, as published in the July 2019 edition of the CFR, are the correct modeling guidelines to use for implementation of CAA programs. A detailed summary of EPA's review and rationale for approving Delaware's submissions may be found in the technical support document (TSD) for the proposed rulemaking action which is available online at 
                    <E T="03">www.regulations.gov,</E>
                     docket number EPA-R03-OAR-2019-0663. Other specific requirements and background information, as well as the rationale for EPA's proposed action, are explained in the NPRM and will not be restated here.
                </P>
                <HD SOURCE="HD1">III. Response to Comments</HD>
                <P>EPA received four sets of comments in response to the NPRM that are available in the docket for this action. Summaries of the significant adverse comments and EPA's responses are provided below.</P>
                <P>
                    <E T="03">Comment 1:</E>
                     The first commenter stated that EPA should disapprove Delaware's infrastructure SIP submission because, “it is substantially higher than the 2012 federal levels EPA established for that smog-forming pollutant.” The commenter continued by mentioning a “1,000-pound-per-square-mile rule” which, the commenter stated, Delaware and New Jersey have already implemented while other states have not but are now in the process of complying.
                </P>
                <P>
                    <E T="03">Response 1:</E>
                     EPA disagrees with the comment. The commenter did not provide any additional information beyond general assertions; the commenter did not identify any specific infrastructure element. The commenter suggests Delaware has substantially higher smog-forming pollutants than “2012 federal levels,” but EPA notes that the Agency did not set any “federal levels” in the 2012 calendar year for any smog-forming pollutants such as oxides of nitrogen (NO
                    <E T="52">X</E>
                    ) or volatile organic compounds (VOCs). Furthermore, EPA notes the purpose of an infrastructure SIP is to ensure the state has addressed the basic program elements, including, but not limited to, regulatory structure, monitoring, modeling, legal authority, and adequate resources necessary to assure attainment and maintenance of the NAAQS; an infrastructure SIP submission is not required to address the nonattainment plan SIP submission requirements of section 110(a)(2)(I) for attainment of the NAAQS in question.
                    <SU>1</SU>
                    <FTREF/>
                     To the extent that Delaware has designated nonattainment areas for this NAAQS, the State will address and EPA will evaluate those requirements in a separate action. With respect to a “1,000-pound-per-square-mile rule,” EPA is unaware of any such rule implemented by any of the states named by the commenter, nor was EPA able to identify the commenter's concerns with EPA's proposed approval of Delaware's infrastructure submission as it relates to any such rule.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Guidance on Infrastructure State Implementation Plan (SIP) Elements under Clear Air Act Section 110(a)(1) and 110(a)(2),” Memorandum from Stephen D. Page, September 13, 2013.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Comment 2:</E>
                     The second commenter suggested that EPA should disapprove Delaware's infrastructure SIP submission, “because of its findings that either EPA hasn't considered this issue fully or that it is not sufficiently vigilant in its enforcement of its regulations.” The commenter also stated that EPA should disapprove the infrastructure SIP submission out of concern that the State will not be able to sustain its planned measures to reduce ozone during the next two decades. The commenter also referenced four reasonably available control technology (RACT) programs in the states of Delaware, New Jersey, New York, and the Commonwealth of Pennsylvania, and suggested that EPA should disapprove Delaware's infrastructure SIP submission, “until all four states have RACT programs that are approved.”
                </P>
                <P>
                    <E T="03">Response 2:</E>
                     EPA disagrees with the commenter's statement that, “EPA hasn't considered this issue fully or that it is not sufficiently vigilant in its enforcement of its regulations.” In the TSD for this rulemaking action, EPA determined that the State of Delaware is currently operating a program to provide for the enforcement of emission limits and other control measures, means, or techniques as may be necessary or appropriate to meet the applicable requirements of the CAA. Delaware's SIP submission references several State laws and regulations which allow the State to exercise its programmatic authority to utilize enforcement powers, and to impose criminal, civil, and administrative penalties to sources in the State that violate applicable SIP emission limits or control measures.
                </P>
                <P>EPA further disagrees that the Agency should disapprove Delaware's submission based on the assertion that the State may not be able to sustain its ozone reductions for the next two decades. In terms of the SIP submissions before EPA in this rulemaking action, the commenter did not identify any specific infrastructure SIP deficiencies which would prevent the State from meeting its obligations. Although the commenter does not identify any specific CAA requirements, EPA believes the commenter is referring to the maintenance plan requirements under CAA section 175A which is analogous to the commenter's phrasing “. . . to sustain ozone reductions for the next two decades.” CAA section 175A requires any state requesting a redesignation of a nonattainment area to submit a revision to provide for the maintenance of the NAAQS for at least 10 years. A state is also required under CAA section 175A(b) to submit a second revision to provide for the maintenance of the NAAQS for an additional 10 years after the expiration of the first 10-year period; thus, ensuring maintenance of the NAAQS for a total of 20 years. The latter maintenance plan requirements under section 175A are not applicable in the context of an infrastructure SIP submission.</P>
                <P>EPA also disagrees that it should disapprove Delaware's infrastructure submission because it has not yet approved RACT submissions for the 2015 ozone NAAQS for the States of Delaware, New Jersey, New York, and the Commonwealth of Pennsylvania. These RACT requirements are not relevant to the applicable infrastructure SIP submission requirements of CAA section 110(a)(1) and 110(a)(2), but rather to the requirements in CAA sections 110(a)(2)(I), 182 and 184. These sections establish requirements for nonattainment area SIP submission and the states included in the Ozone Transport Region (OTR).</P>
                <P>
                    As explained in the response to Comment 1 of this preamble, the 
                    <PRTPAGE P="25309"/>
                    purpose of an infrastructure SIP is not to meet nonattainment plan requirements for the NAAQS, but to ensure that a state's SIP includes basic program elements necessary to assure attainment, maintenance, and enforcement of the NAAQS. The requirements of CAA sections 110(a)(2)(I), 175A, 182, and 184 all relate to states' attainment planning requirements if they have designated nonattainment areas for the NAAQS in question. SIP submissions to meet these requirements are due by different statutorily prescribed deadlines under subparts 2 through 5 under part D. Because the CAA directs states to submit these nonattainment plan SIP submissions on a separate schedule, EPA does not interpret the CAA to require states to address these requirements in the infrastructure SIP submission due three years after promulgation or revision of a NAAQS.
                </P>
                <P>
                    <E T="03">Comment 3:</E>
                     The third commenter questioned EPA's proposed approval of Delaware's infrastructure SIP submission with respect to section 110(a)(2)(K) pertaining to modeling requirements, including the revision to Regulation 1125. The commenter asserted EPA has already approved an infrastructure SIP submission from the State of New Mexico in which that State had language similar to that of the State of Delaware, and thus suggested that EPA is being inconsistent in its approach to this infrastructure SIP element. The comment further asserted that EPA must explain why Delaware's pre-existing regulation was different from the New Mexico regulation, or else “recall the approval of New Mexico's SIP action and force the state to fix the problem.” The comment also suggested that EPA cannot require Delaware to revise its regulations with respect to modeling authority and requirements to meet CAA section 110(a)(2)(K) “while allowing New Mexico to skirt federal regulations.”
                </P>
                <P>
                    <E T="03">Response 3:</E>
                     EPA disagrees with the commenter. First, as EPA stated in the NPRM and the TSD for this rulemaking action, Delaware is correctly addressing the requirements of section 110(a)(2)(K) in this action. The State correctly addressed the deficiency initially identified by EPA and submitted a separate SIP revision to change the reference in Regulation 1125 to refer clearly to the Guideline on Air Quality Models in 40 CFR part 51, appendix W. Delaware initially identified an existing state regulation to meet the requirements of 110(a)(2)(K) that explicitly referenced an outdated version of EPA's Guideline on Air Quality Models. Upon further investigation, EPA determined, and Delaware agreed, that the State regulation did not authorize the State to use the most recent version of EPA's Guideline on Air Quality Models. Delaware made the necessary changes to the State regulation. EPA proposed approval of Delaware's revision to Regulation 1125 because the revision is consistent with CAA section 110(a)(2)(K) and allows the State to comply and use the correct modeling guidelines found in 40 CFR part 51, appendix W.
                </P>
                <P>
                    Second, EPA disagrees with the commenter's assertion that the Agency is allowing states to “skirt federal regulations” or that the Agency must “recall the approval of New Mexico's SIP action and force the state to fix the problem.” EPA assumes the commenter is referring to the final rulemaking notice (FRN) published on September 18, 2019, relating to New Mexico's 2015 ozone NAAQS infrastructure SIP.
                    <SU>2</SU>
                    <FTREF/>
                     In the New Mexico FRN, EPA responded to similar comments regarding the appropriateness of the Agency's proposed approval of CAA section 110(a)(2)(K) and explained why the Agency believed the wording of the New Mexico regulation was sufficient in the response to comments section. In that action, upon evaluation of the authority provided by the regulation in question, EPA and the State agreed that New Mexico's regulations submitted to meet the relevant CAA requirements provide the State with the authority and the requirement to use the latest version of EPA's Guideline on Air Quality Models, also known as Appendix W, and is not restricting the State to use the version referenced in the State's regulation.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See</E>
                         84 FR 49057, September 18, 2019; “Air Plan Approval; New Mexico; Infrastructure for the 2015 Ozone National Ambient Air Quality Standards and Repeal of State Regulations for Total Suspended Particulate”.
                    </P>
                </FTNT>
                <P>Finally, EPA is not acting on any New Mexico SIP submission in this action, thus how New Mexico's SIP meets CAA section 110(a)(2)(K) is not relevant to the approval of Delaware's Regulation 1125 or the Delaware infrastructure SIP submission for the 2015 ozone NAAQS with respect to CAA section 110(a)(2)(K). Further, the New Mexico action's public comment period closed on May 20, 2019 and the FRN was published on September 18, 2019 (84 FR 49057, September 18, 2019); there is no basis to reopen that action at this time, nor does the commenter provide any such basis.</P>
                <P>
                    <E T="03">Comment 4:</E>
                     The fourth commenter asked why EPA was approving Delaware's modeling regulation change. The commenter claimed Delaware's ozone air quality has remained substantially unchanged from 2005 through 2012 even though ozone levels fell in other states. The comment referenced an “Ozone Science Program's (OSP) review of the Virginia program and other states' EPA-issued Ground Level Ozone Standards (GLOS),” but did not elaborate this review's conclusions. The comment claims that EPA approved Delaware's proposed rule change based on flawed science and because of political and regulatory considerations. The comment concludes by claiming, “As a result of EPA's disregard for its own standards, Delaware's ozone standards remain virtually unchanged from 2012 until 2022.”
                </P>
                <P>
                    <E T="03">Response 4:</E>
                     EPA disagrees with the comment. EPA proposed approval of Delaware's Regulation 1125 because the revision corrects a deficiency where the State regulation referenced a specific document authored and published by EPA in 1986 and supplemented in 1987. This document was replaced by 40 CFR part 51, appendix W and was most recently updated in the 
                    <E T="04">Federal Register</E>
                     on January 17, 2017 at, 82 FR 5203. Based on this information, DNREC correctly revised Regulation 1125 and submitted it to EPA for approval into the SIP, which EPA subsequently proposed approval in the NPRM. The commenter's assertions that the proposed approval of this regulation is “based on flawed science and because of political and regulatory considerations” is incorrect and the commenter did not provide any additional information to support these claims.
                </P>
                <P>
                    As a factual matter, EPA also disagrees with the assertions that Delaware's air quality has remained unchanged for 10 years. Since 2007, design values 
                    <SU>3</SU>
                    <FTREF/>
                     in Delaware have consistently trended downward and the most recent data shows only three out of the seven State monitors are showing violations of the 2015 ozone NAAQS based on 2018 design values.
                    <SU>4</SU>
                    <FTREF/>
                     EPA reiterates that the purpose of an infrastructure SIP is not to demonstrate attainment of the NAAQS, but to ensure that a state's SIP has addressed basic program elements necessary to assure attainment, maintenance, and enforcement of the NAAQS. Therefore, the status of Delaware's air quality is not relevant to whether EPA should approve 
                    <PRTPAGE P="25310"/>
                    the revisions to Regulation 1125 or the State's infrastructure SIP submission.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         A “design value” is a statistical metric that describes the air quality status of a given location relative to the level of the NAAQS.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See https://www.epa.gov/air-trends/air-quality-design-values#report</E>
                        .
                    </P>
                </FTNT>
                <HD SOURCE="HD1">IV. Final Action</HD>
                <P>EPA is approving Delaware's October 11, 2018 infrastructure SIP submission for the 2015 ozone NAAQS because it provides the basic program elements specified in CAA section 110(a)(2)(A), (B), (C), (D), (E), (F), (G), (H), (J), (K), (L), and (M) necessary to implement, maintain, and enforce the 2015 ozone NAAQS. This rulemaking action does not include action on CAA section 110(a)(2)(I) which pertains to the nonattainment planning requirements of part D, title I of the CAA, because this element is not required to be submitted by the 3-year submission deadline of section 110(a)(1) of the CAA and will be addressed in a separate process. EPA is also approving Delaware's December 16, 2019 SIP submission which updates 7 DE Admin. Code 1125 in order to incorporate by reference the correct modeling guidelines contained in 40 CFR part 51, appendix W. EPA's approval of the infrastructure SIP submission with respect to section 110(a)(2)(K) is based on this revision to Delaware's SIP.</P>
                <HD SOURCE="HD1">V. Incorporation by Reference</HD>
                <P>
                    In this document, EPA is finalizing regulatory text that includes incorporation by reference. In accordance with requirements of 1 CFR 51.5, EPA is finalizing the incorporation by reference of section 3.10 of 7 DE Admin. Code, Regulation 1125, effective January 11, 2020. EPA has made, and will continue to make, these materials generally available through 
                    <E T="03">https://www.regulations.gov</E>
                     and at the EPA Region III Office (please contact the person identified in the 
                    <E T="02">For Further Information Contact</E>
                     section of this preamble for more information). Therefore, these materials have been approved by EPA for inclusion in the SIP, have been incorporated by reference by EPA into that plan, are fully federally enforceable under sections 110 and 113 of the CAA as of the effective date of the final rulemaking of EPA's approval, and will be incorporated by reference in the next update to the SIP compilation.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         62 FR 27968 (May 22, 1997).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">VI. Statutory and Executive Order Reviews</HD>
                <HD SOURCE="HD2">A. General Requirements</HD>
                <P>Under the CAA, the Administrator is required to approve a SIP submission that complies with the provisions of the CAA and applicable Federal regulations. 42 U.S.C. 7410(k); 40 CFR 52.02(a). Thus, in reviewing SIP submissions, EPA's role is to approve state choices, provided that they meet the criteria of the CAA. Accordingly, this action merely approves state law as meeting Federal requirements and does not impose additional requirements beyond those imposed by state law. For that reason, this action:</P>
                <P>• Is not a “significant regulatory action” subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);</P>
                <P>• Is not an Executive Order 13771 (82 FR 9339, February 2, 2017) regulatory action because SIP approvals are exempted under Executive Order 12866.</P>
                <P>
                    • Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    • Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);</P>
                <P>• Does not have Federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);</P>
                <P>• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);</P>
                <P>• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);</P>
                <P>• Is not subject to requirements of Section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because application of those requirements would be inconsistent with the CAA; and</P>
                <P>• Does not provide EPA with the discretionary authority to address, as appropriate, disproportionate human health or environmental effects, using practicable and legally permissible methods, under Executive Order 12898 (59 FR 7629, February 16, 1994).</P>
                <P>In addition, this rule does not have tribal implications as specified by Executive Order 13175 (65 FR 67249, November 9, 2000), because the SIP is not approved to apply in Indian country located in the state, and EPA notes that it will not impose substantial direct costs on tribal governments or preempt tribal law.</P>
                <HD SOURCE="HD2">B. Submission to Congress and the Comptroller General</HD>
                <P>
                    The Congressional Review Act, 5 U.S.C. 801 
                    <E T="03">et seq.,</E>
                     as added by the Small Business Regulatory Enforcement Fairness Act of 1996, generally provides that before a rule may take effect, the agency promulgating the rule must submit a rule report, which includes a copy of the rule, to each House of the Congress and to the Comptroller General of the United States. EPA will submit a report containing this action 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>
                    . A major rule cannot take effect until 60 days after it is published in the 
                    <E T="04">Federal Register</E>
                    . This action is not a “major rule” as defined by 5 U.S.C. 804(2).
                </P>
                <HD SOURCE="HD2">C. Petitions for Judicial Review</HD>
                <P>Under section 307(b)(1) of the CAA, petitions for judicial review of this action must be filed in the United States Court of Appeals for the appropriate circuit by June 30, 2020. Filing a petition for reconsideration by the Administrator of this final rule does not affect the finality of this action for the purposes of judicial review nor does it extend the time within which a petition for judicial review may be filed, and shall not postpone the effectiveness of such rule or action. This action, pertaining to Delaware's section 110(a)(2) infrastructure requirements for the 2015 ozone NAAQS and revisions to Regulation 1125, may not be challenged later in proceedings to enforce its requirements. (See section 307(b)(2).)</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 52</HD>
                    <P>Environmental protection, Air pollution control, Incorporation by reference, Nitrogen dioxide, Ozone, Volatile organic compounds.</P>
                </LSTSUB>
                <SIG>
                    <DATED>Dated: April 13, 2020.</DATED>
                    <NAME>Cosmo Servidio,</NAME>
                    <TITLE>Regional Administrator, Region III.</TITLE>
                </SIG>
                <P>40 CFR part 52 is amended as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 52—APPROVAL AND PROMULGATION OF IMPLEMENTATION PLANS</HD>
                </PART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>1. The authority citation for part 52 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P>
                             42 U.S.C. 7401 
                            <E T="03">et seq.</E>
                        </P>
                    </AUTH>
                </REGTEXT>
                <SUBPART>
                    <HD SOURCE="HED">Subpart I—Delaware</HD>
                </SUBPART>
                <REGTEXT TITLE="40" PART="52">
                    <AMDPAR>2. Amend § 52.420:</AMDPAR>
                    <AMDPAR>
                        a. In the table in paragraph (c), under “1125 Requirements for Preconstruction 
                        <PRTPAGE P="25311"/>
                        Review” by revising the entry for “Section 3.0”; and
                    </AMDPAR>
                    <AMDPAR>b. In the table in paragraph (e) by adding the entry “Section 110(a)(2) Infrastructure Requirements for the 2015 Ozone NAAQS” at the end of the table.</AMDPAR>
                    <P>The revision and addition read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 52.420 </SECTNO>
                        <SUBJECT>Identification of plan.</SUBJECT>
                        <STARS/>
                        <P>(c) * * *</P>
                        <GPOTABLE COLS="5" OPTS="L1,i1" CDEF="s25,r50,12,r50,r75">
                            <TTITLE>Epa-Approved Regulations and Statutes in the Delaware Sip</TTITLE>
                            <BOXHD>
                                <CHED H="1">State regulation (7 DNREC 1100)</CHED>
                                <CHED H="1">Title/subject</CHED>
                                <CHED H="1">
                                    State 
                                    <LI>effective </LI>
                                    <LI>date</LI>
                                </CHED>
                                <CHED H="1">EPA approval date</CHED>
                                <CHED H="1">Additional explanation</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW RUL="s">
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW RUL="s" EXPSTB="04">
                                <ENT I="21">
                                    <E T="02">1125 Requirements for Preconstruction Review</E>
                                </ENT>
                            </ROW>
                            <ROW EXPSTB="00">
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW RUL="s">
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">Section 3.0</ENT>
                                <ENT>Prevention of Significant Deterioration of Air Quality</ENT>
                                <ENT>1/11/20</ENT>
                                <ENT>
                                    5/1/2020, [insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                                <ENT>Docket #: 2019-0663. Revised 3.10.1 and 3.10.2. Note: Previous Section 3.0 approval October 2, 2012.</ENT>
                            </ROW>
                            <ROW EXPSTB="00">
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                        </GPOTABLE>
                        <STARS/>
                        <P>(e) * * *</P>
                        <GPOTABLE COLS="5" OPTS="L1,tp0,i1" CDEF="s50,r25,12,r50,r100">
                            <TTITLE> </TTITLE>
                            <BOXHD>
                                <CHED H="1">Name of non-regulatory SIP revision</CHED>
                                <CHED H="1">Applicable geographic area</CHED>
                                <CHED H="1">State submittal date</CHED>
                                <CHED H="1">EPA approval date</CHED>
                                <CHED H="1">Additional explanation</CHED>
                            </BOXHD>
                            <ROW EXPSTB="00">
                                <ENT I="22"> </ENT>
                            </ROW>
                            <ROW RUL="s">
                                <ENT I="28">*         *         *         *         *         *         *</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">Section 110(a)(2) Infrastructure Requirements for the 2015 Ozone NAAQS</ENT>
                                <ENT>Statewide</ENT>
                                <ENT>10/11/18</ENT>
                                <ENT>
                                    5/1/2020, [insert 
                                    <E T="02">Federal Register</E>
                                     citation]
                                </ENT>
                                <ENT>Docket #: 2019-0663. This action addresses CAA section 110(a)(2)(A), (B), (C), (D), (E), (F), (G), (H), (J), (K), (L), and (M).</ENT>
                            </ROW>
                        </GPOTABLE>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08241 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 6560-50-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Part 96</CFR>
                <DEPDOC>[GN Docket 12-354, FCC 16-55; GN 17-258, FCC 18-149; FRS 16630]</DEPDOC>
                <SUBJECT>Commercial Operations in the 3550-3650 MHz Band; Promoting Investment in the 3550-3700 MHz Band</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule; announcement of compliance date.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        In this document, the Commission announces that the Office of Management and Budget (OMB) has approved four information collections associated with rules governing Priority Access Licenses (PALs) in the 3550-3700 MHz (3.5 GHz) band in the 2016 Order on Reconsideration and Second Report and Order, FCC 16-55, in GN Docket No. 12-354, and 2018 Report and Order, FCC 18-149, in GN Docket No. 17-258. The Commission also announces that compliance with the rules is now required. It removes paragraphs advising that compliance was not required until OMB approval was obtained. This document is consistent with the 2016 Order on Reconsideration and Second Report and Order and 2018 Report and Order, which state the Commission will publish a document in the 
                        <E T="04">Federal Register</E>
                         announcing a compliance date for the rule sections and revise the rules accordingly.
                    </P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Effective May 1, 2020.</P>
                    <P>Compliance date: Compliance with 47 CFR 1.9046, 96.23(a), 96.25(b), 96.32(a) and (b), and 96.66, published at 81 FR 49024 on July 26, 2016, and 83 FR 63076 on December 7, 2018, is required as of May 1, 2020.</P>
                    <P>This document also removes sections 96.23(d), 96.25(b)(5), and 96.32(d) of the Commission's rules, which advised that compliance with 96.23(a), 96.25(b), and 96.32(b) was not required until OMB approval was obtained.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jessica Quinley of the Wireless Telecommunications Bureau, Mobility Division, at (202) 418-1991 or 
                        <E T="03">Jessica.Quinley@fcc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This document announces that OMB approved the four information collection requirements in §§ 1.9046, 96.23(a), 96.25(b), 96.32(a) and (b), and 96.66 on March 31, 2020.</P>
                <P>
                    The Commission publishes this document as an announcement of the compliance date of the rules. If you have any comments on the burden estimates listed below, or how the Commission can improve the collections and reduce any burdens caused thereby, please contact Cathy Williams, Federal Communications Commission, Room 1-C823, 445 12th Street, SW, Washington, DC 20554, regarding OMB Control Numbers 3060-1211, 3060-1058, 3060-0798, and 3060-0800. Please include the applicable OMB Control Number in your correspondence. The Commission will also accept your comments via email at 
                    <E T="03">PRA@fcc.gov.</E>
                </P>
                <P>
                    To request materials in accessible formats for people with disabilities (Braille, large print, electronic files, audio format), send an email to 
                    <E T="03">fcc504@fcc.gov</E>
                     or call the Consumer and 
                    <PRTPAGE P="25312"/>
                    Governmental Affairs Bureau at (202) 418-0530 (voice), (202) 418-0432 (TTY).
                </P>
                <HD SOURCE="HD1">Synopsis</HD>
                <P>As required by the Paperwork Reduction Act of 1995 (44 U.S.C. 3507), the FCC is notifying the public that it received final OMB approval on March 31, 2020, for the information collection requirements contained in §§ 1.9046, 96.23(a), 96.25(b), 96.32(a) and (b), and 96.66. Under 5 CFR part 1320, an agency may not conduct or sponsor a collection of information unless it displays a current, valid OMB Control Number.</P>
                <P>No person shall be subject to any penalty for failing to comply with a collection of information subject to the Paperwork Reduction Act that does not display a current, valid OMB Control Number.</P>
                <P>The foregoing notice is required by the Paperwork Reduction Act of 1995, Public Law 104-13, October 1, 1995, and 44 U.S.C. 3507.</P>
                <P>The total annual reporting burdens and costs for the respondents are as follows:</P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     3060-1211.
                </P>
                <P>
                    <E T="03">OMB Approval Date:</E>
                     March 31, 2020.
                </P>
                <P>
                    <E T="03">OMB Expiration Date:</E>
                     March 31, 2023.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Sections 96.17; 96.21; 96.23; 96.25; 96.33; 96.35; 96.39; 96.41; 96.43; 96.45; 96.51; 96.57; 96.59; 96.61; 96.63; 96.67, Commercial Operations in the 3550-3700 MHz Band
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     N/A.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Business or other for-profit entities, not for profit institutions and state, local, or tribal government.
                </P>
                <P>
                    <E T="03">Number of Respondents and Responses:</E>
                     110,782 respondents; 226,099 responses.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     0.25 to 1.5 hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Ten-year reporting requirement, one time and on occasion reporting requirements, other reporting requirements—as needed basis for equipment safety certifications that is no long in use, and consistently (likely daily) responses automated via the device.
                </P>
                <P>
                    <E T="03">Obligation to Respond:</E>
                     Required to obtain or retain benefits. Statutory authority for these collections is contained in 47 U.S.C. 151, 152, 154(i), 154(j), 155(c), 302a, 303, 304, 307(e), and 316 of the Communications Act of 1934.
                </P>
                <P>
                    <E T="03">Total Annual Burden:</E>
                     64,561 hours.
                </P>
                <P>
                    <E T="03">Total Annual Cost:</E>
                     $13,213,975.
                </P>
                <P>
                    <E T="03">Privacy Impact Assessment:</E>
                     No impact(s).
                </P>
                <P>
                    <E T="03">Nature and Extent of Confidentiality:</E>
                     In general, there is no need for confidentiality with this collection of information.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     On October 24, 2018, the Commission released a Report and Order, FCC 18-149, in GN Docket No. 17-158, adopting limited changes to the rules governing Priority Access Licenses (PALs) in the 3550-3700 MHz (3.5 GHz) band, including larger license areas, longer license terms, renewability, and performance requirements. The Commission anticipated that the targeted changes made in its 2018 Report and Order will spur additional investment and broader deployment in the band, promote robust and efficient spectrum use, and help ensure the rapid deployment of advanced wireless technologies—including 5G—in the United States.
                </P>
                <P>The rule changes and information requirements contained in the Commission's previous 3.5 GHz band orders—the 2015 Report and Order, FCC 15-47, and 2016 Order on Reconsideration and Second Report and Order, FCC 16-55, both in GN Docket No. 12-354—are also approved under this Office of Management and Budget (OMB) control number (3060-1211) and have not changed since OMB last approved them.</P>
                <P>
                    The Commission received approval from OMB for the information collection requirements contained in the 2018 Report and Order, FCC 18-149, stemming from the changes made to section 96.25(b) of it rules. The Commission revised section 96.25(b) to adopt performance requirements for Priority Access Licensees. Specifically, under the revised rule, Priority Access Licensees must provide substantial service in their license area by the end of the initial license term, 
                    <E T="03">i.e.,</E>
                     at the end of 10 years. “Substantial service” is defined as service which is sound, favorable, and substantially above the level of mediocre service which might minimally warrant renewal. Failure by any licensee to meet this requirement will result in forfeiture of the license without further Commission action, and the licensee will be ineligible to regain it. Licensees shall demonstrate compliance with the performance requirement by filing a construction notification with the Commission in accordance with section 1.946(d) of the Commission's rules. The licensee must certify whether it has met the performance requirement, and file supporting documentation, including description and demonstration of the bona fide service provided, electronic maps accurately depicting the boundaries of the license area and where in the license area the licensee provides service that meets the performance requirement, supporting technical documentation, any population-related assumptions or data used in determining the population covered by a service to the extent any were relied upon, and any other information the Wireless Telecommunications Bureau may prescribe by public notice. A licensee's showing of substantial service may not rely on service coverage outside of the PAL Protection Areas of registered Citizens Broadband Radio Service Devices (CBSDs) or on deployments that are not reflected in Spectrum Access System (SAS) records of CBSD registrations.
                </P>
                <P>
                    The Commission adopted two safe harbors for meeting the “substantial service” requirement: (1) A Priority Access Licensee providing a 
                    <E T="03">mobile service or point-to-multipoint service</E>
                     may demonstrate substantial service by showing that it provides signal coverage and offers service, either to customers or for internal use, over at least 50 percent of the population in the license area; and (2) A Priority Access Licensee providing a 
                    <E T="03">fixed point-to-point service</E>
                     may demonstrate substantial service by showing that it has constructed and operates at least four links, either to customers or for internal use, in license areas with 134,000 population or less and in license areas with greater population, a minimum number of links equal to the population of the license area divided by 33,500 and rounded up to the nearest whole number. To satisfy this provision, such links must operate using registered Category B CBSDs.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     3060-1058.
                </P>
                <P>
                    <E T="03">OMB Approval Date:</E>
                     March 31, 2020.
                </P>
                <P>
                    <E T="03">OMB Expiration Date:</E>
                     March 31, 2023.
                </P>
                <P>
                    <E T="03">Title:</E>
                     FCC Application or Notification for Spectrum Leasing Arrangement or Private Commons Arrangement: Wireless Telecommunications Bureau Public Safety and Homeland Security Bureau.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     FCC Form 608.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Business or other for-profit entities, not for profit institutions, individual or households, and state, local, or tribal government.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     1,091 respondents; 1,091 responses.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     0.5 to 1 hour.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Recordkeeping requirement, third party disclosure requirement, on occasion reporting requirement and periodic reporting requirement.
                </P>
                <P>
                    <E T="03">Obligation to Respond:</E>
                     Required to obtain or retain benefits. Statutory authority for these collections is contained in 47 U.S.C., 154, 155, 158, 
                    <PRTPAGE P="25313"/>
                    161, 301, 303(r), 308, 309, 310, and 332 of the Communications Act of 1934.
                </P>
                <P>
                    <E T="03">Total Annual Burden:</E>
                     1,096 hours.
                </P>
                <P>
                    <E T="03">Total Annual Cost:</E>
                     $1,411,450.
                </P>
                <P>
                    <E T="03">Privacy Impact Assessment:</E>
                     Yes.
                </P>
                <P>
                    <E T="03">Nature and Extent of Confidentiality:</E>
                     In general, there is no need for confidentiality with this collection of information.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     FCC Form 608 is a multipurpose form. It is used to provide notification or request approval for any spectrum leasing arrangement (“Leases”) entered into between an existing licensee (“Licensee”) in certain wireless services and a spectrum lessee (“Lessee”). This form also is required to notify or request approval for any spectrum subleasing arrangement (“Sublease”). The data collected on the form is used by the FCC to determine whether the public interest would be served by the Lease or Sublease. The form is also used to provide notification for any Private Commons Arrangement entered into between a Licensee, Lessee, or Sublessee and a class of third-party users (as defined in Section 1.9080 of the Commission's Rules). Respondents are required to submit FCC Form 608 electronically, except in certain services specifically designated by the Commission.
                </P>
                <P>
                    Records may include information about individuals or households, 
                    <E T="03">e.g.,</E>
                     personally identifiable information or PII, and the use(s) and disclosure of this information will be governed by the requirements of a system of records notice or `SORN', FCC/WTB-1, “Wireless Services Licensing Records.” Updating the SORN to include FCC Form 608 is currently underway. There are no additional impacts under the Privacy Act.
                </P>
                <P>On April 28, 2016, the Commission adopted its Second Report and Order, FCC 16-55, in GN Docket No. 12-354, adopting additional rules for the Citizens Broadband Radio Service in the 3.5 GHz band. As part of the Second Report and Order, the Commission adopted a light-touch leasing regime for Priority Access Licensees by amending its existing Part 1 rules to include a streamlined spectrum manager leasing process, based on the current spectrum manager leasing rules, tailored for the PAL leasing context. The Commission expects there will be a demand for Priority Access rights for a wide variety of use cases, and that a robust, flexible, and lightly regulated secondary market through these band-specific spectrum manager leasing rules will incentivize efficient spectrum use, promote innovation, and encourage the rapid deployment of broadband networks in the 3.5 GHz Band. Specifically, in the Second Report and Order, the Commission adopted section 1.9046, which provides special provisions for spectrum manager leases in the Citizens Broadband Radio Service. This rule allows a Priority Access Licensee to engage in spectrum manager leasing for any portion of its spectrum or geographic area, outside of the PAL Protection Area, for any bandwidth or duration period of time with any entity that has provided a certification to the Commission in accordance with section 1.9046 or pursuant to the general notification procedures of section 1.9020(e) of the Commission's rules. The lessee seeking to engage in spectrum manager leasing pursuant to section 1.9046 must certify with the Commission that it meets the same eligibility and qualification requirements applicable to the licensee before entering into a spectrum manger leasing arrangement with a Priority Access Licensee. The certification will be made via FCC Form 608.</P>
                <P>Prior to lessee operation, the licensee seeking to engage in spectrum manager leasing pursuant to section 1.9046 must submit notification of the leasing arrangement to the Spectrum Access System (SAS) Administrator with the following information: (1) Lessee contact information including name, address, telephone number, fax number, email address; (2) Lessee FCC Registration Number (FRN); (3) name of Real Party in Interest and related FCC Registration Number (FRN); (4) the specific spectrum leased (in terms of amount of bandwidth and geographic area involved) including the call sign(s) affected by the lease; and (5) duration of the lease.</P>
                <P>A spectrum leasing arrangement may be extended beyond the initial term set forth in the spectrum leasing notification for an additional period not to exceed the term of the Priority Access License, provided that the licensee notifies the SAS Administrator of the extension in advance of operation under the extended term and does so pursuant to the notification procedures in section 1.9046.</P>
                <P>If a spectrum leasing arrangement is terminated earlier than the termination date set forth in the notification, either by the licensee or by the parties' mutual agreement, the licensee must file a notification with the SAS Administrator no later than ten (10) days after the early termination, indicating the date of the termination.</P>
                <P>If the parties fail to put the spectrum leasing arrangement into effect, they must so notify the Spectrum Access System Administrator as promptly as practicable.</P>
                <P>Under the Part 96 rules, three types of respondents may be completing FCC Form 608. First, entities seeking to engage in light touch leasing will pre-certify with the FCC that they meet the non-lease-specific eligibility and qualification criteria by completing non-lease-specific data fields pulled from FCC Form 608. Second, the Priority Access Licensees would use the form in three ways. For light touch leasing, Priority Access Licensees would notify the SAS Administrator of leasing arrangements with pre-certified lessees by completing lease-specific data fields pulled from FCC Form 608. Part 96 also permits Priority Access Licensees to enter into lease agreements using the general spectrum manager leasing agreement rules under part 1 of the rules, which would require a FCC Form 608. Priority Access Licensees may also enter into de facto transfer leasing arrangements for a portion of their licensed spectrum pursuant to part 1 of the Commission's rules and would use FCC Form 608 to do so. Third, on a daily basis, the SAS Administrator will provide the Commission with an electronic report of the leasing notifications completed by the Priority Access Licensees. The SAS Administrators will be providing the report through an Application Programming Interface (API). The Commission has reused the code from the general spectrum manager leasing FCC Form 608 in the Commission's Universal Licensing System (ULS) to program the SAS light touch leasing API.</P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     3060-0798.
                </P>
                <P>
                    <E T="03">OMB Approval Date:</E>
                     March 31, 2020.
                </P>
                <P>
                    <E T="03">OMB Expiration Date:</E>
                     March 31, 2023.
                </P>
                <P>
                    <E T="03">Title:</E>
                     FCC Application for Radio Service Authorization; Wireless Telecommunications Bureau; Public Safety and Homeland Security Bureau.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     FCC Form 601.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Business or other for-profit entities, not for profit institutions, individuals and households, and state, local, or tribal government.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     255,452 respondents; 255,452 responses.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     0.5 to 1.25 hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Recordkeeping requirement, third party disclosure requirement, on occasion reporting requirement and periodic reporting requirement.
                </P>
                <P>
                    <E T="03">Obligation to Respond:</E>
                     Required to obtain or retain benefits. Statutory authority for these collections is contained in 47 U.S.C. 151, 152, 154, 154(i), 155(c), 157, 201, 202, 208, 214, 301, 302a, 303, 307, 308, 309, 310, 311, 
                    <PRTPAGE P="25314"/>
                    314, 316, 319, 324, 331, 332, 333, 336, 534, 535, 554.
                </P>
                <P>
                    <E T="03">Total Annual Burden:</E>
                     223,921 hours.
                </P>
                <P>
                    <E T="03">Total Annual Cost:</E>
                     $71,906,000.
                </P>
                <P>
                    <E T="03">Privacy Impact Assessment:</E>
                     Yes.
                </P>
                <P>
                    <E T="03">Nature and Extent of Confidentiality:</E>
                     In general, there is no need for confidentiality with this collection of information.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     FCC Form 601 is a consolidated, multi-part application form that is used for market-based and site-based licensing for wireless telecommunications services, including public safety licenses, which are filed through the Commission's Universal Licensing System (ULS). FCC Form 601 is composed of a main form that contains administrative information and a series of schedules used for filing technical and other information. This form is used to apply for a new license, to amend or withdraw a pending application, to modify or renew an existing license, cancel a license, request a duplicate license, submit required notifications, request an extension of time to satisfy construction requirements, or request an administrative update to an existing license (such as mailing address change), request a Special Temporary Authority or Developmental License. Respondents are required to submit FCC Form 601 electronically, except in certain services specifically designated by the Commission.
                </P>
                <P>
                    The data collected on FCC Form 601 includes the FCC Registration Number (FRN), which serves as a “common link” for all filings an entity has with the FCC. The Debt Collection Improvement Act of 1996 requires entities filing with the Commission to use an FRN. Records may include information about individuals or households, 
                    <E T="03">e.g.,</E>
                     personally identifiable information or PII, and the use(s) and disclosure of this information are governed by the requirements of a system of records notice or `SORN', FCC/WTB-1, “Wireless Services Licensing Records.” There are no additional impacts under the Privacy Act.
                </P>
                <P>On October 24, 2018, the Commission released a Report and Order, FCC 18-149, in GN Docket No. 17-158, adopting limited changes to the rules governing Priority Access Licenses (PALs) in the 3550-3700 MHz (3.5 GHz) band, including larger license areas, longer license terms, renewability, and performance requirements. The Commission anticipated that the targeted changes made in its 2018 Report and Order will spur additional investment and broader deployment in the band, promote robust and efficient spectrum use, and help ensure the rapid deployment of advanced wireless technologies—including 5G—in the United States. Among these changes, the Commission revised section 96.23(a) of its rules to require that an applicant must file an application for an initial PAL, and that the application must: (1) Demonstrate the applicant's qualifications to hold an authorization; (2) state how a grant would serve the public interest, convenience, and necessity; (3) contain all information required by FCC rules and application forms; (4) propose operation of a facility or facilities in compliance with all rules governing the Citizens Broadband Radio Service; and (5) be amended as necessary to remain substantially accurate and complete in all significant respects, in accordance with the provisions of section 1.65 of the Commission's rules.</P>
                <P>The Commission received approval for a revision to its currently approved information collection on FCC Form 601.</P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     3060-0800.
                </P>
                <P>
                    <E T="03">OMB Approval Date:</E>
                     March 31, 2020.
                </P>
                <P>
                    <E T="03">OMB Expiration Date:</E>
                     March 31, 2023.
                </P>
                <P>
                    <E T="03">Title:</E>
                     FCC Application For Assignment of Authorization and Transfers of Control: Wireless Telecommunications Bureau and Public Safety and Homeland Security Bureau.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     FCC Form 603.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Business or other for-profit entities, not for profit institutions, individuals and households, and state, local, or tribal government.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     2,547 respondents; 2,547 responses.
                </P>
                <P>
                    <E T="03">Estimated Time per Response:</E>
                     0.5 to 1.75 hours.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     Recordkeeping requirement, on occasion reporting requirement, and periodic reporting requirement.
                </P>
                <P>
                    <E T="03">Obligation to Respond:</E>
                     Required to obtain or retain benefits. Statutory authority for these collections is contained in 47 U.S.C. 154, 155, 158, 161, 301, 303(r), 308, 309, 310, and 332.
                </P>
                <P>
                    <E T="03">Total Annual Burden</E>
                    : 2,872 hours.
                </P>
                <P>
                    <E T="03">Total Annual Cost:</E>
                     $381,975.
                </P>
                <P>
                    <E T="03">Privacy Impact Assessment:</E>
                     Yes.
                </P>
                <P>
                    <E T="03">Nature and Extent of Confidentiality:</E>
                     In general, there is no need for confidentiality with this collection of information.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     FCC Form 603 is a multi-purpose form that is used by radio services in Wireless Services within the Universal Licensing System (ULS). FCC 603 is composed of a main form that contains the administrative information and a series of schedules. These schedules are required when applying for Auctioned Services, Partitioning and Disaggregation, Undefined Geographical Area Partitioning, and Notification of Consummation or Request for Extension of Time for Consummation. Applicants/licensees in the Public Mobile Services, Personal Communications Services, Private Land Mobile Radio Services, Broadband Radio Service, Educational Broadband Service, Maritime Services (excluding Ship), and Aviation Services (excluding Aircraft) use FCC Form 603 to apply for an assignment or transfer, to establish their parties' basic eligibility and qualifications, to classify the filing, and/or to determine the nature of the proposed service. This form is also used to notify the FCC of consummated assignments and transfers of wireless licenses to which the Commission has previously consented or for which notification but not prior consent is required. Respondents are required to submit FCC Form 603 electronically, except in certain services specifically designated by the Commission.
                </P>
                <P>The data collected on FCC Form 603 include the FCC Registration Number (FRN), which serves as a “common link” for all filings an entity has with the FCC. The Debt Collection Improvement Act of 1996 required that those filing with the Commission to use an FRN, effective December 3, 2001.</P>
                <P>
                    Records may include information about individuals or households, 
                    <E T="03">e.g.,</E>
                     personally identifiable information or PII, and the use(s) and disclosure of this information are governed by the requirements of a system of records notice or `SORN', FCC/WTB-1, “Wireless Services Licensing Records.” There are no additional impacts under the Privacy Act.
                </P>
                <P>
                    On October 24, 2018, the Commission released a Report and Order, FCC 18-149, in GN Docket No. 17-158, adopting limited changes to the rules governing Priority Access Licenses (PALs) in the 3550-3700 MHz (3.5 GHz) band, including larger license areas, longer license terms, renewability, and performance requirements. The Commission anticipated that the targeted changes made in its 2018 Report and Order will spur additional investment and broader deployment in the band, promote robust and efficient spectrum use, and help ensure the rapid deployment of advanced wireless technologies—including 5G—in the United States. The Commission received approval for the information under OMB Control Number 3060-0800 to permit the collection of the additional information in connection with partial assignments of authorizations for geographic partitioning, spectrum disaggregation, or a combination of 
                    <PRTPAGE P="25315"/>
                    both, pursuant to the rules and information collection requirements adopted by the Commission 2018 Report and Order. Specifically, in the 2018 Report and Order, the Commission revised section 96.32(b) of its rules to allow Priority Access Licensees to partition their licenses or disaggregate their spectrum, and partially assign or transfer their licenses, pursuant to § 1.950 of the Commission's rules. Because of the additional Priority Access Licensees, additional respondents may be filing FCC Form 603 for assignments or transfers of control of licenses.
                </P>
                <LSTSUB>
                    <HD SOURCE="HED">Lists of Subjects in 47 CFR Part 96</HD>
                    <P>Citizens broadband radio service.</P>
                </LSTSUB>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Cecilia Sigmund,</NAME>
                    <TITLE>Federal Register Liaison Officer.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Final Rules</HD>
                <P>For the reasons discussed in the preamble, the Federal Communications Commission amends 47 CFR part 90 as follows.</P>
                <PART>
                    <HD SOURCE="HED">PART 96—CITIZENS BROADBAND RADIO SERVICE</HD>
                </PART>
                <REGTEXT TITLE="47" PART="96">
                    <AMDPAR>1. The authority citation for part 96 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>47 U.S.C. 154(i), 303, and 307.</P>
                    </AUTH>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 96.23 </SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="47" PART="96">
                    <AMDPAR>2. Amend § 96.23 by removing paragraph (d).</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 96.25</SECTNO>
                    <SUBJECT> [Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="47" PART="96">
                    <AMDPAR>3. Amend § 96.25 by removing paragraph (b)(5).</AMDPAR>
                </REGTEXT>
                <SECTION>
                    <SECTNO>§ 96.32</SECTNO>
                    <SUBJECT> [Amended]</SUBJECT>
                </SECTION>
                <REGTEXT TITLE="47" PART="96">
                    <AMDPAR>4. Amend § 96.32 by removing paragraph (d).</AMDPAR>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-07582 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6712-01-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Transportation Security Administration</SUBAGY>
                <CFR>49 CFR Part 1570</CFR>
                <DEPDOC>[Docket No. TSA-2015-0001]</DEPDOC>
                <RIN>RIN 1652-AA55</RIN>
                <SUBJECT>Security Training for Surface Transportation Employees</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Transportation Security Administration, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final rule, delay of effective date.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This rule delays the effective date of the final rule entitled, “Security Training for Surface Transportation Employees” from June 22, 2020, until September 21, 2020. TSA has concluded that many owner/operators within the regulated community may be unable to meet deadlines in the rule because of actions taken at various levels of government to address the COVID-19 crisis. TSA is, therefore, extending the effective date of the rule and related compliance deadlines.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The effective date of the Security Training for Surface Transportation Employees final rule published at 85 FR 16456 is delayed until September 21, 2020. The revisions to part 1570 in this rule are effective September 21, 2020.</P>
                </EFFDATE>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Harry Schultz (TSA; Policy, Plans, and Engagement, Surface Division) or David Kasminoff (TSA, Senior Counsel; Regulations and Security Standards; Office of Chief Counsel) by telephone at (571) 227-5563 or email to 
                        <E T="03">SecurityTrainingPolicy@tsa.dhs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    On March 23, 2020, TSA published the final rule, “Security Training for Surface Transportation Employees.” 
                    <SU>1</SU>
                    <FTREF/>
                     The regulation requires owner/operators of higher-risk freight railroad carriers, public transportation agencies (including rail mass transit and bus systems), passenger railroad carriers, and over-the-road bus companies, to provide TSA-approved security training to employees performing security-sensitive functions. As originally published, that final rule was scheduled to take effect on June 22, 2020, with the first compliance deadline set for July 22, 2020.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         85 FR 16456.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See, e.g.,</E>
                         85 FR at 16469.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">II. Delayed Effective Date</HD>
                <P>
                    Before and since publication, TSA has observed the growing nationwide impact of the spread of the novel coronavirus that causes COVID-19, including the impact of actions taken at various levels of government to slow its spread.
                    <SU>3</SU>
                    <FTREF/>
                     Some of these actions have affected the operations and staffing of many of the owner/operators affected by the final rule. In recognition of the potential impact of COVID-19 measures and related strain on resources, TSA is delaying the effective date for requirements in the rule.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         On January 31, 2020, the Secretary of the Department of Health and Human Services declared a nationwide “public health emergency” under section 319 of the Public Health Service Act, 42 U.S.C. 274d, as a result of confirmed cases of COVID-19. 
                        <E T="03">See</E>
                         HHS, “Determination that a Public Health Emergency Exists,” 
                        <E T="03">https://www.phe.gov/emergency/news/healthactions/phe/Pages/2019-nCoV.aspx.</E>
                         On March 11, 2020, the World Health Organization announced that the COVID-19 outbreak can be characterized as a pandemic. On March 13, 2020, the President determined that the ongoing COVID-19 pandemic is of sufficient severity and magnitude to warrant an emergency determination under section 501(b) of the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121-5207. In addition, on March 13, 2020, the President declared a national emergency under sections 201 and 301 of the National Emergencies Act, 50 U.S.C. 1601 
                        <E T="03">et seq. See</E>
                         Proclamation 9994 of Mar. 13, 2020 on Declaring a National Emergency Concerning the Novel Coronavirus Disease (COVID-19) Outbreak, 85 FR 15337 (Mar. 18, 2020). State and local jurisdictions throughout the United States are engaged in various social distancing practices, which frequently entail closing non-essential business and government services and avoiding crowds.
                    </P>
                </FTNT>
                <P>The following table identifies the revised effective date and the impact of this change on compliance dates tied to the effective date.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,r50,r50">
                    <TTITLE>Summary of Extended Deadlines for Compliance</TTITLE>
                    <TDESC>[IN ORDER OF DEADLINE]</TDESC>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Final Rule</CHED>
                        <CHED H="1">Extension</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Effective date of rule</ENT>
                        <ENT>June 22, 2020</ENT>
                        <ENT>September 21, 2020.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Deadline for notifying TSA of applicability determination (1570.105)</ENT>
                        <ENT>July 22, 2020</ENT>
                        <ENT>October 21, 2020.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Deadline for providing security coordinator information (49 CFR 1570.201)</ENT>
                        <ENT>July 29, 2020</ENT>
                        <ENT>October 28, 2020.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Deadline for submission of security training program to TSA for approval (1570.109(b))</ENT>
                        <ENT>September 20, 2020</ENT>
                        <ENT>December 21, 2020.</ENT>
                    </ROW>
                </GPOTABLE>
                <PRTPAGE P="25316"/>
                <P>In addition to extending the effective date, this document also makes corresponding amendments to the final rule. Finally, this rule corrects paragraph (g) of 49 CFR 1570.109 to be paragraph (d).</P>
                <HD SOURCE="HD1">III. Regulatory Analysis</HD>
                <HD SOURCE="HD2">A. Administrative Procedure Act</HD>
                <P>TSA takes this action without prior notice and public comment. Sections 553(b) and (d) of the Administrative Procedure Act (5 U.S.C. 553) authorize agencies to dispense with certain rulemaking procedures when they find good cause to do so. Under section 553(b), the requirements of notice and opportunity to comment do not apply when the agency for good cause finds that these procedures are “impracticable, unnecessary, or contrary to the public interest.” Section 553(d) allows an agency, upon finding good cause, to make a rule effective immediately, thereby avoiding the 30-day delayed effective date requirement in section 553.</P>
                <P>This final rule recognizes the need to extend the effective date of the Security Training for Surface Transportation Employees final rule in light of the significant disruption and uncertainty in both private and government operations caused by the COVID-19 pandemic. The compliance dates for this rule require action in the near term by owner/operators at a time when they are shifting resources or eliminating operations to respond to exigent circumstances created by the COVID-19 pandemic. The owner/operators subject to the requirements of the final rule need immediate certainty regarding the effective date of the rule so that they may focus on other issues affecting their operations.</P>
                <P>
                    TSA has good cause to delay the rule's effective date without advance notice and comment.
                    <SU>4</SU>
                    <FTREF/>
                     To delay taking this action while waiting for public comment would be impracticable and contrary to the public interest.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         5 U.S.C. 553(b)(B).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. Paperwork Reduction Act</HD>
                <P>This rule calls for no new collection of information under the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520).</P>
                <HD SOURCE="HD2">C. Executive Orders 12866 and 13563 Assessment</HD>
                <P>This rule does not constitute a “significant regulatory action” under Executive Order 12866, as supplemented by Executive Order 13563, and therefore has not been reviewed by the Office of Management and Budget (OMB). Executive Order 12866 defines “significant regulatory action” as one that is likely to result in a rule that may (1) have an annual effect on the economy of $100 million or more 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, 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 impact of entitlements, grants, user fees, or loan programs or the rights or obligations of recipients thereof; or (4) raise novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles set forth in the Executive Order.</P>
                <HD SOURCE="HD2">D. Regulatory Flexibility Act Assessment</HD>
                <P>
                    The Regulatory Flexibility Act of 1980, 5 U.S.C. 601-612, as amended by the Small Business Regulatory Enforcement Fairness Act of 1996 (Pub. L. 104-121), requires Federal agencies to consider the potential impact of regulations on small businesses, small government jurisdictions, and small organizations during the development of their rules. This final rule, however, makes changes for which notice and comment are not necessary. Accordingly, DHS is not required to prepare a regulatory flexibility analysis.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         See 5 U.S.C. 603, 604.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">E. Executive Order 12132 (Federalism)</HD>
                <P>
                    A rule has federalism implications under Executive Order 13132 if it has a substantial direct effect on State governments, on the relationship between the national government and the States, or on the distribution of power and responsibilities among the various levels of government. DHS has analyzed this rule under that Order and has determined that although this rule affects the states, it does not impose substantial direct compliance costs or preempt State law.
                    <SU>6</SU>
                    <FTREF/>
                     The rule relieves burdens on States.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         See E.O. 13132, sec. 6.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">F. Unfunded Mandates Assessment</HD>
                <P>The Unfunded Mandates Reform Act of 1995 requires Federal agencies to assess the effects of their discretionary regulatory actions. In particular, the Unfunded Mandates Reform Act addresses actions that may result in the expenditure by a State, local, or Tribal government, in the aggregate, or by the private section of $100 million (adjusted for inflation) or more in any one year. This final rule will not result in such an expenditure.</P>
                <HD SOURCE="HD2">G. Environment</HD>
                <P>TSA has reviewed this rulemaking for purposes of the National Environmental Policy Act of 1969 (NEPA) (42 U.S.C. 4321-4347) and has determined that this action will not have a significant effect on the human environment. This action is covered by categorical exclusion (CATEX) number A3(e) in DHS Management Directive 023-01 (formerly Management Directive 5100.1), Environmental Planning Program, which guides TSA compliance with NEPA.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 49 CFR Part 1570</HD>
                    <P>Commuter bus systems, Crime, Fraud, Hazardous materials transportation, Motor carriers, Over-the-Road bus safety, Over-the-Road buses, Public transportation, Public transportation safety, Rail hazardous materials receivers, Rail hazardous materials shippers, Rail transit systems, Railroad carriers, Railroad safety, Railroads, Reporting and recordkeeping requirements, Security measures, Transportation facility, Transportation Security-Sensitive Materials.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Amendments</HD>
                <P>For the reasons stated in the preamble, the Transportation Security Administration is amending 1570 of chapter XII, title 49, Code of Federal Regulations as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 1570—GENERAL RULES</HD>
                </PART>
                <REGTEXT TITLE="49" PART="1570">
                    <AMDPAR>1. The authority citation for part 1570 continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority: </HD>
                        <P>18 U.S.C. 842, 845; 46 U.S.C. 70105; 49 U.S.C. 114, 5103a, 40113, and 46105; Pub. L. 108-90 (117 Stat. 1156, Oct. 1, 2003), sec. 520 (6 U.S.C. 469), as amended by Pub. L. 110-329 (122 Stat. 3689, Sept. 30, 2008) sec. 543 (6 U.S.C. 469); Pub. L. 110-53 (121 Stat. 266, Aug. 3, 2007) secs. 1402 (6 U.S.C. 1131), 1405 (6 U.S.C. 1134), 1408 (6 U.S.C. 1137), 1413 (6 U.S.C. 1142), 1414 (6 U.S.C. 1143), 1501 (6 U.S.C. 1151), 1512 (6 U.S.C. 1162), 1517 (6 U.S.C. 1167), 1522 (6 U.S.C. 1170), 1531 (6 U.S.C. 1181), and 1534 (6 U.S.C. 1184).</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="49" PART="1570">
                    <AMDPAR>2. Revise § 1570.105 to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1570.105 </SECTNO>
                        <SUBJECT>Responsibility for determinations.</SUBJECT>
                        <P>
                            (a) 
                            <E T="03">Higher-risk operations.</E>
                             While TSA has determined the criteria for applicability of the requirements in subpart B to 49 CFR parts 1580, 1582, and 1584 based on risk-assessments for freight railroad, public transportation system, passenger railroad, or over-the-road (OTRB) owner/operators are 
                            <PRTPAGE P="25317"/>
                            required to determine if the applicability criteria identified in subpart B to parts 1580, 1582, and 1584 apply to their operations. Owner/operators are required to notify TSA of applicability by October 21, 2020.
                        </P>
                        <P>
                            (b) 
                            <E T="03">New or modified operations.</E>
                             If an owner/operator commences new operations or modifies existing operations after September 21, 2020, that person is responsible for determining whether the new or modified operations would meet the applicability criteria in subpart B to 49 CFR parts 1580, 1582, or 1584, and must notify TSA no later than 90 calendar days before commencing operations or implementing modifications.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="40" PART="1570">
                    <AMDPAR>3. Amend § 1570.109 by:</AMDPAR>
                    <AMDPAR>a. Revising paragraphs (b)(1) and (2);</AMDPAR>
                    <AMDPAR>b. Redesignating paragraph (g) as paragraph (d); and</AMDPAR>
                    <AMDPAR>c. Revising newly redesignated paragraph (d).</AMDPAR>
                    <P>The revisions read as follows:</P>
                    <SECTION>
                        <SECTNO>§ 1570.109 </SECTNO>
                        <SUBJECT>Submission and approval.</SUBJECT>
                        <STARS/>
                        <P>(b) * * *</P>
                        <P>(1) Submit its program to TSA for approval no later than December 21, 2020.</P>
                        <P>(2) If commencing or modifying operations so as to be subject to the requirements of subpart B to 49 CFR parts 1580, 1582, or 1584 after September 21, 2020, submit a training program to TSA no later than 90 calendar days before commencing new or modified operations.</P>
                        <STARS/>
                        <P>
                            (d) 
                            <E T="03">Petition for Reconsideration.</E>
                             Within 30 days of receiving the notice to modify, the owner/operator may file a petition for reconsideration under § 1570.119 of this part.
                        </P>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="49" PART="1570">
                    <AMDPAR>5. Amend § 1570.201, by revising paragraph (e) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 1570.201 </SECTNO>
                        <SUBJECT>Security Coordinator.</SUBJECT>
                        <STARS/>
                        <P>(e) Each owner/operator required to have a Security Coordinator must provide in writing to TSA the names, U.S. citizenship status, titles, phone number(s), and email address(es) of the Security Coordinator and alternate Security Coordinator(s) by October 28, 2020, commencement of operations, or change in any of the information required by this section.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <SIG>
                    <DATED>Date: April 17, 2020.</DATED>
                    <NAME>David P. Pekoske,</NAME>
                    <TITLE>Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08528 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 9110-05-P</BILCOD>
        </RULE>
        <RULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>50 CFR Part 300</CFR>
                <DEPDOC>[Docket No. 200427-0121]</DEPDOC>
                <RIN>RIN 0648-BJ39</RIN>
                <SUBJECT>Pacific Halibut Fisheries; Catch Sharing 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>Final rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This final rule implements the Pacific Halibut Catch Sharing Plan for the International Pacific Halibut Commission's regulatory Area 2A off Washington, Oregon, and California. In addition, this final rule implements management measures that are not implemented through the International Pacific Halibut Commission. These measures include the recreational fishery seasons and allocations, and other management measures for Area 2A, including some season dates that are different than proposed. This rule also announces that it may be necessary to further modify the opening dates or other fishing days for some subareas shortly after the publication of this final rule, in response to changes in state measures related to the spread of COVID-19. These actions are intended to conserve Pacific halibut and provide angler opportunity where available.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This rule is effective on April 30, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Additional information regarding this action may be obtained by contacting the Sustainable Fisheries Division, NMFS West Coast Region, 1201 NE Lloyd Boulevard, Suite 1100, Portland, OR 97232. For information regarding all halibut fisheries and general regulations not contained in this rule, contact the International Pacific Halibut Commission, 2320 W. Commodore Way, Suite 300, Seattle, WA 98199-1287. Electronic copies of the Regulatory Impact Review (RIR) and Final Regulatory Flexibility Analysis (FRFA) prepared for this action may be obtained by contacting Kathryn Blair, phone: 503-231-6858, email: 
                        <E T="03">kathryn.blair@noaa.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kathryn Blair, phone: 503-231-6858, fax: 503-231-6893, or email: 
                        <E T="03">kathryn.blair@noaa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Background</HD>
                <P>The Northern Pacific Halibut Act (Halibut Act) of 1982 gives the Secretary of Commerce (Secretary) responsibility for implementing the provisions of the Halibut Convention between the United States and Canada. 16 U.S.C. 773-773k. The Halibut Act requires that the Secretary adopt regulations to carry out the purposes and objectives of the Halibut Convention and Halibut Act 16 U.S.C. 773(c). The Halibut Act also authorizes the regional fishery management councils to develop regulations in addition to, but not in conflict with, regulations of the International Pacific Halibut Commission (IPHC) to govern the Pacific halibut catch in their corresponding U.S. Convention waters (16 U.S.C. 773c(c)).</P>
                <P>At its annual meeting in February 2020, the IPHC recommended an Area 2A catch limit of 1,500,000 pounds (lb) (680.4 metric tons (mt)) for 2020. This catch limit is derived from the total constant exploitation yield (TCEY) of 1,650,000 lb (748.4 mt), which includes commercial discards and bycatch estimates calculated using a formula developed by the IPHC. The table below shows the fishery and subarea allocations resulting from the framework described in the 2020 Area 2A Catch Sharing Plan.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,12,12">
                    <TTITLE>Table 1—Area 2A Catch Limit and Fishery Subarea Allocations for 2020</TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Pounds</CHED>
                        <CHED H="1">Metric tons</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Area 2A TCEY</ENT>
                        <ENT>1,650,000</ENT>
                        <ENT>748.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Area 2A Catch Limit</ENT>
                        <ENT>1,500,000</ENT>
                        <ENT>680.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Tribal commercial fishery</ENT>
                        <ENT>492,800</ENT>
                        <ENT>223.5</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Incidental commercial catch during sablefish fishery</ENT>
                        <ENT>70,000</ENT>
                        <ENT>31.8</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Non-tribal directed commercial fishery</ENT>
                        <ENT>254,426</ENT>
                        <ENT>115.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Incidental commercial catch during salmon troll fishery</ENT>
                        <ENT>44,899</ENT>
                        <ENT>20.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Washington recreational fishery—Puget Sound</ENT>
                        <ENT>77,550</ENT>
                        <ENT>35.2</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25318"/>
                        <ENT I="01">Washington recreational fishery—North Coast</ENT>
                        <ENT>128,187</ENT>
                        <ENT>58.1</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Washington recreational fishery—South Coast</ENT>
                        <ENT>62,896</ENT>
                        <ENT>28.5</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Columbia River recreational fishery</ENT>
                        <ENT>18,450</ENT>
                        <ENT>8.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Oregon recreational fishery—Central Oregon</ENT>
                        <ENT>271,592</ENT>
                        <ENT>123.2</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Oregon recreational fishery—Southern Oregon</ENT>
                        <ENT>8,000</ENT>
                        <ENT>3.6</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">California recreational fishery</ENT>
                        <ENT>39,000</ENT>
                        <ENT>17.7</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    The Area 2A catch limit, tribal commercial fishery allocation, and commercial fishery allocations are adopted by the IPHC and were published in the 
                    <E T="04">Federal Register</E>
                     on March 13, 2020 (85 FR 14586) after acceptance by the Secretary of State in accordance with 50 CFR 300.62.
                </P>
                <P>
                    Since 1988, NMFS has implemented annual Catch Sharing Plans that allocate the IPHC regulatory Area 2A Pacific halibut catch limit between treaty Indian and non-Indian harvesters, and among non-Indian commercial and recreational (sport) fisheries. The Pacific Fishery Management Council (Council) develops Catch Sharing Plans in accordance with the Halibut Act. In 1995, the Council recommended, and NMFS approved and implemented a long-term Area 2A Catch Sharing Plan (60 FR 14651; March 20, 1995). NMFS has been implementing adjustments to the Area 2A Catch Sharing Plan based on Council recommendations each year to address the changing needs of these fisheries. While the full Catch Sharing Plan is not published in the 
                    <E T="04">Federal Register</E>
                    , it is made available on the Council and NMFS websites.
                </P>
                <P>This rule adopts the Council's recommended changes to the Catch Sharing Plan for IPHC regulatory Area 2A, which affect only the recreational fishery. The Catch Sharing Plan changes provide more opportunities for anglers in Washington and Oregon by remaining open more days per week, opening up to one month earlier, and transferring quota to the Columbia River from the Southern Oregon subarea in years with a high catch limit. Details of these changes are described in the proposed rule and are not repeated here.</P>
                <P>In addition, this rule implements the recreational Pacific halibut fishery management measures, such as season dates and some catch limits, set in NMFS regulations and described in the proposed rule (85 FR 6883; February 6, 2020). These management measures are detailed in the Council's recommended Catch Sharing Plan and were developed through the Council's public process. This rule implements most of the 2020 dates for the recreational fisheries consistent with the Council's recommendations as well as recommendations from Oregon, Washington, and California that were received either during the Council process or during the comment period for the proposed rule. However, this rule implements season dates different from the proposed rule for the State of Washington, in response to measures enacted due to the COVID-19 pandemic.</P>
                <HD SOURCE="HD2">Regulatory Changes</HD>
                <P>
                    This rule also revises some provisions of the regulations at 50 CFR part 300, subpart E, for clarity and consistency. Regulations at 50 CFR 300.61 and 300.64 describe the usual and accustomed (U&amp;A) fishing areas of Indian tribes with treaty fishing rights to Pacific halibut. NMFS is revising the definition of Subarea 2A-1 at 50 CFR 300.61 to a more general description. At 50 CFR 300.64, NMFS is updating the table to reflect a March 5, 2018, court decision revising the western boundaries of the U&amp;A fishing areas for the Quileute Indian Tribe and the Quinault Indian Nation. 
                    <E T="03">United States</E>
                     v. 
                    <E T="03">Washington,</E>
                     2:09-sp-00001-RSM, (W.D. Wash. March 5, 2018) (Order Regarding Boundaries of Quinault and Quileute U&amp;As). The boundaries of other U&amp;A fishing areas are not affected by this rulemaking. At 50 CFR 300.63(d), NMFS is removing cross-references to specific section numbers in IPHC regulations to prevent inconsistency.
                </P>
                <HD SOURCE="HD2">Incidental Halibut Retention in the Sablefish Primary Fishery North of Pt. Chehalis, WA</HD>
                <P>The 2020 Catch Sharing Plan allows incidental halibut retention in the sablefish primary fishery north of Pt. Chehalis, WA, when the Washington recreational catch limit is 214,110 lb (101.7 mt) or greater, provided that a minimum of 10,000 lb (4.5 mt) is available. The Area 2A catch limit for 2020 is great enough to allow 70,000 lb (31.8 mt) for incidental halibut retention in the sablefish primary fishery, which is the maximum amount that may be allocated to the sablefish fishery when the catch limit is 1,500,000 lb (680.4 mt) or more. This limit was adopted as part of the rule published March 13, 2020 (85 FR 14586), and as shown in Table 1. Incidental halibut landing restrictions in the sablefish fishery are recommended by the Council and implemented in the groundfish regulations at 50 CFR 660.231(b)(3)(iv).</P>
                <HD SOURCE="HD2">2020 Recreational Fishery Management Measures</HD>
                <P>The annual domestic management measures are published each year through a final rule under NMFS' authority to implement the Halibut Convention (50 CFR 300.62). For the 2020 fishing season, the final rule for the commercial fisheries, IPHC regulations, and catch limits was published on March 13, 2020 (85 FR 14586). The section numbers below correspond to IPHC regulation sections in the March 13, 2020, final rule.</P>
                <P>NMFS is adopting recreational fishery management measures, including season dates that are necessary to implement the Council's recommended Catch Sharing Plan in 2020. The Catch Sharing Plan includes a framework for setting fishing open days by subarea, and each state submits final recommended season dates annually. While this rule implements most season dates as recommended by the Council, some season dates for the State of Washington are different from the proposed rule, in response to measures enacted due to the COVID-19 pandemic. With the exception of some Washington season dates, the recreational fishing regulations for Area 2A are consistent with the measures adopted by the IPHC and approved by the Secretary of State, but were developed in part by the Council and promulgated by the United States under the Halibut Act.</P>
                <P>
                    At the time of the publication of this rule, in response to the spread of COVID-19, there are certain measures in place in the State of Washington that would inhibit the accurate monitoring of the quota allocations implemented through this action. Accurate monitoring and catch accounting of the overall Area 2A allocation, as well subarea allocations, is important for the 
                    <PRTPAGE P="25319"/>
                    conservation and management of Pacific halibut and maintaining the intended fishing opportunity provided by this rule. Specifically, State port samplers are currently not being deployed to collect catch information on recreational landings, and data collected by these samplers is necessary to track the state and subarea catch allocations and prevent overages. At the time of this publication, Washington has announced that it anticipates keeping this restriction in place through May 4, 2020. Based on this information, NMFS has determined that it is necessary to implement an opening season date in Washington State subareas such that the season will start on the next proposed open day after May 4, 2020. For Washington subareas, the first open date is May 7, 2020. The largest difference in these dates compared to what was proposed is for the Puget Sound subarea. Initially, the Puget Sound subarea was proposed to open April 16, 2020, which would have been two weeks earlier than the May 2, 2019, opening. In 2018, Washington fisheries opened statewide May 11, therefore this change does not result in a major difference compared with previous years' opening dates.
                </P>
                <P>State measures being put in place as a result of the COVID-19 pandemic are fluid, and it may be necessary to further modify the opening dates or respond to a decrease in catch monitoring in other subareas within Washington State, or California and Oregon shortly after the publication of this final rule. Any such change will be announced on the NMFS hotline at (206) 526-6667 or 800-662-9825. NMFS is closely monitoring this situation and coordinating with all three of the West Coast state fish and wildlife agencies, so that we can meet conservation needs while also providing fishing opportunity.</P>
                <P>This rule provides specific regulations, as referred to in paragraph (7) of the 2020 IPHC regulations under the heading, “Recreational (Sport) Fishing for Pacific Halibut—IPHC Regulatory Area 2A”:</P>
                <P>(8) The sport fishing subareas, subquotas, fishing dates, and daily bag limits are as follows, except as modified by an inseason action consistent with 50 CFR 300.63(c). All sport fishing in Area 2A is managed on a “port of landing” basis, whereby any halibut landed into a port counts toward the quota for the area in which that port is located, and the regulations governing the area of landing apply, regardless of the specific area of catch.</P>
                <P>(a) The quota for the area in Puget Sound and the U.S. waters in the Strait of Juan de Fuca, east of a line extending from 48°17.30′ N lat., 124°23.70′ W long. north to 48°24.10′ N lat., 124°23.70′ W long., is 77,550 pounds (35.18 mt).</P>
                <P>(i) The fishing seasons are:</P>
                <P>(A) For the area in Puget Sound and the U.S. waters in the Strait of Juan de Fuca, east of a line at approximately 123°49.60′ W long., fishing is open May 7-9, 14-16, 22-24, 28-30; June 4-6, 11-13, 18-20, and 25-27, or until there is not sufficient quota for another full day of fishing and the area is closed by the Commission. Any closure will be announced on the NMFS hotline at (206) 526-6667 or 800-662-9825.</P>
                <P>(B) For the area in U.S. waters in the Strait of Juan de Fuca, approximately between 124°23.70′ W long. and 123°49.60′ W long., fishing is open May 7, 9, 14, 16, 22, 23, 24, 28-30; June 4-6, 11-13, 18-20, and 25-27, or until there is not sufficient quota for another full day of fishing and the area is closed by the Commission. Any closure will be announced on the NMFS hotline at (206) 526-6667 or 800-662-9825.</P>
                <P>(ii) The daily bag limit is one halibut of any size per day per person.</P>
                <P>(b) The quota for landings into ports in the area off the north Washington coast, west of the line described in paragraph (2)(a) of section 26 and north of the Queets River (47°31.70′ N lat.) (North Coast subarea), is 128,187 pounds (58.14 mt).</P>
                <P>(i) The fishing seasons are:</P>
                <P>(A) Fishing is open May 7, 9, 14, 16, 22, 24, 28, 30; June 4, 6, 11, 13, 18, 20, 25, and 27, or until there is not sufficient quota for another full day of fishing and the area is closed by the Commission. Any closure will be announced on the NMFS hotline at (206) 526-6667 or 800-662-9825.</P>
                <P>(ii) The daily bag limit is one halibut of any size per day per person.</P>
                <P>(iii) Recreational fishing for groundfish and halibut is prohibited within the North Coast Recreational Yelloweye Rockfish Conservation Area (YRCA). It is unlawful for recreational fishing vessels to take and retain, possess, or land halibut taken with recreational gear within the North Coast Recreational YRCA. A vessel fishing with recreational gear in the North Coast Recreational YRCA may not be in possession of any halibut. Recreational vessels may transit through the North Coast Recreational YRCA with or without halibut on board. The North Coast Recreational YRCA is a C-shaped area off the northern Washington coast intended to protect yelloweye rockfish. The North Coast Recreational YRCA is defined in groundfish regulations at 50 CFR 660.70(b).</P>
                <P>(c) The quota for landings into ports in the area between the Queets River, WA (47°31.70′ N lat.), and Leadbetter Point, WA (46°38.17′ N lat.)(South Coast subarea), is 62,896 pounds (28.53 mt).</P>
                <P>(i) This subarea is divided between the all-depth fishery (the Washington South coast primary fishery), and the incidental nearshore fishery in the area from 47°31.70′ N lat. south to 46°58.00′ N lat. and east of a boundary line approximating the 30-fm (55-m) depth contour. This area is defined by straight lines connecting all of the following points in the order stated as described by the following coordinates (the Washington South coast, northern nearshore area):</P>
                <EXTRACT>
                    <P>(1) 47°31.70′ N lat, 124°37.03′ W long;</P>
                    <P>(2) 47°25.67′ N lat, 124°34.79′ W long;</P>
                    <P>(3) 47°12.82′ N lat, 124°29.12′ W long;</P>
                    <P>(4) 46°58.00′ N lat, 124°24.24′ W long.</P>
                </EXTRACT>
                <P>The primary fishery season dates are May 7, 10, 14, 17, 21; June 18, 21, 25, and 28, or until there is not sufficient quota for another full day of fishing and the area is closed by the Commission. Any closure will be announced on the NMFS hotline at (206) 526-6667 or 800-662-9825. If sufficient quota remains, the fishing season in the nearshore area commences the Saturday subsequent to the closure of the primary fishery and continues 7 days per week until 62,896 pounds (28.53 mt) is projected to be taken by the two fisheries combined and the fishery is closed by the Commission or September 30, whichever is earlier. If the fishery is closed prior to September 30, and there is insufficient quota remaining to reopen the northern nearshore area for another fishing day, then any remaining quota may be transferred inseason to another Washington coastal subarea by NMFS.</P>
                <P>(ii) The daily bag limit is one halibut of any size per day per person.</P>
                <P>(iii) Seaward of the boundary line approximating the 30-fm (55-m) depth contour and during days open to the primary fishery, lingcod may be taken, retained and possessed when allowed by groundfish regulations at 50 CFR 660.360.</P>
                <P>
                    (iv) Recreational fishing for groundfish and halibut is prohibited within the South Coast Recreational YRCA and Westport Offshore YRCA. It is unlawful for recreational fishing vessels to take and retain, possess, or land halibut taken with recreational gear within the South Coast Recreational YRCA and Westport Offshore YRCA. A vessel fishing in the South Coast Recreational YRCA and/or Westport Offshore YRCA may not be in possession of any halibut. Recreational vessels may transit through the South Coast Recreational YRCA and Westport Offshore YRCA with or without halibut 
                    <PRTPAGE P="25320"/>
                    on board. The South Coast Recreational YRCA and Westport Offshore YRCA are areas off the southern Washington coast established to protect yelloweye rockfish. The South Coast Recreational YRCA is defined at 50 CFR 660.70(e). The Westport Offshore YRCA is defined at 50 CFR 660.70(f).
                </P>
                <P>(d) The quota for landings into ports in the area between Leadbetter Point, WA (46°38.17′ N lat.), and Cape Falcon, OR (45°46.00′ N lat.)(Columbia River subarea), is 18,450 pounds (8.37 mt).</P>
                <P>(i) This subarea is divided into an all-depth fishery and a nearshore fishery. The nearshore fishery is allocated 500 lb (0.23 mt) of the subarea allocation. The nearshore fishery extends from Leadbetter Point (46°38.17′ N lat., 124°15.88′ W long.) to the Columbia River (46°16.00′ N lat., 124°15.88′ W long.) by connecting the following coordinates in Washington: 46°38.17′ N lat., 124°15.88′ W long. 46°16.00′ N lat., 124°15.88′ W long. and connecting to the boundary line approximating the 40-fm (73-m) depth contour in Oregon. The nearshore fishery opens May 4, and continues on Monday, Tuesday, and Wednesday each week until the nearshore allocation is taken, or September 30, whichever is earlier. The all-depth fishing season is open April 30; May 3, 7, 10, 14, 17, 21, 28, 31; June 4, 7, 11, 14, 18, 21, 25, and 28, or until there is not sufficient quota for another full day of fishing and the area is closed by the Commission, or September 30, whichever is earlier. Any closure will be announced on the NMFS hotline at (206) 526-6667 or 800-662-9825. Subsequent to this closure, if there is insufficient quota remaining in the Columbia River subarea for another fishing day, then any remaining quota may be transferred inseason to another Washington and/or Oregon subarea by NMFS. Any remaining quota would be transferred to each state in proportion to its contribution.</P>
                <P>(ii) The daily bag limit is one halibut of any size per day per person.</P>
                <P>(iii) Pacific Coast groundfish may not be taken and retained, possessed or landed when halibut are on board the vessel, except sablefish, Pacific cod, flatfish species, and lingcod caught north of the Washington-Oregon border during the recreational halibut fishery, when allowed by Pacific Coast groundfish regulations, during days open to the all-depth fishery only.</P>
                <P>(iv) Taking, retaining, possessing, or landing halibut on groundfish trips is only allowed in the nearshore area on days not open to all-depth Pacific halibut fisheries.</P>
                <P>(e) The quota for landings into ports in the area off Oregon between Cape Falcon (45°46.00′ N lat.) and Humbug Mountain (42°40.50′ N lat.) (Oregon Central Coast subarea), is 271,592 pounds (123.19 mt).</P>
                <P>(i) The fishing seasons are:</P>
                <P>(A) The first season (the “inside 40-fm” fishery) commences May 1, and continues 7 days a week, in the area shoreward of a boundary line approximating the 40-fm (73-m) depth contour, or until the sub-quota for the central Oregon “inside 40-fm” fishery of 32,591 pounds (14.8 mt), or any inseason revised subquota, is estimated to have been taken and the season is closed by the Commission, or October 31, whichever is earlier. The boundary line approximating the 40-fm (73-m) depth contour between 45°46.00′ N lat. and 42°40.50′ N lat. is defined at § 660.71(o).</P>
                <P>(B) The second season (spring season), which is for the “all-depth” fishery, is open May 14, 15, 16; 21, 22, 23; 28, 29, 30; June 11, 12, 13; 18, 19, 20; and July 9, 10, 11. The allocation to the all-depth fishery is 171,103 pounds (77.6 mt). If sufficient unharvested quota remains for additional fishing days, the season will re-open July 23, 24, 25. Notice of the re-opening will be announced on the NMFS hotline (206) 526-6667 or (800) 662-9825.</P>
                <P>(C) The third season (summer season), which is for the “all-depth” fishery, will be August 6, 7, 8; 20, 21, 22; September 3, 4, 5; 17, 18, 19; October 1, 2, 3; 15, 16, 17; 29, 30, 31; and will continue until the combined spring season and summer season quotas in the area between Cape Falcon and Humbug Mountain, Oregon, are estimated to have been taken and the area is closed by the Commission. NMFS will announce on the NMFS hotline in July whether the fishery will re-open for the summer season in August. Additional fishing days may be opened if sufficient quota remains after the last day of the first scheduled open period. If, after this date, an amount greater than or equal to 60,000 lb (27.2 mt) remains in the combined all-depth and inside 40-fm (73-m) quota, the fishery may re-open every Thursday, Friday and Saturday, beginning August 6, 7, and 8, and ending when there is insufficient quota remaining, whichever is earlier. If after September 8, an amount greater than or equal to 30,000 lb (13.6 mt) remains in the combined all-depth and inside 40-fm (73-m) quota, and the fishery is not already open every Thursday, Friday and Saturday, the fishery may re-open every Thursday, Friday and Saturday, beginning September 10, 11, and 12, and ending October 31. After September 8, the bag limit may be increased to two fish of any size per person, per day. NMFS will announce on the NMFS hotline whether the summer all-depth fishery will be open on such additional fishing days, what days the fishery will be open and what the bag limit is.</P>
                <P>(ii) The daily bag limit is one halibut of any size per day per person, unless otherwise specified. NMFS will announce on the NMFS hotline any bag limit changes.</P>
                <P>(iii) During days open to all-depth halibut fishing when the groundfish fishery is restricted by depth, no groundfish may be taken and retained, possessed or landed, when halibut are on board the vessel, except sablefish, Pacific cod, and flatfish species, when allowed by groundfish regulations, if halibut are onboard the vessel. During days open to all-depth halibut fishing when the groundfish fishery is open to all depths, any groundfish species permitted under the groundfish regulations may be retained, possessed or landed if halibut are on board the vessel. During days open to nearshore halibut fishing, flatfish species may be taken and retained seaward of the seasonal groundfish depths restrictions, if halibut are on board the vessel.</P>
                <P>(iv) When the all-depth halibut fishery is closed and halibut fishing is permitted only shoreward of a boundary line approximating the 40-fm (73-m) depth contour, halibut possession and retention by vessels operating seaward of a boundary line approximating the 40-fm (73-m) depth contour is prohibited.</P>
                <P>(v) Recreational fishing for groundfish and halibut is prohibited within the Stonewall Bank YRCA. It is unlawful for recreational fishing vessels to take and retain, possess, or land halibut taken with recreational gear within the Stonewall Bank YRCA. A vessel fishing in the Stonewall Bank YRCA may not possess any halibut. Recreational vessels may transit through the Stonewall Bank YRCA with or without halibut on board. The Stonewall Bank YRCA is an area off central Oregon, near Stonewall Bank, intended to protect yelloweye rockfish. The Stonewall Bank YRCA is defined at § 660.70(g).</P>
                <P>(f) The quota for landings into ports in the area south of Humbug Mountain, OR (42°40.50′ N lat.) to the Oregon/California Border (42°00.00′ N lat.) (Southern Oregon subarea) is 8,000 pounds (3.63 mt).</P>
                <P>(i) The fishing season commences on May 1, and continues 7 days per week until the subquota is taken, or October 31, whichever is earlier.</P>
                <P>(ii) The daily bag limit is one halibut per person with no size limit.</P>
                <P>
                    (iii) No Pacific Coast groundfish may be taken and retained, possessed or 
                    <PRTPAGE P="25321"/>
                    landed, except sablefish, Pacific cod, and flatfish species, in areas closed to groundfish, if halibut are on board the vessel.
                </P>
                <P>(g) The quota for landings into ports south of the Oregon/California Border (42°00.00′ N lat.) and along the California coast is 39,000 pounds (17.69 mt).</P>
                <P>(i) The fishing season will be open May 1 through October 31, or until the subarea quota is estimated to have been taken and the season is closed by the Commission, whichever is earlier. NMFS will announce any closure by the Commission on the NMFS hotline (206) 526-6667 or (800) 662-9825.</P>
                <P>(ii) The daily bag limit is one halibut of any size per day per person.</P>
                <HD SOURCE="HD1">Comments and Responses</HD>
                <P>NMFS accepted public comments on the Council's recommended modifications to the 2020 Area 2A Catch Sharing Plan and the resulting proposed domestic fishing regulations through March 9, 2020. NMFS received two comments from State agencies- the Oregon Department of Fish and Wildlife (ODFW) and the California Department of Fish and Wildlife (CDFW), and one comment from a stakeholder.</P>
                <P>
                    <E T="03">Comment 1:</E>
                     ODFW submitted a comment recommending final recreational fishing season dates for the 2020 season for the Central Oregon Coast subarea. ODFW hosted a public meeting and an online survey following the IPHC annual meeting. Based on stakeholder input, past effort, and tides, ODFW recommended season dates for the spring and summer Central Coast fisheries. For spring, fixed open dates on May 14, 15, 16; May 21, 22, 23; May 28, 29, 30; June 11, 12, 13; June 18, 19, 20; and July 9, 10, 11. ODFW recommended spring fishery backup dates on July 23, 24, 25. ODFW recommended summer fishery dates on August 6, 7, 8; August 20, 21, 22; September 3, 4, 5; September 17, 18,19; October 1, 2, 3; October 15, 16, 17; and October 29, 30, 31; or until the total 2020 all-depth catch limit for the subarea is taken.
                </P>
                <P>
                    <E T="03">Response:</E>
                     NMFS concurs that the ODFW-recommended season dates are appropriate. There are a few differences between the spring season dates NMFS published in the proposed rule and those recommended by ODFW. However, ODFW surveyed their stakeholders after the IPHC adopted the catch limit for 2020 and considered stakeholder input, past effort and tides in making their recommendation. NMFS has updated the recreational fishery season dates off of Oregon to those recommended by ODFW in this final rule.
                </P>
                <P>
                    <E T="03">Comment 2:</E>
                     CDFW submitted a comment concurring with the season dates NMFS published in the proposed rule for the 2020 season. CDFW hosted an online survey following the IPHC annual meeting. Based on public comments received on Pacific halibut fisheries in California and fishing performance in recent years, CDFW recommended season dates of May 1-October 31, or until quota has been attained, whichever comes first.
                </P>
                <P>
                    <E T="03">Response:</E>
                     NMFS concurs that these season dates are appropriate. The catch limit for 2020 is the same as 2019, and the California catch limit was not fully attained last year with the same season dates. NMFS affirms the recreational fishery season dates off of California in this final rule.
                </P>
                <P>
                    <E T="03">Comment 3:</E>
                     NMFS received one public comment in support of approving the 2020 Pacific Halibut Catch Sharing Plan. This comment also suggested further review of incidental catch and fostering input from diverse groups of stakeholders.
                </P>
                <P>
                    <E T="03">Response:</E>
                     NMFS concurs that approving the 2020 Pacific Halibut Catch Sharing Plan is appropriate. With regards to the commenters' concern regarding the incidental catch distribution and stakeholder opinion, although NMFS believes in the accuracy of the incidental catch and has made various attempts, including taking public comment on the proposed rule, to gain insight on the public's needs, we will continue to review ways to ensure these two areas are as accurate as possible in the future.
                </P>
                <HD SOURCE="HD1">Changes From the Proposed Rule</HD>
                <P>As described in the response to Comment 1 above, NMFS changed season dates off of Oregon in this final rule.</P>
                <P>NMFS is also implementing season dates in the Washington subareas such that the season will start on the next proposed open day after May 4, 2020. For Washington fisheries, the first open date is May 7, 2020. The Puget Sound subarea dates are the most different than those proposed. An opening date of April 16, 2020, was originally proposed and would have resulted in the Puget Sound fishery opening two weeks earlier than previous years, in an attempt to provide more angler opportunity in an area that had low attainment in 2019. The other Washington subareas will have two fewer fishing days than proposed and would open around the same time as previous years. Therefore this is not a significant change from previous years' opening dates.</P>
                <P>The decision to modify the opening season date for Washington subareas is a result of the various measures currently in place associated with Washington State's “Stay Home, Stay Healthy” order. Specifically, State port samplers are currently not being deployed to collect catch information on recreational landings, and data collected by these samplers is necessary to track the state and subarea catch allocations and prevent overages. At this time, it is unclear when port sampling will resume. WDFW has also closed all State recreational fisheries through May 4, 2020. Therefore, unless that order is revised, it is unlikely that samplers will begin working before that date. The situation due to the COVID-19 pandemic remains fluid. While it appears there will not be port sampling prior to May 5, 2020, port sampling is carried out by the State and may be revised quickly. It may therefore be necessary to further modify the opening dates or other fishing days for some subareas shortly after the publication of this final rule in response to changes in State measures related to the spread of COVID-19.</P>
                <HD SOURCE="HD1">Classification</HD>
                <P>Regulations governing the U.S. fisheries for Pacific halibut are developed by the International Pacific Halibut Commission (IPHC), the Pacific Fishery Management Council, the North Pacific Fishery Management Council, and the Secretary of Commerce. Section 5 of the Halibut Act (16 U.S.C. 773c) allows the Regional Council having authority for a particular geographical area to develop regulations governing the allocation and catch of halibut in U.S. Convention waters as long as those regulations do not conflict with IPHC regulations. This action is consistent with the Council's authority to allocate halibut catches among fishery participants in the waters in and off Washington, Oregon, and California.</P>
                <P>This final rule has been determined to be not significant for purposes of Executive Order 12866. This final rule is not an Executive Order 13771 regulatory action because this rule is not significant under Executive Order 12866.</P>
                <P>
                    Pursuant to 5 U.S.C. 553(d)(1), a thirty-day delay in effective date is not applicable because these final regulations for the 2020 Pacific halibut fishing season relieve a restriction. The 2020 Catch Sharing Plan provides the framework for the annual management measures and subarea allocations based on the 2020 Area 2A catch limit for 
                    <PRTPAGE P="25322"/>
                    Pacific halibut. These allocations are based on the best available new information on the population status of Pacific halibut, determined at the annual meeting of the IPHC held February 3-7, 2020. Additionally, the Washington Puget Sound subarea was originally scheduled to be open April 16, 2020, two weeks earlier than in 2019, to allow more opportunity for fishing and this rule implements subarea allocations for that fishery. Due to COVID-19, Washington has closed its recreational fisheries and paused its port sampling and catch accounting program. Without catch data, there is no way to track state and subarea landings against the allocation to prevent overages. NMFS is responding to the Washington recreational fishing actions by revising season dates in the Washington subareas such that the season will start on the next proposed open day after May 4, 2020. The season date being implemented in this action is similar to season start dates in previous years, when Washington had season openers on May 2, 2019, and May 11, 2018. The recreational season for the Columbia River subarea, beginning on the soonest possible scheduled date after April 30, 2020, is scheduled to take place as proposed. A delay in the effectiveness of this rule for a full thirty days would result in delayed openings for these fisheries rather than on the dates the affected public are expecting.
                </P>
                <P>Additionally, there is good cause under 5 U.S.C. 553(d)(3) to ensure these regulations are effective immediately upon publication. The Council's 2020 Catch Sharing Plan approved in this rule includes changes that respond to the needs of the fisheries in Washington and Oregon, including fisheries that begin on the soonest possible scheduled date after April 30, 2020. In 2019, the recreational fisheries in Washington, Oregon, and California did not achieve their full quotas as in previous years. The Council recommended changes to the Catch Sharing Plan to allow fisheries in Washington and Oregon to open up earlier and remain open more days per week, as well as transfer quota from Southern Oregon to the Columbia River subarea in years with a high catch limit. Delaying the effective date of this rule beyond April 30, 2020, would be contrary to the public interest because, without these changes, fishing opportunity is lost, potentially causing economic harm to communities at sport fishing ports. Washington season dates published in the proposed rule were revised in the final rule from mid-April to early May. The Columbia River subarea is still scheduled to be open on the soonest possible scheduled date after April 30, and Oregon and California fisheries are still scheduled to be open May 1. Additionally, the season dates in this rule are specific to 2020 according to the Catch Sharing Plan framework. Without the publication of this rule, the 2019 season dates would remain in place, and would not occur on the days of the week specified in the Catch Sharing Plan.</P>
                <P>
                    Therefore, allowing the 2019 Catch Sharing Plan to remain in place would not respond to the needs of the fishery and would be in conflict with the Council's final recommendation for 2020. A thirty-day delay in effectiveness could cause economic harm to the associated fishing communities by reducing fishing opportunity at the start of the fishing year. As a result of the potential harm to fishing communities that could be caused by delaying the effectiveness of this final rule, NMFS finds good cause to make this rule effective upon publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <HD SOURCE="HD1">Final Regulatory Flexibility Analysis</HD>
                <P>A final regulatory flexibility analysis (FRFA) was prepared. The FRFA incorporates the IRFA, a summary of the significant issues raised by the public comments in response to the IRFA, and NMFS responses to those comments, and a summary of the analyses completed to support the action. A summary of the analysis follows.</P>
                <P>
                    <E T="03">A statement of the significant issues raised by the public comments in response to the IRFA, a statement of the assessment of the agency of such issues, and a statement of any changes made in the proposed rule as a result of such comments.</E>
                </P>
                <P>There were no issues raised about the IRFA in the public comments.</P>
                <P>
                    <E T="03">The response of the agency to any comments filed by the Chief Counsel for Advocacy in response to the proposed rule, and a detailed statement of any change made to the proposed rule in the final rule as a result of the comments.</E>
                </P>
                <P>There were no comments filed by the Chief Counsel for Advocacy.</P>
                <HD SOURCE="HD2">Statement of the Objectives of, and Legal Basis for, the Final Rule</HD>
                <P>The Halibut Act gives the Secretary of Commerce responsibility for implementing the provisions of the Halibut Convention between the United States and Canada. The Halibut Act requires that the Secretary adopt regulations to carry out the purposes and objectives of the Halibut Convention and Halibut Act. The Halibut Act also authorizes the regional fishery management councils to develop regulations in addition to, but not in conflict with, regulations of the IPHC to govern the Pacific halibut catch in their corresponding U.S. Convention waters. The Council's main management objective for the Pacific halibut fishery in Area 2A is to manage fisheries to remain within the catch limit for Area 2A.</P>
                <P>A second objective is to allow the recreational (sport) fishery to target halibut in the manner that is appropriate to meet the conservation requirements for species that co-occur with Pacific halibut. A third objective is to meet the needs of fishery participants in particular fisheries and fishing areas.</P>
                <HD SOURCE="HD2">A Description and, Where Feasible, Estimate of the Number of Small Entities to Which the Final Rule Applies</HD>
                <P>This action revises the recreational Pacific halibut fishery management measures, such as season dates and some catch limits that are set in NMFS regulations. This rule opens the recreational fishery with 2020 season dates and subarea allocations, impacting charter boats, anglers, and businesses relying on sport fishing across all of Area 2A. This rule also makes changes to the sport fishing sector of the Catch Sharing Plan for the halibut fishery, impacting participants in the recreational Washington and Oregon subareas. Therefore, this rule may affect some charterboat operations in Area 2A. Previous analyses determined that charterboats are small businesses (see 77 FR 5477 (February 3, 2012) and 76 FR 2876 (January 18, 2011)). Charter fishing operations are classified under NAICS code, 487210, with a corresponding Small Business Association size standard of $7.5 million in annual receipts. No commercial fishing entities are directly affected by this rule.</P>
                <P>In 2019, the IPHC issued 84 licenses to the charterboat fleet. NMFS estimates there are 47 licensed charterboats in Washington, and 26 in Oregon. Recent information on charterboat activity is not available, but prior analysis indicated that 60 percent of the IPHC charterboat license holders (around 50 vessels) may be affected by these regulations. Private vessels used for recreational fishing are not businesses and are therefore not subject to the RFA.</P>
                <HD SOURCE="HD2">Reporting, Record-Keeping, and Other Compliance Requirements</HD>
                <P>
                    The changes to the Catch Sharing Plan and domestic management measures do not include any new reporting or recordkeeping requirements.
                    <PRTPAGE P="25323"/>
                </P>
                <HD SOURCE="HD2">Federal Rules That May Duplicate, Overlap or Conflict With the Final Rule</HD>
                <P>There are no relevant Federal rules that may duplicate, overlap, or conflict with this action.</P>
                <HD SOURCE="HD2">Description and Estimate of Economic Effects on Entities, by Entity Size and Industry</HD>
                <P>The major effect of halibut management on small entities will be from the catch limit decisions made by the IPHC, a decision independent from this action. This action implements management measures including season dates and bag limits for the recreational fishery, and makes minor changes to the Catch Sharing Plan to provide increased recreational opportunities under the allocations that result from the Area 2A catch limit. The changes to the Catch Sharing Plan are considered minor, with minimal economic effects.</P>
                <HD SOURCE="HD2">A Description of, and an Explanation of the Basis for, Assumptions Used</HD>
                <P>In the description of the entities affected, estimates of the amount of charterboat activity from the number of licensed vessels were based on a 2004 report by the Pacific States Marine Fisheries Commission. This report has not been updated and the number of entities is assumed to be similar.</P>
                <HD SOURCE="HD2">Description of any Significant Alternatives to the Final Rule That Accomplish the Stated Objectives of Applicable Statutes and That Minimize any Significant Economic Impact of the Rule on Small Entities</HD>
                <P>The status quo alternative of not implementing management measures, such as season dates and bag limits, or revising the Catch Sharing Plan would not achieve the objectives and requirements of the Convention and Halibut Act, specifically conserving Pacific halibut and allocating quota equitably. Without establishing 2020 season dates and subarea allocations, there would be a significant economic impact on the entire recreational sector, including charter boats. When considered with the management measures, the changes to the Catch Sharing Plan have minimal effect on the fishery and there are no other additional significant alternatives that further minimize the impact of the rule on small entities while achieving the goals and objectives of the Convention and Halibut Act. In addition, these management measures and Catch Sharing Plan changes were proposed by stakeholders to address the needs of the fisheries, and, as explained above, the changes are not expected to have a significant economic impact on a substantial number of small entities.</P>
                <P>
                    Section 212 of the Small Business Regulatory Enforcement Fairness Act of 1996 states that, for each rule or group of related rules for which an agency is required to prepare a FRFA, the agency shall publish one or more guides to assist small entities in complying with the rule, and shall designate such publications as “small entity compliance guides.” The agency shall explain the actions a small entity is required to take to comply with a rule or group of rules. As part of this rulemaking process, a public notice to fishery participants that also serves as a small entity compliance guide (the guide) was prepared. Copies of this final rule are available from the West Coast Regional Office, and the guide, 
                    <E T="03">i.e.,</E>
                     public notice, will be sent to all stakeholders on the email listserv for the groundfish fishery, and posted to the West Coast groundfish and halibut web pages. The guide and this final rule will be available upon request.
                </P>
                <P>
                    A copy of this analysis is available from NMFS (see 
                    <E T="02">ADDRESSES</E>
                    ).
                </P>
                <P>This rule was developed after meaningful consultation and collaboration with the tribal representative on the Council, pursuant to Executive Order 13175.</P>
                <P>The U.S. Government formally recognizes that the 13 Washington Tribes have treaty rights to fish for Pacific halibut. In general terms, the quantification of those rights is 50 percent of the harvestable surplus of Pacific halibut available in the tribes' usual and accustomed fishing areas (described at 50 CFR 300.64). Each of the treaty tribes has the discretion to administer their fisheries and to establish their own policies to achieve program objectives. Accordingly, tribal allocations and regulations, including the changes to the Catch Sharing Plan, have been developed in consultation with the affected tribe(s) and, insofar as possible, with tribal consensus.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 50 CFR Part 300</HD>
                    <P>Administrative practice and procedure, Antarctica, Canada, Exports, Fish, Fisheries, Fishing, Imports, Indians, Labeling, Marine resources, Reporting and recordkeeping requirements, Russian Federation, Transportation, Treaties, Wildlife.</P>
                </LSTSUB>
                <SIG>
                    <DATED>Dated: April 27, 2020.</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, 50 CFR part 300, subpart E, is amended as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 300-INTERNATIONAL FISHERIES REGULATIONS</HD>
                    <SUBPART>
                        <HD SOURCE="HED">Subpart E—Pacific Halibut Fisheries</HD>
                    </SUBPART>
                </PART>
                <REGTEXT TITLE="50" PART="300">
                    <AMDPAR> 1. The authority citation for part 300, subpart E, continues to read as follows:</AMDPAR>
                    <AUTH>
                        <HD SOURCE="HED">Authority:</HD>
                        <P> 16 U.S.C. 773-773k.</P>
                    </AUTH>
                </REGTEXT>
                <REGTEXT TITLE="50" PART="300">
                    <AMDPAR> 2, In § 300.61, revise the definition of “Subarea 2A-1” to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 300.61 </SECTNO>
                        <SUBJECT>Definitions.</SUBJECT>
                        <STARS/>
                        <P>
                            <E T="03">Subarea 2A-1</E>
                             includes the usual and accustomed fishing areas for Pacific Coast treaty tribes off the coast of Washington and all inland marine waters of Washington north of Point Chehalis (46°53.30′ N lat.), including Puget Sound. Boundaries of a tribe's fishing area may be revised as ordered by a Federal court.
                        </P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="50" PART="300">
                    <AMDPAR>3. In § 300.63, revise paragraph (d) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 300.63 </SECTNO>
                        <SUBJECT>Catch sharing plan and domestic management measures in area 2A.</SUBJECT>
                        <STARS/>
                        <P>
                            (d) 
                            <E T="03">Fishery Election in Area 2A.</E>
                             (1) A vessel that fishes in Area 2A may participate in only one of the following three fisheries in Area 2A:
                        </P>
                        <P>(i) The sport fishery established in the annual domestic management measures and International Pacific Halibut Commission (IPHC) regulations and defined at § 300.61;</P>
                        <P>(ii) The commercial directed fishery for halibut during the fishing period(s) established in the annual domestic management measures and IPHC regulations and/or the incidental retention of halibut during the sablefish primary fishery described at 50 CFR 660.231; or</P>
                        <P>(iii) The incidental catch fishery during the salmon troll fishery as authorized in the annual domestic management measures and IPHC regulations.</P>
                        <P>
                            (2) No person shall fish for halibut in the sport fishery in Area 2A under the annual domestic management measures and IPHC regulations, from a vessel that has been used during the same calendar year for commercial halibut fishing in Area 2A, or that has been issued a permit for the same calendar year for the commercial halibut fishery in Area 2A.
                            <PRTPAGE P="25324"/>
                        </P>
                        <P>(3) No person shall fish for halibut in the directed commercial halibut fishery during the fishing periods established in the annual domestic management measures and IPHC regulations, and/or retain halibut incidentally taken in the sablefish primary fishery in Area 2A from a vessel that has been used during the same calendar year for the incidental catch fishery during the salmon troll fishery, as authorized in the annual domestic management measures and IPHC regulations.</P>
                        <P>(4) No person shall fish for halibut in the directed commercial halibut fishery and/or retain halibut incidentally taken in the sablefish primary fishery in Area 2A from a vessel that, during the same calendar year, has been used in the sport halibut fishery in Area 2A or that is licensed for the sport charter halibut fishery in Area 2A.</P>
                        <P>(5) No person shall retain halibut in the salmon troll fishery in Area 2A as authorized under the annual domestic management measures and IPHC regulations, taken on a vessel that, during the same calendar year, has been used in the sport halibut fishery in Area 2A, or that is licensed for the sport charter halibut fishery in Area 2A.</P>
                        <P>(6) No person shall retain halibut in the salmon troll fishery in Area 2A as authorized under the annual domestic management measures and IPHC regulations, taken on a vessel that, during the same calendar year, has been used in the directed commercial halibut fishery during the fishing periods established in the annual domestic management measures and IPHC regulations, and/or retained halibut incidentally taken in the sablefish primary fishery for Area 2A or that is licensed to participate in these commercial fisheries during the fishing periods established in the annual domestic management measures and IPHC regulations in Area 2A.</P>
                        <STARS/>
                    </SECTION>
                </REGTEXT>
                <REGTEXT TITLE="50" PART="300">
                    <AMDPAR>4. In § 300.64, revise paragraph (i) to read as follows:</AMDPAR>
                    <SECTION>
                        <SECTNO>§ 300.64 </SECTNO>
                        <SUBJECT> Fishing by U.S. treaty Indian tribes.</SUBJECT>
                        <STARS/>
                        <P>(i) Table 1 to this paragraph (i) sets forth the fishing areas of each of the 13 treaty Indian tribes fishing pursuant to this section. Within subarea 2A-1, boundaries of a tribe's fishing area may be revised as ordered by a Federal court.</P>
                        <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="xs125,r200">
                            <TTITLE>
                                Table 1 to Paragraph (
                                <E T="01">i</E>
                                )
                            </TTITLE>
                            <BOXHD>
                                <CHED H="1">Tribe</CHED>
                                <CHED H="1">Boundaries</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="01">HOH</ENT>
                                <ENT>The area between 47°54.30′ N lat. (Quillayute River) and 47°21.00′ N lat. (Quinault River) and east of 125°44.00′ W long.</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">JAMESTOWN S'KLALLAM</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 626 F. Supp. 1486, to be places at which the Jamestown S'Klallam Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">LOWER ELWHA S'KLALLAM</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 459 F. Supp. 1049 and 1066 and 626 F. Supp. 1443, to be places at which the Lower Elwha S'Klallam Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">LUMMI</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 384 F. Supp. 360, as modified in Subproceeding No. 89-08 (W.D. Wash., February 13, 1990) (decision and order re: cross-motions for summary judgement), to be places at which the Lummi Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">MAKAH</ENT>
                                <ENT>The area north of 48°02.25′ N lat. (Norwegian Memorial) and east of 125°44.00′ W long.</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">NOOKSACK</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash. 1974), and particularly at 459 F. Supp. 1049, to be places at which the Nooksack Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">PORT GAMBLE S'KLALLAM</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 626 F. Supp. 1442, to be places at which the Port Gamble S'Klallam Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">QUILEUTE</ENT>
                                <ENT>The area commencing at Cape Alava, located at 48°10′00″ N lat, 124°43′56.9″ W long.; then proceeding west approximately 40 nautical miles at that latitude to a northwestern point located at 48°10′00″ N lat, 125°44′00″ W long.; then proceeding in a southeasterly direction mirroring the coastline at a distance no farther than 40 nautical miles from the mainland Pacific coast shoreline at any line of latitude, to a southwestern point at 47°31′42″ N lat., 125°20′26″ W long.; then proceeding east along that line of latitude to the Pacific coast shoreline at 47°31′42″ N lat., 124°21′9.0″ W long.</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">QUINAULT</ENT>
                                <ENT>The area commencing at the Pacific coast shoreline near Destruction Island, located at 47°40′06″ N lat., 124°23′51.362″ W long.; then proceeding west approximately 30 nautical miles at that latitude to a northwestern point located at 47°40′06″ N lat., 125°08′30″ W long.; then proceeding in a southeasterly direction mirroring the coastline no farther than 30 nautical miles from the mainland Pacific coast shoreline at any line of latitude, to a southwestern point at 46°53′18″ N lat., 124°53′53″ W long.; then proceeding east along that line of latitude to the Pacific coast shoreline at 46°53′18″ N lat., 124°7′36.6″ W long.</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">SKOKOMISH</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 384 F. Supp. 377, to be places at which the Skokomish Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">SUQUAMISH</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 459 F. Supp. 1049, to be places at which the Suquamish Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <PRTPAGE P="25325"/>
                                <ENT I="01">SWINOMISH</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 459 F. Supp. 1049, to be places at which the Swinomish Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">TULALIP</ENT>
                                <ENT>
                                    Those locations in the Strait of Juan de Fuca and Puget Sound as determined in or in accordance with Final Decision No. 1 and subsequent orders in 
                                    <E T="03">United States</E>
                                     v. 
                                    <E T="03">Washington</E>
                                    , 384 F. Supp. 312 (W.D. Wash., 1974), and particularly at 626 F. Supp. 1531-1532, to be places at which the Tulalip Tribe may fish under rights secured by treaties with the United States.
                                </ENT>
                            </ROW>
                        </GPOTABLE>
                    </SECTION>
                </REGTEXT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09231 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 3510-22-P</BILCOD>
        </RULE>
    </RULES>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Proposed Rules</UNITNAME>
    <PRORULES>
        <PRORULE>
            <PREAMB>
                <PRTPAGE P="25326"/>
                <AGENCY TYPE="F">DEPARTMENT OF ENERGY</AGENCY>
                <CFR>10 CFR Part 430</CFR>
                <DEPDOC>[EERE-2019-BT-STD-0030]</DEPDOC>
                <SUBJECT>Energy Conservation Program: Energy Conservation Standards for General Service Fluorescent Lamps and Incandescent Reflector Lamps</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Energy Efficiency and Renewable Energy, Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Request for information.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Energy (“DOE”) is initiating an effort to determine whether to amend the current energy conservation standards for general service fluorescent lamps (“GSFLs”) and incandescent reflector lamps (“IRLs”). Under the Energy Policy and Conservation Act, as amended, DOE must review these standards at least once every six years and publish either a notice of proposed rulemaking (“NOPR”) to propose new standards for GSFLs and/or IRLs or a notice of determination that the existing standards do not need to be amended. This request for information (“RFI”) solicits information from the public to help DOE determine whether amended standards for GSFLs and IRLs would result in significant energy savings and whether such standards would be technologically feasible and economically justified. DOE welcomes written comments from the public on any subject within the scope of this document (including those topics not specifically raised), as well as the submission of data and other relevant information.</P>
                </SUM>
                <EFFDATE>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Written comments and information will be accepted on or before June 1, 2020.</P>
                </EFFDATE>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are encouraged to submit comments using the Federal eRulemaking Portal at 
                        <E T="03">http://www.regulations.gov.</E>
                         Follow the instructions for submitting comments. Alternatively, interested persons may submit comments, identified by docket number EERE-2019-BT-STD-0030, by any of the following methods:
                    </P>
                    <P>
                        1. 
                        <E T="03">Federal eRulemaking Portal: http://www.regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        2. 
                        <E T="03">Email: GSFLIRL2019STD0030@ee.doe.gov.</E>
                         Include the docket number EERE-2019-BT-STD-0030 in the subject line of the message.
                    </P>
                    <P>
                        3. 
                        <E T="03">Postal Mail:</E>
                         Appliance and Equipment Standards Program, U.S. Department of Energy, Building Technologies Office, Mailstop EE-5B, 1000 Independence Avenue SW, Washington, DC 20585-0121. Telephone: (202) 287-1445. If possible, please submit all items on a compact disc (“CD”), in which case it is not necessary to include printed copies.
                    </P>
                    <P>
                        4. 
                        <E T="03">Hand Delivery/Courier:</E>
                         Appliance and Equipment Standards Program, U.S. Department of Energy, Building Technologies Office, 950 L'Enfant Plaza SW, 6th Floor, Washington, DC 20024. Telephone: (202) 287-1445. If possible, please submit all items on a CD, in which case it is not necessary to include printed copies.
                    </P>
                    <P>No telefacsimilies (faxes) will be accepted. For detailed instructions on submitting comments and additional information on this process, see section IV of this document.</P>
                    <P>
                        <E T="03">Docket:</E>
                         The docket for this activity, which includes 
                        <E T="04">Federal Register</E>
                         notices, comments, and other supporting documents/materials, is available for review at 
                        <E T="03">http://www.regulations.gov.</E>
                         All documents in the docket are listed in the 
                        <E T="03">http://www.regulations.gov</E>
                         index. However, some documents listed in the index, such as those containing information that is exempt from public disclosure, may not be publicly available.
                    </P>
                    <P>
                        The docket web page can be found at 
                        <E T="03">http://www.regulations.gov/#!docketDetail;D=EERE-2019-BT-STD-0030.</E>
                         The docket web page contains instructions on how to access all documents, including public comments, in the docket. See section IV for information on how to submit comments through 
                        <E T="03">http://www.regulations.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Ms. Lucy deButts, U.S. Department of Energy, Office of Energy Efficiency and Renewable Energy, Building Technologies Office, EE-5B, 1000 Independence Avenue SW, Washington, DC 20585-0121. Telephone: (202) 287-1604. Email: 
                        <E T="03">ApplianceStandardsQuestions@ee.doe.gov.</E>
                    </P>
                    <P>
                        Ms. Kathryn McIntosh, U.S. Department of Energy, Office of the General Counsel, GC-33, 1000 Independence Avenue SW, Washington, DC 20585-0121. Telephone: (202) 586-2002. Email: 
                        <E T="03">Kathryn.McIntosh@hq.doe.gov.</E>
                    </P>
                    <P>
                        For further information on how to submit a comment, or review other public comments and the docket contact the Appliance and Equipment Standards Program staff at (202) 287-1445 or by email: 
                        <E T="03">ApplianceStandardsQuestions@ee.doe.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Introduction</FP>
                    <FP SOURCE="FP1-2">A. Authority and Background</FP>
                    <FP SOURCE="FP1-2">B. Rulemaking Process</FP>
                    <FP SOURCE="FP-2">II. Request for Information and Comments</FP>
                    <FP SOURCE="FP1-2">A. Products Covered by This Process</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">1. Definitions</E>
                    </FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">2. Certain ER, BR, and R IRLs</E>
                    </FP>
                    <FP SOURCE="FP1-2">B. Market and Technology Assessment</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">1. Product Classes</E>
                    </FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">2. Technology Assessment</E>
                    </FP>
                    <FP SOURCE="FP1-2">C. Screening Analysis</FP>
                    <FP SOURCE="FP1-2">D. Engineering Analysis</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">1. Representative Product Classes</E>
                    </FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">2. Baseline lamps</E>
                    </FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">3. Efficacy Levels and Maximum Technologically Feasible Levels</E>
                    </FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">4. Scaling to Other Product Classes</E>
                    </FP>
                    <FP SOURCE="FP1-2">E. Product Price Determination</FP>
                    <FP SOURCE="FP1-2">F. Energy Use Analysis</FP>
                    <FP SOURCE="FP1-2">G. Life-Cycle Cost and Payback Analysis</FP>
                    <FP SOURCE="FP1-2">H. Shipments</FP>
                    <FP SOURCE="FP1-2">I. National Impact Analysis</FP>
                    <FP SOURCE="FP1-2">J. Manufacturer Impact Analysis</FP>
                    <FP SOURCE="FP-2">III. Other Energy Conservation Standards Topics</FP>
                    <FP SOURCE="FP1-2">A. Market Failures</FP>
                    <FP SOURCE="FP1-2">B. Network Mode/“Smart” Technology</FP>
                    <FP SOURCE="FP1-2">C. Other Issues</FP>
                    <FP SOURCE="FP-2">IV. Submission of Comments</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Introduction</HD>
                <HD SOURCE="HD2">A. Authority and Background</HD>
                <P>
                    The Energy Policy and Conservation Act, as amended (“EPCA”),
                    <SU>1</SU>
                    <FTREF/>
                     authorizes DOE to regulate the energy efficiency of a number of consumer products and certain industrial equipment. (42 U.S.C. 6291-6317) Title III, Part B 
                    <SU>2</SU>
                    <FTREF/>
                     of EPCA 
                    <PRTPAGE P="25327"/>
                    established the Energy Conservation Program for Consumer Products Other Than Automobiles. These products include GSFLs and IRLs, the subject of this document. (42 U.S.C. 6292(a)(14))
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         All references to EPCA in this document refer to the statute as amended through America's Water Infrastructure Act of 2018, Public Law 115-270 (October 23, 2018).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         For editorial reasons, upon codification in the U.S. Code, Part B was redesignated Part A.
                    </P>
                </FTNT>
                <P>The energy conservation program under EPCA consists essentially of four parts: (1) Testing, (2) labeling, (3) Federal energy conservation standards, and (4) certification and enforcement procedures. Relevant provisions of EPCA specifically include definitions (42 U.S.C. 6291), test procedures (42 U.S.C. 6293), labeling provisions (42 U.S.C. 6294), energy conservation standards (42 U.S.C. 6295), and the authority to require information and reports from manufacturers (42 U.S.C. 6296).</P>
                <P>Federal energy efficiency requirements for covered products established under EPCA generally supersede State laws and regulations concerning energy conservation testing, labeling, and standards. (42 U.S.C. 6297(a)-(c)). DOE may, however, grant waivers of Federal preemption for particular State laws or regulations, in accordance with the procedures and other provisions set forth under EPCA. See 42 U.S.C. 6297(d).</P>
                <P>
                    Amendments to EPCA in the Energy Policy Act of 1992 (“EPAct 1992”; Pub. L. 102-486), established energy conservation standards for certain classes of GSFLs and IRLs, and authorized DOE to conduct two rulemaking cycles to determine whether these standards should be amended. (42 U.S.C. 6295(i)(1) and (3)-(4)) EPCA also authorized DOE to adopt standards for additional GSFLs, if such standards were warranted. (42 U.S.C. 6295(i)(5)). DOE completed the first of these rulemaking cycles in a final rule published on July 14, 2009, that adopted amended performance standards for GSFLs and IRLs manufactured on or after July 14, 2012. 74 FR 34080 (“2009 GSFL-IRL ECS final rule”). That rule adopted standards for additional GSFLs, amended the definition of “colored fluorescent lamp” and “rated wattage,” and also adopted test procedures applicable to the newly covered GSFLs. 
                    <E T="03">Id.</E>
                     DOE completed a second rulemaking cycle to amend the standards for GSFLs and IRLs by publishing a final rule on January 26, 2015. 80 FR 4042 (“2015 GSFL-IRL ECS final rule”). In this rule DOE amended standards for GSFLs; and concluded that amending standards for IRLs would not be economically justified. 
                    <E T="03">Id.</E>
                     The current energy conservation standards for GSFLs and IRLs are located in Title 10 of the Code of Federal Regulations (“CFR”) section 430.32. The currently applicable DOE test procedures appear at 10 CFR part 430, subpart B, appendix R.
                </P>
                <P>EPCA also requires that, not later than 6 years after the issuance of any final rule establishing or amending a standard, DOE evaluate the energy conservation standards for each type of covered product, including those at issue here, and publish either a notice of determination that the standards do not need to be amended, or a NOPR that includes new proposed energy conservation standards (proceeding to a final rule, as appropriate). (42 U.S.C. 6295(m)(1)) DOE must make the analysis on which the determination is based publicly available and provide an opportunity for written comment. (42 U.S.C. 6295(m)(2)) In making a determination that the standards do not need to be amended, DOE must evaluate whether amended standards (1) will result in significant conservation of energy, (2) are technologically feasible, and (3) are cost effective as described under 42 U.S.C. 6295(o)(2)(B)(i)(II). (42 U.S.C. 6295(m)(1)(A); 42 U.S.C. 6295(n)(2)) Under 42 U.S.C. 6295(o)(2)(B)(i)(II), DOE must determine whether the benefits of a standard exceed its burdens by, to the greatest extent practicable, considering the savings in operating costs throughout the estimated average life of the covered product in the type (or class) compared to any increase in the price of, or in the initial charges for, or maintenance expenses of, the covered products which are likely to result from the imposition of the standard. If DOE determines not to amend a standard based on the statutory criteria, not later than 3 years after the issuance of a final determination not to amend standards, DOE must publish either a notice of determination that standards for the product do not need to be amended, or a NOPR including new proposed energy conservation standards (proceeding to a final rule, as appropriate). (42 U.S.C. 6295(m)(3)(B))</P>
                <P>In determining whether to propose new standards, DOE must evaluate that proposal against the criteria of 42 U.S.C. 6295(o), as described in the following section, and follow the rulemaking procedures set out in 42 U.S.C. 6295(p). (42 U.S.C. 6295(m)(1)(B) If DOE decides to amend the standard based on the statutory criteria, DOE must publish a final rule not later than two years after energy conservation standards are proposed. (42 U.S.C. 6295(m)(3)(A))</P>
                <P>DOE is publishing this RFI to collect data and information to inform its decision consistent with its obligations under EPCA.</P>
                <HD SOURCE="HD2">B. Rulemaking Process</HD>
                <P>DOE must follow specific statutory criteria for prescribing new or amended standards for covered products. EPCA requires that any new or amended energy conservation standard prescribed by the Secretary be designed to achieve the maximum improvement in energy or water efficiency that is technologically feasible and economically justified. (42 U.S.C. 6295(o)(2)(A)) EPCA also precludes DOE from adopting any standard that would not result in the significant conservation of energy. (42 U.S.C. 6295(o)(3)(B)) To determine whether a standard is economically justified, EPCA requires that DOE determine whether the benefits of the standard exceed its burdens by considering, to the greatest extent practicable, the following seven factors:</P>
                <P>(1) The economic impact of the standard on the manufacturers and consumers of the affected products;</P>
                <P>(2) The savings in operating costs throughout the estimated average life of the product compared to any increases in the initial cost, or maintenance expenses;</P>
                <P>(3) The total projected amount of energy and water (if applicable) savings likely to result directly from the standard;</P>
                <P>(4) Any lessening of the utility or the performance of the products likely to result from the standard;</P>
                <P>(5) The impact of any lessening of competition, as determined in writing by the Attorney General, that is likely to result from the standard;</P>
                <P>(6) The need for national energy and water conservation; and</P>
                <P>(7) Other factors the Secretary of Energy (Secretary) considers relevant.</P>
                <P>(42 U.S.C. 6295(o)(2)(B)(i)(I)-(VII))</P>
                <P>
                    DOE fulfills these and other applicable requirements by conducting a series of analyses throughout the rulemaking process. Table I.1 shows the individual analyses that are performed to satisfy each of the requirements within EPCA.
                    <PRTPAGE P="25328"/>
                </P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s75,r150">
                    <TTITLE>Table I.1—EPCA Requirements and Corresponding DOE Analysis</TTITLE>
                    <BOXHD>
                        <CHED H="1">EPCA requirement</CHED>
                        <CHED H="1">Corresponding DOE analysis</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Significant Energy Savings</ENT>
                        <ENT>
                            • Shipments Analysis
                            <LI>• National Impact Analysis</LI>
                            <LI>• Energy and Water Use Determination</LI>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Technological Feasibility</ENT>
                        <ENT>
                            • Market and Technology Assessment
                            <LI>• Screening Analysis</LI>
                            <LI>• Engineering Analysis</LI>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Economic Justification</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">1. Economic impact on manufacturers and consumers</ENT>
                        <ENT>
                            • Manufacturer Impact Analysis
                            <LI>• Life-Cycle Cost and Payback Period Analysis</LI>
                            <LI>• Life-Cycle Cost Subgroup Analysis</LI>
                            <LI>• Shipments Analysis</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2. Lifetime operating cost savings compared to increased cost for the product</ENT>
                        <ENT>
                            • Markups for Product Price Determination
                            <LI>• Energy and Water Use Determination</LI>
                            <LI>• Life-Cycle Cost and Payback Period Analysis</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3. Total projected energy savings</ENT>
                        <ENT>
                            • Shipments Analysis
                            <LI>• National Impact Analysis</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4. Impact on utility or performance</ENT>
                        <ENT>
                            • Screening Analysis
                            <LI>• Engineering Analysis</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5. Impact of any lessening of competition</ENT>
                        <ENT>• Manufacturer Impact Analysis</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6. Need for national energy and water conservation</ENT>
                        <ENT>
                            • Shipments Analysis
                            <LI>• National Impact Analysis</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7. Other factors the Secretary considers relevant</ENT>
                        <ENT>
                            • Employment Impact Analysis
                            <LI>• Utility Impact Analysis</LI>
                            <LI>• Emissions Analysis</LI>
                            <LI>• Monetization of Emission Reductions Benefits</LI>
                            <LI>• Regulatory Impact Analysis</LI>
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <P>As detailed throughout this RFI, DOE is publishing this document seeking input and data from interested parties to aid in the development of the technical analyses on which DOE will ultimately rely to determine whether (and if so, how) to amend the standards for GSFLs and IRLs.</P>
                <HD SOURCE="HD1">II. Request for Information and Comments</HD>
                <P>In the following sections, DOE has identified a variety of issues on which it seeks input to aid in the development of the technical and economic analyses regarding whether amended standards for GSFLs and IRLs may be warranted. DOE also welcomes comments on other issues relevant to this data-gathering process that may not specifically be identified in this document.</P>
                <P>As an initial matter, DOE seeks comment on whether there have been sufficient technological or market changes since the most recent standards update that may justify a new rulemaking to consider more stringent standards. Specifically, DOE seeks data and information that could enable the agency to determine whether DOE should propose a “no new standard” determination because a more stringent standard: (1) Would not result in a significant savings of energy; (2) is not technologically feasible; (3) is not economically justified; or (4) any combination of foregoing.</P>
                <HD SOURCE="HD2">A. Products Covered by This Process</HD>
                <P>This RFI covers those products that meet the definitions of GSFL and IRL, as codified at 10 CFR 430.2. DOE conducts separate analyses of GSFLs and IRLs.</P>
                <HD SOURCE="HD3">1. Definitions</HD>
                <P>The definition of “general service fluorescent lamp” is based on the definition of “fluorescent lamp,” both of which are specified below.</P>
                <P>
                    <E T="03">Fluorescent lamp</E>
                     means a low pressure mercury electric-discharge source in which a fluorescing coating transforms some of the ultraviolet energy generated by the mercury discharge into light, including only the following:
                </P>
                <P>(1) Any straight-shaped lamp (commonly referred to as 4-foot medium bipin lamps) with medium bipin bases of nominal overall length of 48 inches and rated wattage of 25 or more;</P>
                <P>(2) Any U-shaped lamp (commonly referred to as 2-foot U-shaped lamps) with medium bipin bases of nominal overall length between 22 and 25 inches and rated wattage of 25 or more;</P>
                <P>(3) Any rapid start lamp (commonly referred to as 8-foot high output lamps) with recessed double contact bases of nominal overall length of 96 inches;</P>
                <P>(4) Any instant start lamp (commonly referred to as 8-foot slimline lamps) with single pin bases of nominal overall length of 96 inches and rated wattage of 49 or more;</P>
                <P>(5) Any straight-shaped lamp (commonly referred to as 4-foot miniature bipin standard output lamps) with miniature bipin bases of nominal overall length between 45 and 48 inches and rated wattage of 25 or more; and</P>
                <P>(6) Any straight-shaped lamp (commonly referred to 4-foot miniature bipin high output lamps) with miniature bipin bases of nominal overall length between 45 and 48 inches and rated wattage of 44 or more.</P>
                <P>
                    <E T="03">General service fluorescent lamp</E>
                     means any fluorescent lamp which can be used to satisfy the majority of fluorescent lighting applications, but does not include any lamp designed and marketed for the following nongeneral application:
                </P>
                <P>(1) Fluorescent lamps designed to promote plant growth;</P>
                <P>(2) Fluorescent lamps specifically designed for cold temperature applications;</P>
                <P>(3) Colored fluorescent lamps;</P>
                <P>(4) Impact-resistant fluorescent lamps;</P>
                <P>(5) Reflectorized or aperture lamps;</P>
                <P>(6) Fluorescent lamps designed for use in reprographic equipment;</P>
                <P>(7) Lamps primarily designed to produce radiation in the ultra-violet region of the spectrum; and</P>
                <P>
                    (8) Lamps with a Color Rendering Index of 87 or greater. 
                    <PRTPAGE P="25329"/>
                </P>
                <HD SOURCE="HD3">10 CFR 430.2</HD>
                <P>
                    DOE also defines the following lamp types not included in the GSFL definition: “cold temperature fluorescent lamp,” “colored fluorescent lamp,” “impact-resistant fluorescent lamp,” “reflectorized or aperture lamp,” “fluorescent lamp designed for use in reprographic equipment.” (
                    <E T="03">See</E>
                     10 CFR 430.2 for complete definitions.)
                </P>
                <P>DOE defines “incandescent reflector lamp” as follows: </P>
                <EXTRACT>
                    <P>
                        <E T="03">Incandescent reflector lamp</E>
                         (commonly referred to as a reflector lamp) means any lamp in which light is produced by a filament heated to incandescence by an electric current, which: Contains an inner reflective coating on the outer bulb to direct the light; is not colored; is not designed for rough or vibration service applications; is not an R20 short lamp; has an R, PAR, ER, BR, BPAR, or similar bulb shapes with an E26 medium screw base; has a rated voltage or voltage range that lies at least partially in the range of 115 and 130 volts; has a diameter that exceeds 2.25 inches; and has a rated wattage that is 40 watts or higher.
                    </P>
                </EXTRACT>
                <HD SOURCE="HD3">10 CFR 430.2</HD>
                <P>
                    DOE has separate definitions for “rough or vibration service incandescent reflector lamp” and “R20 short lamp.” Additionally, DOE uses industry standards to define the size and shape of certain reflector lamp shapes: The bulged parabolic reflector (“BPAR”) incandescent reflector lamp definition references ANSI C78.21-2003 
                    <SU>3</SU>
                    <FTREF/>
                    ; the R20 and bulged reflector (“BR”) incandescent reflector lamp definitions reference ANSI C79.1-1994; 
                    <SU>4</SU>
                    <FTREF/>
                     and the elliptical reflector (“ER”) incandescent reflector lamp definition references both ANSI C79.1-1994 and ANSI C78.21-1989. (See 10 CFR 430.2 for complete definitions.) There is a 2002 version available for ANSI C79.1 
                    <SU>5</SU>
                    <FTREF/>
                     and 2011 version of ANSI C78.21 
                    <SU>6</SU>
                    <FTREF/>
                     available. DOE is considering updating the definitions with the latest versions of the currently referenced industry standards. Additionally, DOE is considering providing definitions for reflector (“R”) and parabolic aluminized reflector (“PAR”) incandescent reflector lamps that reference the 2011 version of ANSI C78.21.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         American National Standards Institute, 
                        <E T="03">American National Standards For Electric Lamps—PAR and R Shapes.</E>
                         Approved October 30, 2003.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         American National Standards Institute, 
                        <E T="03">American National Standard for Nomenclature for Glass Bulbs-Intended for Use with Electric Lamps,</E>
                         Approved March 24, 1994.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         American National Standards Institute, 
                        <E T="03">American National Standard For Electric Lamps—Nomenclature for Glass Bulbs Intended for Use with Electric Lamps.</E>
                         Approved September 16, 2002.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         American National Standards Institute, 
                        <E T="03">American National Standard for Electric Lamps—PAR and R Shapes. Approved January 17, 2017.</E>
                    </P>
                </FTNT>
                <P>
                    <E T="03">Issue 1:</E>
                     DOE seeks comment on updating the industry references for the definitions of BPAR, R20, ER, and BR incandescent reflector lamps. DOE also seeks comments on providing a definition for R and PAR incandescent reflector shapes.
                </P>
                <P>
                    <E T="03">Issue 2:</E>
                     DOE seeks feedback on whether the definitions for GSFLs and IRLs require any revisions—and if so, how those definitions should be revised. DOE also requests feedback on whether definitions related to GSFLs and IRLs require any revisions, and if so, how these should be revised.
                </P>
                <P>
                    <E T="03">Issue 3:</E>
                     DOE seeks comment on whether additional product definitions are necessary to close any potential gaps in coverage between product types. DOE also seeks input on whether such products currently exist in the market or whether they are being planned for introduction.
                </P>
                <P>EPCA defines an incandescent reflector lamp as a lamp that “has a rated wattage that is 40 watts or higher” but does not provide an upper wattage limit. (42 U.S.C. 6291(30)(C)(ii) and (F)) Current DOE energy conservation standards cover IRLs with rated wattages greater than or equal to 40 watts (“W”) and less than or equal to 205 W. 10 CFR 430.32(n)(6) Based on an initial assessment of the market, IRLs higher than 205 W comprise a small portion of product offerings.</P>
                <P>
                    <E T="03">Issue 4:</E>
                     DOE seeks feedback on the shipment volume of IRLs with wattages higher than 205 W and the performance characteristics (including wattage, lumen output, and lifetime), shape, and diameter of IRLs in this wattage range.
                </P>
                <HD SOURCE="HD3">2. Certain ER, BR, and R IRLs</HD>
                <P>As amended by section 322(b) of the Energy Independence and Security Act of 2007 (“EISA 2007”; Pub. L. 110-140), EPCA exempted certain IRLs from the statutorily prescribed standards: (1) Lamps rated 50 watts or less that are ER30, BR30, BR40, or ER40; (2) lamps rated 65 watts that are BR30, BR40, or ER40 lamps; and (3) R20 incandescent reflector lamps rated 45 watts or less (referred to as “certain ER, BR, and R lamps”). (42 U.S.C. 6295(i)(1)(C))</P>
                <P>
                    In the 2009 GSFL-IRL ECS rulemaking, DOE initially concluded that it was precluded from adopting energy conservation standards for the certain ER, BR, and R lamps. 73 FR 13620, 13626 (March 13, 2008). Based on comments received in response to the advanced notice of proposed rulemaking (“ANOPR”), DOE re-evaluated its initial interpretation of the statutory exemption of the certain ER, BR, and R lamps and whether the required rulemaking cycles authorized DOE to reconsider the exemptions. 74 FR 16920, 16930-16931 (Apr. 13, 2009). As a practical matter, because DOE did not wish to delay the rulemaking and resulting potential energy savings for the sole reason of considering these certain R, ER, BR lamps, it did not include these lamps in the analysis. 
                    <E T="03">Id.</E>
                     and 74 FR 34080, 34092.
                </P>
                <P>On May 3, 2010, DOE initiated a separate rulemaking to consider standards for these certain ER, BR, and R IRLs by issuing a notice of public meeting and availability of a framework document. 75 FR 23191 (May 3, 2010); see also 80 FR 4042, 4050. DOE held a public meeting on May 26, 2010, but did not publish any further documents in this docket.</P>
                <P>In the 2015 GSFL-IRL ECS rulemaking DOE did not consider standards for certain ER, BR, and R lamps when evaluating standards for IRLs because they were the subject of the separate rulemaking when the 2015 GSFL-IRL ECS rulemaking was initiated in September 2011. 76 FR 56678, 56679. Subsequently, DOE suspended activity on the separate rulemaking on the certain ER, BR, and R lamps as a result of a then applicable Appropriations Rider (section 315 of Pub. L. 112-74 (Dec. 23, 2011)), which prohibited DOE from using appropriated funds to implement or enforce standards for ER, BR, and BPAR IRLs. See, 79 FR 24068, 24078 and 80 FR 4042, 4056. Also, because of the Appropriations Rider (section 322 of Pub. L. 113-76 (January 17, 2014)), DOE did not consider ER, BR, or BPAR IRLs (that do not fall in the certain ER, BR and R lamp category) in the 2015 GSFL-IRL ECS rulemaking. 80 FR 4042, 4057.</P>
                <P>
                    The Appropriations Rider is no longer in effect.
                    <SU>7</SU>
                    <FTREF/>
                     Therefore, in this analysis DOE is considering analyzing certain ER, BR, and R IRLs.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         The Appropriations Rider expired on May 5, 2017, when the Consolidated Appropriations Act of 2017 was enacted. See, the Consolidated Appropriations Act of 2017 (Pub. L. 115-31, div. D, tit. III); see also, Consolidated Appropriations Act, 2018 (Pub. L. 115-141).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. Market and Technology Assessment</HD>
                <P>
                    The market and technology assessment that DOE routinely conducts when analyzing the impacts of a potential new or amended energy conservation standard provides information about the GSFL and IRL industry that will be used in DOE's analysis throughout the rulemaking process. DOE uses qualitative and quantitative information to characterize the structure of the industry and market. 
                    <PRTPAGE P="25330"/>
                    DOE identifies manufacturers, estimates market shares and trends, addresses regulatory and non-regulatory initiatives intended to improve energy efficiency or reduce energy consumption, and explores the potential for efficiency improvements in the design and manufacturing of GSFLs and IRLs. Additionally, DOE considers conducting interviews with manufacturers to improve its assessment of the market and available technologies for GSFLs and IRLs.
                </P>
                <HD SOURCE="HD3">1. Product Classes</HD>
                <P>
                    When evaluating and establishing energy conservation standards, DOE may divide covered products into product classes by the type of energy used, or by capacity or other performance-related features that justify a standard higher or lower than that which applies (or would apply) for such type (or class) for any group of covered products which have the same function or intended use. (42 U.S.C. 6295(q)) In making a determination whether capacity or another performance-related feature justifies a separate product class, DOE must consider such factors as the utility of the feature to the consumer and other factors DOE deems appropriate. (
                    <E T="03">Id.</E>
                    ) Current standards for IRLs and GSFLs require products to meet a minimum lamp efficacy (lumens divided by wattage [“lm/W”]). To identify product-class setting factors, DOE examined performance features that offer a unique utility and would impact lamp efficacy, and thereby energy consumption.
                </P>
                <P>
                    For GSFLs, the current energy conservation standards specified in 10 CFR 430.32(n)(4) are based on 12 product classes as analyzed in the 2015 GSFL-IRL ECS final rule, separated according to the following three factors: (1) Correlated color temperature (“CCT”); (2) physical constraints of lamps (
                    <E T="03">i.e.,</E>
                     lamp shape and length); and (3) lumen package (
                    <E T="03">i.e.,</E>
                     standard output (“SO”) versus high output (“HO”)). 80 FR 4042, 4063. Table II.1 lists the current 12 product classes for GSFLs.
                </P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s100,xs96">
                    <TTITLE>Table II.1—Current GSFL Product Classes</TTITLE>
                    <BOXHD>
                        <CHED H="1">Lamp type</CHED>
                        <CHED H="1">CCT</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">4-foot medium bipin</ENT>
                        <ENT>
                            ≤4,500 K
                            <LI>&gt;4,500 K and ≤7,000 K</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2-foot U-shaped</ENT>
                        <ENT>
                            ≤4,500 K
                            <LI>&gt;4,500 K and ≤7,000 K</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8-foot single pin slimline</ENT>
                        <ENT>
                            ≤4,500 K
                            <LI>&gt;4,500 K and ≤7,000 K</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8-foot recessed double contact high output</ENT>
                        <ENT>
                            ≤4,500 K
                            <LI>&gt;4,500 K and ≤7,000 K</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4-foot T5, miniature bipin standard output</ENT>
                        <ENT>
                            ≤4,500 K
                            <LI>&gt;4,500 K and ≤7,000 K</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4-foot T5, miniature bipin high output</ENT>
                        <ENT>
                            ≤4,500 K
                            <LI>&gt;4,500 K and ≤7,000 K</LI>
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">Issue 5:</E>
                     DOE requests feedback on the current GSFL product classes and whether changes to these individual product classes and their descriptions should be made or whether certain classes should be merged or separated. DOE further requests feedback on whether combining or separating certain classes could impact product utility by eliminating any performance-related features or impact the stringency of the current energy conservation standard for these products.
                </P>
                <P>
                    <E T="03">Issue 6:</E>
                     DOE seeks information regarding any other new product classes it should consider for inclusion in its analysis of GSFLs. Specifically, DOE requests information on the performance-related features (
                    <E T="03">e.g.,</E>
                     dimmability, lifetime, 
                    <E T="03">etc.</E>
                    ) that provide unique consumer utility and data detailing the corresponding impacts on energy use that would justify separate product classes (
                    <E T="03">i.e.,</E>
                     explanation for why the presence of these performance-related features would increase energy consumption).
                </P>
                <P>
                    <E T="03">Issue 7:</E>
                     DOE seeks information on whether there are issues with dimming reduced wattage GSFLs, and if so, what are the specific issues and for what types of GSFLs do they occur.
                </P>
                <P>
                    <E T="03">Issue 8:</E>
                     DOE requests information regarding the maximum efficacy achievable by 2-foot U-shaped lamps with 1 
                    <FR>5/8</FR>
                     inch spacing versus those with 6 inch spacing and the utility that each offer consumers. DOE seeks information on the shipment volume of 2-foot U-shaped lamps with 1 
                    <FR>5/8</FR>
                     inch spacing 
                    <SU>8</SU>
                    <FTREF/>
                     versus those with 6 inch spacing.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         Spacing refers to the length between the legs of a U-shaped fluorescent lamp.
                    </P>
                </FTNT>
                <P>For IRLs, the current energy conservation standards specified in 10 CFR 430.2(n) are based on 8 product classes as analyzed in the 2015 GSFL-IRL ECS final rule, separated according to the following three factors: (1) Rated voltage; (2) lamp spectrum; and (3) lamp diameter. 80 FR 4042, 4063-4064. Table II.2 lists the current product classes for IRLs.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,14,xs70">
                    <TTITLE>Table II.2—Current IRL Product Classes</TTITLE>
                    <BOXHD>
                        <CHED H="1">Lamp type</CHED>
                        <CHED H="1">
                            Diameter
                            <LI>(in inches)</LI>
                        </CHED>
                        <CHED H="1">Input voltage</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Standard Spectrum</ENT>
                        <ENT>&gt;2.5</ENT>
                        <ENT>
                            ≥125 Volts (V)
                            <LI>&lt;125 V</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>≤2.5</ENT>
                        <ENT>
                            ≥125 V
                            <LI>&lt;125 V</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Modified Spectrum</ENT>
                        <ENT>&gt;2.5</ENT>
                        <ENT>
                            ≥125 V
                            <LI>&lt;125 V</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25331"/>
                        <ENT I="22"> </ENT>
                        <ENT>≤2.5</ENT>
                        <ENT>
                            ≥125 V
                            <LI>&lt;125 V</LI>
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">Issue 9:</E>
                     DOE requests feedback on the current IRL product classes and whether changes to these individual product classes and their descriptions should be made or whether certain classes should be merged or separated. DOE further requests feedback on whether combining or separating certain classes could impact product utility by eliminating any performance-related features or impact the stringency of the current energy conservation standard for these products.
                </P>
                <P>
                    <E T="03">Issue 10:</E>
                     DOE seeks information regarding any other new product classes it should consider for inclusion in its analysis of IRLs. Specifically, DOE requests information on performance-related features (
                    <E T="03">e.g.,</E>
                     length, beam spread, 
                    <E T="03">etc.</E>
                    ) that provide unique consumer utility and data detailing the corresponding impacts on energy use that would justify separate product classes (
                    <E T="03">i.e.,</E>
                     explanation for why the presence of these performance-related features would increase energy consumption).
                </P>
                <P>
                    <E T="03">Issue 11:</E>
                     DOE requests information regarding the maximum efficacy achievable by the certain ER, BR, and R lamps newly included in this analysis and whether ER, BR, and R lamps offer the consumer unique utility. DOE also requests information regarding the shipments of the certain ER, BR, and R lamps exempt from current standards compared to the shipments of other ER, BR, and R lamps that must comply with current standards.
                </P>
                <HD SOURCE="HD3">2. Technology Assessment</HD>
                <P>In analyzing the feasibility of potential new or amended energy conservation standards, DOE uses information about existing and past technology options and prototype designs to help identify technologies that manufacturers could use to meet and/or exceed a given set of energy conservation standards under consideration. In consultation with interested parties, DOE intends to develop a list of technologies to consider in its analysis. That analysis will likely include a number of the technology options DOE previously considered during its most recent rulemaking for GSFLs and IRLs. A complete list of those prior options appears in Table II.3 for GSFLs and Table II.4 for IRLs of this RFI.</P>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s100,r150">
                    <TTITLE>Table II.3—GSFL Technology Options From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Name of technology option</CHED>
                        <CHED H="1">Description</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Highly Emissive Electrode Coatings</ENT>
                        <ENT>Improved electrode coatings allow electrons to be more easily removed from electrodes, reducing lamp power and increasing overall efficacy.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Efficiency Lamp Fill Gas Composition</ENT>
                        <ENT>Fill gas compositions improve cathode thermionic emission or increase mobility of ions and electrons in the lamp plasma.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Efficiency Phosphors</ENT>
                        <ENT>Phosphors increase the conversion of ultraviolet light into visible light.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Glass Coatings</ENT>
                        <ENT>Coatings on inside of bulb enable the phosphors to absorb more UV energy, so that they emit more visible light.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Efficiency Lamp Diameter</ENT>
                        <ENT>Optimal lamp diameters improve lamp efficacy.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Multi-Photon Phosphors</ENT>
                        <ENT>Phosphors emit more than one visible photon for each incident UV photon.</ENT>
                    </ROW>
                </GPOTABLE>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s100,r150">
                    <TTITLE>Table II.4—IRL Technology Options From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Name of technology option</CHED>
                        <CHED H="1">Description</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Higher Temperature Operation</ENT>
                        <ENT>Operating the filament at higher temperatures, the spectral output shifts to lower wavelengths, increasing its overlap with the eye sensitivity curve.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Microcavity Filaments</ENT>
                        <ENT>Texturing, surface perforations, microcavity holes with material fillings, increasing surface area and thereby light output.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Novel Filament Materials</ENT>
                        <ENT>More efficient filament alloys that have a high melting point, low vapor pressure, high strength, high ductility, or good radiating characteristics.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Thinner Filaments</ENT>
                        <ENT>Thinner filaments to increase operating temperature. This measure may shorten the operating life of the lamp.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Crystallite Filament Coatings</ENT>
                        <ENT>Layers of micron or submicron crystallites deposited on the filament surface that increases emissivity of the filament.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Efficiency Inert Fill Gas</ENT>
                        <ENT>Filling lamps with alternative gases, such as Krypton, to reduce heat conduction.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Pressure Tungsten-Halogen Lamps</ENT>
                        <ENT>Increased halogen bulb burner pressurization, allowing higher temperature operation.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Non-Tungsten-Halogen Regenerative Cycles</ENT>
                        <ENT>Novel filament materials that regenerate.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Infrared Glass Coatings</ENT>
                        <ENT>When used with a halogen burner, this is referred to as an HIR lamp. Infrared coatings on the inside of the bulb to reflect some of the radiant energy back onto the filament.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">IR Phosphor Glass Coatings</ENT>
                        <ENT>Phosphor coatings that can absorb IR radiation and re-emit it at shorter wavelengths (visible region of light), increasing the lumen output.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">UV Phosphor Glass Coatings</ENT>
                        <ENT>Phosphor coatings that convert UV radiation into longer wavelengths (visible region of light), increasing the lumen output.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25332"/>
                        <ENT I="01">Electron Stimulated Luminescence</ENT>
                        <ENT>A low voltage cathodoluminescent phosphor that emits green light (visible region of light) upon impingement by thermally ejected electrons, increasing the lumen output.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Efficiency Reflector Coatings</ENT>
                        <ENT>Alternative reflector coatings such as silver, with higher reflectivity increase the amount of directed light.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Corner Reflectors</ENT>
                        <ENT>Individual corner reflectors in the cover glass that reflect light directly back in the direction from which it came.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">High Reflectance Filament Supports</ENT>
                        <ENT>Filament supports that include a reflective face that reflects light to another filament, the reflective face of another filament support, or radially outward.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Permanent Infrared Reflector Coating Shroud</ENT>
                        <ENT>Permanent shroud with an IR reflector coating and a removable and replaceable lamp can increase efficiency while reducing manufacturing costs by allowing IR reflector coatings to be reused.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Efficiency Burners</ENT>
                        <ENT>A double-ended burner that features a lead wire outside of the burner, where it does not interfere with the reflectance of energy from the burner wall back to the burner filament in HIR lamps.</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">Issue 12:</E>
                     DOE seeks information on the technologies listed in Table II.3 and Table II.4 of this RFI regarding their applicability to the current market and how these technologies may impact the efficacy of GSFLs and IRLs (including certain ER, BR, and R IRLs) as measured according to the DOE test procedure. DOE also seeks information on how these technologies may have changed since they were considered in the 2015 GSFL-IRL ECS final rule analysis. Specifically, DOE seeks information on the range of efficiencies or performance characteristics that are currently available for each technology option.
                </P>
                <P>
                    <E T="03">Issue 13:</E>
                     DOE seeks information on the technologies listed in Table II.3 and Table II.4 of this RFI regarding their market adoption, costs, and any concerns with incorporating them into products (
                    <E T="03">e.g.,</E>
                     impacts on consumer utility, potential safety concerns, manufacturing/production/implementation issues, 
                    <E T="03">etc.</E>
                    ), particularly as to changes that may have occurred since the 2015 GSFL-IRL ECS final rule analysis.
                </P>
                <P>
                    <E T="03">Issue 14:</E>
                     DOE seeks comment on other technology options that it should consider for inclusion in its analysis and if these technologies may impact product features or consumer utility.
                </P>
                <HD SOURCE="HD2">C. Screening Analysis</HD>
                <P>The purpose of the screening analysis is to evaluate the technologies that improve lamp efficacy to determine which technologies will be eliminated from further consideration and which will be passed to the engineering analysis for further consideration.</P>
                <P>DOE determines whether to eliminate certain technology options from further consideration based on the following criteria:</P>
                <P>
                    (1) 
                    <E T="03">Technological feasibility.</E>
                     Technologies that are not incorporated in commercial products or in working prototypes will not be considered further.
                </P>
                <P>
                    (2) 
                    <E T="03">Practicability to manufacture, install, and service.</E>
                     If it is determined that mass production of a technology in commercial products and reliable installation and servicing of the technology could not be achieved on the scale necessary to serve the relevant market at the time of the compliance date of the standard, then that technology will not be considered further.
                </P>
                <P>
                    (3) 
                    <E T="03">Adverse impacts on product utility or product availability.</E>
                     If a technology is determined to have significant adverse impact on the utility of the product to significant subgroups of consumers, or result in the unavailability of any covered product type with performance characteristics (including reliability), features, sizes, capacities, and volumes that are substantially the same as equipment generally available in the United States at the time, it will not be considered further.
                </P>
                <P>
                    (4) 
                    <E T="03">Adverse impacts on health or safety.</E>
                     If it is determined that a technology will have significant adverse impacts on health or safety, it will not be considered further.
                </P>
                <P>10 CFR part 430, subpart C, appendix A, 4(a)(4) and 5(b).</P>
                <P>
                    Technology options identified in the technology assessment are evaluated against these criteria using DOE analysis and inputs from interested parties (
                    <E T="03">e.g.,</E>
                     manufacturers, trade organizations, and energy efficiency advocates). Technologies that pass through the screening analysis are referred to as “design options” in the engineering analysis. Technology options that fail to meet one or more of the four criteria are eliminated from consideration.
                </P>
                <P>
                    Additionally, DOE notes that the four screening criteria do not directly address the proprietary status of technology options. DOE only considers potential efficiency levels achieved through the use of proprietary designs in the engineering analysis if they are not part of a unique pathway to achieve that efficiency level (
                    <E T="03">i.e.,</E>
                     if there are other non-proprietary technologies capable of achieving the same efficiency level).
                </P>
                <P>Table II.5 and Table II.6 of this RFI summarize the technology options that DOE screened out in the 2015 GSFL-IRL ECS final rule, and the applicable screening criteria.</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s50,12C,12C,12C,12C">
                    <TTITLE>Table II.5—Screened Out GSFL Technology Options From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="2">Screened technology option</CHED>
                        <CHED H="1">
                            EPCA Criteria
                            <LI>(X = Basis for Screening Out)</LI>
                        </CHED>
                        <CHED H="2">Technological feasibility</CHED>
                        <CHED H="2">Practicability to manufacture, install, and service</CHED>
                        <CHED H="2">
                            Adverse 
                            <LI>impact on </LI>
                            <LI>product utility</LI>
                        </CHED>
                        <CHED H="2">
                            Adverse 
                            <LI>impacts on </LI>
                            <LI>health and safety</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Multi-Photon Phosphors</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                </GPOTABLE>
                <PRTPAGE P="25333"/>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s100,12,12,12,12">
                    <TTITLE>Table II.6—Screened Out IRL Technology Options From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="2">Screened technology option</CHED>
                        <CHED H="1">
                            EPCA Criteria
                            <LI>(X = Basis for Screening Out)</LI>
                        </CHED>
                        <CHED H="2">Technological feasibility</CHED>
                        <CHED H="2">Practicability to manufacture, install, and service</CHED>
                        <CHED H="2">Adverse impact on product utility</CHED>
                        <CHED H="2">Adverse impacts on health and safety</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Microcavity Filaments</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Novel Filament Materials</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Crystallite Filament Coatings</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Non-Tungsten-Halogen Regenerative Cycles</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Infrared Phosphor Glass Coating</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Ultraviolet Phosphor Glass Coating</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Electron Stimulated Luminescence</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Corner Reflectors</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">High Reflectance Filament Supports</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Permanent Infrared Reflector Coating Shroud</ENT>
                        <ENT>X</ENT>
                        <ENT>X</ENT>
                        <ENT/>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">Higher Efficiency Burners for Small Diameter IRLs (less than or equal to 2.5 inches)</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>X</ENT>
                        <ENT/>
                    </ROW>
                    <ROW>
                        <ENT I="01">High Efficiency Gold Reflector Coatings</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>X</ENT>
                        <ENT/>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">Issue 15:</E>
                     With respect to the screened out technology options listed in Table II.5 and Table II.6 of this RFI, DOE seeks information on whether these options would, based on current and projected assessments regarding each of them, remain screened out for GSFLs and IRLs (including certain ER, BR, and R lamps) under the four screening criteria described in this section. With respect to each of these technology options, what steps, if any, could be (or have already been) taken to facilitate the introduction of each option as a means to improve the energy performance of GSFLs and IRLs and the potential to impact consumer utility of the GSFLs and IRLs.
                </P>
                <P>
                    <E T="03">Issue 16:</E>
                     DOE seeks information regarding how the screening criteria would affect any other technology options not already identified in this document with respect to their potential use in GSFLs and IRLs (including certain ER, BR, and R lamps).
                </P>
                <HD SOURCE="HD2">D. Engineering Analysis</HD>
                <P>The engineering analysis estimates the cost-efficiency relationship of products at different levels of increased energy efficacy (“efficacy levels”). This relationship serves as the basis for the cost-benefit calculations for customers, manufacturers, and the Nation. In determining the cost-efficiency relationship, DOE estimates the increase in manufacturer production cost (“MPC”) associated with increasing the efficiency of product above the baseline, up to the maximum technologically feasible (“max-tech”) efficacy level for each product class.</P>
                <P>DOE historically has used the following three methodologies to generate incremental manufacturing costs and establish efficacy levels (“ELs”) for analysis: (1) The design-option approach, which provides the incremental costs of adding to a baseline model design options that will improve its efficacy; (2) the efficacy-level approach, which provides the relative costs of achieving increases in efficacy levels, without regard to the particular design options used to achieve such increases; and (3) the cost-assessment (or reverse engineering) approach, which provides “bottom-up” manufacturing cost assessments for achieving various levels of increased efficacy, based on detailed cost data for parts and material, labor, shipping/packaging, and investment for models that operate at particular efficacy levels.</P>
                <P>
                    Because GSFLs and IRLs are difficult to reverse-engineer (
                    <E T="03">i.e.,</E>
                     not easily disassembled), DOE is considering directly deriving end-user prices for the lamps covered in this evaluation. Specifically, DOE is considering deriving ELs in the engineering analysis and end-user prices in the product price determination. By combining the results of the engineering analysis and the product price determination, DOE can derive typical inputs for use in the life-cycle cost (“LCC”) analysis and national impact analysis (“NIA”).
                </P>
                <HD SOURCE="HD3">1. Representative Product Classes</HD>
                <P>For the 2015 GSFL-IRL ECS final rule, DOE did not analyze all GSFL and IRL product classes. Rather, DOE identified and focused on representative product classes and then scaled the ELs from representative product classes to those product classes it did not analyze directly (see section II.D.4 for further details on scaling). For GSFLs, DOE identified lamps with CCTs less than 4,500 K (with the exception of the 2-foot U-shaped lamps) as representative product classes due to their high market volume. 80 FR 4042, 4067. For IRLs, DOE identified standard spectrum lamps, with diameters greater than 2.5 inches, and input voltage less than 125 V as the representative product class due to their high market volume. 80 FR 4042, 4075. Consistent with this approach, DOE tentatively plans to analyze the aforementioned product classes as representative.</P>
                <HD SOURCE="HD3">2. Baseline lamps</HD>
                <P>For each representative product class, DOE selects a baseline lamp as a reference point against which any changes resulting from new or amended energy conservation standards can be measured. Typically, a baseline model is the most common, least efficacious lamp sold in a given product class. DOE also considers other lamp characteristics in choosing the most appropriate baseline for each product class such as wattage, lumen output, and lifetime.</P>
                <P>Consistent with this analytical approach, DOE tentatively plans to consider the current minimum energy conservation standards (which were required for compliance starting on January 26, 2018 for GSFLs and July 14, 2012 for IRLs) to establish the baseline model for each product class. As noted previously, the current GSFL and IRL standards are based on lamp efficacy. The current standards for GSFLs are found in 10 CFR 430.32(n)(4) and for IRLs in 10 CFR 430.32(n)(6). DOE tentatively plans to identify efficacies of products from the DOE's Compliance Certification Management System (“CCMS”) database.</P>
                <P>
                    <E T="03">Issue 17:</E>
                     DOE requests feedback on whether the current energy conservation standards for GSFLs and IRLs provide an appropriate baseline efficiency level 
                    <PRTPAGE P="25334"/>
                    for DOE to use in evaluating whether to amend the current energy conservation standards for any of the product classes regulated by DOE. DOE requests data and suggestions to select the baseline models in order to better evaluate amending energy conservation standards for GSFLs and IRLs. In particular, DOE requests comment on the most common wattages, diameters, lifetimes, and features of GSFLs and IRLs (including certain ER, BR, and R lamps) sold today and whether these characteristics vary in popularity based on the region in which the lamps are sold.
                </P>
                <P>
                    <E T="03">Issue 18:</E>
                     DOE requests feedback on how to determine baseline models for product classes that have lamps with minimum efficacies above the existing standard (
                    <E T="03">i.e.,</E>
                     T5 SO and T5 HO lamps).
                </P>
                <P>
                    <E T="03">Issue 19:</E>
                     DOE requests feedback on the appropriate baseline models for any newly analyzed product classes for which standards are not currently in place or for the contemplated combined product classes, as discussed in II.B.1 of this document.
                </P>
                <HD SOURCE="HD3">3. Efficacy Levels and Maximum Technologically Feasible Levels</HD>
                <P>
                    In the 2015 GSFL-IRL final rule, for GSFLs, DOE selected more efficacious substitutes with characteristics (
                    <E T="03">e.g.,</E>
                     CCT, color rendering index [“CRI”], lifetime) as similar as possible to the baseline lamps. 80 FR 4042, 4067. DOE also ensured that full wattage lamps could meet each EL. 80 FR 4042, 4069-4070. Because fluorescent lamps operate on a ballast in practice, to capture real-world energy use and light output, DOE analyzed lamp-and-ballast systems in the engineering analysis. DOE analyzed more efficacious systems that maintain mean lumen output within 10 percent of the baseline, when possible.
                </P>
                <P>
                    For IRLs, in the GSFL-IRL ECS final rule, DOE considered substitute lamps that saved energy and, where possible, had a light output within 10 percent of the baseline lamp's light output. 
                    <E T="03">Id.</E>
                     at 80 FR 4076. For IRLs, DOE developed a continuous equation that specifies a minimum efficacy requirement across wattages and represents the potential efficacy a lamp can achieve using a particular design option.
                </P>
                <P>
                    In the 2015 GSFL-IRL ECS final rule, after identifying more efficacious substitutes for each baseline model, DOE developed ELs. DOE developed ELs based on: (1) The design options associated with the specific lamps studied; (2) the ability of lamps across wattages to comply with the standard level of a given product class; 
                    <SU>9</SU>
                    <FTREF/>
                     and (3) the maximum technologically feasible efficacy level or “max-tech”. For GSFLs, DOE used initial lumens from manufacturer catalogs and ANSI wattages, where possible, to develop initial ELs. DOE then compared these ELs to CCMS data and adjusted levels downward as necessary.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         Efficacy levels span multiple lamps of different wattages. In selecting ELs, DOE considered whether these multiple lamps can meet the standard levels.
                    </P>
                </FTNT>
                <P>In the 2015 GSFL-IRL ECS final rule, for GSFLs, DOE adopted the highest efficiency levels for the 4-foot MBP, 4-foot T5 SO, and 4-foot T5 HO product classes, requiring the use of 800 series rare earth phosphors for full wattage lamps. DOE maintained the baseline level for the 8-foot SP slimline product class, representing the use of less efficacious 800 series rare earth phosphors for full wattage lamps. DOE also maintained the baseline level for the 8-foot RDC HO product class, representing the use of less efficacious 700 series rare earth phosphors for full wattage lamps. This combination of ELs for the GSFL product classes represented the maximum net present value (“NPV”).</P>
                <P>In the 2015 GSFL-IRL ECS final rule, DOE proposed one EL representing the use of either a halogen infrared (“HIR”) lamp with a lifetime of 2,500 hours or an improved HIR lamp that may utilize improvements in reflector coatings with a lifetime of 4,200 hours. However, DOE did not adopt this EL because of the potential reduction in industry value and potential negative costs to the consumer in the scenario where manufacturers shortened the lifetime of IRLs. Instead, DOE maintained the baseline level requiring the use of a halogen lamp with a lifetime of 1,500 hours that utilizes a higher efficiency inert fill gas and a higher efficiency reflector coating.</P>
                <P>The maximum available efficacies for the analyzed product classes from the 2015 GSFL-IRL ECS final rule are included in Table II.7 for GSFLs, and Table II.8 of this RFI.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s25,r50,12">
                    <TTITLE>Table II.7—GSFL Maximum Efficacy Levels From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">CCT</CHED>
                        <CHED H="1">Lamp type</CHED>
                        <CHED H="1">Efficacy level (lumens/watt)</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">≤ 4,500 K</ENT>
                        <ENT>4-foot medium bipin</ENT>
                        <ENT>92.4</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>8-foot single pin slimline</ENT>
                        <ENT>99.0 *</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>8-foot recessed double contact HO</ENT>
                        <ENT>97.6 *</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>4-foot T5 miniature bipin SO</ENT>
                        <ENT>95.0</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>4-foot T5 miniature bipin HO</ENT>
                        <ENT>82.7</ENT>
                    </ROW>
                    <TNOTE>* indicates maximum efficacy levels not adopted in the 2015 GSFL-IRL ECS final rule.</TNOTE>
                </GPOTABLE>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                    <TTITLE>Table II.8—IRL Maximum Efficacy Levels from the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Lamp type</CHED>
                        <CHED H="1">Diameter</CHED>
                        <CHED H="1">Voltage</CHED>
                        <CHED H="1">EL 1</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Standard spectrum</ENT>
                        <ENT>&gt; 2.5 inches</ENT>
                        <ENT>&lt; 125 V</ENT>
                        <ENT>
                            6.2P 
                            <E T="51">0.27</E>
                             *
                        </ENT>
                    </ROW>
                    <TNOTE>P = rated wattage; * indicates maximum efficacy levels not adopted in the 2015 GSFL-IRL ECS final rule.</TNOTE>
                </GPOTABLE>
                <P>
                    DOE defines a max-tech efficacy level to represent the theoretical maximum possible efficacy if all available design options are incorporated in a model. In the 2015 GSFL-IRL ECS rule all max-tech levels analyzed were commercially available. In many cases, the max-tech efficiency level is not commercially available because it is not economically feasible. Since the 2015 GSFL-IRL ECS final rule, DOE found, compared to values in Table II.7 of this RFI, GSFLs that indicate a 6 percent increase in efficacy for the 4-foot MBP product class, a 3 percent increase in efficacy for the 8-foot SP slimline product class, an 11 percent increase in efficacy for the 8-foot RDC HO product class, a 4 percent increase in efficacy for the 4-foot T5 miniature bipin (MiniBP) SO product class, and a 17 percent increase in efficacy for the 4-foot T5 MiniBP HO product class. Since the GSFL-IRL ECS final rule, DOE found, compared to the value in Table II.8 of this RFI, IRLs that indicate a 5 percent increase in efficacy for the standard spectrum, &gt; 2.5 inches 
                    <PRTPAGE P="25335"/>
                    diameter, &lt; 125 V rated voltage product class.
                </P>
                <P>
                    <E T="03">Issue 20:</E>
                     DOE seeks input on the maximum achievable efficacy levels for GSFLs and IRLs (including certain ER, BR, and R lamps).
                </P>
                <P>
                    <E T="03">Issue 21:</E>
                     DOE seeks feedback on what design options would be incorporated at a max-tech efficacy level, and the efficacies associated with those levels. As part of this request, DOE also seeks information as to whether there are limitations on the use of certain combinations of design options.
                </P>
                <HD SOURCE="HD3">4. Scaling to Other Product Classes</HD>
                <P>As noted previously, for the GSFL-IRL ECS final rule DOE analyzed the representative product classes directly. DOE then scaled the levels developed for the representative product classes to determine levels for product classes not analyzed directly.</P>
                <P>
                    For GSFLs, in the 2015 GSFL-IRL ECS final rule, DOE did not directly analyze the 2-foot U-shaped lamps, and instead established ELs for this product class by scaling from ELs developed for the 4-foot MBP product class. DOE developed the scaling factor by comparing the efficacy of 2-foot U-shaped GSLs and the equivalent 4-foot MBP GSLs with the only difference between the two lamp types being the shape. For scaling ELs in the 4-foot MBP product class to ELs for the 2-foot MBP product class, DOE determined an average efficacy reduction of 8 percent. DOE also did not directly analyze lamps with CCTs greater than 4,500K and instead scaled the efficacy levels from lamps with CCTs less than or equal to 4,500K. DOE developed scaling factors for each product class with the higher CCT value by identifying pairs of the same lamp type differing only by CCT. DOE determined an average efficacy reduction of 4 percent for the 4-foot MBP product class, 2 percent for the 2-foot U-shaped product class, 3 percent for the 8-foot SP slimline product class, 4 percent for the 8-foot RDC HO product class, 6 percent for the T5 MiniBP SO product class, and 7 percent for the T5 MiniBP HO product class. 80 FR 4042, 4074; see 2015 GSFL-IRL ECS final rule chapter 5 technical support document (“TSD”).
                    <SU>10</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         The 205 GSFL-IRL ECS final rule TSD is available at: 
                        <E T="03">https://www.regulations.gov/document?D=EERE-2011-BT-STD-0006-0066.</E>
                    </P>
                </FTNT>
                <P>
                    <E T="03">Issue 22:</E>
                     DOE requests feedback on the average efficacy difference between 2-foot MBP and 4-foot MBP lamps, where the only difference is shape; and between lamps with CCT less than or equal to 4,500K and CCT greater than 4,500K, where the only difference is CCT.
                </P>
                <P>For IRLs, in the 2015 GSFL-IRL ECS final rule, DOE did not directly analyze modified spectrum IRLs, and instead established ELs for this product class by scaling from the ELs developed for the standard spectrum product class. DOE developed a scaling factor by comparing pairs of standard spectrum and modified spectrum IRLs, where each pair had the same bulb shape, rated life, rated voltage, and filament shape, and differed only in spectrum. DOE determined that an efficacy reduction of 15 percent was appropriate. 80 FR 4042, 4081.</P>
                <P>DOE also did not directly analyze IRLs with diameters less than or equal to 2.5 inches, and instead established ELs for this product class by scaling from the ELs developed for the IRL product class with diameters greater than 2.5 inches. DOE developed a scaling factor by comparing the halogen PAR20 lamp (the most common IRL with a diameter less than or equal to 2.5 inches) with the same type of halogen PAR30 or PAR38. For scaling IRLs with smaller diameters with larger diameters, DOE determined an average efficacy reduction of 12 percent.</P>
                <P>
                    DOE also did not directly analyze IRLs with rated voltages greater than or equal to 125 V, and instead established ELs for this product class by scaling from the ELs developed for the IRL product class with rated voltages less than 125 V. Most consumers operate 130 V lamps at 120 V, which slightly decreases their efficacy but increases their lifetime. DOE developed a scaling factor by using the Illuminating Engineering Society of North America (IESNA) Lighting Handbook equations that relate lifetime, lumens, and wattage to voltage of incandescent lamps to represent the potential increase in efficacy of a 130 V lamp operated at 120 V. Specifically, the scaling factor captured the difference in efficacy between a 130 V lamp operating at 130 V and a 130 V lamp operating at 120 V with the same lifetime as the lamps analyzed in the 120 V product class. 
                    <E T="03">Id.</E>
                     at 4080-1.
                </P>
                <P>
                    <E T="03">Issue 23:</E>
                     DOE requests feedback, including any relevant data, on the average efficacy difference between the standard and modified spectrum IRLs, where the only difference is spectrum; between IRLs with diameters less than or equal to 2.5 inches and greater than 2.5 inches, where the only difference is diameter; and between IRLs with rated voltages less than or equal to 125 V and greater than 125 V, where the only difference is rated voltage.
                </P>
                <HD SOURCE="HD2">E. Product Price Determination</HD>
                <P>
                    In generating end-user price inputs for the LCC analysis and NIA, DOE must identify distribution channels (
                    <E T="03">i.e.,</E>
                     how the products are distributed from the manufacturer to the consumer), and estimate relative sales volumes through each channel. In the 2015 GSFL-IRL ECS final rule, DOE determined end-user prices for GSFLs and IRLs by gathering publicly available pricing data. DOE identified three main distribution channels through which GSFLs and IRLs are sold and their relative price range: (1) State procurement (low prices), (2) large retail distributors (medium prices), and (3) internet retailers (high prices). Based on manufacturer feedback, DOE determined an aggregated percentage of shipments that go through each of the main channels for GSFLs and IRLs: 10 Percent for state procurement, 85 percent for large distributors, and 5 percent for internet retailers. DOE then applied these percentages respectively to the average low price determined state procurement, average medium price determined for large distributors, and the average high price determined for internet retailers. The sum of these weighted prices was used as the average consumer price for GSFLs and IRLs in the main LCC analysis and NIA. 80 FR 4042, 4082. See also chapter 7 of the 2015 GSFL-IRL ECS final rule TSD.
                </P>
                <P>
                    <E T="03">Issue 24:</E>
                     DOE requests comments on the described methodology for the pricing analysis, as well as information on the existence of any distribution channels other than those described and their assigned weighting. DOE also requests information on whether this methodology is appropriate for certain ER, BR, and R IRLs.
                </P>
                <HD SOURCE="HD2">F. Energy Use Analysis</HD>
                <P>
                    As part of the rulemaking process, DOE conducts an energy use analysis to identify how products are used by consumers, and thereby determine the energy savings potential of energy efficiency improvements. In the 2015 GSFL-IRL ECS final rule, to develop annual energy-use estimates, DOE multiplied annual usage (in hours per year) by the lamp power (in watts) for IRLs and the lamp-and-ballast system input power (in watts) for GSFLs. DOE characterized representative lamp or lamp-and-ballast systems in the engineering analysis. 80 FR 4042, 4082. For GSFLs, DOE considered two different lamp-and-ballast system scenarios: (1) A lamp replacement scenario in which the consumer selects a reduced wattage replacement lamp that can operate on the installed ballast 
                    <PRTPAGE P="25336"/>
                    and (2) a lamp-and-ballast replacement scenario in which the consumer selects a lamp that has the same or lower wattage compared to the baseline lamp and also selects a new ballast with improved performance characteristics. DOE selected lamp-and-ballast systems that maintained mean lumen output within 10 percent of the baseline system, when possible, giving priority to energy savings. 80 FR 4042, 4068.
                </P>
                <P>To characterize the country's average use of lamps for a typical year, in the 2015 GSFL-IRL ECS final rule, DOE developed annual operating hour distributions by sector, using data published in the 2010 U.S. Lighting Market Characterization report (“2010 LMC”), the Commercial Building Energy Consumption Survey (“CBECS”), the Manufacturer Energy Consumption Survey (“MECS”), and the Residential Energy Consumption Survey (“RECS”). Because the 2010 LMC operating hour data used is based on building surveys and metering data, it accounted for the use of occupancy sensors. 80 FR 4042, 4082.</P>
                <P>Table II.9 provides the operating hours from the 2015 GSFL-IRL ECS final rule.</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,r50,12">
                    <TTITLE>Table II.9—Average Operating Hours by Sector and Lamp Type From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Sector</CHED>
                        <CHED H="1">Lamp type</CHED>
                        <CHED H="1">
                            Average
                            <LI>annual</LI>
                            <LI>operating hours</LI>
                            <LI>
                                <E T="03">hr/year</E>
                            </LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Residential</ENT>
                        <ENT>GSFL</ENT>
                        <ENT>634</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>IRL</ENT>
                        <ENT>763</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Commercial</ENT>
                        <ENT>GSFL</ENT>
                        <ENT>4,065</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>IRL</ENT>
                        <ENT>4,532</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Industrial</ENT>
                        <ENT>GSFL</ENT>
                        <ENT>4,586</ENT>
                    </ROW>
                </GPOTABLE>
                <P>DOE did account for the use of dimmers or light sensors by modeling GSFLs and IRLs on dimmers and developing associated energy-use results as a sensitivity analysis. For GSFLs, DOE determined that the average reduction of system lumen output for GSFLs was 33 percent, based on research and manufacturer input. For IRLs, DOE modeled two scenarios: (1) All lamps are on dimmers and on average consumers using dimmers reduce lamp wattage by 20 percent, corresponding to a lumen reduction of 25 percent and an increase in lifetime by a factor of 3.94 at the baseline and (2) there is a distribution of lamps on dimmers and weighted-average characteristics were determined based on estimated percentage of IRLs that operate on dimmers and sensors (29 percent for residential sector, 5 percent for commercial sector). 80 FR 4042, 4083. See also, chapter 6 of the 2015 GSFL-IRL ECS final rule TSD.</P>
                <P>
                    <E T="03">Issue 25:</E>
                     DOE seeks feedback on the average annual operating hours for GSFLs and IRLs (including certain ER, BR and R lamps) by sector, and whether the values in Table II.9 continue to be adequate for future potential analyses. Please provide relevant data in support of whatever alternative values that DOE should use in lieu of its values listed in these tables.
                </P>
                <P>
                    <E T="03">Issue 26:</E>
                     DOE seeks feedback on its methodology and data used to determine impact of lighting controls for GSFLs and IRLs (including certain ER, BR, and R lamps), and whether it is adequate for future potential analyses.
                </P>
                <P>
                    <E T="03">Issue 27:</E>
                     DOE seeks feedback on any type of lighting control not mentioned that should be included in future potential analyses of GSFLs or IRLs (
                    <E T="03">e.g.,</E>
                     smart controls). Please provide relevant supporting data including how it is distinct from or works in conjunction with dimmers or sensors, prevalence of use by sector, and associated annual operating hours.
                </P>
                <HD SOURCE="HD2">G. Life-Cycle Cost and Payback Analysis</HD>
                <P>DOE conducts the LCC and payback period (“PBP”) analysis to evaluate the economic impacts of potential energy conservation standards for GSFLs and IRLs on individual customers. For any given efficacy level, DOE measures the PBP and the change in LCC relative to an estimated baseline level. The LCC is the total consumer expense over the life of the product, consisting of purchase, installation, and operating costs (expenses for energy use, maintenance, and repair). Inputs to the calculation of total installed cost include cost of the product—which includes consumer product price and sales taxes—and installation costs. Inputs to the calculation of operating expenses include annual energy consumption, energy prices and price projections, repair and maintenance costs, product lifetimes, discount rates, and the year that compliance with amended standards is required.</P>
                <P>
                    In the 2015 GSFL-IRL ECS final rule, DOE defined lifetime as the age in hours of operation when a lamp or ballast is retired from service. DOE used manufacturer literature to determine lamp lifetimes. Additionally, DOE assumed that a GSFL subject to group relamping 
                    <SU>11</SU>
                    <FTREF/>
                     operates for 75 percent of its rated lifetime. For average ballast lifetime, DOE used 15 years for the residential sector and 49,054 hours for the commercial sector. 80 FR 4042, 4087-4088. See also chapter 8 of the 2015 GSFL-IRL ECS final rule TSD.
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         Group relamping refers to the scenario when consumers replace all the lamps in a fixture or area at a predetermined time.
                    </P>
                </FTNT>
                <P>In the 2015 GSFL-IRL ECS final rule, DOE determined LCC savings for GSFLs under three different consumer purchasing events: (1) Lamp failure, when in a standards scenario a consumer must purchase a standards-compliant lamp that operates on the existing ballast; (2) ballast failure, when in a standards scenario a consumer must purchase a standards-compliant lamp-and-ballast combination such that the system light output stays within 10 percent of the baseline system; (3) new construction and renovation, when light design can be completely new (assuming spacing between lamps does not change) and a consumer must purchase all new fixture installations. Only lamp purchase events were applicable to IRLs, which do not use a ballast. 80 FR 4041, 4087. See also chapter 8 of the 2015 GSFL-IRL ECS final rule TSD.</P>
                <P>
                    <E T="03">Issue 28:</E>
                     DOE seeks feedback on the described methodology for determining lifetime (including whether other factors not mentioned may affect lifetime), the frequency of group relamping, and ballast lifetimes for GSFLs, and whether it is valid for use in potential future analyses.
                    <PRTPAGE P="25337"/>
                </P>
                <P>
                    <E T="03">Issue 29:</E>
                     DOE seeks feedback on GSFL and IRL purchasing events for which LCC savings should be determined and information on any other typical purchasing events other than those described.
                </P>
                <HD SOURCE="HD2">
                    H. 
                    <E T="03">Shipments</E>
                </HD>
                <P>DOE develops shipment forecasts of GSFLs and IRLs to calculate the national impacts of potential amended energy conservation standards on energy consumption, NPV, and future manufacturer cash flows. DOE develops shipment projections based on historical data and an analysis of key market drivers for each product. Historical shipment data are used to build up a product stock and also to calibrate the shipments model. The shipments model projects shipments over a 30-year analysis period for the base case (no new standards) and for all standards cases.</P>
                <P>In the 2015 GSFL-IRL ECS final rule, separate shipment projections were calculated for the residential sector and for the commercial and industrial sectors. The shipments model used to estimate GSFL and IRL lamp shipments had four main interacting elements: (1) A lamp demand module that estimated the demand for GSFL and IRL lighting for each year of the analysis period; (2) a price-learning module, which projected future prices based on historic price trends; (3) substitution matrices, which specified the product choices available to consumers (lamps as well as lamp-and-ballast combinations for fluorescent lamps) depending on whether they are renovating, in new construction, or replacements; and (4) a market-share module that assigned shipments to product classes, ballasts, and lamp options, based on consumer sensitivities to first costs (prices) and operation and maintenance costs. 80 FR 4042, 4089.</P>
                <P>For GSFLs, DOE projected that in cases of renovation or new construction, some fraction of the lighting market being served by T8 lamps will migrate to T5 lamps in the absence of standards. Additionally, DOE allowed all full wattage and reduced wattage lamp versions of the 4-foot MBP lamp type to be coupled to dimming ballasts; with the latter limited to 10 percent of the dimming ballast system market due to performance issues. For the GSFL reference scenario, DOE used the most recent price data (June 2014) for rare earth phosphors (“REO”) but also conducted a sensitivity analysis where the average rare earth phosphor price was 4.5 times the reference level.</P>
                <P>For IRLs, DOE assumed all potential switching from PAR to BR lamps had already taken place and accounted for some consumers shifting to light emitting diode (“LED”) lamps with the use of an LED market adoption curve. For additional detail in the development of shipments data in the 2015 GSFL-IRL ECS final rule see chapter 11 of the 2015 GSFL-IRL ECS final rule TSD.</P>
                <P>
                    <E T="03">Issue 30:</E>
                     DOE requests information on the migration of GSFL lamp types among GSFL product classes and to exempt products (
                    <E T="03">e.g.,</E>
                     high CRI linear fluorescent lamps) or to other lamp technologies and suggestions on how to account for such shifts in its shipment model.
                </P>
                <P>
                    <E T="03">Issue 31:</E>
                     DOE requests information on migration of IRL lamp types among IRL product classes and to exempt products or to other lamp technologies and suggestions on how to account for such shifts in its shipment model.
                </P>
                <P>Table II.10 and Table II.11 of this RFI, respectively, provide GSFL and IRL shipment projections from the 2015 GSFL-IRL ECS final rule for the years 2017 through 2019.</P>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,12,12,12">
                    <TTITLE>Table II.10—Projected GSFL Shipments From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Lamp type</CHED>
                        <CHED H="1">2017</CHED>
                        <CHED H="1">2018</CHED>
                        <CHED H="1">2019</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">4-ft Medium Bipin (Commercial/Industrial)</ENT>
                        <ENT>295,498</ENT>
                        <ENT>292,682</ENT>
                        <ENT>288,025</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4-ft Medium Bipin (Residential)</ENT>
                        <ENT>14,094</ENT>
                        <ENT>13,221</ENT>
                        <ENT>12,564</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8-ft Slimline</ENT>
                        <ENT>11,734</ENT>
                        <ENT>11,129</ENT>
                        <ENT>10,858</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8-ft High Output</ENT>
                        <ENT>3,340</ENT>
                        <ENT>2,937</ENT>
                        <ENT>2,546</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">T5 Standard Output</ENT>
                        <ENT>40,565</ENT>
                        <ENT>43,493</ENT>
                        <ENT>45,905</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">T5 High Output</ENT>
                        <ENT>31,646</ENT>
                        <ENT>33,266</ENT>
                        <ENT>34,493</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">U-shaped</ENT>
                        <ENT>14,194</ENT>
                        <ENT>14,086</ENT>
                        <ENT>13,908</ENT>
                    </ROW>
                </GPOTABLE>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                    <TTITLE>Table II.11—Projected Total IRL Shipments From the 2015 GSFL-IRL ECS Final Rule</TTITLE>
                    <BOXHD>
                        <CHED H="1">Sector</CHED>
                        <CHED H="1">2017</CHED>
                        <CHED H="1">2018</CHED>
                        <CHED H="1">2019</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Residential</ENT>
                        <ENT>27,021</ENT>
                        <ENT>24,654</ENT>
                        <ENT>20,974</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Commercial</ENT>
                        <ENT>3,746</ENT>
                        <ENT>2,993</ENT>
                        <ENT>2,506</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">Issue 32:</E>
                     DOE seeks feedback on how the projected shipments in Table II.10 and Table II.11 of this RFI compare to actual shipments of GSFLs and IRLs in these years.
                </P>
                <P>
                    <E T="03">Issue 33:</E>
                     DOE seeks shipment data on GSFLs and IRLs over the last 5-year period, separated by product classes. For each product class of GSFLs, DOE seeks shipment data by lamp diameter.
                </P>
                <P>
                    <E T="03">Issue 34:</E>
                     DOE requests information on the current and past five years of shipments of certain ER, BR, and R lamps. DOE also requests information on expected market trends for these products over the analysis period.
                </P>
                <P>
                    NEMA periodically releases lamp indices. In a recent lamp index report, NEMA stated that shipments for T5, T8, and T12 lamps in the first quarter of 2019 decreased by 12.3 percent, 13.6 percent, and 2.8 percent, respectively compared to the same period the previous year. In the first quarter of 2019 tubular light-emitting diodes (“TLEDs”) accounted for 30.4 percent and T5, T8, and T12 fluorescent lamps accounted for respectively, 8.2 percent, 50.9 percent, and 10.4 percent of fluorescent lamp shipments.
                    <SU>12</SU>
                    <FTREF/>
                     Comparatively, in the fourth quarter of 2017, TLEDs accounted for 23.1 percent and T5, T8, and T12 fluorescent lamps accounted for respectively 8.5 percent, 57.1 percent, and 11.4 percent of the fluorescent lamp shipments.
                    <SU>13</SU>
                    <FTREF/>
                     NEMA's 
                    <PRTPAGE P="25338"/>
                    data point to a decline in linear fluorescent shipments and an increase in TLED shipments.
                </P>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">Linear Fluorescent Lamp Indexes Continue Year-Over-Year Decline in First Quarter 2019 while T-LED Market Penetration Increases.</E>
                         See 
                        <E T="03">https://www.nema.org/Intelligence/Indices/Pages/Linear-Fluorescent-Lamp-Indexes-Continue-Year-Over-Year-Decline-in-First-Quarter-2019-while-T-LED-Market-Penetration-Increa.aspx.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">
                            Linear Fluorescent Lamp Indexes Continue Year-Over-Year Decline in Fourth Quarter 2017 
                            <PRTPAGE/>
                            while T-LED Market Penetration Increases.
                        </E>
                         See 
                        <E T="03">https://www.nema.org/Intelligence/Indices/Pages/Linear-Fluorescent-Lamp-Indexes-Continue-Year-Over-Year-Decline-in-Fourth-Quarter-2017-while-T-LED-Market-Penetration-Incre.aspx.</E>
                    </P>
                </FTNT>
                <P>
                    <E T="03">Issue 35:</E>
                     DOE seeks feedback on the projected rate of increase/decline of GSFL and IRL (including certain ER, BR, and R lamps) shipments in the next five years.
                </P>
                <P>
                    <E T="03">Issue 36:</E>
                     DOE also seeks information on the rate of shift from linear fluorescents to TLEDs including what types of GSFLs TLEDs are most frequently replacing (
                    <E T="03">i.e.,</E>
                     diameter, length) and in what scenarios are replacements occurring (
                    <E T="03">i.e.,</E>
                     single lamp replacement, renovation, new construction).
                </P>
                <P>
                    <E T="03">Issue 37:</E>
                     DOE seeks information regarding the potential variables that could cause consumers to opt to purchase other technologies (such as TLEDs) instead of GSFLs. DOE specifically seeks input on the magnitude of the change in efficiency, first cost, payback, or other variables that could cause consumers to opt for an alternate technology if energy conservation standards for GSFLs were amended.
                </P>
                <P>
                    <E T="03">Issue 38:</E>
                     DOE also seeks information on shifts within reflector incandescent/halogen lamps and/or to other lamp technologies.
                </P>
                <P>Linear fluorescent lamps with a CRI greater than or equal 87 (“high CRI fluorescent lamps”) are not subject to standards. Based on a preliminary review of products on the market, DOE found several high CRI fluorescent lamps on the market. DOE found that most of these products are T12 linear fluorescent lamps comprising mainly of the 4-foot MBP lamp type followed by the 8-foot SP slimline lamp type.</P>
                <P>
                    <E T="03">Issue 39:</E>
                     DOE requests information on the portion of the fluorescent lamp market that comprises of lamps with CRI of 87 or higher and information on the common shapes, lengths, diameters, and base types of these lamps. DOE also requests information on the specific applications for which fluorescent lamps with CRI of 87 or higher are used.
                </P>
                <P>Additionally, based on its preliminary review of the market, DOE found several T12 lamps of lengths that are not currently regulated.</P>
                <P>
                    <E T="03">Issue 40:</E>
                     DOE requests information on the portion of the fluorescent lamp market comprised of lamps with T12 diameters and the common base types and lengths of those lamps. DOE also requests information on the specific applications for which these T12 lamps are used.
                </P>
                <HD SOURCE="HD2">I. National Impact Analysis</HD>
                <P>The purpose of the NIA is to estimate the aggregate economic impacts of potential efficacy standards at the national level. The NIA assesses the national energy savings (“NES”) and the national NPV of total consumer costs and savings that would be expected to result from new or amended standards at specific efficiency levels.</P>
                <P>In the 2015 GSFL-IRL ECS final rule, DOE evaluated the impacts of new and amended standards for GSFLs and IRLs by comparing projections of total energy consumption with amended energy conservation standards to projections of energy consumption without the standards (no new standards). The no-new-standards case projections characterize energy use and consumer costs for each product class in the absence of new or amended energy conservation standards. In characterizing the no-new-standards and standards cases, DOE considered shipments from the shipments model, the mix of efficiencies sold in the absence of amended standards and how they may change, the annual energy consumption and installed cost per unit, and changes in electricity prices. In the reference case DOE assumed lighting controls penetration grows year-by-year in the commercial and industrial sector, as driven by an estimated 75 percent compliance rate with building codes (assuming these building codes remain frozen in time).</P>
                <P>DOE reduced the unit energy consumption (UEC) by a fixed 30 percent for the stock of lighting in which controls based on switching only were assumed to operate. For controls systems that incorporate dimming, DOE assumed the energy consumption reductions per those described in section II.F of this RFI.</P>
                <P>Since lamps and ballasts are sold separately, DOE considered a broad array of lamp-and-ballast pairings that were representative of what consumer may choose and ensured that the ballast and lamp were compatible and where possible (without sacrificing energy savings) provided light output within 10 percent or less of the baseline lamp-and-ballast system. DOE assumed no rebound effect for lighting. The rebound effect refers to the tendency of a consumer to respond to the cost savings associated with more efficient products in a manner that leads to marginally greater equipment usage, thereby diminishing some portion of anticipated benefits related to improved efficacy. See chapter 11 and 12 of the 2015 GSFL-IRL ECS final rule TSD for a detailed discussion of the NIA.</P>
                <P>
                    <E T="03">Issue 41:</E>
                     DOE seeks information on the distribution of lamp efficacy within each product class and whether that is expected to change under the currently applicable energy conservation standards.
                </P>
                <P>
                    <E T="03">Issue 42:</E>
                     DOE seeks information regarding the use of lighting controls at a national level broken down, if possible, by the type of lighting control (
                    <E T="03">e.g.</E>
                     occupancy sensors, dimmers, etc.).
                </P>
                <P>
                    <E T="03">Issue 43:</E>
                     DOE seeks comments and information on whether a rebound rate of 0 percent is appropriate.
                </P>
                <HD SOURCE="HD2">J. Manufacturer Impact Analysis</HD>
                <P>The purpose of the manufacturer impact analysis (“MIA”) is to estimate the financial impact of amended energy conservation standards on manufacturers of GSFLs and IRLs, and to evaluate the potential impact of such standards on direct employment and manufacturing capacity. The MIA includes both quantitative and qualitative aspects. The quantitative part of the MIA primarily relies on the Government Regulatory Impact Model (“GRIM”), an industry cash-flow model adapted for each product in this analysis, with the key output of industry net present value (“INPV”). The qualitative part of the MIA addresses the potential impacts of energy conservation standards on manufacturing capacity and industry competition, as well as factors such as product characteristics, impacts on particular subgroups of firms, and important market and product trends.</P>
                <P>
                    In the 2015 GSFL-IRL ECS final rule, for the MIA, DOE modeled two standards case markup scenarios to represent the uncertainty regarding the potential impacts on prices and profitability for manufacturers following the implementation of potential amended energy conservation standards: (1) A flat, or preservation of gross margin, markup scenario (absolute dollar markup increases as product costs increase with efficacy) and (2) a preservation of operating profit markup scenario (maintain the no-new-standards case total operating profit in absolute dollars in the standards case, despite higher production costs and investment). In addition, based on manufacturer feedback, for GSFLs, DOE evaluated a two-tiered markup scenario which assumed higher efficacy GSFLs command a higher manufacturer markup and baseline efficacy GSFLs subsequently have a lower manufacturer markup. See chapter 13 of the GSFL-IRL ECS final rule TSD.
                    <PRTPAGE P="25339"/>
                </P>
                <P>
                    <E T="03">Issue 44:</E>
                     DOE seeks feedback on the manufacturer markup scenarios described above, and whether they are valid for use in potential future analyses.
                </P>
                <P>
                    As part of the MIA, DOE intends to analyze impacts of amended energy conservation standards on subgroups of manufacturers of covered products, including small business manufacturers. DOE uses the Small Business Administration's (“SBA's”) small business size standards to determine whether manufacturers qualify as small businesses, which are listed by the applicable North American Industry Classification System (“NAICS”) code.
                    <SU>14</SU>
                    <FTREF/>
                     Manufacturing of GSFLs and IRLs is classified under NAICS 335110, “Electric Lamp Bulb and Part Manufacturing,” and the SBA sets a threshold of 1,250 employees or less for a domestic entity to be considered as a small business. This employee threshold includes all employees in a business' parent company and any other subsidiaries.
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         Available online at 
                        <E T="03">https://www.sba.gov/document/support--table-size-standards.</E>
                    </P>
                </FTNT>
                <P>One aspect of assessing manufacturer burden involves examining the cumulative impact of multiple DOE standards and the product-specific regulatory actions of other Federal agencies that affect the manufacturers of a covered product. While any one regulation may not impose a significant burden on manufacturers, the combined effects of several existing or impending regulations may have serious consequences for some manufacturers, groups of manufacturers, or an entire industry. Assessing the impact of a single regulation may overlook this cumulative regulatory burden. In addition to energy conservation standards, other regulations can significantly affect manufacturers' financial operations. Multiple regulations affecting the same manufacturer can strain profits and lead companies to abandon product lines or markets with lower expected future returns than competing products. For these reasons, DOE conducts an analysis of cumulative regulatory burden as part of its rulemakings pertaining to appliance efficiency.</P>
                <P>
                    <E T="03">Issue 45:</E>
                     To the extent feasible, DOE seeks the names and contact information of any domestic or foreign-based manufacturers that distribute GSFLs and IRLs (including certain ER, BR, and R lamps) in the United States.
                </P>
                <P>
                    <E T="03">Issue 46:</E>
                     DOE identified small businesses as a subgroup of manufacturers that could be disproportionally impacted by amended energy conservation standards. DOE requests the names and contact information of small business manufacturers, as defined by the SBA's size threshold, of GSFLs and IRLs (including certain ER, BR, and R lamps) that distribute products in the United States. In addition, DOE requests comment on any other manufacturer subgroups that could be disproportionately impacted by amended energy conservation standards. DOE requests feedback on any potential approaches that could be considered to address impacts on manufacturers, including small businesses.
                </P>
                <P>
                    <E T="03">Issue 47:</E>
                     DOE requests information regarding the cumulative regulatory burden impacts on manufacturers of GSFLs and IRLs (including certain ER, BR, and R lamps) associated with (1) other DOE standards applying to different products that these manufacturers may also make and (2) product-specific regulatory actions of other Federal agencies. DOE also requests comment on its methodology for computing cumulative regulatory burden and whether there are any flexibilities it can consider that would reduce this burden while remaining consistent with the requirements of EPCA.
                </P>
                <HD SOURCE="HD1">III. Other Energy Conservation Standards Topics</HD>
                <HD SOURCE="HD2">A. Market Failures</HD>
                <P>In the field of economics, a market failure is a situation in which the market outcome does not maximize societal welfare. Such an outcome would result in unrealized potential welfare. DOE welcomes comment on any aspect of market failures, especially those in the context of amended energy conservation standards for GSFLs and IRLs.</P>
                <HD SOURCE="HD2">B. Network Mode/“Smart” Technology</HD>
                <P>DOE published an RFI on the emerging smart technology appliance and equipment market. 83 FR 46886 (Sept. 17, 2018). In that RFI, DOE sought information to better understand market trends and issues in the emerging market for appliances and commercial equipment that incorporate smart technology. DOE's intent in issuing the RFI was to ensure that DOE did not inadvertently impede such innovation in fulfilling its statutory obligations in setting efficiency standards for covered products and equipment. DOE seeks comments, data and information on the issues presented in the RFI as they may be applicable to energy conservation standards for GSFLs and IRLs.</P>
                <HD SOURCE="HD2">C. Other Issues</HD>
                <P>Additionally, DOE welcomes comments on other issues relevant to the conduct of this rulemaking that may not specifically be identified in this document. In particular, DOE notes that under Executive Order 13771, “Reducing Regulation and Controlling Regulatory Costs,” Executive Branch agencies such as DOE are directed to manage the costs associated with the imposition of expenditures required to comply with Federal regulations. See 82 FR 9339 (Feb. 3, 2017). Consistent with that Executive Order, DOE encourages the public to provide input on measures DOE could take to lower the cost of its energy conservation standards rulemakings, recordkeeping and reporting requirements, and compliance and certification requirements applicable to GSFLs and IRLs while remaining consistent with the requirements of EPCA.</P>
                <HD SOURCE="HD1">IV. Submission of Comments</HD>
                <P>
                    DOE invites all interested parties to submit in writing by the date specified previously in the 
                    <E T="02">DATES</E>
                     section of this document, comments and information on matters addressed in this document and on other matters relevant to DOE's consideration of amended energy conservations standards for GSFLs and IRLs. After the close of the comment period, DOE will review the public comments received and may begin collecting data and conducting the analyses discussed in this document.
                </P>
                <P>
                    <E T="03">Submitting comments via http://www.regulations.gov.</E>
                     The 
                    <E T="03">http://www.regulations.gov</E>
                     web page requires you to provide your name and contact information. Your contact information will be viewable to DOE Building Technologies Office staff only. Your contact information will not be publicly viewable except for your first and last names, organization name (if any), and submitter representative name (if any). If your comment is not processed properly because of technical difficulties, DOE will use this information to contact you. If DOE cannot read your comment due to technical difficulties and cannot contact you for clarification, DOE may not be able to consider your comment.
                </P>
                <P>
                    However, your contact information will be publicly viewable if you include it in the comment or in any documents attached to your comment. Any information that you do not want to be publicly viewable should not be included in your comment, nor in any document attached to your comment. Persons viewing comments will see only first and last names, organization 
                    <PRTPAGE P="25340"/>
                    names, correspondence containing comments, and any documents submitted with the comments.
                </P>
                <P>
                    Do not submit to 
                    <E T="03">http://www.regulations.gov</E>
                     information for which disclosure is restricted by statute, such as trade secrets and commercial or financial information (hereinafter referred to as Confidential Business Information (“CBI”)). Comments submitted through 
                    <E T="03">http://www.regulations.gov</E>
                     cannot be claimed as CBI. Comments received through the website will waive any CBI claims for the information submitted. For information on submitting CBI, see the Confidential Business Information section.
                </P>
                <P>
                    DOE processes submissions made through 
                    <E T="03">http://www.regulations.gov</E>
                     before posting. Normally, comments will be posted within a few days of being submitted. However, if large volumes of comments are being processed simultaneously, your comment may not be viewable for up to several weeks. Please keep the comment tracking number that 
                    <E T="03">www.regulations.gov</E>
                     provides after you have successfully uploaded your comment.
                </P>
                <P>
                    <E T="03">Submitting comments via email, hand delivery/courier, or postal mail.</E>
                     Comments and documents submitted via email, hand delivery/courier, or postal mail also will be posted to 
                    <E T="03">http://www.regulations.gov.</E>
                     If you do not want your personal contact information to be publicly viewable, do not include it in your comment or any accompanying documents. Instead, provide your contact information on a cover letter. Include your first and last names, email address, telephone number, and optional mailing address. The cover letter will not be publicly viewable as long as it does not include any comments.
                </P>
                <P>Include contact information each time you submit comments, data, documents, and other information to DOE. If you submit via postal mail or hand delivery/courier, please provide all items on a CD, if feasible. It is not necessary to submit printed copies. No telefacsimiles (faxes) will be accepted.</P>
                <P>Comments, data, and other information submitted to DOE electronically should be provided in PDF (preferred), Microsoft Word or Excel, WordPerfect, or text (ASCII) file format. Provide documents that are not secured, written in English, and free of any defects or viruses. Documents should not contain special characters or any form of encryption and, if possible, they should carry the electronic signature of the author.</P>
                <P>
                    <E T="03">Campaign form letters.</E>
                     Please submit campaign form letters by the originating organization in batches of between 50 to 500 form letters per PDF or as one form letter with a list of supporters' names compiled into one or more PDFs. This reduces comment processing and posting time.
                </P>
                <P>
                    <E T="03">Confidential Business Information.</E>
                     According to 10 CFR 1004.11, any person submitting information that he or she believes to be confidential and exempt by law from public disclosure should submit via email, postal mail, or hand delivery/courier two well-marked copies: One copy of the document marked confidential including all the information believed to be confidential, and one copy of the document marked “non-confidential” with the information believed to be confidential deleted. Submit these documents via email or on a CD, if feasible. DOE will make its own determination about the confidential status of the information and treat it according to its determination.
                </P>
                <P>It is DOE's policy that all comments may be included in the public docket, without change and as received, including any personal information provided in the comments (except information deemed to be exempt from public disclosure).</P>
                <P>
                    DOE considers public participation to be a very important part of the process for developing energy conservation standards. DOE actively encourages the participation and interaction of the public during the comment period in each stage of the rulemaking process. Interactions with and between members of the public provide a balanced discussion of the issues and assist DOE in the rulemaking process. Anyone who wishes to be added to the DOE mailing list to receive future notices and information about this process or would like to request a public meeting should contact Appliance and Equipment Standards Program staff at (202) 287-1445 or via email at 
                    <E T="03">ApplianceStandardsQuestions@ee.doe.gov.</E>
                </P>
                <HD SOURCE="HD3">Signing Authority</HD>
                <P>
                    This document of the Department of Energy was signed on February 25, 2020, by Alexander N. Fitzsimmons, Deputy Assistant Secretary for Energy Efficiency, Energy Efficiency and Renewable Energy, pursuant to delegated authority from the Secretary of Energy. That document with the original signature and date is maintained by DOE. For administrative purposes only, and in compliance with requirements of the Office of the Federal Register, the undersigned DOE Federal Register Liaison Officer has been authorized to sign and submit the document in electronic format for publication, as an official document of the Department of Energy. This administrative process in no way alters the legal effect of this document upon publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <DATED>Signed in Washington, DC, on April 22, 2020.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08851 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6450-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <CFR>10 CFR Part 1021</CFR>
                <DEPDOC>[DOE-HQ-2020-0017]</DEPDOC>
                <RIN>RIN 1990-AA49</RIN>
                <SUBJECT>National Environmental Policy Act Implementing Procedures</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the General Counsel, Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking and request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Department of Energy (DOE or the Department) proposes to update its National Environmental Policy Act (NEPA) implementing procedures regarding authorizations issued under section 3 of the Natural Gas Act. These changes will improve the efficiency of the DOE decision-making process by saving time and money in the NEPA review process and eliminating unnecessary environmental documentation. DOE invites public comments on the proposed changes.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received by (or, if mailed, postmarked by) June 1, 2020 to ensure consideration.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Documents relevant to this rulemaking are posted on the Federal eRulemaking Portal at 
                        <E T="03">https://www.regulations.gov</E>
                         (
                        <E T="03">Docket: DOE-HQ-2020-0017</E>
                        ). Documents posted to this docket include: This notice of proposed rulemaking; DOE's “Technical Support Document” which provides additional information; and a “redline/strikeout” (markup) file of affected sections of the DOE NEPA regulations indicating the changes proposed in this proposed rule.
                    </P>
                    <P>Submit comments, labeled “DOE NEPA/NG Procedures, RIN 1990-AA49,” by one of the following methods:</P>
                    <P>
                        1. 
                        <E T="03">Federal eRulemaking Portal: https://www.regulations.gov.</E>
                         Follow the online instructions for submitting comments electronically. This 
                        <PRTPAGE P="25341"/>
                        rulemaking is assigned 
                        <E T="03">Docket: DOE-HQ-2020-0017.</E>
                    </P>
                    <P>
                        2. 
                        <E T="03">Postal Mail:</E>
                         Mail comments to Office of NEPA Policy and Compliance (GC-54), ATTN: NEPA/NG Procedures (RIN 1990-AA49), U.S. Department of Energy, 1000 Independence Avenue SW, Washington, DC 20585. Because security screening may delay mail sent through the U.S. Postal Service, DOE encourages electronic submittal of comments through the Federal eRulemaking Portal.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For questions concerning how to comment on this proposed rule, contact Yardena Mansoor, Office of NEPA Policy and Compliance, at 
                        <E T="03">DOE-NEPA-Rulemaking@hq.doe.gov</E>
                         or 800-472-2756. For detailed information on submitting comments, see “How may the public comment on DOE's proposed changes?”.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    DOE is responsible for authorizing exports of domestically produced natural gas to foreign countries under section 3 of the Natural Gas Act (NGA).
                    <SU>1</SU>
                    <FTREF/>
                     Section 3(a) of the NGA requires DOE to issue an order authorizing natural gas exports unless it finds that such an order “will not be consistent with the public interest.” DOE complies with NEPA 
                    <SU>2</SU>
                    <FTREF/>
                     before reaching a final decision on applications to export natural gas to countries with which the United States does not have a free trade agreement requiring national treatment for trade in natural gas (non-FTA countries).
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         15 U.S.C. 717b.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         42 U.S.C. 4321 
                        <E T="03">et seq.</E>
                    </P>
                </FTNT>
                <P>
                    DOE authorization also is required for imports of natural gas under section 3(a) of the NGA. However, section 3(c) of the NGA was amended by section 201 of the Energy Policy Act of 1992 
                    <SU>3</SU>
                    <FTREF/>
                     to require that applications to authorize the import of natural gas (as well as the export of natural gas to FTA countries) be “deemed consistent with the public interest, and . . . granted without modification or delay.” This requirement leaves DOE with no discretion in its approvals of natural gas imports, as they are deemed to be in the public interest. Accordingly, DOE proposes to remove the reference to authorizations to import natural gas from its NEPA regulations consistent with the legal principle that an agency is not required to prepare a NEPA analysis when it has no discretion in its action.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         EPACT 1992, Public Law 102-486.
                    </P>
                </FTNT>
                <P>
                    In addition, with regard to authorizations for export to non-FTA countries, DOE proposes to revise its regulations consistent with the legal principle that potential environmental effects considered under NEPA do not include effects that the agency has no authority to prevent, because they would not have a sufficiently close causal connection to the proposed action.
                    <SU>4</SU>
                    <FTREF/>
                     Here, DOE's proposed action is authorization of natural gas exports.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See Dep't of Transp.</E>
                         v. 
                        <E T="03">Pub. Citizen,</E>
                         541 U.S. 752 (2004); 
                        <E T="03">Sierra Club</E>
                         v. 
                        <E T="03">Fed. Energy Regulatory Comm'n,</E>
                         827 F.3d 36 (D.C. Cir. 2016).
                    </P>
                </FTNT>
                <P>
                    The statutory term “export” is not defined in the NGA. In adjudications under NGA section 3(a), however, DOE has construed an “export” of LNG from the United States as occurring “when the LNG is delivered to the flange of the LNG export vessel.” 
                    <SU>5</SU>
                    <FTREF/>
                     To ensure that DOE's NEPA regulations are consistent with this longstanding practice, DOE will focus exclusively on NEPA review of potential environmental impacts resulting from actions occurring at or after the point of export.
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See, e.g., Freeport LNG Expansion L.P., et al.,</E>
                         DOE/FE Order No. 3282-C, FE Docket No. 10-161-LNG, Final Opinion and Order Granting Long-Term, Multi-Contract Authorization to Export Liquefied Natural Gas by Vessel from the Freeport LNG Terminal on Quintana Island, Texas, to Non-Free Trade Agreement Nations, at 23 (Nov. 14, 2014) (“Export occurs when the LNG is delivered to the flange of the LNG export vessel.”) (citing 
                        <E T="03">Dow Chem. Co.,</E>
                         DOE/FE Order No. 2859, FE Docket No. 10-57-LNG, Order Granting Blanket Authorization to Export Liquefied Natural Gas, at 1 (Oct. 5, 2010)).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         This scope of analysis is also consistent with decisions in recent years of the U.S. Court of Appeal for the District of Columbia Circuit (D.C. Circuit), which recognized that DOE “maintains exclusive jurisdiction over the export of natural gas as a commodity.” 
                        <E T="03">Sierra Club</E>
                         v. 
                        <E T="03">Fed. Energy Regulatory Comm'n,</E>
                         827 F.3d 36, 40 (2016). Specifically, the D.C. Circuit observed that the Federal Energy Regulatory Commission (FERC) has an obligation to comply with the NGA and NEPA with respect to its decisions to authorize the construction of LNG terminals, whereas DOE has an independent obligation “to consider the environmental impacts of its export authorization decision under NEPA and determine whether it satisfied the Natural Gas Act's `public interest' test.” 
                        <E T="03">Sierra Club</E>
                         v. 
                        <E T="03">U.S. Dep't of Energy,</E>
                         867 F.3d 189, 192 (D.C. Cir. 2017).
                    </P>
                </FTNT>
                <P>
                    Additionally, this proposed rulemaking is consistent with two life cycle analyses (LCAs) that DOE commissioned to calculate the life cycle greenhouse gas (GHG) emissions for LNG exported from the United States. DOE commissioned both the original LCA GHG Report, published in 2014,
                    <SU>7</SU>
                    <FTREF/>
                     and an updated LCA GHG Report, published in 2019,
                    <SU>8</SU>
                    <FTREF/>
                     to evaluate environmental aspects of the LNG export chain under NGA section 3(a). Both Reports concluded that the use of U.S. LNG exports for power production in European and Asian markets will not increase global GHG emissions from a life cycle perspective, when compared to regional coal extraction and consumption for power production.
                    <SU>9</SU>
                    <FTREF/>
                     DOE has used these Reports to support its public interest determination regarding a proposed export. These Reports are not, however, part of DOE's NEPA reviews because the regasification and ultimate burning of LNG in foreign countries are beyond the scope of DOE's NEPA review.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         U.S. Dep't of Energy, Life Cycle Greenhouse Gas Perspective on Exporting Liquefied Natural Gas From the United States, 79 FR 32260 (June 4, 2014) (LCA GHG Report).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See</E>
                         U.S. Dep't of Energy, Life Cycle Greenhouse Gas Perspective on Exporting Liquefied Natural Gas From the United States; Notice of Availability of Report Entitled Life Cycle Greenhouse Gas Perspective on Exporting Liquefied Natural Gas From the United States: 2019 Update and Request for Comments, 84 FR 49278 (Sept. 19, 2019) (LCA GHG Update).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See, e.g.,</E>
                         U.S. Dep't of Energy, Life Cycle Greenhouse Gas Perspective on Exporting Liquefied Natural Gas From the United States: 2019 Update—Response to Comments, 85 FR 72, 78, 85 (Jan. 2, 2020).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">What parts of DOE's current NEPA regulations does DOE propose to amend?</HD>
                <P>
                    DOE's current NEPA regulations list classes of actions for each level of NEPA review.
                    <SU>10</SU>
                    <FTREF/>
                     Five of these classes regard applications to import or export natural gas to a non-FTA country. There are two categorical exclusions: B5.7 (Import or export of natural gas, with operational changes) and B5.8 (Import or export of natural gas, with new cogeneration powerplant); one class of actions normally requiring an EA: C13 (Import or export natural gas involving minor new construction); and two classes of action normally requiring an EIS: D8 (Import or export of natural gas involving major new facilities) and D9 (Import or export of natural gas involving major operational change).
                    <SU>11</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         There are three levels of NEPA review established in the Council on Environmental Quality's (CEQ's) NEPA implementing regulations (40 CFR parts 1500-1508)—categorical exclusion, environmental assessment (EA), and environmental impact statement (EIS)—each involving different levels of information and analysis.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         
                        <E T="03">See</E>
                         10 CFR 1021.410 and subpart D.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">What changes does DOE propose?</HD>
                <P>
                    DOE proposes to revise the classes of action in its NEPA regulations regarding authorizations under section 3 of the NGA consistent with the legal principle enunciated in 
                    <E T="03">Public Citizen</E>
                     and 
                    <E T="03">Sierra Club</E>
                     
                    <SU>12</SU>
                    <FTREF/>
                     that potential environmental effects considered under NEPA do not include effects that the agency has no authority to prevent. DOE's authority under Section 3 of the NGA is limited to authorization of exports of natural gas. Therefore, DOE need not review potential environmental impacts associated with the construction or 
                    <PRTPAGE P="25342"/>
                    operation of natural gas export facilities because DOE lacks authority to approve the construction or operation of those facilities. DOE's review is properly focused on potential environmental impacts resulting from the exercise of its NGA section 3 authority. These impacts occur at or after the point of export.
                </P>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See Dep't of Transp.</E>
                         v. 
                        <E T="03">Pub. Citizen,</E>
                         541 U.S. 752 (2004); 
                        <E T="03">Sierra Club</E>
                         v. 
                        <E T="03">Fed. Energy Regulatory Comm'n,</E>
                         827 F.3d 36 (D.C. Cir. 2016).
                    </P>
                </FTNT>
                <P>Accordingly, DOE proposes to revise the scope of categorical exclusion B5.7 by deleting the reference to operation of natural gas facilities. The revised B5.7 would include a new statement that the scope includes any “associated transportation of natural gas by marine vessel,” which is the only source of potential environmental impacts associated with DOE's decision regarding authorizations under section 3 of the NGA. Based on prior NEPA reviews and technical reports, DOE has determined that transport of natural gas by marine vessel normally does not pose the potential for significant environmental impacts. (See Technical Support Document.)</P>
                <P>
                    DOE also proposes to remove the reference to import authorizations from B5.7 because section 3(c) of the Natural Gas Act directs that authorization requests to import natural gas “shall be granted without modification or delay.” DOE is not required to prepare NEPA analysis when it has no discretion in its action.
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         15 U.S.C. 717b(c).
                    </P>
                </FTNT>
                <P>Finally, DOE proposes to remove and reserve categorical exclusion B5.8 and classes of action C13, D8, and D9. These would no longer be needed with the proposed changes to categorical exclusion B5.7.</P>
                <HD SOURCE="HD1">How does DOE make a categorical exclusion determination?</HD>
                <P>
                    The proposed revision to B5.7 would be subject to the same conditions as other categorical exclusions listed in appendix B to subpart D of DOE's NEPA regulations. Before a proposed action such as an export authorization may be categorically excluded, DOE must determine in accordance with 10 CFR 1021.410(b) that: (1) The proposed action fits within a categorical exclusion listed in appendix A or B to subpart D; (2) there are no extraordinary circumstances related to the proposal that may affect the significance of the environmental impacts of the proposed action; and (3) the proposal has not been segmented to meet the definition of a categorical exclusion, there are no connected or related actions with cumulatively significant impacts and the proposed action is not precluded as an impermissible interim action.
                    <SU>14</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         40 CFR 1506.1 and 10 CFR 1021.211.
                    </P>
                </FTNT>
                <P>In addition, to fit within a class of actions in appendix B (including B5.7), a proposed action must satisfy certain conditions known as “integral elements” (appendix B, paragraphs (1) through (5)). These conditions ensure that a proposed action would not have the potential to cause significant environmental impacts—for example, due to a threatened violation of applicable environmental, safety, and health requirements, or by disturbing hazardous substances such that there would be uncontrolled or unpermitted releases.</P>
                <HD SOURCE="HD1">How may the public comment on DOE's proposed changes?</HD>
                <P>DOE invites interested persons to participate in this proposed rulemaking by submitting comments on the proposed rule and on the supporting information for proposed changes set forth in the preamble and the Technical Support Document, including on industry experience with marine transport of natural gas. As appropriate, comments should refer to the specific section of the proposed rule to which the comment applies, identify a comment as a general comment, or identify a comment as a new proposal.</P>
                <P>DOE will consider all timely comments received in response to this notice of proposed rulemaking.</P>
                <P>
                    Comments may be submitted by one of the methods in the 
                    <E T="02">ADDRESSES</E>
                     section of this proposed rule. Comments received will be included in the administrative record and will be made available online at 
                    <E T="03">https://www.regulations.gov,</E>
                     including any personal information provided, unless the comment includes information specifically identified as Confidential Business Information (CBI) or other information whose disclosure is restricted by statute. Information that you consider to be CBI or otherwise protected should be submitted by mail, not through 
                    <E T="03">https://www.regulations.gov.</E>
                     If you submit information that you believe to be exempt by law from public disclosure, you should mail one complete copy, as well as one copy from which the information claimed to be exempt by law from public disclosure has been redacted. Please include written justification as to why the redacted information is exempt from disclosure. DOE is responsible for the final determination with regard to disclosure or nondisclosure of the information and for treating it accordingly under the DOE Freedom of Information Act regulations (10 CFR 1004.11).
                </P>
                <P>The Federal eRulemaking Portal is an “anonymous access” system, which means DOE will not know your contact information unless you provide it. If you choose not to provide contact information and DOE cannot read your comment due to technical difficulties, DOE may not be able to consider your comment. Electronic files should avoid the use of special characters and any form of encryption, and be free of any defects or viruses.</P>
                <HD SOURCE="HD1">Procedural Requirements</HD>
                <HD SOURCE="HD2">A. Review Under Executive Order 12866</HD>
                <P>This proposed rule has been determined not to be a significant regulatory action under E.O. 12866, “Regulatory Planning and Review,” 58 FR 51735 (October 4, 1993). Accordingly, this action was not subject to review under that Executive Order by the Office of Information and Regulatory Affairs (OIRA) of the Office of Management and Budget (OMB).</P>
                <HD SOURCE="HD2">B. Review Under National Environmental Policy Act</HD>
                <P>The requirements for Federal agencies to establish NEPA implementing procedures are set forth in the CEQ regulations at 40 CFR 1505.1 and 40 CFR 1507.3. DOE NEPA procedures assist the Department in the fulfillment of its responsibilities under NEPA but are not final determinations of the level of NEPA analysis required for particular actions. The CEQ regulations do not require agencies to prepare a NEPA analysis before establishing or updating agency procedures for implementing NEPA. DOE has determined that the proposed revision would not have a significant effect on the environment because it would not authorize any activity or commit resources to a project that may affect the environment. Therefore, DOE does not intend to conduct a NEPA analysis of these proposed regulations.</P>
                <HD SOURCE="HD2">C. Review Under Regulatory Flexibility Act</HD>
                <P>
                    The Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    ) requires preparation of an initial regulatory flexibility analysis for any rule that by law must be proposed for public comment, unless the agency certifies that the rule, if promulgated, will not have a significant economic impact on a substantial number of small entities. As required by E.O. 13272, “Proper Consideration of Small Entities in Agency Rulemaking,” 67 FR 53461 (August 16, 2002), DOE published procedures and policies on February 19, 2003, to ensure that the potential impacts of its rules on small entities are properly considered during the rulemaking process (68 FR 7990). 
                    <PRTPAGE P="25343"/>
                    DOE has made its procedures and policies available on the Office of the General Counsel's website: 
                    <E T="03">https://energy.gov/gc.</E>
                </P>
                <P>DOE has reviewed this proposed rule under the provisions of the Regulatory Flexibility Act and the procedures and policies published on February 19, 2003. The proposed rule would not directly regulate small entities. The proposed revisions to 10 CFR part 1021 would revise the scope of categorical exclusion B5.7 by removing reference to operation of natural gas facilities and adding “transportation of natural gas by marine vessel.” The proposed revisions would also focus on the export of natural gas because imports are deemed by law to be in the public interest. The proposal is intended to appropriately focus DOE's NEPA analysis for natural gas export applications, and does not impose any new requirements on small entities. DOE anticipates that the rule could reduce the burden on applicants for conducting environmental reviews.</P>
                <P>On the basis of the foregoing, DOE certifies that this proposed rule, if adopted, would not have a significant economic impact on a substantial number of small entities. Accordingly, DOE has not prepared a regulatory flexibility analysis for this proposed rulemaking. DOE's certification and supporting statement of factual basis will be provided to the Chief Counsel for Advocacy of the Small Business Administration pursuant to 5 U.S.C. 605(b).</P>
                <HD SOURCE="HD2">D. Review Under Paperwork Reduction Act</HD>
                <P>
                    This proposed rulemaking will impose no new information or record-keeping requirements. Accordingly, OMB clearance is not required under the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <HD SOURCE="HD2">E. Review Under Unfunded Mandates Reform Act of 1995</HD>
                <P>The Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4) generally requires Federal agencies to examine closely the impacts of regulatory actions on state, local, and tribal governments. Subsection 101(5) of title I of that law defines a Federal intergovernmental mandate to include any regulation that would impose upon state, local, or tribal governments an enforceable duty, except a condition of Federal assistance or a duty arising from participating in a voluntary Federal program. Title II of that law requires each Federal agency to assess the effects of Federal regulatory actions on state, local, and tribal governments, in the aggregate, or to the private sector, other than to the extent such actions merely incorporate requirements specifically set forth in a statute. Section 202 of that title requires a Federal agency to perform a detailed assessment of the anticipated costs and benefits of any rule that includes a Federal mandate which may result in costs to state, local, or tribal governments, or to the private sector, of $100 million or more in any one year (adjusted annually for inflation) (2 U.S.C. 1532(a) and (b)). Section 204 of that title requires each agency that proposes a rule containing a significant Federal intergovernmental mandate to develop an effective process for obtaining meaningful and timely input from elected officers of state, local, and tribal governments (2 U.S.C. 1534).</P>
                <P>The proposed rule would amend DOE's existing regulations governing compliance with NEPA to update DOE's regulations consistent with controlling legal principle. The proposed rule would not result in the expenditure by state, local, and tribal governments in the aggregate, or by the private sector, of $100 million or more in any one year. Accordingly, no assessment or analysis is required under the Unfunded Mandates Reform Act of 1995.</P>
                <HD SOURCE="HD2">F. Review Under Treasury and General Government Appropriations Act, 1999</HD>
                <P>Section 654 of the Treasury and General Government Appropriations Act, 1999 (Pub. L. 105-277) requires Federal agencies to issue a Family Policymaking Assessment for any proposed rule that may affect family well-being. The proposed rule would not have any impact on the autonomy or integrity of the family as an institution. Accordingly, DOE has concluded that it is not necessary to prepare a Family Policymaking Assessment.</P>
                <HD SOURCE="HD2">G. Review Under Executive Order 13132</HD>
                <P>E.O. 13132, “Federalism,” 64 FR 43255 (August 4, 1999), imposes certain requirements on agencies formulating and implementing policies or regulations that preempt state law or that have federalism implications. Agencies are required to examine the constitutional and statutory authority supporting any action that would limit the policymaking discretion of the states and carefully assess the necessity for such actions. DOE has examined this proposed rule and has determined that it would not preempt state law and would not have a substantial direct effect on the states, on the relationship between the national government and the states, or on the distribution of power and responsibilities among the various levels of government. No further action is required by E.O. 13132.</P>
                <HD SOURCE="HD2">H. Review Under Executive Order 12988</HD>
                <P>With respect to the review of existing regulations and the promulgation of new regulations, section 3(a) of E.O. 12988, “Civil Justice Reform,” 61 FR 4729 (February 7, 1996), imposes on Executive agencies the general duty to adhere to the following requirements: (1) Eliminate drafting errors and ambiguity; (2) write regulations to minimize litigation; and (3) provide a clear legal standard for affected conduct rather than a general standard and promote simplification and burden reduction. With regard to the review required by section 3(a), section 3(b) of E.O. 12988 specifically requires that Executive agencies make every reasonable effort to ensure that the regulation: (1) Clearly specifies the regulation's preemptive effect, if any; (2) clearly specifies any effect on existing Federal law or regulation; (3) provides a clear legal standard for affected conduct while promoting simplification and burden reduction; (4) specifies the retroactive effect, if any; (5) adequately defines key terms; and (6) addresses other important issues affecting clarity and general draftsmanship under any guidelines issued by the Attorney General. Section 3(c) of E.O. 12988 requires Executive agencies to review regulations in light of applicable standards in section 3(a) and section 3(b) to determine whether they are met or it is unreasonable to meet one or more of them. DOE has completed the required review and determined that, to the extent permitted by law, the proposed rule meets the relevant standards of E.O. 12988.</P>
                <HD SOURCE="HD2">I. Review Under Treasury and General Government Appropriations Act, 2001</HD>
                <P>The Treasury and General Government Appropriations Act, 2001 (44 U.S.C. 3516 note) provides for agencies to review most disseminations of information to the public under guidelines established by each agency pursuant to general guidelines issued by OMB.</P>
                <P>OMB's guidelines were published at 67 FR 8452 (February 22, 2002), and DOE's guidelines were published at 67 FR 62446 (October 7, 2002). DOE has reviewed this proposed rule under the OMB and DOE guidelines and has concluded that it is consistent with applicable policies in those guidelines.</P>
                <HD SOURCE="HD2">J. Review Under Executive Order 13211</HD>
                <P>
                    Executive Order 13211, “Actions Concerning Regulations That Significantly Affect Energy Supply, 
                    <PRTPAGE P="25344"/>
                    Distribution, or Use,” 66 FR 28355 (May 22, 2001), requires Federal agencies to prepare and submit to OMB a Statement of Energy Effects for any proposed significant energy action. A “significant energy action” is defined as any action by an agency that promulgated or is expected to lead to promulgation of a final rule, and that: (1)(i) Is a significant regulatory action under E.O. 12866, or any successor order, and (ii) is likely to have a significant adverse effect on the supply, distribution, or use of energy; or (2) is designated by the Administrator of OIRA as a significant energy action. For any proposed significant energy action, the agency must give a detailed statement of any adverse effects on energy supply, distribution, or use should the proposal be implemented, and of reasonable alternatives to the action and their expected benefits on energy supply, distribution, and use. This regulatory action would not have a significant adverse effect on the supply, distribution, or use of energy, and is therefore not a significant energy action. Accordingly, DOE has not prepared a Statement of Energy Effects.
                </P>
                <HD SOURCE="HD2">K. Review Under Executive Order 12630</HD>
                <P>DOE has determined pursuant to E.O. 12630, “Governmental Actions and Interference with Constitutionally Protected Property Rights,” 53 FR 8859 (March 18, 1988), that this proposed rule would not result in any takings that might require compensation under the Fifth Amendment to the United States Constitution.</P>
                <HD SOURCE="HD2">L. Review Under Executive Orders 13771 and 13777</HD>
                <P>On January 30, 2017, the President issued E.O. 13771, “Reducing Regulation and Controlling Regulatory Costs.” E.O. 13771 states that the policy of the executive branch is to be prudent and financially responsible in the expenditure of funds, from both public and private sources. E.O. 13771 states that it is essential to manage the costs associated with the governmental imposition of private expenditures required to comply with Federal regulations.</P>
                <P>Additionally, on February 24, 2017, the President issued E.O. 13777, “Enforcing the Regulatory Reform Agenda.” E.O. 13777 requires the head of each agency to designate an agency official as its Regulatory Reform Officer (RRO). Each RRO oversees the implementation of regulatory reform initiatives and policies to ensure that agencies effectively carry out regulatory reforms, consistent with applicable law. Further, E.O. 13777 requires the establishment of a regulatory task force at each agency. The regulatory task force is required to make recommendations to the agency head regarding the repeal, replacement, or modification of existing regulations, consistent with applicable law. At a minimum, each regulatory reform task force must attempt to identify regulations that:</P>
                <P>(i) Eliminate jobs, or inhibit job creation;</P>
                <P>(ii) Are outdated, unnecessary, or ineffective;</P>
                <P>(iii) Impose costs that exceed benefits;</P>
                <P>(iv) Create a serious inconsistency or otherwise interfere with regulatory reform initiatives and policies;</P>
                <P>(v) Are inconsistent with the requirements of Information Quality Act, or the guidance issued pursuant to that Act, in particular those regulations that rely in whole or in part on data, information, or methods that are not publicly available or that are insufficiently transparent to meet the standard for reproducibility; or</P>
                <P>(vi) Derive from or implement Executive Orders or other Presidential directives that have been subsequently rescinded or substantially modified.</P>
                <P>DOE initially concludes that this rulemaking is consistent with the directives set forth in these Executive Orders. This proposed rule would update and improve efficiency in DOE's implementation of NEPA by appropriately focusing DOE's NEPA analysis for natural gas export applications and eliminating certain requirements of its existing regulations that are unnecessary.</P>
                <HD SOURCE="HD1">Approval of the Office of the Secretary</HD>
                <P>The Secretary of Energy has approved publication of this notice of proposed rulemaking.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 10 CFR Part 1021</HD>
                    <P>Environmental impact statements.</P>
                </LSTSUB>
                <HD SOURCE="HD1">Signing Authority</HD>
                <P>
                    This document of the Department of Energy was signed on April 16, 2020, by William S. Cooper III, General Counsel, pursuant to delegated authority from the Secretary of Energy. That document with the original signature and date is maintained by DOE. For administrative purposes only, and in compliance with requirements of the Office of the Federal Register, the undersigned DOE Federal Register Liaison Officer has been authorized to sign and submit the document in electronic format for publication, as an official document of the Department of Energy. This administrative process in no way alters the legal effect of this document upon publication in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <DATED>Signed in Washington, DC, on April 17, 2020.</DATED>
                    <NAME>Treena V. Garrett,</NAME>
                    <TITLE>Federal Register Liaison Officer, U.S. Department of Energy.</TITLE>
                </SIG>
                <P>For the reasons stated in the preamble, DOE is proposing to amend part 1021 of Chapter X of Title 10 of the Code of Federal Regulations as set forth below:</P>
                <PART>
                    <HD SOURCE="HED">PART 1021—NATIONAL ENVIRONMENTAL POLICY ACT IMPLEMENTING PROCEDURES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 1021 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority: </HD>
                    <P>
                        42 U.S.C. 7101 
                        <E T="03">et seq.;</E>
                         42 U.S.C. 4321 
                        <E T="03">et seq.;</E>
                         50 U.S.C. 2401 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <AMDPAR>2. Appendix B to subpart D of part 1021 is amended by:</AMDPAR>
                <AMDPAR>a. Revising section B5.7; and</AMDPAR>
                <AMDPAR>b. Removing and reserving section B5.8.</AMDPAR>
                <P>The revision reads as follows:</P>
                <HD SOURCE="HD1">APPENDIX B TO SUBPART D OF PART 1021—CATEGORICAL EXCLUSIONS APPLICABLE TO SPECIFIC AGENCY ACTIONS</HD>
                <EXTRACT>
                    <STARS/>
                    <P>B5. * * *</P>
                    <STARS/>
                    <P>
                        <E T="03">B5.7 Export of natural gas and associated transportation by marine vessel</E>
                    </P>
                    <P>Approvals or disapprovals of new authorizations or amendments of existing authorizations to export natural gas under section 3 of the Natural Gas Act and any associated transportation of natural gas by marine vessel.</P>
                    <P>B5.8 [Removed and Reserved].</P>
                    <STARS/>
                </EXTRACT>
                <HD SOURCE="HD1">APPENDIX C TO SUBPART D OF PART 1021—CLASSES OF ACTIONS THAT NORMALLY REQUIRE EAs BUT NOT NECESSARILY EISs</HD>
                <HD SOURCE="HD1">C13 [Removed and Reserved]</HD>
                <AMDPAR>3. Remove and reserve section C13.</AMDPAR>
                <HD SOURCE="HD1">APPENDIX D TO SUBPART D OF PART 1021—CLASSES OF ACTIONS THAT NORMALLY REQUIRE EISs</HD>
                <HD SOURCE="HD1">D8 and D9 [Removed and Reserved]</HD>
                <AMDPAR>4. Remove and reserve sections D8 and D9.</AMDPAR>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08511 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6450-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <PRTPAGE P="25345"/>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 39</CFR>
                <DEPDOC>[Docket No. FAA-2020-0343; Product Identifier 2019-NM-206-AD]</DEPDOC>
                <RIN>RIN 2120-AA64</RIN>
                <SUBJECT>Airworthiness Directives; Airbus SAS Airplanes</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking (NPRM).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FAA proposes to supersede Airworthiness Directive (AD) 2018-17-05, which applies to all Airbus SAS Model A350-941 and -1041 airplanes. AD 2018-17-05 requires a check of the insulation resistance of the direct drive solenoid valve (DDSOV) of each affected electro-hydrostatic actuator (EHA) and applicable corrective actions. Since the FAA issued AD 2018-17-05, it has been determined that certain EHA part numbers can be modified and re-identified as specified in European Union Aviation Safety Agency (EASA) AD 2019-0301, dated December 12, 2019, which would inadvertently remove certain part numbers from the applicability in other EHA-related ADs. This proposed AD would require a check of the insulation resistance of the DDSOV of each affected EHA and applicable corrective actions, and modifying or replacing certain EHAs, as specified in two EASA ADs, which will be incorporated by reference. The FAA is proposing this AD to address the unsafe condition on these products.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The FAA must receive comments on this proposed AD by June 15, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         202-493-2251.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        For the material identified in this proposed AD that will be incorporated by reference (IBR), contact the EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 89990 1000; email 
                        <E T="03">ADs@easa.europa.eu;</E>
                         internet 
                        <E T="03">www.easa.europa.eu.</E>
                         You may find this IBR material on the EASA website at 
                        <E T="03">https://ad.easa.europa.eu.</E>
                         You may view this IBR material at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195. It is also available in the AD docket on the internet at 
                        <E T="03">https://www.regulations.gov</E>
                         by searching for and locating Docket No. FAA-2020-0343.
                    </P>
                </ADD>
                <HD SOURCE="HD1">Examining the AD Docket</HD>
                <P>
                    You may examine the AD docket on the internet at 
                    <E T="03">https://www.regulations.gov</E>
                     by searching for and locating Docket No. FAA-2020-0343; or in person at Docket Operations between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. The AD docket contains this NPRM, the regulatory evaluation, any comments received, and other information. The street address for Docket Operations is listed above. Comments will be available in the AD docket shortly after receipt.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kathleen Arrigotti, Aerospace Engineer, Large Aircraft Section, International Validation Branch, FAA, 2200 South 216th St., Des Moines, WA 98198; telephone and fax 206-231-3218; 
                        <E T="03">Kathleen.Arrigotti@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>
                    The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under the 
                    <E T="02">ADDRESSES</E>
                     section. Include “Docket No. FAA-2020-0343; Product Identifier 2019-NM-206-AD” at the beginning of your comments. The FAA specifically invites comments on the overall regulatory, economic, environmental, and energy aspects of this NPRM. The FAA will consider all comments received by the closing date and may amend this NPRM based on those comments.
                </P>
                <P>
                    The FAA will post all comments received, without change, to 
                    <E T="03">https://www.regulations.gov,</E>
                     including any personal information you provide. The FAA will also post a report summarizing each substantive verbal contact we receive about this NPRM.
                </P>
                <HD SOURCE="HD1">Discussion</HD>
                <P>The FAA issued AD 2018-17-05, Amendment 39-19359 (83 FR 40438, August 15, 2018) (“AD 2018-17-05”), which applied to all Airbus SAS Model A350-941 and -1041 airplanes. AD 2018-17-05 requires a check of the insulation resistance of the DDSOV of each affected EHA and applicable corrective actions. The FAA issued AD 2018-17-05 to address degraded insulation resistance in the DDSOV, due to incorrect sealing application, which could lead to the DDSOV being unable to command or maintain the EHA in active mode, possibly resulting in reduced control of the airplane.</P>
                <HD SOURCE="HD1">Actions Since AD 2018-17-05 Was Issued</HD>
                <P>Since AD 2018-17-05 was issued, it has been determined that certain EHA part numbers can be modified and re-identified as described in EASA AD 2019-0301, dated December 12, 2019 (“EASA 2019-0301”), which would inadvertently remove certain part numbers from the applicability in other EHA-related ADs. Therefore, EASA issued AD 2020-0027R1, dated February 21, 2020 (“EASA AD 2020-0027R1”), to revise the definition of an affected EHA.</P>
                <P>The EASA, which is the Technical Agent for the Member States of the European Union, has issued EASA AD 2019-0301 and EASA AD 2020-0027R1 (these ADs are also referred to as the Mandatory Continuing Airworthiness Information, or “the MCAI”), to correct an unsafe condition for all Airbus SAS Model A350-941 and -1041 airplanes. EASA AD 2020-0027R1 supersedes EASA AD 2018-0141, dated July 3, 2018 (which corresponds to FAA AD 2018-17-05).</P>
                <P>
                    In addition to the determination that certain EHA part numbers might have been inadvertently removed from the actions required by AD 2018-17-05, this proposed AD was prompted by reports of EHA units that were returned to the manufacturer with degraded insulation resistance in the DDSOV; investigation results revealed that moisture ingress, due to incorrect sealing application, had caused this degradation. This AD was also prompted by a report of a technical issue detected on EHAs installed on inboard ailerons and elevators, causing potential erroneous monitoring of those actuators. The FAA is proposing this AD to address degraded insulation resistance, which could lead to the DDSOV being unable to command or maintain the EHA in active mode, and possibly result in reduced control of the 
                    <PRTPAGE P="25346"/>
                    airplane. The FAA is also proposing this AD to address the possibility of an in-flight loss of inboard aileron or elevator control, which, due to the resulting drag, would lead to increased fuel consumption, and when combined with one engine inoperative, could result in reduced control of the airplane. See the MCAI for additional background information.
                </P>
                <HD SOURCE="HD1">Related IBR Material Under 1 CFR Part 51</HD>
                <P>
                    EASA AD 2019-0301 describes, among other actions, procedures for modifying or replacing affected EHAs. In addition, EASA AD 2020-0027R1 describes procedures for a check of the insulation resistance of the DDSOV of each affected EHA (installed on inboard ailerons, elevators, and rudder) and applicable corrective actions (replacing or reidentifying the affected EHA). This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in the 
                    <E T="02">ADDRESSES</E>
                     section.
                </P>
                <HD SOURCE="HD1">FAA's Determination and Requirements of This Proposed AD</HD>
                <P>This product has been approved by the aviation authority of another country, and is approved for operation in the United States. Pursuant to a bilateral agreement with the State of Design Authority, the FAA has been notified of the unsafe condition described in the MCAI referenced above. The FAA is proposing this AD because the agency evaluated all pertinent information and determined an unsafe condition exists and is likely to exist or develop on other products of the same type design.</P>
                <HD SOURCE="HD1">Proposed AD Requirements</HD>
                <P>This proposed AD would require accomplishing certain actions specified in EASA AD 2019-0301 and the actions specified in EASA AD 2020-0027R1, described previously, as incorporated by reference, except for any differences identified as exceptions in the regulatory text of this AD and except as discussed under “Differences Between this Proposed AD and the MCAI.”</P>
                <HD SOURCE="HD1">Explanation of Required Compliance Information</HD>
                <P>
                    In the FAA's ongoing efforts to improve the efficiency of the AD process, the FAA initially worked with Airbus and EASA to develop a process to use certain EASA ADs as the primary source of information for compliance with requirements for corresponding FAA ADs. The FAA has since coordinated with other manufacturers and civil aviation authorities (CAAs) to use this process. As a result, EASA AD 2019-0301 and EASA AD 2020-0027R1 will be incorporated by reference in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2019-0301 and EASA AD 2020-0027R1 in their entirety, through that incorporation, except for any differences identified as exceptions in the regulatory text of this proposed AD. Using common terms that are the same as the heading of a particular section in the EASA AD does not mean that operators need comply only with that section. For example, where the AD requirement refers to “all required actions and compliance times,” compliance with this AD requirement is not limited to the section titled “Required Action(s) and Compliance Time(s)” in the EASA AD. Service information specified in EASA AD 2019-0301 and EASA AD 2020-0027R1 that is required for compliance with EASA AD 2019-0301 and EASA AD 2020-0027R1 will be available on the internet at 
                    <E T="03">https://www.regulations.gov</E>
                     by searching for and locating Docket No. FAA-2020-0343 after the FAA final rule is published.
                </P>
                <HD SOURCE="HD1">Differences Between This Proposed AD and the MCAI</HD>
                <P>EASA AD 2019-0301 requires the accomplishment of paragraphs (1) through (6). However, this AD only requires the accomplishment of paragraphs (5) and (6) of EASA AD 2019-0301. Paragraphs (1) through (4) of EASA AD 2019-0301 are addressed in FAA AD 2019-16-08, Amendment 39-19711 (84 FR 51957, October 1, 2019), which requires revising the airplane flight manual (AFM) to provide the flightcrew with updated procedures related to inboard aileron fault operations, and also requires modification of the electronic centralized aircraft monitoring (ECAM) procedures by installing an Airbus temporary quick change (ATQC) and activating an ECAM temporary change.</P>
                <HD SOURCE="HD1">Clarification of a Definition in EASA AD 2020-0027R1</HD>
                <P>For EASA AD 2020-0027R1, all serial numbers listed in the “applicable SB” are included in the definition of “affected EHA” regardless of the associated part numbers that are also listed in the “applicable SB.”</P>
                <HD SOURCE="HD1">Costs of Compliance</HD>
                <P>The FAA estimates that this proposed AD affects 13 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s25,r50,12,r25,r25">
                    <TTITLE>Estimated Costs for Required Actions *</TTITLE>
                    <BOXHD>
                        <CHED H="1">Action</CHED>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">Cost per product</CHED>
                        <CHED H="1">Cost on U.S. operators</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">New proposed actions</ENT>
                        <ENT>Up to 28 work-hours × $85 per hour = $2,380</ENT>
                        <ENT>** $0</ENT>
                        <ENT>Up to $2,380</ENT>
                        <ENT>Up to $30,940.</ENT>
                    </ROW>
                    <TNOTE>* Table does not include estimated costs for reporting.</TNOTE>
                    <TNOTE>** The FAA has received no definitive date on the parts cost for the modification or replacement specified in this proposed AD.</TNOTE>
                </GPOTABLE>
                <P>The FAA estimates that it would take about 1 work-hour per product to comply with the proposed reporting requirement in this proposed AD. The average labor rate is $85 per hour. Based on these figures, the FAA estimates the cost of reporting the inspection results on U.S. operators to be $1,105, or $85 per product.</P>
                <P>The FAA estimates the following costs to do any necessary on-condition actions that would be required based on the results of any required actions. The FAA has no way of determining the number of aircraft that might need these on-condition actions:</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,r50,r50">
                    <TTITLE>Estimated Costs of On-Condition Actions</TTITLE>
                    <BOXHD>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">Cost per product</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Up to 28 work-hours × $85 per hour = $2,380</ENT>
                        <ENT>Up to $518,314</ENT>
                        <ENT>Up to $520,694.</ENT>
                    </ROW>
                </GPOTABLE>
                <PRTPAGE P="25347"/>
                <HD SOURCE="HD1">Paperwork Reduction Act</HD>
                <P>A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a current valid OMB control number. The control number for the collection of information required by this proposed AD is 2120-0056. The paperwork cost associated with this proposed AD has been detailed in the Costs of Compliance section of this document and includes time for reviewing instructions, as well as completing and reviewing the collection of information. Therefore, all reporting associated with this proposed AD is mandatory. Comments concerning the accuracy of this burden and suggestions for reducing the burden should be directed to Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.</P>
                <HD SOURCE="HD1">Authority for This Rulemaking</HD>
                <P>Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.</P>
                <P>The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: “General requirements.” Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.</P>
                <HD SOURCE="HD1">Regulatory Findings</HD>
                <P>The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.</P>
                <P>For the reasons discussed above, I certify this proposed regulation:</P>
                <P>(1) Is not a “significant regulatory action” under Executive Order 12866,</P>
                <P>(2) Will not affect intrastate aviation in Alaska, and</P>
                <P>(3) Will not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 14 CFR Part 39</HD>
                    <P>Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Proposed Amendment</HD>
                <P>Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 39—AIRWORTHINESS DIRECTIVES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 39 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 39.13</SECTNO>
                    <SUBJECT> [Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>2. The FAA amends § 39.13 by removing Airworthiness Directive (AD) 2018-17-05, Amendment 39-19359 (83 FR 40438, August 15, 2018), and adding the following new AD:</AMDPAR>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="04">Airbus SAS:</E>
                         Docket No. FAA-2020-0343; Product Identifier 2019-NM-206-AD.
                    </FP>
                    <HD SOURCE="HD1">(a) Comments Due Date</HD>
                    <P>We must receive comments by June 15, 2020.</P>
                    <HD SOURCE="HD1">(b) Affected ADs</HD>
                    <P>This AD replaces AD 2018-17-05, Amendment 39-19359 (83 FR 40438, August 15, 2018) (“AD 2018-17-05”).</P>
                    <HD SOURCE="HD1">(c) Applicability</HD>
                    <P>This AD applies to all Airbus SAS Model A350-941 and -1041 airplanes, certificated in any category.</P>
                    <HD SOURCE="HD1">(d) Subject</HD>
                    <P>Air Transport Association (ATA) of America Code 27, Flight controls.</P>
                    <HD SOURCE="HD1">(e) Reason</HD>
                    <P>This AD was prompted by reports of electro-hydrostatic actuator (EHA) units that were returned to the manufacturer with degraded insulation resistance in the direct drive solenoid valve (DDSOV); investigation results revealed that moisture ingress, due to incorrect sealing application, had caused this degradation. This AD was also prompted by a report of a technical issue detected on EHAs installed on inboard ailerons and elevators, causing potential erroneous monitoring of those actuators. The FAA is issuing this AD to address degraded insulation resistance, which could lead to the DDSOV being unable to command or maintain the EHA in active mode, and possibly result in reduced control of the airplane. The FAA is also issuing this AD to address the possibility of an in-flight loss of inboard aileron or elevator control, which, due to the resulting drag, would lead to increased fuel consumption, and when combined with one engine inoperative, could result in reduced control of the airplane.</P>
                    <HD SOURCE="HD1">(f) Compliance</HD>
                    <P>Comply with this AD within the compliance times specified, unless already done.</P>
                    <HD SOURCE="HD1">(g) Requirements</HD>
                    <P>Except as specified in paragraph (h) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, European Union Aviation Safety Agency (EASA) AD 2020-0027R1, dated February 21, 2020 (“EASA AD 2020-0027R1”) and EASA AD 2019-0301, dated December 12, 2019 (“EASA AD 2019-0301”).</P>
                    <HD SOURCE="HD1">(h) Exceptions and Clarifications to EASA AD 2019-0301 and EASA AD 2020-0027R1</HD>
                    <P>(1) Where EASA AD 2019-0301 and EASA AD 2020-0027R1 refer to their effective date, this AD requires using the effective date of this AD.</P>
                    <P>(2) The “Remarks” section of EASA AD 2019-0301 and EASA AD 2020-0027R1 do not apply to this AD.</P>
                    <P>(3) Where EASA AD 2019-0301 requires the accomplishment of paragraphs (1) through (6), this AD only requires the accomplishment of paragraphs (5) and (6).</P>
                    <P>
                        (4) Paragraph (6) of EASA AD 2020-0027R1 specifies to report insulation check results (
                        <E T="03">e.g.,</E>
                         results of the detailed inspection of the insulation resistance) to Airbus within a certain compliance time. For this AD, report inspection results at the applicable time specified in paragraph (h)(4)(i) or (ii) of this AD.
                    </P>
                    <P>(i) If the insulation check was done on or after the effective date of this AD: Submit the report within 30 days after the insulation check.</P>
                    <P>(ii) If the insulation check was done before the effective date of this AD: Submit the report within 30 days after the effective date of this AD.</P>
                    <P>(5) EASA AD 2020-0027R1 includes a definition for “affected EHA” that specifies “as listed by serial number in the applicable SB.” All serial numbers listed in the “applicable SB” are included in the definition of “affected EHA” regardless of the associated part numbers that are also listed in the “applicable SB.”</P>
                    <P>(6) For any service information referenced in EASA AD EASA AD 2019-0301 that specifies to return parts to the manufacturer, that action is not required by this AD.</P>
                    <HD SOURCE="HD1">(i) Other FAA AD Provisions</HD>
                    <P>The following provisions also apply to this AD:</P>
                    <P>
                        (1) 
                        <E T="03">Alternative Methods of Compliance (AMOCs):</E>
                         The Manager, Large Aircraft Section, International Validation Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 39.19, send your request to your principal inspector or local Flight Standards District Office, as appropriate. If sending information directly to the
                        <E T="03"/>
                         International Section, send it to the attention of the person 
                        <PRTPAGE P="25348"/>
                        identified in paragraph (j)(2) of this AD. Information may be emailed to: 
                        <E T="03">9-ANM-116-AMOC-REQUESTS@faa.gov.</E>
                    </P>
                    <P>(i) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the local flight standards district office/certificate holding district office.</P>
                    <P>(ii) AMOCs approved previously for AD 2018-17-05, Amendment 39-19359 (83 FR 40438, August 15, 2018), are approved as AMOCs for the corresponding provisions of EASA AD 2020-0027 R1 that are required by paragraph (g) of this AD.</P>
                    <P>
                        (2) 
                        <E T="03">Contacting the Manufacturer:</E>
                         For any requirement in this AD to obtain instructions from a manufacturer, the instructions must be accomplished using a method approved by the Manager, Large Aircraft Section, International Validation Branch, FAA; or EASA; or Airbus SAS's EASA Design Organization Approval (DOA). If approved by the DOA, the approval must include the DOA-authorized signature.
                    </P>
                    <P>
                        (3) 
                        <E T="03">Required for Compliance (RC):</E>
                         For any service information referenced in EASA AD 2020-0027R1 and paragraphs (5) and (6) of EASA AD 2019-0301 that contains RC procedures and tests: Except as required by paragraph (i)(2) of this AD, RC procedures and tests must be done to comply with this AD; any procedures or tests that are not identified as RC are recommended. Those procedures and tests that are not identified as RC may be deviated from using accepted methods in accordance with the operator's maintenance or inspection program without obtaining approval of an AMOC, provided the procedures and tests identified as RC can be done and the airplane can be put back in an airworthy condition. Any substitutions or changes to procedures or tests identified as RC require approval of an AMOC.
                    </P>
                    <P>
                        (4) 
                        <E T="03">Paperwork Reduction Act Burden Statement:</E>
                         A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to a penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a current valid OMB Control Number. The OMB Control Number for this information collection is 2120-0056. Public reporting for this collection of information is estimated to be approximately 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. All responses to this collection of information are mandatory as required by this AD; the nature and extent of confidentiality to be provided, if any. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.
                    </P>
                    <HD SOURCE="HD1">(j) Related Information</HD>
                    <P>
                        (1) For information about EASA AD 2020-0027R1 and EASA AD 2019-0301, contact the EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; telephone +49 221 89990 6017; email 
                        <E T="03">ADs@easa.europa.eu;</E>
                         internet 
                        <E T="03">www.easa.europa.eu.</E>
                         You may find this EASA AD on the EASA website at 
                        <E T="03">https://ad.easa.europa.eu.</E>
                         You may view this material at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195. This material may be found in the AD docket on the internet at 
                        <E T="03">https://www.regulations.gov</E>
                         by searching for and locating Docket No. FAA-2020-0343.
                    </P>
                    <P>
                        (2) For more information about this AD, contact Kathleen Arrigotti, Aerospace Engineer, Large Aircraft Section, International Validation Branch, FAA, 2200 South 216th St., Des Moines, WA 98198; telephone and fax 206-231-3218; 
                        <E T="03">Kathleen.Arrigotti@faa.gov.</E>
                    </P>
                </EXTRACT>
                <SIG>
                    <DATED>Issued on April 23, 2020.</DATED>
                    <NAME>Lance T. Gant,</NAME>
                    <TITLE>Director, Compliance &amp; Airworthiness Division, Aircraft Certification Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09140 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 39</CFR>
                <DEPDOC>[Docket No. FAA-2019-0705; Product Identifier 2019-NM-098-AD]</DEPDOC>
                <RIN>RIN 2120-AA64</RIN>
                <SUBJECT>Airworthiness Directives; The Boeing Company Airplanes</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Supplemental notice of proposed rulemaking (SNPRM); reopening of comment period.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FAA is revising an earlier proposal for certain The Boeing Company Model 737-600, -700, -700C, -800, and -900 series airplanes. This action revises the notice of proposed rulemaking (NPRM) by revising certain inspections to provide the correct thickness callouts for the fuselage skin and bear strap. The FAA is proposing this airworthiness directive (AD) to address the unsafe condition on these products. Since these actions would impose an additional burden over that in the NPRM, the FAA is reopening the comment period to allow the public the chance to comment on these changes.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        The comment period for the NPRM published in the 
                        <E T="04">Federal Register</E>
                         on October 1, 2019 (84 FR 52047), is reopened.
                    </P>
                    <P>The FAA must receive comments on this SNPRM by June 15, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         202-493-2251.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590, between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        For service information identified in this SNPRM, contact Boeing Commercial Airplanes, Attention: Contractual &amp; Data Services (C&amp;DS), 2600 Westminster Blvd., MC 110-SK57, Seal Beach, CA 90740-5600; phone: 562-797-1717; internet: 
                        <E T="03">https://www.myboeingfleet.com.</E>
                         You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195. It is also available on the internet at 
                        <E T="03">https://www.regulations.gov</E>
                         by searching for and locating Docket No. FAA-2019-0705.
                    </P>
                </ADD>
                <HD SOURCE="HD1">Examining the AD Docket</HD>
                <P>
                    You may examine the AD docket on the internet at 
                    <E T="03">https://www.regulations.gov</E>
                     by searching for and locating Docket No. FAA-2019-0705; or in person at Docket Operations between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. The AD docket contains this SNPRM, the regulatory evaluation, any comments received, and other information. The street address for Docket Operations is listed above. Comments will be available in the AD docket shortly after receipt.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Michael Bumbaugh, Aerospace Engineer, Airframe Section, FAA, Seattle ACO Branch, 2200 South 216th St., Des Moines, WA 98198; phone and fax: 206-231-3522; email: 
                        <E T="03">michael.bumbaugh@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>
                    The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed 
                    <PRTPAGE P="25349"/>
                    under the 
                    <E T="02">ADDRESSES</E>
                     section. Include “Docket No. FAA-2019-0705; Product Identifier 2019-NM-098-AD” at the beginning of your comments. The FAA specifically invites comments on the overall regulatory, economic, environmental, and energy aspects of this SNPRM. The FAA will consider all comments received by the closing date and may amend this SNPRM because of those comments.
                </P>
                <P>
                    The FAA will post all comments, without change, to 
                    <E T="03">https://www.regulations.gov,</E>
                     including any personal information you provide. The FAA will also post a report summarizing each substantive verbal contact received about this SNPRM.
                </P>
                <HD SOURCE="HD1">Discussion</HD>
                <P>
                    The FAA issued an NPRM to amend 14 CFR part 39 by adding an AD that would apply to certain The Boeing Company Model 737-600, -700, -700C, -800, and -900 series airplanes. The NPRM published in the 
                    <E T="04">Federal Register</E>
                     on October 1, 2019 (84 FR 52047). The NPRM was prompted by reports of cracks in the bear strap between certain stations, sometimes common to fasteners in the gap cover and emanating from rough sanding marks found on the surface of the bear strap. The NPRM proposed to require inspections of the fuselage skin and bear strap at the forward galley door between certain stations for cracks, and applicable on-condition actions.
                </P>
                <HD SOURCE="HD1">Actions Since the NPRM Was Issued</HD>
                <P>Since the FAA issued the NPRM, the FAA has determined that, for certain inspections specified in the proposed AD, certain thickness callouts for the fuselage skin and bear strap were incorrect. Therefore, the FAA has determined the correct thickness callouts must be included in those inspections.</P>
                <HD SOURCE="HD1">Comments</HD>
                <P>The FAA gave the public the opportunity to comment on the NPRM. The following presents the comments received on the NPRM and the FAA's response to each comment.</P>
                <HD SOURCE="HD1">Effect of Winglets on Accomplishment of the Proposed Actions</HD>
                <P>Aviation Partners Boeing stated that accomplishing Supplemental Type Certificate (STC) ST00830SE does not affect the actions specified in the proposed AD.</P>
                <P>The FAA concurs with the commenter. The FAA has redesignated paragraph (c) of the proposed AD as paragraph (c)(1) of this AD and added paragraph (c)(2) to this AD to state that installation of STC ST00830SE does not affect the ability to accomplish the actions required by this AD. Therefore, for airplanes on which STC ST00830SE is installed, a “change in product” alternative method of compliance (AMOC) approval request is not necessary to comply with the requirements of 14 CFR 39.17.</P>
                <HD SOURCE="HD1">Request To Include Updated Service Information</HD>
                <P>Boeing requested that the FAA revise the NPRM to include a later revision of the service information. Boeing pointed out that the skin and bear strap thicknesses referenced in Boeing Alert Requirements Bulletin 737-53A1383 RB, dated May 9, 2019, were incorrectly specified as 0.0710 inches and 0.10 inches respectively, which affects the proper calibration of the inspection probe. Boeing stated that the correct skin and bear strap thicknesses should be 0.100 inches and 0.090 inches respectively. Boeing also mentioned that a new revision to the service information that corrects the skin and bear strap thicknesses was being coordinated with the FAA.</P>
                <P>The FAA agrees for the reasons provided. Therefore, the FAA has included Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, as the appropriate source of service information for doing the actions specified in this SNPRM. Additionally, the FAA has also included paragraph (i) of this SNPRM to allow credit for actions accomplished before the effective date of this AD, using Boeing Alert Requirements Bulletin 737-53A1383 RB, dated May 9, 2019, provided that for airplanes on which Option 2, Condition 4, has been done (no external repair and have done the external low frequency eddy current (LFEC) inspection of the forward galley door bear strap and external high frequency eddy current (HFEC) inspection of the fuselage skin for any crack), operators also do the external LFEC inspection of the forward galley door bear strap and external HFEC inspection of the fuselage skin for any crack identified in accordance with Figure 4 of the Accomplishment Instructions of Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, and do all applicable on-condition actions.</P>
                <HD SOURCE="HD1">Request for Credit for Actions Accomplished Prior to the Effective Date</HD>
                <P>Alaska Airlines (AAL), United Airlines (UAL), and Delta Air Lines (DAL) requested that the FAA provide credit for accomplishing the actions specified in paragraph (g) of the proposed AD prior to the effective date of this AD in accordance with Boeing Alert Requirements Bulletin 737-53A1383 RB, dated May 9, 2019 (which was referred to as the appropriate source of information for doing the actions required by paragraph (g) of the proposed AD).</P>
                <P>The FAA acknowledges the commenter's requests and agrees to clarify. As previously stated, the FAA has included Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, as the appropriate source of service information for doing the actions specified in this SNPRM. The FAA has also included paragraph (i) of this SNPRM to allow credit for actions accomplished before the effective date of this SNPRM, using Boeing Alert Requirements Bulletin 737-53A1383 RB, dated May 9, 2019, provided, for certain airplanes, that certain actions are done.</P>
                <HD SOURCE="HD1">Request To Exclude a Certain Inspection of Certain Repaired Areas</HD>
                <P>DAL requested that the proposed AD be revised to exclude an internal surface HFEC inspection in areas that were repaired if the repair met certain conditions. DAL noted that the design approval holder has specifically recommended that the surface HFEC inspection not be required if certain repairs have been accomplished, however, those repairs must have been installed after the original issue date of Boeing Alert Requirements Bulletin 737-53A1383 RB and must have been approved by The Boeing Company Organization Designation Authorization (ODA) via FAA Form 8100-9. DAL asked that such repairs be approved as AMOCs, regardless of when the repair was installed.</P>
                <P>
                    The FAA agrees to clarify. Paragraph (h)(1) of this AD allows using the notes and flag notes in Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, as written. This means that, for actions done “after the original issue date of Boeing Alert Requirements Bulletin 737-53A1383 RB” operators are not required to do the internal surface HFEC in areas where the repair covers the affected inspection zone, provided the repair meets the conditions specified in Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020. Operators do not need to obtain an AMOC to use this provision, provided the repair meets the conditions specified in Boeing Alert 
                    <PRTPAGE P="25350"/>
                    Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020.
                </P>
                <P>However, the FAA notes that this provision does not extend to repairs that were done before the original issue date of Boeing Alert Requirements Bulletin 737-53A1383 RB. Under the provisions of paragraph (i) of this AD, the FAA will consider requests for approval of repairs in this area that affect compliance with this AD and were done before the original issue date of Boeing Alert Requirements Bulletin 737-53A1383 RB if sufficient data are submitted to substantiate that the repair would provide an acceptable level of safety. The FAA has not changed this SNPRM regarding this issue.</P>
                <HD SOURCE="HD1">Request for AMOC for Repairs Accomplished Before Service Information Publication</HD>
                <P>Southwest Airlines (SWA) requested that the FAA include previously accomplished repairs for the crack condition identified in Boeing Alert Requirements Bulletin 737-53A1383 RB as an approved AMOC, including repairs accomplished before the original issue date of Boeing Alert Requirements Bulletin 737-53A1383 RB. SWA mentioned that its fleet has repaired many crack conditions common to the inspection area specified in Boeing Alert Requirements Bulletin 737-53A1383 RB, and that most of those repairs were accomplished before Boeing Alert Requirements Bulletin 737-53A1383 RB, was released. SWA also pointed out that those repairs were approved via FAA Form 8100-9.</P>
                <P>The FAA disagrees with the commenter's request. Note (b) to Tables 1 and 2 in Boeing Alert Requirements Bulletin 737-53A1383 RB is intended to address repairs that were designed as corrective actions to the unsafe condition addressed in the service information and this AD, are approved by The Boeing Company ODA, and include a follow-on inspection program. For this reason, the FAA allows FAA Form 8100-9 for approved repairs that meet all criteria specified in note (b) to Tables 1 and 2 in Boeing Alert Requirements Bulletin 737-53A1383 RB to be exempted from the inspections in those repaired areas, but does not allow just any FAA-approved repair to be exempted from these required inspections. However, under the provisions of paragraph (i) of this AD, the FAA will consider requests for approval of certain repairs in this area that affect compliance with this AD if sufficient data are submitted to substantiate that the repair would provide an acceptable level of safety. The FAA has not changed this SNPRM regarding this issue.</P>
                <HD SOURCE="HD1">Request To Clarify Acceptable Previous Repairs</HD>
                <P>Qantas Airways LTD (Qantas) requested that the FAA clarify whether certain blend repairs would require approval of a new FAA Form 8100-9, to reauthorize the existing repairs. Qantas pointed out that the criteria for the general visual inspection is “any repair.” Qantas also mentioned that a blend repair to a small depth may not be detectable with a general visual inspection (as specified in Boeing Alert Requirements Bulletin 737-53A1383 RB) because the area is shot or flap peened after blending.</P>
                <P>The FAA agrees to clarify. Boeing Alert Requirements Bulletin 737-53A1383 RB specifies certain repairs that do not require additional contact with The Boeing Company ODA or the FAA. Those certain repairs are specified in note (a) to Table 1 and notes (a) and (b) to Table 2 of Boeing Alert Requirements Bulletin 737-53A1383 RB as: Fuselage skin blend out within the 737-600 structural repair manual (SRM) 53-00-01, 737-700 SRM 53-00-01, 737-700CONV SRM 53-00-01, 737-700IGW (BBJ) SRM 53-00-01, 737-800 SRM 53-00-01, 737-800BCF SRM 53-00-01, or 737-900 SRM 53-00-01 allowable damage. Any existing repair that is not specified in that section would require additional contact with The Boeing Company ODA or the FAA. The FAA has not changed this SNPRM regarding this issue.</P>
                <HD SOURCE="HD1">Request To Clarify Exception to the Service Information</HD>
                <P>Qantas requested that the FAA clarify the intent of the exception to the service information specified in paragraph (h)(2) of the proposed AD. Qantas mentioned its perception that when Boeing Alert Requirements Bulletin 737-53A1383 RB, specifies that “It is not required to contact Boeing,” that the NPRM then requires the operator to contact The Boeing Company ODA.</P>
                <P>The FAA agrees to clarify. Boeing Alert Requirements Bulletin 737-53A1383 RB specifies certain conditions, where contact with Boeing is unnecessary. Whereas, the exception specified in paragraph (h)(2) of this SNPRM, states that if Boeing Alert Requirements Bulletin 737-53A1383 RB, specifies to contact Boeing for repair instructions or for alternative inspections, this SNPRM requires doing the repair, or doing the alternative inspections and applicable on-condition actions using a method approved as an AMOC. The exception in paragraph (h)(2) of this AD, therefore, does not affect the statements in Boeing Alert Requirements Bulletin 737-53A1383 RB, that specify “It is not required to contact Boeing.” The FAA has not changed this SNPRM regarding this issue.</P>
                <HD SOURCE="HD1">Request To Allow Alternate Inspection Procedure</HD>
                <P>Structural Monitoring Systems PLC (SMS) requested that the FAA allow the use of SMS comparative vacuum monitoring (CVM) structural monitoring sensors (and a CVM nondestructive testing procedure (NDT)) as an alternative to the HFEC inspections of the bear strap. SMS also requested that for the CVM NDT procedure, the FAA set a repetitive inspection frequency to 18,000 flight cycles to reduce the level of repair burden on the operator when a crack is discovered. SMS also requested that the CVM structural monitoring sensors be used to periodically monitor any crack propagation, using damage tolerant assessment data to determine the point of reaching the residual strength capability limit, noting that this is a similar practice to that used on engines. SMS stated that the structural monitoring sensors are less intrusive, require less time to access, and take less time to inspect, while providing an equal level of safety to the proposed HFEC inspection method. SMS further specified that a CVM NDT inspection method can be applied three times (or more) more frequently than the proposed HFEC inspection, while still being less time consuming, because there is no further disassembly/assembly after initial sensor installation. SMS then mentioned that it (SMS) would perform any specific evaluation or testing required by the FAA to demonstrate standard 90 percent probability of detection with 95 percent confidence for the application. SMS mentioned a recent FAA statement acknowledging “that an aircraft structure which is subject to damage tolerance assessment can be considered safe while continuing to operate with an existing [undetected] crack.” SMS specified the belief that the direct quote expresses a philosophy that is supportive of using the CVM structural monitoring sensors, and would allow operators to operate the aircraft until such time as the residual strength capability is reached, using an appropriate inspection interval.</P>
                <P>
                    The FAA disagrees with the request to mandate CVM structural monitoring sensors, a repetitive CVM NDT procedure with an 18,000 flight cycle compliance time, and periodic 
                    <PRTPAGE P="25351"/>
                    monitoring of crack propagation. SMS did not provide sufficient substantiation to show the effectivity of CVM technology for this application. Therefore, the FAA cannot specify or allow that technology and inspection method as an alternative to those specified in this SNPRM. The FAA has not changed this SNPRM regarding this issue. Once the final rule is published, any person may request approval of an alternative method of compliance (AMOC) under the provisions of paragraph (j) of this AD.
                </P>
                <HD SOURCE="HD1">Related Service Information Under 1 CFR Part 51</HD>
                <P>
                    The FAA reviewed Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020. This service information describes procedures for inspecting for cracks of the fuselage skin and bear strap at the forward galley door between certain stations, through the use of two alternative inspection methods: (1) Internal and external general visual inspections and internal surface HFEC inspections, and (2) external general visual and external eddy current inspections, and applicable on-condition actions. On-condition actions include inspections for cracks, HFEC inspections for cracks, LFEC inspections for cracks, and repair, depending on the inspection method selected. This service information is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in the 
                    <E T="02">ADDRESSES</E>
                     section.
                </P>
                <HD SOURCE="HD1">FAA's Determination</HD>
                <P>The FAA is proposing this AD because the FAA evaluated all the relevant information and determined the unsafe condition described previously is likely to exist or develop in other products of the same type design. Certain revisions to the service information described above expand the scope of the NPRM. As a result, the FAA has determined that it is necessary to reopen the comment period to provide additional opportunity for the public to comment on this SNPRM.</P>
                <HD SOURCE="HD1">Proposed Requirements of This SNPRM</HD>
                <P>
                    This SNPRM would require accomplishing the actions specified in the service information described previously. This proposed AD would also allow credit for airplanes that have done Option 2, Condition 4, as specified in Boeing Alert Requirements Bulletin 737-53A1383 RB, dated May 9, 2019, provided that those airplanes do additional inspections. For information on the procedures and compliance times, see this service information at 
                    <E T="03">https://www.regulations.gov</E>
                     by searching for and locating Docket No. FAA-2019-0705.
                </P>
                <HD SOURCE="HD1">Costs of Compliance</HD>
                <P>The FAA estimates that this proposed AD affects 752 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s25,r50,12,r25,r25">
                    <TTITLE>Estimated Costs for Required Actions: Option 1</TTITLE>
                    <BOXHD>
                        <CHED H="1">Action</CHED>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">
                            Cost per
                            <LI>product</LI>
                        </CHED>
                        <CHED H="1">Cost on U.S. operators</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Internal general visual inspection</ENT>
                        <ENT>11 work-hours × $85 per hour = $935</ENT>
                        <ENT>$0</ENT>
                        <ENT>$935</ENT>
                        <ENT>$703,120.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">External general visual inspection</ENT>
                        <ENT>1 work-hour × $85 per hour = $85</ENT>
                        <ENT>0</ENT>
                        <ENT>85</ENT>
                        <ENT>63,920.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Internal Surface HFEC inspections</ENT>
                        <ENT>3 work-hours × $85 per hour = $255 per inspection cycle</ENT>
                        <ENT>0</ENT>
                        <ENT>255 per inspection cycle</ENT>
                        <ENT>191,760 per inspection cycle.</ENT>
                    </ROW>
                </GPOTABLE>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s25,r50,12,r25,r25">
                    <TTITLE>Estimated Costs for Required Actions: Option 2</TTITLE>
                    <BOXHD>
                        <CHED H="1">Action</CHED>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">
                            Cost per
                            <LI>product</LI>
                        </CHED>
                        <CHED H="1">Cost on U.S. operators</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">External general visual inspection</ENT>
                        <ENT>1 work-hour × $85 per hour = $85</ENT>
                        <ENT>$0</ENT>
                        <ENT>$85</ENT>
                        <ENT>$63,920.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">External LFEC and HFEC inspections</ENT>
                        <ENT>18 work-hours × $85 per hour = $1,530 per inspection cycle</ENT>
                        <ENT>0</ENT>
                        <ENT>1,530 per inspection cycle</ENT>
                        <ENT>1,150,560 per inspection cycle.</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The FAA has received no definitive data that would enable the agency to provide cost estimates for the on-condition actions specified in this proposed AD.</P>
                <HD SOURCE="HD1">Authority for This Rulemaking</HD>
                <P>Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. “Subtitle VII: Aviation Programs” describes in more detail the scope of the Agency's authority.</P>
                <P>The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: “General requirements.” Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.</P>
                <HD SOURCE="HD1">Regulatory Findings</HD>
                <P>The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.</P>
                <P>For the reasons discussed above, I certify this proposed regulation:</P>
                <P>(1) Is not a “significant regulatory action” under Executive Order 12866,</P>
                <P>(2) Will not affect intrastate aviation in Alaska, and</P>
                <P>(3) Will not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.</P>
                <LSTSUB>
                    <PRTPAGE P="25352"/>
                    <HD SOURCE="HED">List of Subjects in 14 CFR Part 39</HD>
                    <P>Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Proposed Amendment</HD>
                <P>Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 39—AIRWORTHINESS DIRECTIVES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 39 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 39.13</SECTNO>
                    <SUBJECT> [Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>2. The FAA amends § 39.13 by adding the following new airworthiness directive (AD):</AMDPAR>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="04">The Boeing Company:</E>
                         Docket No. FAA-2019-0705; Product Identifier 2019-NM-098-AD.
                    </FP>
                    <HD SOURCE="HD1">(a) Comments Due Date</HD>
                    <P>The FAA must receive comments by June 15, 2020.</P>
                    <HD SOURCE="HD1">(b) Affected ADs</HD>
                    <P>None.</P>
                    <HD SOURCE="HD1">(c) Applicability</HD>
                    <P>(1) This AD applies to The Boeing Company Model 737-600, -700, -700C, -800, and -900 series airplanes, certificated in any category, as identified in Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020.</P>
                    <P>(2) Installation of Supplemental Type Certificate (STC) ST00830SE does not affect the ability to accomplish the actions required by this AD. Therefore, for airplanes on which STC ST00830SE is installed, a “change in product” alternative method of compliance (AMOC) approval request is not necessary to comply with the requirements of 14 CFR 39.17.</P>
                    <HD SOURCE="HD1">(d) Subject</HD>
                    <P>Air Transport Association (ATA) of America Code 53, Fuselage.</P>
                    <HD SOURCE="HD1">(e) Unsafe Condition</HD>
                    <P>This AD was prompted by reports of cracks in the bear strap from station (STA) 290 to STA 296, and between S-8R and S-9R, sometimes common to fasteners in the gap cover and emanating from rough sanding marks found on the surface of the bear strap. The FAA is issuing this AD to address cracking of the bear strap, which could result in severing of the bear strap, possibly leading to uncontrolled decompression of the airplane and loss of structural integrity of the airplane.</P>
                    <HD SOURCE="HD1">(f) Compliance</HD>
                    <P>Comply with this AD within the compliance times specified, unless already done.</P>
                    <HD SOURCE="HD1">(g) Required Actions</HD>
                    <P>Except as specified by paragraph (h) of this AD: At the applicable times specified in the “Compliance” paragraph of Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, do all applicable actions identified in, and in accordance with, the Accomplishment Instructions of Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020.</P>
                    <NOTE>
                        <HD SOURCE="HED">Note 1 to paragraph (g):</HD>
                        <P> Guidance for accomplishing the actions required by this AD can be found in Boeing Alert Service Bulletin 737-53A1383, Revision 1, dated February 19, 2020, which is referred to in Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020.</P>
                    </NOTE>
                    <HD SOURCE="HD1">(h) Exceptions to Service Information Specifications</HD>
                    <P>(1) Where Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, uses the phrase “the original issue date of Requirements Bulletin 737-53A1383 RB,” this AD requires using “the effective date of this AD,” except where Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, uses the phrase “the original issue date of Requirements Bulletin 737-53A1383 RB” in a note or flag note.</P>
                    <P>(2) Where Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, specifies contacting Boeing for repair instructions or for alternative inspections: This AD requires doing the repair, or doing the alternative inspections and applicable on-condition actions, using a method approved in accordance with the procedures specified in paragraph (j) of this AD.</P>
                    <HD SOURCE="HD1">(i) Credit for Previous Actions</HD>
                    <P>This paragraph provides credit for the actions specified in paragraph (g) of this AD, if those actions were performed before the effective date of this AD, using Boeing Alert Requirements Bulletin 737-53A1383 RB, dated May 9, 2019, except for airplanes on which Option 2, Condition 4 has been done. For airplanes on which Option 2, Condition 4, has been done, credit is given provided operators do the external low frequency eddy current (LFEC) inspection of the forward galley door bear strap and external high frequency eddy current (HFEC) inspection of the fuselage skin for any crack in accordance with Figure 4 of the Accomplishment Instructions of Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020. The compliance time for accomplishing these actions is at the later of the time specified in paragraphs (i)(1) and (2) of this AD. Do all applicable on-condition actions identified in, and in accordance with, the Accomplishment Instructions of Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020, at the applicable times specified in the “Compliance” paragraph of Boeing Alert Requirements Bulletin 737-53A1383 RB, Revision 1, dated February 19, 2020.</P>
                    <P>(1) Before 15,000 total flight cycles.</P>
                    <P>(2) Within 6,000 flight cycles after the effective date of this AD.</P>
                    <HD SOURCE="HD1">(j) Alternative Methods of Compliance (AMOCs)</HD>
                    <P>
                        (1) The Manager, Seattle ACO Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 39.19, send your request to your principal inspector or local Flight Standards District Office, as appropriate. If sending information directly to the manager of the certification office, send it to the attention of the person identified in paragraph (k)(1) of this AD. Information may be emailed to: 
                        <E T="03">9-ANM-Seattle-ACO-AMOC-Requests@faa.gov.</E>
                    </P>
                    <P>(2) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the local flight standards district office/certificate holding district office.</P>
                    <P>(3) An AMOC that provides an acceptable level of safety may be used for any repair, modification, or alteration required by this AD if it is approved by The Boeing Company Organization Designation Authorization (ODA) that has been authorized by the Manager, Seattle ACO Branch, FAA to make those findings. To be approved, the repair method, modification deviation, or alteration deviation must meet the certification basis of the airplane, and the approval must specifically refer to this AD.</P>
                    <HD SOURCE="HD1">(k) Related Information</HD>
                    <P>
                        (1) For more information about this AD, contact Michael Bumbaugh, Aerospace Engineer, Airframe Section, FAA, Seattle ACO Branch, 2200 South 216th St., Des Moines, WA 98198; phone and fax: 206-231-3522; email: 
                        <E T="03">michael.bumbaugh@faa.gov.</E>
                    </P>
                    <P>
                        (2) For service information identified in this AD, contact Boeing Commercial Airplanes, Attention: Contractual &amp; Data Services (C&amp;DS), 2600 Westminster Blvd., MC 110-SK57, Seal Beach, CA 90740-5600; phone: 562-797-1717; internet: 
                        <E T="03">https://www.myboeingfleet.com.</E>
                         You may view this referenced service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
                    </P>
                </EXTRACT>
                <SIG>
                    <DATED>Issued on April 20, 2020.</DATED>
                    <NAME>Gaetano A. Sciortino,</NAME>
                    <TITLE>Deputy Director for Strategic Initiatives, Compliance &amp; Airworthiness Division, Aircraft Certification Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09114 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <PRTPAGE P="25353"/>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 39</CFR>
                <DEPDOC>[Docket No. FAA-2020-0345; Product Identifier 2019-NM-154-AD]</DEPDOC>
                <RIN>RIN 2120-AA64</RIN>
                <SUBJECT>Airworthiness Directives; AVOX System Inc. (formerly Scott Aviation) Oxygen Cylinder and Valve Assemblies; and Oxygen Valve Assemblies</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking (NPRM).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FAA proposes to adopt a new airworthiness directive (AD) for certain AVOX System Inc. (formerly Scott Aviation) oxygen cylinder and valve assemblies; and oxygen valve assemblies; installed on but not limited to various transport airplanes. This proposed AD was prompted by reports of cylinder and valve assemblies having oxygen leakage from the valve assembly vent hole, caused by the absence of a guide that maintains appropriate spacing between certain parts. This proposed AD would require an inspection of the oxygen valve assemblies, and oxygen cylinder and valve assemblies, to determine the serial number of the valve, cylinder, and entire assembly. For assemblies and parts with certain serial numbers, this AD would require a detailed inspection for correct spacing of the gap between the bottom of the packing retainer and top of the valve body on the assemblies, and replacement of assemblies having unacceptable gaps. The FAA is proposing this AD to address the unsafe condition on these products.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The FAA must receive comments on this proposed AD by June 15, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         202-493-2251.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery:</E>
                         Deliver to Mail address above between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        For service information identified in this NPRM, contact AVOX Systems Inc., 225 Erie Street, Lancaster, NY 14086; telephone 716-683-5100; internet 
                        <E T="03">https://www.safran-aerosystems.com.</E>
                         You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
                    </P>
                </ADD>
                <HD SOURCE="HD1">Examining the AD Docket</HD>
                <P>
                    You may examine the AD docket on the internet at 
                    <E T="03">https://www.regulations.gov</E>
                     by searching for and locating Docket No. FAA-2020-0345; or in person at Docket Operations between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. The AD docket contains this NPRM, the regulatory evaluation, any comments received, and other information. The street address for Docket Operations is listed above. Comments will be available in the AD docket shortly after receipt.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Darren Gassetto, Aerospace Engineer, Mechanical Systems and Administrative Services Section, FAA, New York ACO Branch, 1600 Stewart Avenue, Suite 410, Westbury, NY 11590; telephone 516-228-7323; fax 516-794-5531; email 
                        <E T="03">9-avs-nyaco-cos@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>
                    The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under the 
                    <E T="02">ADDRESSES</E>
                     section. Include “Docket No. FAA-2020-0345; Product Identifier 2019-NM-154-AD” at the beginning of your comments. The FAA specifically invites comments on the overall regulatory, economic, environmental, and energy aspects of this NPRM. The FAA will consider all comments received by the closing date and may amend this NPRM because of those comments.
                </P>
                <P>
                    The FAA will post all comments, without change, to 
                    <E T="03">https://www.regulations.gov,</E>
                     including any personal information you provide. The FAA will also post a report summarizing each substantive verbal contact received about this NPRM.
                </P>
                <HD SOURCE="HD1">Discussion</HD>
                <P>The FAA has received reports of cylinder and valve assemblies having oxygen leakage from the valve assembly vent hole, caused by the absence of a guide that maintains appropriate spacing between certain parts. It was determined that this guide was not installed during manufacturing, resulting in the O-ring and backup ring not being sufficiently constrained with the valve assembly. This condition, if not addressed, could result in oxygen leakage from the cylinder, leading to decreased or insufficient oxygen supply during a depressurization event; and heating or flow friction, which could cause an ignition event in the valve assembly.</P>
                <HD SOURCE="HD1">Related Service Information Under 1 CFR Part 51</HD>
                <P>
                    The FAA reviewed AVOX Systems Inc., Alert Service Bulletins 10015804-35-01, Revision 02, dated October 16, 2019; 10015804-35-02, Revision 2, dated October 31, 2019; and 10015804-35-03, Revision 02, dated October 15, 2019. This service information describes procedures for an inspection to determine the serial number of the oxygen cylinder and valve assemblies; and the oxygen valve assemblies; a detailed inspection for correct spacing of the gap between the bottom of the packing retainer and top of the valve body on the assemblies. These documents are distinct since they apply to different assembly part numbers. This service information is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in the 
                    <E T="02">ADDRESSES</E>
                     section.
                </P>
                <HD SOURCE="HD1">FAA's Determination</HD>
                <P>The FAA is proposing this AD because the FAA evaluated all the relevant information and determined the unsafe condition described previously is likely to exist or develop in other products of the same type design.</P>
                <HD SOURCE="HD1">Proposed AD Requirements</HD>
                <P>This proposed AD would require an inspection of the oxygen valve assemblies, and oxygen cylinder and valve assemblies, to determine the serial number of the valve, cylinder, and entire assembly. For assemblies and parts with certain serial numbers, this AD would require a detailed inspection for correct spacing of the gap between the bottom of the packing retainer and top of the valve body on the assemblies, and replacement of assemblies having unacceptable gap (removing affected assemblies and installing serviceable assemblies). This proposed AD would also require reporting and the return of affected parts to the manufacturer.</P>
                <HD SOURCE="HD1">Clarification of Inspection Terminology</HD>
                <P>
                    In this proposed AD, the “visual inspection” specified in the AVOX Systems Inc., service bulletins is referred to as a “detailed inspection.” 
                    <PRTPAGE P="25354"/>
                    The FAA has included the definition for a detailed inspection in this proposed AD.
                </P>
                <HD SOURCE="HD1">Clarification of Inspection Requirements</HD>
                <P>AVOX Systems Inc., Alert Service Bulletins 10015804-35-01, Revision 02, dated October 16, 2019; 10015804-35-02, Revision 2, dated October 31, 2019; and 10015804-35-03, Revision 02, dated October 15, 2019, specify to inspect to determine the serial number of the oxygen cylinder and valve assemblies; and the oxygen valve assemblies. However, the valve and cylinder that are part of those assemblies must also be inspected, not just the assemblies themselves. Therefore, in this proposed AD, the FAA specifies to inspect the oxygen valve assemblies, and oxygen cylinder and valve assemblies, to determine the serial number of the valve, cylinder, and entire assembly.</P>
                <HD SOURCE="HD1">Costs of Compliance</HD>
                <P>The FAA estimates that this proposed AD affects up to 3,034 oxygen cylinder and valve assemblies; and oxygen valve assemblies; installed on various transport category airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s25,r50,xs54,12,12">
                    <TTITLE>Estimated Costs</TTITLE>
                    <BOXHD>
                        <CHED H="1">Action</CHED>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">
                            Cost per 
                            <LI>product</LI>
                        </CHED>
                        <CHED H="1">
                            Cost on U.S. 
                            <LI>operators</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Serial number inspection</ENT>
                        <ENT>1 work-hour × $85 per hour = $85</ENT>
                        <ENT>None</ENT>
                        <ENT>$85</ENT>
                        <ENT>$257,890</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Reporting</ENT>
                        <ENT>1 work-hour × $85 per hour = $85</ENT>
                        <ENT>$0</ENT>
                        <ENT>85</ENT>
                        <ENT>257,890</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The FAA estimates the following costs to do any necessary follow-on actions that would be required based on the results of the proposed inspection. The FAA has no way of determining the number of aircraft that might need these actions:</P>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s25,r50,r25,12">
                    <TTITLE>On-Condition Costs *</TTITLE>
                    <BOXHD>
                        <CHED H="1">Action</CHED>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">
                            Cost per 
                            <LI>product</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Detailed inspection</ENT>
                        <ENT>1 work-hour × $85 per hour = $85</ENT>
                        <ENT>None</ENT>
                        <ENT>$85</ENT>
                    </ROW>
                    <TNOTE>* The FAA has received no definitive data on the cost of on-condition replacements.</TNOTE>
                </GPOTABLE>
                <P>According to the manufacturer, some or all of the costs of this proposed AD may be covered under warranty, thereby reducing the cost impact on affected individuals. The FAA does not control warranty coverage for affected individuals. As a result, the FAA has included all known costs in our cost estimate.</P>
                <HD SOURCE="HD1">Paperwork Reduction Act</HD>
                <P>A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a current valid OMB control number. The control number for the collection of information required by this proposed AD is 2120-0056. The paperwork cost associated with this proposed AD has been detailed in the Costs of Compliance section of this document and includes time for reviewing instructions, as well as completing and reviewing the collection of information. Therefore, all reporting associated with this proposed AD is mandatory. Comments concerning the accuracy of this burden and suggestions for reducing the burden should be directed to Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.</P>
                <HD SOURCE="HD1">Authority for This Rulemaking</HD>
                <P>Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.</P>
                <P>The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: “General requirements.” Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.</P>
                <HD SOURCE="HD1">Regulatory Findings</HD>
                <P>The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.</P>
                <P>For the reasons discussed above, I certify this proposed regulation:</P>
                <P>(1) Is not a “significant regulatory action” under Executive Order 12866,</P>
                <P>(2) Will not affect intrastate aviation in Alaska, and</P>
                <P>(3) Will not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 14 CFR Part 39</HD>
                    <P>Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Proposed Amendment</HD>
                <P>Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 39—AIRWORTHINESS DIRECTIVES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 39 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701.</P>
                </AUTH>
                <SECTION>
                    <PRTPAGE P="25355"/>
                    <SECTNO>§ 39.13</SECTNO>
                    <SUBJECT> [Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>2. The FAA amends § 39.13 by adding the following new airworthiness directive (AD):</AMDPAR>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="04">AVOX Systems Inc. (formerly Scott Aviation):</E>
                         Docket No. FAA-2020-0345; Product Identifier 2019-NM-154-AD.
                    </FP>
                    <HD SOURCE="HD1">(a) Comments Due Date</HD>
                    <P>The FAA must receive comments by June 15, 2020.</P>
                    <HD SOURCE="HD1">(b) Affected ADs</HD>
                    <P>None.</P>
                    <HD SOURCE="HD1">(c) Applicability</HD>
                    <P>This AD applies to AVOX Systems Inc. (formerly Scott Aviation) oxygen cylinder and valve assemblies having part number (P/N) 89794077, 89794015, 891511-14, 806835-01, 807982-01, or 808433-01; and oxygen valve assemblies (body and gage assemblies) having P/N 807206-01. These assemblies might be installed on, but not limited to, the aircraft identified in paragraphs (c)(1) through (12) of this AD, certificated in any category.</P>
                    <P>(1) Airbus SAS Model A300 B2-1A, B2-1C, B2K-3C, B2-203, B4-2C, B4-103, and B4-203 airplanes.</P>
                    <P>(2) Airbus SAS Model A300 B4-601, B4-603, B4-620, B4-622, B4-605R, B4-622R, F4-605R, F4-622R, and C4-605R Variant F airplanes.</P>
                    <P>(3) Airbus SAS Model A310-203, -204, -221, -222, -304, -322, -324, and -325 airplanes.</P>
                    <P>(4) Airbus SAS Model A318-111, -112, -121, and -122 airplanes.</P>
                    <P>(5) Airbus SAS Model A319-111, -112, -113, -114, -115, -131, -132, -133, and -151N airplanes.</P>
                    <P>(6) Airbus SAS Model A320-211, -212, -214, -216, -231, -232, -233, -251N, -252N, -253N, -271N, -272N, and -273N airplanes.</P>
                    <P>(7) Airbus SAS Model A321-111, -112, -131, -211, -212, -213, -231, -232, -251N, -252N, -253N, -271N, -272N, -251NX, -252NX, -253NX, -271NX, and -272NX airplanes.</P>
                    <P>(8) Airbus SAS Model A330-201, -202, -203, -223, -243, -301, -302, -303, -321, -322, -323, -341, -342, -343, and -941 airplanes.</P>
                    <P>(9) Airbus Model A340-211, -212, -213, -311, -312, -313, -541, and -642 airplanes.</P>
                    <P>(10) ATR—GIE Avions de Transport Régional Model ATR42-200, -300, -320, and -500 airplanes.</P>
                    <P>(11) ATR—GIE Avions de Transport Régional Model ATR72-101, -102, -201, -202, -211, -212, and -212A airplanes.</P>
                    <P>(12) The Boeing Company Model 747-8 series airplanes.</P>
                    <HD SOURCE="HD1">(d) Subject</HD>
                    <P>Air Transport Association (ATA) of America Code 35, Oxygen System.</P>
                    <HD SOURCE="HD1">(e) Unsafe Condition</HD>
                    <P>This AD was prompted by reports of cylinder and valve assemblies having oxygen leakage from the valve assembly vent hole, caused by the absence of a guide that maintains appropriate spacing between certain parts. The FAA is issuing this AD to address oxygen leakage from the cylinder, which could result in decreased or insufficient oxygen supply during a depressurization event; and heating or flow friction, which could cause an ignition event in the valve assembly.</P>
                    <HD SOURCE="HD1">(f) Compliance</HD>
                    <P>Comply with this AD within the compliance times specified, unless already done.</P>
                    <HD SOURCE="HD1">(g) Definition of Detailed Inspection</HD>
                    <P>For the purposes of this AD, a detailed inspection is an intensive examination of a specific item, installation, or assembly to detect damage, failure, or irregularity. Available lighting is normally supplemented with a direct source of good lighting at an intensity deemed appropriate. Inspection aids such as mirror, magnifying lenses, etc., may be necessary. Surface cleaning and elaborate procedures may be required.</P>
                    <HD SOURCE="HD1">(h) Identification of Affected Cylinder and Valve Assemblies</HD>
                    <P>Within 60 days after the effective date of this AD, inspect the oxygen valve assemblies, and oxygen cylinder and valve assemblies, to determine if the serial number of the valve, cylinder, and entire assembly, is listed in Appendix 1, “Affected Shipments,” of the applicable service information identified in paragraphs (h)(1) through (3) of this AD. A review of airplane maintenance records is acceptable in lieu of this inspection if the serial numbers can be conclusively determined from that review.</P>
                    <P>(1) AVOX Systems Inc., Alert Service Bulletin 10015804-35-01, Revision 02, dated October 16, 2019.</P>
                    <P>(2) AVOX Systems Inc., Alert Service Bulletin 10015804-35-02, Revision 2, dated October 31, 2019.</P>
                    <P>(3) AVOX Systems Inc., Alert Service Bulletin 10015804-35-03, Revision 02, dated October 15, 2019.</P>
                    <HD SOURCE="HD1">(i) Inspection of the Gap, Parts Marking Actions, and Replacement</HD>
                    <P>If, during any inspection or records review required by paragraph (h) of this AD, any oxygen valve assembly, valve or cylinder of an oxygen cylinder and valve assembly, or oxygen cylinder and valve assembly having an affected serial number is found: Before further flight, do a detailed inspection for correct spacing of the gap between the bottom of the packing retainer and top of the valve body, in accordance with paragraph 3.C. of the Accomplishment Instructions of the applicable service information identified in paragraphs (h)(1) through (3) of this AD.</P>
                    <P>(1) If the gap is found to be acceptable, before further flight, do the parts marking actions in accordance with paragraph 3.D.(1) of the Accomplishment Instructions of the applicable service information identified in paragraph (h)(1) through (3) of this AD.</P>
                    <P>(2) If the gap is found to be unacceptable, as defined in the applicable service information identified in paragraphs (h)(1) through (3) of this AD, before further flight, remove the affected assembly, in accordance with paragraphs 3.D.(2) or 3.D.(3), as applicable, of the Accomplishment Instructions of the applicable service information identified in paragraphs (h)(1) through (3) of this AD; and replace with a serviceable assembly.</P>
                    <HD SOURCE="HD1">(j) Reporting and Return of Parts</HD>
                    <P>(1) Report the results of the inspection required by paragraph (i) of this AD within the applicable time specified in paragraph (j)(1)(i) or (ii) of this AD. Report the results in accordance with the paragraph 3.D.(1)(a), of the Accomplishment instructions of the applicable service information identified in paragraphs (h)(1) through (3) of this AD.</P>
                    <P>(i) If the inspection was done on or after the effective date of this AD: Submit the report within 30 days after the inspection.</P>
                    <P>(ii) If the inspection was done before the effective date of this AD: Submit the report within 30 days after the effective date of this AD.</P>
                    <P>(2) If, during an inspection required by paragraph (i) of this AD, any gap is found to be unacceptable, within the applicable time specified in paragraph (j)(2)(i) or (ii) of this AD, return the assembly to the manufacturer in accordance with paragraph 3.D.(2) or 3.D.(3), as applicable, of the Accomplishment Instructions of the applicable service information identified in paragraphs (h)(1) through (3) of this AD.</P>
                    <P>(i) If the inspection was done on or after the effective date of this AD: Return the assembly within 30 days after the inspection.</P>
                    <P>(ii) If the inspection was done before the effective date of this AD: Return the assembly within 30 days after the effective date of this AD.</P>
                    <HD SOURCE="HD1">(k) Parts Installation Limitation</HD>
                    <P>As of the effective date of this AD, no AVOX Systems Inc., oxygen valve assembly, or valve or cylinder that is part of an oxygen cylinder and valve assembly, or oxygen cylinder and valve assembly having an affected serial number identified in Appendix 1, “Affected Shipments,” of any AVOX Systems Inc., service information identified in paragraphs (h)(1) through (3) of this AD, may be installed on any airplane unless the requirements of paragraph (i) of this AD have been accomplished on that affected assembly.</P>
                    <HD SOURCE="HD1">(l) Credit for Previous Actions</HD>
                    <P>This paragraph provides credit for the actions specified in paragraphs (h) or (i) of this AD, if those actions were performed before the effective date of this AD using the service information specified in paragraphs (l)(1) through (5) of this AD.</P>
                    <P>(1) AVOX Systems Inc., Service Bulletin 10015804-35-01, dated March 6, 2019.</P>
                    <P>(2) AVOX Systems Inc., Alert Service Bulletin 10015804-35-01, Revision 01, dated July 9, 2019.</P>
                    <P>(3) AVOX Systems Inc., Alert Service Bulletin 10015804-35-02, Revision 1, dated September 4, 2019.</P>
                    <P>(4) AVOX Systems Inc., Service Bulletin 10015804-35-03, dated April 11, 2019.</P>
                    <P>
                        (5) AVOX Systems Inc., Alert Service Bulletin 10015804-35-03, Revision 1, dated May 21, 2019.
                        <PRTPAGE P="25356"/>
                    </P>
                    <HD SOURCE="HD1">(m) Paperwork Reduction Act Burden Statement</HD>
                    <P>A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to a penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a current valid OMB Control Number. The OMB Control Number for this information collection is 2120-0056. Public reporting for this collection of information is estimated to be approximately 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. All responses to this collection of information are mandatory as required by this AD; the nature and extent of confidentiality to be provided, if any. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.</P>
                    <HD SOURCE="HD1">(n) Alternative Methods of Compliance (AMOCs)</HD>
                    <P>(1) The Manager, New York ACO Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 39.19, send your request to your principal inspector or local Flight Standards District Office, as appropriate. If sending information directly to the manager of the certification office, send it to ATTN: Program Manager, Continuing Operational Safety, FAA, New York ACO Branch, 1600 Stewart Avenue, Suite 410, Westbury, NY 11590; telephone 516-228-7300; fax 516-794-5531.</P>
                    <P>(2) Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the local flight standards district office/certificate holding district office.</P>
                    <HD SOURCE="HD1">(o) Related Information</HD>
                    <P>
                        (1) For more information about this AD, contact Darren Gassetto, Aerospace Engineer, Mechanical Systems and Administrative Services Section, FAA, New York ACO Branch, 1600 Stewart Avenue, Suite 410, Westbury, NY 11590; telephone 516-228-7323; fax 516-794-5531; email 
                        <E T="03">9-avs-nyaco-cos@faa.gov.</E>
                    </P>
                    <P>
                        (2) For service information identified in this AD, contact AVOX Systems Inc., 225 Erie Street, Lancaster, NY 14086; telephone 716-683-5100; internet 
                        <E T="03">https://www.safran-aerosystems.com.</E>
                         You may view this service information at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195.
                    </P>
                </EXTRACT>
                <SIG>
                    <DATED>Issued on April 23, 2020.</DATED>
                    <NAME>Lance T. Gant,</NAME>
                    <TITLE>Director, Compliance &amp; Airworthiness Division, Aircraft Certification Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09115 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Aviation Administration</SUBAGY>
                <CFR>14 CFR Part 39</CFR>
                <DEPDOC>[Docket No. FAA-2020-0347; Product Identifier 2020-NM-042-AD]</DEPDOC>
                <RIN>RIN 2120-AA64</RIN>
                <SUBJECT>Airworthiness Directives; Airbus SAS Airplanes</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Aviation Administration (FAA), DOT.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of proposed rulemaking (NPRM).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FAA proposes to adopt a new airworthiness directive (AD) for certain Airbus SAS Model A300 F4-600R series airplanes. This proposed AD was prompted by a report of damaged main deck cargo crossbeams on the right-hand side, between certain frame locations. This proposed AD would require repetitive detailed inspections of the affected main deck cargo crossbeams for any damage, and depending on findings, accomplishment of applicable corrective actions, as specified in a European Union Aviation Safety Agency (EASA) AD, which will be incorporated by reference. This proposed AD would also provide optional terminating actions for the repetitive detailed inspections. The FAA is proposing this AD to address the unsafe condition on these products.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The FAA must receive comments on this proposed AD by June 15, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may send comments, using the procedures found in 14 CFR 11.43 and 11.45, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                         Go to 
                        <E T="03">https://www.regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Fax:</E>
                         202-493-2251.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         U.S. Department of Transportation, Docket Operations, M-30, West Building Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery:</E>
                         Deliver to Mail address above between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays.
                    </P>
                    <P>
                        For the material identified in this proposed AD that will be incorporated by reference (IBR), contact the EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; phone: +49 221 89990 1000; email: 
                        <E T="03">ADs@easa.europa.eu;</E>
                         internet: 
                        <E T="03">www.easa.europa.eu.</E>
                         You may find this IBR material on the EASA website at 
                        <E T="03">https://ad.easa.europa.eu.</E>
                         You may view this IBR material at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195. It is also available in the AD docket on the internet at 
                        <E T="03">https://www.regulations.gov</E>
                         by searching for and locating Docket No. FAA-2020-0347.
                    </P>
                </ADD>
                <HD SOURCE="HD1">Examining the AD Docket</HD>
                <P>
                    You may examine the AD docket on the internet at 
                    <E T="03">https://www.regulations.gov</E>
                     by searching for and locating Docket No. FAA-2020-0347; or in person at Docket Operations between 9 a.m. and 5 p.m., Monday through Friday, except Federal holidays. The AD docket contains this NPRM, the regulatory evaluation, any comments received, and other information. The street address for Docket Operations is listed above. Comments will be available in the AD docket shortly after receipt.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Dan Rodina, Aerospace Engineer, Large Aircraft Section, International Validation Branch, FAA, 2200 South 216th St., Des Moines, WA 98198; phone and fax: 206-231-3225; email: 
                        <E T="03">dan.rodina@faa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>
                    The FAA invites you to send any written relevant data, views, or arguments about this proposal. Send your comments to an address listed under the 
                    <E T="02">ADDRESSES</E>
                     section. Include “Docket No. FAA-2020-0347; Product Identifier 2020-NM-042-AD” at the beginning of your comments. The FAA specifically invites comments on the overall regulatory, economic, environmental, and energy aspects of this NPRM. The FAA will consider all comments received by the closing date and may amend this NPRM based on those comments.
                </P>
                <P>
                    The FAA will post all comments, without change, to 
                    <E T="03">https://www.regulations.gov,</E>
                     including any personal information you provide. The FAA will also post a report summarizing each substantive verbal contact received about this NPRM.
                    <PRTPAGE P="25357"/>
                </P>
                <HD SOURCE="HD1">Discussion</HD>
                <P>The EASA, which is the Technical Agent for the Member States of the European Union, has issued EASA AD 2020-0050, dated March 9, 2020; corrected March 11, 2020 (“EASA AD 2020-0050”) (also referred to as the Mandatory Continuing Airworthiness Information, or “the MCAI”), to correct an unsafe condition for certain Airbus SAS Model A300 F4-600R series airplanes.</P>
                <P>This proposed AD was prompted by a report of damaged main deck cargo crossbeams on the right-hand side, between certain frame locations. The FAA is proposing this AD to address damaged main deck cargo crossbeams, which could adversely affect the structural integrity of the airplane. See the MCAI for additional background information.</P>
                <HD SOURCE="HD1">Related IBR Material Under 1 CFR Part 51</HD>
                <P>EASA AD 2020-0050 describes procedures for repetitive detailed inspections of the affected main deck cargo crossbeams from frame (FR) 48 to FR54 for any damage (including bent, curved, and cracked crossbeams); corrective actions; and terminating actions. Corrective actions include detailed inspections of the right-hand and left-hand crossbeams and lugs for damage (including buckling and cracking) and correct diameter of the lug/crossbeam holes; repair; and replacement of damaged crossbeams. Optional terminating actions include replacement of crossbeams with reinforced machined crossbeams.</P>
                <P>
                    This material is reasonably available because the interested parties have access to it through their normal course of business or by the means identified in the 
                    <E T="02">ADDRESSES</E>
                     section.
                </P>
                <HD SOURCE="HD1">FAA's Determination and Requirements of This Proposed AD</HD>
                <P>This product has been approved by the aviation authority of another country, and is approved for operation in the United States. Pursuant to the FAA's bilateral agreement with the State of Design Authority, the FAA has been notified of the unsafe condition described in the MCAI referenced above. The FAA is proposing this AD because the FAA evaluated all the relevant information and determined the unsafe condition described previously is likely to exist or develop in other products of the same type design.</P>
                <HD SOURCE="HD1">Proposed AD Requirements</HD>
                <P>This proposed AD would require accomplishing the actions specified in EASA AD 2020-0050 described previously, as incorporated by reference, except for any differences identified as exceptions in the regulatory text of this AD. This proposed AD also would require sending the inspection results to Airbus SAS.</P>
                <HD SOURCE="HD1">Explanation of Required Compliance Information</HD>
                <P>
                    In the FAA's ongoing efforts to improve the efficiency of the AD process, the FAA initially worked with Airbus and EASA to develop a process to use certain EASA ADs as the primary source of information for compliance with requirements for corresponding FAA ADs. The FAA has since coordinated with other manufacturers and civil aviation authorities (CAAs) to use this process. As a result, EASA AD 2020-0050 will be incorporated by reference in the FAA final rule. This proposed AD would, therefore, require compliance with EASA AD 2020-0050 in its entirety, through that incorporation, except for any differences identified as exceptions in the regulatory text of this proposed AD. Using common terms that are the same as the heading of a particular section in the EASA AD does not mean that operators need comply only with that section. For example, where the AD requirement refers to “all required actions and compliance times,” compliance with this AD requirement is not limited to the section titled “Required Action(s) and Compliance Time(s)” in the EASA AD. Service information specified in EASA AD 2020-0050 that is required for compliance with EASA AD 2020-0050 will be available on the internet at 
                    <E T="03">https://www.regulations.gov</E>
                     by searching for and locating Docket No. FAA-2020-0347 after the FAA final rule is published.
                </P>
                <HD SOURCE="HD1">Costs of Compliance</HD>
                <P>The FAA estimates that this proposed AD affects 52 airplanes of U.S. registry. The FAA estimates the following costs to comply with this proposed AD:</P>
                <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s25,12,12,12">
                    <TTITLE>Estimated Costs for Required Actions</TTITLE>
                    <BOXHD>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">
                            Cost per 
                            <LI>product</LI>
                        </CHED>
                        <CHED H="1">
                            Cost on U.S. 
                            <LI>operators</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">6 work-hours × $85 per hour = $510</ENT>
                        <ENT>$0</ENT>
                        <ENT>$510</ENT>
                        <ENT>$26,520</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The FAA estimates that it would take about 1 work-hour per product to comply with the proposed reporting requirement in this proposed AD. The average labor rate is $85 per hour. Based on these figures, the FAA estimates the cost of reporting the inspection results on U.S. operators to be $4,420, or $85 per product.</P>
                <P>The FAA estimates the following costs to do any necessary on-condition repairs that would be required based on the results of any required actions. The FAA has no way of determining the number of aircraft that might need these on-condition actions:</P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s75,12,12">
                    <TTITLE>Estimated Costs of On-Condition Repairs</TTITLE>
                    <BOXHD>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">
                            Cost per 
                            <LI>product</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">6 work-hours × $85 per hour = $510</ENT>
                        <ENT>$10,000</ENT>
                        <ENT>$10,510</ENT>
                    </ROW>
                </GPOTABLE>
                <P>The FAA has received no definitive data that would enable the FAA to provide cost estimates for the on-condition inspections and replacements specified in this proposed AD.</P>
                <P>
                    The FAA estimates the following costs to do the optional terminating actions specified in this proposed AD.
                    <PRTPAGE P="25358"/>
                </P>
                <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s75,12,12">
                    <TTITLE>Estimated Costs for Optional Terminating Actions</TTITLE>
                    <BOXHD>
                        <CHED H="1">Labor cost</CHED>
                        <CHED H="1">Parts cost</CHED>
                        <CHED H="1">
                            Cost per 
                            <LI>product</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">18 work-hours × $85 per hour = $1,530</ENT>
                        <ENT>$10,000</ENT>
                        <ENT>$11,530</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Paperwork Reduction Act</HD>
                <P>A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a current valid OMB control number. The control number for the collection of information required by this proposed AD is 2120-0056. The paperwork cost associated with this proposed AD has been detailed in the Costs of Compliance section of this document and includes time for reviewing instructions, as well as completing and reviewing the collection of information. Therefore, all reporting associated with this proposed AD is mandatory. Comments concerning the accuracy of this burden and suggestions for reducing the burden should be directed to Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.</P>
                <HD SOURCE="HD1">Authority for This Rulemaking</HD>
                <P>Title 49 of the United States Code specifies the FAA's authority to issue rules on aviation safety. Subtitle I, section 106, describes the authority of the FAA Administrator. Subtitle VII: Aviation Programs, describes in more detail the scope of the Agency's authority.</P>
                <P>The FAA is issuing this rulemaking under the authority described in Subtitle VII, Part A, Subpart III, Section 44701: “General requirements.” Under that section, Congress charges the FAA with promoting safe flight of civil aircraft in air commerce by prescribing regulations for practices, methods, and procedures the Administrator finds necessary for safety in air commerce. This regulation is within the scope of that authority because it addresses an unsafe condition that is likely to exist or develop on products identified in this rulemaking action.</P>
                <HD SOURCE="HD1">Regulatory Findings</HD>
                <P>The FAA determined that this proposed AD would not have federalism implications under Executive Order 13132. This proposed AD would not have a substantial direct effect on the States, on the relationship between the national Government and the States, or on the distribution of power and responsibilities among the various levels of government.</P>
                <P>For the reasons discussed above, I certify this proposed regulation:</P>
                <P>(1) Is not a “significant regulatory action” under Executive Order 12866,</P>
                <P>(2) Will not affect intrastate aviation in Alaska, and</P>
                <P>(3) Will not have a significant economic impact, positive or negative, on a substantial number of small entities under the criteria of the Regulatory Flexibility Act.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 14 CFR Part 39</HD>
                    <P>Air transportation, Aircraft, Aviation safety, Incorporation by reference, Safety.</P>
                </LSTSUB>
                <HD SOURCE="HD1">The Proposed Amendment</HD>
                <P>Accordingly, under the authority delegated to me by the Administrator, the FAA proposes to amend 14 CFR part 39 as follows:</P>
                <PART>
                    <HD SOURCE="HED">PART 39—AIRWORTHINESS DIRECTIVES</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 39 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> 49 U.S.C. 106(g), 40113, 44701.</P>
                </AUTH>
                <SECTION>
                    <SECTNO>§ 39.13 </SECTNO>
                    <SUBJECT>[Amended]</SUBJECT>
                </SECTION>
                <AMDPAR>2. The FAA amends § 39.13 by adding the following new airworthiness directive (AD):</AMDPAR>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="04">Airbus SAS:</E>
                         Docket No. FAA-2020-0347; Product Identifier 2020-NM-042-AD.
                    </FP>
                    <HD SOURCE="HD1">(a) Comments Due Date</HD>
                    <P>The FAA must receive comments by June 15, 2020.</P>
                    <HD SOURCE="HD1">(b) Affected ADs</HD>
                    <P>None.</P>
                    <HD SOURCE="HD1">(c) Applicability</HD>
                    <P>This AD applies to Airbus SAS Model A300 F4-605R and F4-622R airplanes, certificated in any category, as identified in European Union Aviation Safety Agency (EASA) AD 2020-0050, dated March 9, 2020; corrected March 11, 2020 (“EASA AD 2020-0050”).</P>
                    <HD SOURCE="HD1">(d) Subject</HD>
                    <P>Air Transport Association (ATA) of America Code 53, Fuselage.</P>
                    <HD SOURCE="HD1">(e) Reason</HD>
                    <P>This AD was prompted by a report of damaged main deck cargo crossbeams on the right-hand side, between certain frame locations. The FAA is issuing this AD to address damaged main deck cargo crossbeams, which could adversely affect the structural integrity of the airplane.</P>
                    <HD SOURCE="HD1">(f) Compliance</HD>
                    <P>Comply with this AD within the compliance times specified, unless already done.</P>
                    <HD SOURCE="HD1">(g) Requirements</HD>
                    <P>Except as specified in paragraph (h) of this AD: Comply with all required actions and compliance times specified in, and in accordance with, EASA AD 2020-0050.</P>
                    <HD SOURCE="HD1">(h) Exceptions to EASA AD 2020-0050</HD>
                    <P>(1) Where EASA AD 2020-0050 refers to its effective date, this AD requires using the effective date of this AD.</P>
                    <P>(2) The “Remarks” section of EASA AD 2020-0050 does not apply to this AD.</P>
                    <P>(3) Paragraph (4) of EASA AD 2020-0050 specifies to report inspection results to Airbus within a certain compliance time. For this AD, report inspection results at the applicable time specified in paragraph (h)(3)(i) or (ii) of this AD.</P>
                    <P>(i) If the inspection was done on or after the effective date of this AD: Submit the report within 30 days after the inspection.</P>
                    <P>(ii) If the inspection was done before the effective date of this AD: Submit the report within 30 days after the effective date of this AD.</P>
                    <HD SOURCE="HD1">(i) Other FAA AD Provisions</HD>
                    <P>The following provisions also apply to this AD:</P>
                    <P>
                        (1) 
                        <E T="03">Alternative Methods of Compliance (AMOCs):</E>
                         The Manager, Large Aircraft Section, International Validation Branch, FAA, has the authority to approve AMOCs for this AD, if requested using the procedures found in 14 CFR 39.19. In accordance with 14 CFR 39.19, send your request to your principal inspector or local Flight Standards District Office, as appropriate. If sending information directly to the International Section, send it to the attention of the person identified in paragraph (j)(2) of this AD. Information may be emailed to: 
                        <E T="03">9-ANM-116-AMOC-REQUESTS@faa.gov.</E>
                         Before using any approved AMOC, notify your appropriate principal inspector, or lacking a principal inspector, the manager of the local flight standards district office/certificate holding district office.
                    </P>
                    <P>
                        (2) 
                        <E T="03">Contacting the Manufacturer:</E>
                         For any requirement in this AD to obtain instructions from a manufacturer, the instructions must be accomplished using a method approved by the Manager, Large Aircraft Section, International Validation Branch, FAA; or EASA; or Airbus SAS's EASA Design Organization Approval (DOA). If approved by 
                        <PRTPAGE P="25359"/>
                        the DOA, the approval must include the DOA-authorized signature.
                    </P>
                    <P>
                        (3) 
                        <E T="03">Required for Compliance (RC</E>
                        ): For any service information referenced in EASA AD 2020-0050 that contains RC procedures and tests: Except as required by paragraph (i)(2) of this AD, RC procedures and tests must be done to comply with this AD; any procedures or tests that are not identified as RC are recommended. Those procedures and tests that are not identified as RC may be deviated from using accepted methods in accordance with the operator's maintenance or inspection program without obtaining approval of an AMOC, provided the procedures and tests identified as RC can be done and the airplane can be put back in an airworthy condition. Any substitutions or changes to procedures or tests identified as RC require approval of an AMOC.
                    </P>
                    <P>
                        (4) 
                        <E T="03">Paperwork Reduction Act Burden Statement:</E>
                         A federal agency may not conduct or sponsor, and a person is not required to respond to, nor shall a person be subject to a penalty for failure to comply with a collection of information subject to the requirements of the Paperwork Reduction Act unless that collection of information displays a current valid OMB Control Number. The OMB Control Number for this information collection is 2120-0056. Public reporting for this collection of information is estimated to be approximately 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. All responses to this collection of information are mandatory as required by this AD; the nature and extent of confidentiality to be provided, if any. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to Information Collection Clearance Officer, Federal Aviation Administration, 10101 Hillwood Parkway, Fort Worth, TX 76177-1524.
                    </P>
                    <HD SOURCE="HD1">(j) Related Information</HD>
                    <P>
                        (1) For information about EASA AD 2020-0050, contact the EASA, Konrad-Adenauer-Ufer 3, 50668 Cologne, Germany; phone: +49 221 89990 6017; email: 
                        <E T="03">ADs@easa.europa.eu;</E>
                         internet: 
                        <E T="03">www.easa.europa.eu.</E>
                         You may find this EASA AD on the EASA website at 
                        <E T="03">https://ad.easa.europa.eu.</E>
                         You may view this material at the FAA, Airworthiness Products Section, Operational Safety Branch, 2200 South 216th St., Des Moines, WA. For information on the availability of this material at the FAA, call 206-231-3195. This material may be found in the AD docket on the internet at 
                        <E T="03">https://www.regulations.gov</E>
                         by searching for and locating Docket No. FAA-2020-0347.
                    </P>
                    <P>
                        (2) For more information about this AD, contact Dan Rodina, Aerospace Engineer, Large Aircraft Section, International Validation Branch, FAA, 2200 South 216th St., Des Moines, WA 98198; phone and fax: 206-231-3225; email: 
                        <E T="03">dan.rodina@faa.gov.</E>
                    </P>
                </EXTRACT>
                <SIG>
                    <DATED>Issued on April 23, 2020.</DATED>
                    <NAME>Gaetano A. Sciortino,</NAME>
                    <TITLE>Deputy Director for Strategic Initiatives, Compliance &amp; Airworthiness Division, Aircraft Certification Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09139 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 4910-13-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <CFR>15 CFR Part 922</CFR>
                <DEPDOC>[Docket No. 200330-0093]</DEPDOC>
                <RIN>RIN 0648-BA21</RIN>
                <SUBJECT>Proposed Expansion of Flower Garden Banks National Marine Sanctuary</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of National Marine Sanctuaries (ONMS), National Ocean Service (NOS), National Oceanic and Atmospheric Administration (NOAA), Department of Commerce (DOC).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule; request for public comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The National Oceanic and Atmospheric Administration (NOAA) proposes to expand the boundaries of Flower Garden Banks National Marine Sanctuary (FGBNMS) and revise the sanctuary's terms of designation. The purpose of this action is to expand the sanctuary to include portions of 14 additional reefs and banks in the northwestern Gulf of Mexico, representing a 104 square mile increase in area. The existing FGBNMS regulations would be applied to the expanded locations. NOAA is soliciting public comment on the proposed rule.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>NOAA will consider all comments received by July 3, 2020. Flower Garden Banks National Marine Sanctuary will hold three virtual public hearings on the following dates and times: June 8, 2020 1:00 p.m.—3:00 p.m. CDT and 6:00 p.m.—8:00 p.m. CDT and June 11, 2020 6:00 p.m.—8:00 p.m. CDT.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments on this document, identified by NOAA-NOS-2019-0033, by:</P>
                    <P>
                        • Electronic Submission: Submit all electronic public comments via the Federal e-Rulemaking Portal. Go to 
                        <E T="03">http://www.regulations.gov/#!docketDetail;D=NOAA-NOS-2019-0033,</E>
                         click the “Comment Now!” icon, complete the required fields, and enter or attach your comments.
                    </P>
                    <P>• Written comments may also be mailed to: George P. Schmahl, Superintendent, Flower Garden Banks National Marine Sanctuary, 4700 Avenue U, Building 216, Galveston, Texas 77551.</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 NOAA. All comments received are part of the public record and will generally be posted for public viewing on 
                        <E T="03">www.regulations.gov</E>
                         without change. All personal identifying information (
                        <E T="03">e.g.,</E>
                         name, address), confidential business information, or otherwise sensitive information submitted voluntarily by the sender will be publicly accessible. NOAA will accept anonymous comments (enter “N/A” in the required fields if you wish to remain anonymous).
                    </P>
                    <P>To participate in the public hearings, online registration is requested in advance via the following links. If you are unable to participate online, you can also connect to the public hearings using the phone numbers provided below.</P>
                </ADD>
                <FP SOURCE="FP-2">(1) June 8, 2020, 1:00 p.m.—3:00 p.m. CDT</FP>
                <P>
                    <E T="03">Registration: https://attendee.gotowebinar.com/register/9162740973626770700</E>
                </P>
                <P>
                    <E T="03">Phone:</E>
                     +1 (213) 929-4232 PIN: 704-409-034
                </P>
                <FP SOURCE="FP-2">(2) June 8, 2020, 6:00 p.m.—8:00 p.m. CDT</FP>
                <P>
                    <E T="03">Registration: https://attendee.gotowebinar.com/register/1668176149101021196</E>
                </P>
                <P>
                    <E T="03">Phone:</E>
                     +1 (213) 929-4232 PIN: 682-728-246
                </P>
                <FP SOURCE="FP-2">(3) June 11, 2020, 6:00 p.m.—8:00 p.m. CDT</FP>
                <P>
                    <E T="03">Registration: https://attendee.gotowebinar.com/register/5569362151706075916</E>
                </P>
                <P>
                    <E T="03">Phone:</E>
                     +1 (415) 655-0052 PIN: 486-551-096
                </P>
                <P>If you would like to provide comment during the hearings, please sign up in advance. Select “yes” during the online registration. The line-up of speakers will be based on your date and time of registration.</P>
                <P>
                    If you will be participating by phone, please send an email to 
                    <E T="03">fgbexpansion@noaa.gov</E>
                     to add your name to the speaker list.
                </P>
                <P>
                    For more details on the public hearings, please visit 
                    <E T="03">https://flowergarden.noaa.gov/management/expansionnpr.html.</E>
                </P>
                <P>
                    Copies of the proposed rule, the DEIS, maps of the proposed expansion areas, and additional background materials can be found on the FGBNMS website at 
                    <E T="03">https://flowergarden.noaa.gov/management/expansionnpr.html.</E>
                     The notice of proposed rulemaking (NPRM) can also be downloaded or viewed on 
                    <PRTPAGE P="25360"/>
                    the internet at 
                    <E T="03">www.regulations.gov</E>
                     (search for docket # NOAA-NOS-2016-0059 and NOAA-NOS-2019-0033).
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        George P. Schmahl, Superintendent, Flower Garden Banks National Marine Sanctuary, 4700 Avenue U, Building 216, Galveston, Texas, at 409-356-0383, or 
                        <E T="03">fgbexpansion@noaa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Introduction</HD>
                <HD SOURCE="HD3">1. Flower Garden Banks National Marine Sanctuary</HD>
                <P>Located in the northwestern Gulf of Mexico, 70 to 115 miles off the coasts of Texas and Louisiana, Flower Garden Banks National Marine Sanctuary (FGBNMS or sanctuary) currently encompasses approximately 56 square miles and includes three separate undersea features: East Flower Garden Bank, West Flower Garden Bank, and Stetson Bank. The banks range in depth from 55 feet (17 meters) to nearly 500 feet (152 meters), and are geological formations created by the movement of ancient salt deposits pushed up through overlying sedimentary layers.</P>
                <P>The banks provide a wide range of habitat conditions that support several distinct biological communities, including the northernmost coral reefs in the continental United States and mesophotic coral habitats. These and similar formations throughout the northwestern Gulf of Mexico provide the foundation for essential habitat for numerous marine species, including a variety of fish species of commercial and recreational importance, and several endangered or threatened species, including sea turtles and manta rays. The combination of location and geology makes the sanctuary an extremely productive and diverse ecosystem.</P>
                <P>
                    NOAA issued a final rule to implement the designation of FGBNMS on December 5, 1991 (56 FR 63634). Congress subsequently passed a law recognizing the designation on January 17, 1992 (Pub. L. 102-251, Title I, Sec. 101). At that time, the sanctuary consisted of two areas known as East and West Flower Garden Banks (56 FR 63634). Among other things, FGBNMS regulated a narrow range of activities, established permit and certification procedures, and exempted certain U.S. Department of Defense (DOD) activities from the sanctuary's prohibitions (56 FR 63634). Those regulations became effective on January 18, 1994 (58 FR 65664). In 1996, Congress added Stetson Bank to the sanctuary (Pub. L. 104-283). The boundaries of Stetson Bank and West Flower Garden Bank were later amended to improve administrative efficiencies and increase the precision of all boundary coordinates based on new positioning technology (65 FR 81175, Dec. 22, 2000). Current FGBNMS regulations can be found at 15 CFR part 922, subpart L, and the existing sanctuary management plan may be found at 
                    <E T="03">https://flowergarden.noaa.gov/management/2012mgmtplan.html.</E>
                </P>
                <HD SOURCE="HD3">2. Need for Action</HD>
                <P>
                    The National Marine Sanctuaries Act (NMSA) (16 U.S.C. 1431 
                    <E T="03">et seq.</E>
                    ) authorizes the Secretary of Commerce (Secretary) to designate and protect as national marine sanctuaries areas of the marine environment that are of special national significance due to their conservation, recreational, ecological, historical, scientific, cultural, archeological, educational, or aesthetic qualities. Day-to-day management of national marine sanctuaries is delegated by the Secretary to ONMS. The primary objective of the NMSA is to protect nationally significant marine resources, including biological features such as coral reefs, and cultural resources, such as historic shipwrecks and archaeological sites. The mission of FGBNMS is to identify, protect, conserve, and enhance the natural and cultural resources, values, and qualities of the sanctuary and its regional environment for this and future generations.
                </P>
                <P>The proposed action responds to the need to provide additional protection of sensitive underwater features and marine habitats associated with continental shelf-edge reefs and banks in the northwestern Gulf of Mexico. The current jurisdictional regime divides authority among several governmental entities that regulate offshore energy exploration (Bureau of Ocean Energy Management (BOEM)), fishing (Gulf of Mexico Fishery Management Council (GMFMC)), and water quality (Environmental Protection Agency (EPA)). This current jurisdictional regime does not provide comprehensive and effective management for the full range of activities that impact the sensitive reefs and banks in the region. For example, BOEM's prohibitions in the No Activity Zones (NAZs) apply only to anchoring by vessels engaged in development activities and platform services, while anchoring by other vessels remains unregulated. Further, these anchoring regulations in the NAZs apply only on a lease-by-lease basis. Other vessel ground tackle (including anchors, chains, and cables) and marine salvage activities are currently unregulated and have caused significant injury to sensitive biological communities.</P>
                <P>
                    The areas proposed for sanctuary expansion are recognized as hotspots of marine biodiversity that provide vital habitat for many important species in the Gulf of Mexico region. They are home to the most significant examples of coral and algal reefs, mesophotic and deepwater coral communities, and other biological assemblages in the Gulf of Mexico. Furthermore, these areas provide important habitat for notable species such as manta rays, sea turtles, and whale sharks, while serving as nurseries for numerous fish species of commercial and recreational importance. As such, most of these areas have also been identified as nationally significant through their designation as Habitat Areas of Particular Concern (HAPC) by the GMFMC and as NAZs by BOEM. These habitats are vulnerable to a variety of known and potential impacts, including large vessel anchoring, marine salvage operations, fishing techniques that may injure benthic habitat (
                    <E T="03">i.e.,</E>
                     trawling, bottom-tending gear), and certain oil and gas exploration and development activities. These impacts can more effectively be addressed within the expanded areas through the comprehensive habitat conservation and management authorities under the NMSA. The protection of these ecologically significant sites would increase the resilience of marine ecosystems, and enhance the sustainability of the region's thriving recreation, tourism, and commercial economies. Ultimately, expanding FGBNMS would help ensure that valuable marine resources remain available for the use and enjoyment of future generations of Americans.
                </P>
                <P>
                    The proposed sanctuary expansion is the logical outcome of decades of scientific research and growing public recognition of the need for coordinated protection of significant offshore marine places in the northern Gulf of Mexico region. Protecting additional habitat in the northwestern Gulf of Mexico emerged as one of the highest priorities identified during a vigorous public review process of FGBNMS management issues. Subsequently, “Sanctuary Expansion” was incorporated as a discrete action plan in the 2012 revision of the sanctuary's management plan. The region is heavily utilized for a variety of recreational, commercial, and industrial purposes, and there are ongoing impacts from bottom-disturbing activities, such as large vessel anchoring and marine salvage, on the sensitive biological resources and geological features associated with many reefs and banks in 
                    <PRTPAGE P="25361"/>
                    the area. Therefore, pursuant to the NMSA's purpose to “facilitate to the extent compatible with the primary objective of resource protection, all public and private uses of the resources of these marine areas,” FGBNMS can further resource protection while balancing multiple uses. The proposed action would expand FGBNMS by incorporating portions of selected reefs and banks in the northwestern Gulf of Mexico. In doing so, the proposed action would provide management of and protection for nationally significant areas with biological, ecological, and/or structural links to the existing sanctuary, including vulnerable mesophotic and deep benthic habitat sites, while providing important opportunities for research and recovery of resources from observed impacts. These areas contain the most significant examples of mesophotic coral communities in the Gulf of Mexico, including some of the highest known densities of mesophotic corals (colonies per square meter). Many banks in the proposed expansion are also nationally significant, in part, because they have been historically recognized by BOEM and GMFMC, as stated above.
                </P>
                <HD SOURCE="HD1">II. History of the FGBNMS Expansion Process</HD>
                <HD SOURCE="HD3">1. Management Plan Review</HD>
                <P>NOAA is required by NMSA Section 304(e) to periodically review sanctuary management plans to ensure that sanctuary management continues to effectively conserve, protect, and enhance the nationally significant living and cultural resources at each site. Management plans generally outline regulatory goals, describe boundaries, identify staffing and budget needs, and set priorities and performance measures for resource protection, research, and education programs. Management plans also guide the development of future management activities.</P>
                <P>The FGBNMS management plan review process began in 2006 with a series of scoping meetings to obtain information about the public's interests and priorities for FGBNMS management (71 FR 52757; September 7, 2006). Subsequently, NOAA worked with the FGBNMS Advisory Council to prioritize issues and develop appropriate management strategies and activities for the preparation of a draft revised management plan. Protecting additional nationally significant habitat in the northwestern Gulf of Mexico emerged as one of the highest priority issues for the sanctuary during the FGBNMS management plan review process.</P>
                <P>In 2007, the FGBNMS Advisory Council, using information developed by its Boundary Expansion Working Group (BEWG), recommended a range of sanctuary boundary expansion alternatives. Based on this input, and information obtained through a subsequent public process, NOAA prepared a revised management plan (77 FR 25060, April 27, 2012) that contained six action plans, including one that specifically addressed sanctuary expansion. The Sanctuary Expansion Action Plan outlined a strategy to expand the protected areas to include additional reefs and banks in the northwestern Gulf of Mexico, and to develop a DEIS to evaluate appropriate expansion alternatives. The recommended expansion alternative, as identified by the FGBNMS Advisory Council in 2007, was included in the Sanctuary Expansion Action Plan. This recommendation included nine additional reefs and banks, encompassing approximately 281 square miles.</P>
                <HD SOURCE="HD3">2. Boundary Expansion Notice of Intent</HD>
                <P>On February 3, 2015, NOAA published a Notice of Intent to prepare a draft environmental impact statement (DEIS) for expanding FGBNMS boundaries (80 FR 5699). That Notice solicited public input on the range and significance of issues related to sanctuary expansion, including potential boundary configurations, resources to be protected, other issues NOAA should consider, and any information that should be included in the resource analysis. The public scoping period was open through April 6, 2015, during which time ONMS held three public hearings and interested parties submitted both written and oral comments.</P>
                <P>NOAA received approximately 200 comments during the scoping period. Most commenters were strongly supportive of the concept of sanctuary expansion. In addition to broad general support, some comments expressed conditional support while raising user concerns primarily relating to the potential impact of sanctuary expansion on the offshore oil and gas industry and historic fishing practices. Other commenters recommended that NOAA consider a broader geographical area than the Sanctuary Expansion Action Plan identified, especially in light of the 2010 BP/Deepwater Horizon oil spill and new information that became available since the 2007 FGBNMS Advisory Council recommendation. This information was considered during the development of the expansion alternatives in the DEIS.</P>
                <HD SOURCE="HD3">3. Draft Environmental Impact Statement</HD>
                <P>
                    In accordance with the National Environmental Policy Act (NEPA, 42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    ) and the NMSA (NMSA, 16 U.S.C. 1434), NOAA prepared and released a DEIS (81 FR 37576, June 10, 2016). The DEIS considered alternatives for the proposed expansion of boundaries at FGBNMS and application of the existing sanctuary regulations and management actions to the expanded area. The DEIS evaluated the environmental consequences of the alternatives and provided an in-depth resource assessment. The action alternatives in the DEIS would expand the network of protected areas within FGBNMS by incorporating selected reefs, banks, and other features in the north central Gulf of Mexico.
                </P>
                <P>
                    The DEIS evaluated five alternatives, ranging from “no action” (maintaining the current boundaries) to one that included a total of 45 discrete boundary units and encompassed approximately 935 square miles. The proposed action discussed in this rulemaking falls within the bounds of the DEIS alternatives as discussed below in part II, section 5 of this proposed rule and in the supplemental information report which is available at the FGBMNS website 
                    <E T="03">https://flowergarden.noaa.gov/management/expansionnpr.html,</E>
                     and the Supporting Documents section of the docket identified in the 
                    <E T="02">ADDRESSES</E>
                     section of this document. The 2007 Advisory Council recommendation (Alternative 2) was included in the range of alternatives. All alternatives were consistent with NOAA's mission to conserve and manage coastal and marine ecosystems and resources, would further the FGBNMS mission to “identify, protect, conserve, and enhance the natural and cultural resources, values, and qualities of FGBNMS and its regional environment for this and future generations,” would provide for more comprehensive management and protection of important and vulnerable ecological and cultural resources across the north central Gulf of Mexico, and would provide important opportunities for research and recovery of resources from observed impacts. No significant adverse impacts to the human environment were identified under any alternative considered in the DEIS.
                </P>
                <P>
                    NOAA's preferred alternative in the 2016 DEIS (Alternative 3) sought to expand the existing sanctuary from approximately 56 square miles to approximately 383 square miles, including additional important and 
                    <PRTPAGE P="25362"/>
                    sensitive marine habitat areas in the northwestern Gulf of Mexico. This alternative would have applied the existing sanctuary regulations and management actions to the expanded area. The 2016 preferred alternative included 15 reefs and banks (in addition to those contained within the existing 3 sanctuary units) encompassed within 11 discrete boundary polygons.
                </P>
                <P>The 2016 preferred alternative would have also modified the existing Stetson Bank boundary and incorporated the existing East and West Flower Garden Banks in a single new sanctuary unit that included an additional feature known as Horseshoe Bank. The preferred alternative also would have established new discontiguous boundaries encompassing seven individual banks (McGrail, Geyer, Sonnier, Alderdice, MacNeil, Elvers, and Parker) and two additional habitat complexes comprising multiple reefs and banks (the Bright-Rankin-28 Fathom complex and the Bouma-Bryant-Rezak-Sidner complex). NOAA developed this alternative based on similar criteria used by the FGBNMS Sanctuary Advisory Council (SAC) in their 2007 recommendation for boundary expansion, supplemented since that time by information obtained from current research, consultation with other federal and state agencies, and public comment.</P>
                <P>
                    The 2016 preferred alternative was also informed by the impacts and restoration plans resulting from the 2010 Deepwater Horizon disaster, and information on biological communities obtained from 
                    <E T="03">in situ</E>
                     surveys contributed to the analysis. Evaluation criteria were applied for standardization and quality control.
                </P>
                <HD SOURCE="HD3">4. Comments Received on the DEIS</HD>
                <HD SOURCE="HD3">a. Public Comments</HD>
                <P>
                    NOAA accepted public comments on the DEIS from June 2016 to August 2016 through 
                    <E T="03">https://www.Regulations.gov,</E>
                     by mail, and in person during public hearings in Galveston, TX; Houston, TX; New Orleans, LA; Lafayette, LA; and Mobile, AL. Public comments are available for review at 
                    <E T="03">https://www.regulations.gov,</E>
                     docket # NOAA-NOS-2016-0059. NOAA received 1,421 separate comments during the public comment period, including three letter campaigns and one petition, each with multiple signatories, for a total of 8,491 comments.
                </P>
                <HD SOURCE="HD3">Characterization of Public Comments</HD>
                <P>In support of expansion, 4,579 expressed support for Alternative 5 (the most comprehensive alternative), 1,501 for Alternative 3 (Preferred Alternative) and 9 for Alternative 2 (the 2007 SAC Recommendation). The public comments are summarized below, and a comprehensive characterization of public comments will be included in the final environmental impact statement (FEIS).</P>
                <P>Public comments identified specific geographic locations of concern within the range of proposed alternatives, and additional areas of concern that were not included in the range of proposed alternatives. Comments raised concerns regarding fish spawning aggregations, open water areas between banks, shipwrecks, mesophotic/deepwater coral ecosystems, artificial reefs, sea turtles, corals, commercial fish, sharks, rays, and whales. Comments supportive of the proposed expansion referred to industrial, environmental, and global impacts. Opposing comments cited existing protections for sensitive resources; restriction to use/access; safety, budget, and management concerns; and socioeconomic consequences.</P>
                <HD SOURCE="HD3">b. Agency Consultations and Other Coordination</HD>
                <HD SOURCE="HD3">i. BOEM Consultation</HD>
                <P>Pursuant to NMSA Section 304(a)(2)(B)(ii) and through the Cooperative Agency Agreement dated September 2015, FGBNMS consulted with BOEM during the development of the DEIS to evaluate the impacts to the oil and gas industry. After NOAA released the DEIS and in a report dated November 2, 2016, BOEM provided additional analysis of the Outer Continental Shelf (OCS) areas affected by Alternative 3 (Preferred Alternative) and Alternative 5. In that report, BOEM provided information on: (1) Discovered, contingent and undiscovered oil and gas resource potential beneath proposed expansion areas; (2) rough cost estimates for directional drilling from outside the sanctuary; (3) potential economic loss to the Federal government from a reduction in OCS leasing if affected sanctuary blocks are not leased; (4) identification of currently leased OCS blocks in the expansion area; (5) rough cost estimates to route new pipelines around the expanded sanctuary area; and (6) areas within the proposed expansion beyond what BOEM currently protects.</P>
                <HD SOURCE="HD3">ii. Gulf of Mexico Fishery Management Council Consultation</HD>
                <P>Pursuant to NMSA Section 304(a)(5), ONMS sent a formal letter, dated June 17, 2016, to initiate consultation with GMFMC. NOAA also provided multiple updates at GMFMC meetings over the course of the development of the DEIS and this proposed rule. Sites in the 2016 DEIS preferred alternative (Alternative 3) were analyzed by GMFMC, and in a communication dated November 9, 2016, GMFMC recommended that NOAA use a “tiered approach” for application of fishing regulations within most banks of the expanded sanctuary (see 2, below). The general concept of this approach is based on utilization of areas previously designated by BOEM as NAZs and that are associated with most of the bank features included in the 2016 DEIS Preferred Alternative. The NAZs are defined pursuant to a Gulf of Mexico OCS lease stipulation contained in Notice to Lessees (NTL) No. 2009-G39.</P>
                <P>The GMFMC recommendations are as follows:</P>
                <P>(1) Maintain current fishing regulations within existing Habitat Areas of Particular Concern (HAPCs).</P>
                <P>East and West Flower Garden, Stetson and McGrail Banks are HAPCs with regulations that prohibit fishing with bottom longline, bottom trawl, buoy gear, dredge, pot or trap, and bottom anchoring by fishing vessels.</P>
                <P>(2) For other banks in the proposed expansion, establish a “tiered” approach for application of fishing regulations as follows: Tier One—areas within existing BOEM NAZs would be established as “no bottom tending gear” zones, in which only traditional hook and line fishing (including bandit rigs) would be allowed, and anchoring would be prohibited; Tier Two—areas outside the BOEM NAZs but inside FGBNMS boundaries where bottom tending gear and anchoring by fishing vessels with an endorsement (see 3, below) would be allowed, but bottom trawling, traps, and dredges would be prohibited; Tier Three—outside of sanctuary boundaries—no sanctuary restrictions. The GMFMC also recommended establishing a truncated “no bottom tending gear zone” for banks without an NAZ.</P>
                <P>
                    (3) For those areas of soft sediment outside of the “no bottom tending gear zone,” create an endorsement program to allow anchoring by commercial vessels. This endorsement would require the use of a vessel monitoring system (VMS) and the use of anchor systems equipped with a weak link environmental safeguard. The endorsement would require an education program for operators of commercial vessels and the use of mooring buoys by recreational vessels.
                    <PRTPAGE P="25363"/>
                </P>
                <P>(4) Place mooring buoys within the “no bottom tending gear zones” to allow for public access.</P>
                <P>(5) Alter boundaries for several specific banks.</P>
                <HD SOURCE="HD3">iii. NOAA Fisheries Coordination</HD>
                <P>Existing protections for FGBNMS include a prohibition on the possession and use of fishing gear with the exception of conventional hook and line gear. Pelagic longline gear is used to target yellowfin tuna and swordfish in the Gulf of Mexico and the proposed sanctuary expansion areas. In an August 2016 letter, NOAA's National Marine Fisheries Service, Atlantic Highly Migratory Species Management Division, requested that an exemption for pelagic longline gear be added to the current exemption for conventional hook and line gear in the expanded sanctuary area.</P>
                <HD SOURCE="HD3">c. FGBNMS Advisory Council Review</HD>
                <P>Prior to the release of the DEIS, the FGBNMS Advisory Council re-established the Boundary Expansion Working Group (BEWG) to provide additional review of NOAA's expansion proposal and make recommendations to the full Advisory Council. The BEWG consisted of 10 Advisory Council members and was co-chaired by representatives of the Oil and Gas Industry and Commercial Fishing constituent groups. Between July 2016 and May 2018, the BEWG met 21 times, and considered a variety of topics, including a range of boundary and regulatory issues.</P>
                <P>
                    At the request of FGBNMS and in consultation with the BEWG, beginning in April 2017, NOAA's National Centers for Coastal and Ocean Science (NCCOS) developed an analysis tool to assist the BEWG in their boundary discussions. As part of this analysis, NCCOS synthesized available information on biology, ecology, human use, and management designations for the study area, and created a geodatabase that helped visualize and evaluate various boundary expansion options. The analysis used a geospatial planning software tool known as 
                    <E T="03">Marxan,</E>
                     which is designed to help decision makers find solutions to conservation planning issues. A variety of geospatial datasets were included in the analysis, including commercial fishing vessel activity, oil and gas infrastructure, known locations of sensitive biological communities, shipping activity, and existing management zones. The various data components were assigned weights, as determined by the BEWG, to give priority and identify potential outcomes. The analysis focused on the locations of the BOEM designated NAZs. NAZs are areas within which no operations, anchoring, or structures are allowed for oil and gas operations. These areas are outlined in BOEM's Western and Central Gulf of Mexico Topographic Features Stipulation Map Package, and further described Notice to Lessees (NTL) No. 2009-G39. The NAZs were developed in the 1970-1980's to protect the shallowest portion of the reefs and banks (
                    <E T="03">i.e.,</E>
                     “topographic features”) under consideration for oil and gas development. The focus on the NAZs by the BEWG was in response to concerns raised primarily by the oil and gas industry regarding potential impacts to offshore energy operations from FGBNMS expansion in this portion of the Gulf of Mexico. Ultimately, the BEWG considered the NAZs as the primary geographically bound characteristic by which to develop recommendations for revisions to the proposed sanctuary expansion boundaries. In April and May 2019, the BEWG adopted a series of recommendations for expansion of 14 of the 15 additional banks proposed in the 2016 DEIS preferred alternative.
                </P>
                <P>The BEWG presented its revised FGBNMS expansion boundaries recommendation to the full FGBNMS Advisory Council (SAC) on May 9, 2018, and the recommendation was accepted by the SAC as proposed.</P>
                <HD SOURCE="HD3">5. NOAA's Revised Preferred Alternative and Supplemental Information Report</HD>
                <P>Based primarily on the May 2018 recommendation from the FGBNMS Advisory Council, along with input received from public comments, and consultation with the GMFMC and various Federal agencies, NOAA is revising its preferred alternative for sanctuary expansion.</P>
                <P>The original 2016 DEIS Preferred Alternative would have added 15 banks, for a total of 18 banks, represented in 11 polygons (including 3 multi-bank complexes). This would have resulted in an increase of the existing sanctuary area from approximately 56 square miles to approximately 383 square miles. NOAA's revised preferred alternative presented in this proposed rule would add 14 banks, for a total of 17 banks, represented in 19 polygons (including 3 banks with multi-polygons). This would increase the current sanctuary area from approximately 56 square miles to approximately 160 square miles. NOAA has reduced the size of the expansion areas proposed in the 2016 DEIS preferred alternative, to promote compatibility with users and reduce potential economic impacts to the offshore energy industry.</P>
                <P>
                    The supplemental information report (SIR), which is available at the FGBNMS website 
                    <E T="03">https://flowergarden.noaa.gov/management/expansionnpr.html,</E>
                     and the Supporting Documents section of the docket identified in the 
                    <E T="02">ADDRESSES</E>
                     section of this document, describes NOAA's development of the revised preferred alternative. In summary, through the SIR, NOAA evaluated changes to the 2016 preferred alternative. As detailed in the SIR, the revised preferred alternative boundaries are more tightly drawn around the shallowest portions of the geological features of interest, and the new polygons include all of the same reefs and banks that were represented in the 2016 preferred alternative, with one exception, Bryant Bank, which is not included in the revised preferred alternative. Bryant Bank is a small area in the Bouma-Bryant-Rezak-Sidner Bank complex. Moreover, the SIR evaluated new circumstances and information related to fishing activity and oil &amp; gas activity. Ultimately, NOAA determined that the changes reflected in the revised preferred alternative are not “substantial changes in the proposed action that are relevant to environmental concerns” (40 CFR 1502.9(c)(1)(i)). NOAA further found that the comments received on the 2016 DEIS do not “constitute significant new circumstances or information relevant to environmental concerns and bearing on the proposed action or its impacts” (40 CFR 1502.9(c)(1)(ii). As such, NOAA determined that preparing a supplement to the 2016 DEIS is neither required, nor necessary under NEPA. Pursuant to applicable CEQ guidance, NOAA will document the agency's rationale for revising the preferred alternative and provide updated information on the affected environment in the Final Environmental Impact Statement (FEIS) and related Record of Decision (ROD).
                </P>
                <P>NOAA submits that the revised preferred alternative, as presented herein, minimizes the impact to offshore energy exploration and production while providing substantial protection to sensitive marine habitats of national significance and meeting the expansion objectives as identified in the 2012 FGBNMS management plan and 2016 DEIS.</P>
                <HD SOURCE="HD3">a. Additional Consultations</HD>
                <HD SOURCE="HD3">i. Executive Order 13795—Implementing an America-First Offshore Energy Strategy</HD>
                <P>
                    On April 28, 2017, President Donald Trump issued Executive Order 13795—
                    <PRTPAGE P="25364"/>
                    <E T="03">Implementing an America-First Offshore Energy Strategy.</E>
                     The proposed action is subject to the criteria contained within Section 4 of that order, which directs the Secretary of Commerce to refrain from designating or expanding any national marine sanctuary unless the proposal includes a full accounting from the Department of the Interior (DOI) of any energy or mineral resource potential (including offshore energy from wind, oil, natural gas, methane hydrates, and any other sources that the Secretary of Commerce deems appropriate) within the proposed area, and the potential impact of the expansion on the energy or mineral resource potential within the area proposed to be designated.
                </P>
                <P>On November 6, 2018, NOAA submitted a letter to BOEM, requesting the analysis required by the Executive Order for the revised preferred alternative boundary developed in response to public comment and a recommendation by the FGBNMS Advisory Council described above in part II, section 5 of this proposed rule.</P>
                <P>
                    On February 25, 2019, BOEM responded with a review of offshore energy and mineral resource potential located within the revised proposed expansion areas. BOEM's report is available at the Supporting Document section of the docket identified in the 
                    <E T="02">ADDRESSES</E>
                     section of this document. The BOEM analysis indicated that the proposed expansion could impact the development of OCS oil and gas resources leading to a potential reduction in Federal revenue from leasing revenue and royalties. BOEM expressed concern that expansion would potentially: (1) Restrict new wells from being drilled in areas that would be inside new sanctuary boundaries, but that are currently outside the existing BOEM-designated NAZs, primarily due to the triggering of the EPA's National Pollutant Discharge Elimination System (NPDES) general permit discharge restriction; (2) incorporate some sandy and muddy seafloor that BOEM considers to be available for development under current guidelines; (3) make it more difficult and costly for OCS oil- and gas-related activities to occur; and (4) increase costs on leases in an expanded sanctuary, potentially deterring current lease holders from developing oil and gas resources, as well as reducing future leasing within the sanctuary, which could result in an economic loss to the federal government.
                </P>
                <P>BOEM's analysis stated that areas within the proposed expansion boundaries contain approximately 0.11 million barrels of oil equivalent (MMBOE) reserves, 3.86 MMBOE of contingent resources, and 4.50 MMBOE of undiscovered resources. The oil reserves estimated in BOEM's analysis represent approximately 0.002% of known oil and gas reserves, 0.07% of the contingent resources, and 0.008% of undiscovered resources in the OCS Gulf of Mexico. This is well below the impacts expressed in the 2016 FGBNMS DEIS, in which NOAA estimated that the proposed expansion had the potential to overlap with approximately 0.25% of known oil and gas reserves.</P>
                <P>BOEM's analysis of the revised preferred alternative found that the expansion of FGBNMS would affect 65 additional whole or partial OCS blocks (by incorporation into the FGBNMS and/or by distancing requirements for bottom disturbing activity), which contain eight active oil and gas leases. Most of this area (73%) is already located within BOEM-designated NAZs. As an indication of the potential value of leases in this area, BOEM reports that the total amount of bonus bids collected for the eight active lease blocks affected by the preferred alternative for sanctuary expansion from 1972 through 2018 was $97 million. Section 304(c) of the NMSA provides that: “Nothing in this chapter shall be construed as terminating or granting to the Secretary the right to terminate any valid lease, permit, license, or right of subsistence use or of access that is in existence on the date of designation of any national marine sanctuary.” This provision is implemented by National Marine Sanctuary Program Regulations at 15 CFR 922.47, which would apply to the expanded area. Accordingly, anyone who has a pre-existing activity that falls within the ambit of section 304(c) of the NMSA may request certification of that activity by filing a formal application to NOAA within 90 days of the effective date of the final rule to expand the boundaries of FGBNMS.</P>
                <P>
                    BOEM reports that there are also portions of 57 unleased OCS blocks affected by the preferred alternative for the proposed sanctuary expansion that could experience more restrictive oil and gas activity conditions if they are leased following expansion of FGBNMS. NOAA notes that of this area, less than 27% is included in the proposed sanctuary expansion boundaries, and 61% of that area is already included within BOEM NAZs. Therefore, sanctuary designation will not impact most of the lease block area analyzed by BOEM, and it is unlikely that the affected OCS blocks will be rendered un-leasable in the future. However, in the event that these blocks become unavailable for leasing, or if operators choose not to lease them because of Sanctuary designation (
                    <E T="03">e.g.</E>
                     due to the need for directional drilling or relocation), BOEM estimates that there could be a potential loss of revenue to the Federal Government. Under this scenario and, based on a minimum bid amount for the entire unleased acreage, BOEM calculated a potential future cumulative value of $12 million in lost bonuses for leases could be associated with FGBNMS expansion. When considered in context, this amount is less than significant. For example, in the previous 10 years prior to this analysis, approximately $7.7 billion in bonus bids have been collected for offshore oil and gas leases in the Gulf of Mexico.
                </P>
                <P>BOEM reported that if technically and economically feasible, access to the affected oil and gas resources could be obtained through directional drilling technology at a potential total increase in cost of $3.24 million to the oil and gas industry for all future wells impacted by Sanctuary designation. Considering that average offshore well costs range from $10 to $50 million in water depth between 50 and 500 ft (15.2—152 m), with drill depths between 5,000 and 20,000 ft (1524—6096 m), the additional cost related to directional drilling for all future wells that could be impacted by sanctuary expansion is not significant.</P>
                <P>Finally, BOEM estimates that from $8.1 million to $40.5 million in total potential future lease royalties could be forgone related to the recovery of undiscovered resources in the proposed FGBNMS expansion areas. However, NOAA notes that, based on historical records, lease blocks that are partially within or adjacent to East and West Flower Garden Banks have continued to be leased and developed since designation of FGBNMS in 1992.</P>
                <P>BOEM's February 2019 analysis further clarifies the extent of potential for oil and gas development within the proposed sanctuary boundaries and supports the assessment that the proposed action would not have a significant negative economic impact on OCS oil and gas development in the Gulf of Mexico.</P>
                <HD SOURCE="HD3">ii. GMFMC's Response to the Revised Preferred Alternative</HD>
                <P>In October 2018, NOAA provided the revised preferred alternative boundaries, which is described above in Part II, section 5 of this proposed rule, to the GMFMC for reconsideration. </P>
                <P>
                    The GMFMC sent revised comments to ONMS in a letter dated November 7, 2018, supporting the revised boundary proposal and indicating that the previously recommended tiered approach was no longer needed. For 
                    <PRTPAGE P="25365"/>
                    more information on the revised preferred alternative, please refer to part II, section 5 of this rulemaking and the Supplemental Information Report, which is available at the FGBMNS website 
                    <E T="03">https://flowergarden.noaa.gov/management/expansionnpr.html,</E>
                     and the Supporting Documents section of the docket identified in the 
                    <E T="02">ADDRESSES</E>
                     section of this document. GMFMC also submitted a request to allow spearfishing in the new expansion areas, as well as encouragement for implementing an endorsement program in order to allow fishing inside the sanctuary, and the installation of additional mooring buoys. The GMFMC suggested also that the FGBNMS investigate the potential impacts that the use of “bandit rig” gear could have on coral. The request to allow the use of spearfishing gear in the expanded areas will be vetted through public comment solicitation in part VI section 2 of this proposed rule.
                </P>
                <HD SOURCE="HD3">iii. Ongoing Coordination With NOAA Fisheries</HD>
                <P>Following its review of the revised preferred alternative, NOAA Fisheries has maintained its request for an exemption to allow the use of pelagic longline gear in the expanded sanctuary areas. ONMS is seeking the public's view on this request as described in part VI section 2 of this proposed rule.</P>
                <HD SOURCE="HD1">III. Summary of Regulatory Amendments</HD>
                <HD SOURCE="HD3">1. Sanctuary Boundary Expansion</HD>
                <P>
                    NOAA is proposing to amend the existing sanctuary boundary descriptions at 15 CFR part 922, subpart L, and the terms of designation in order to expand the current boundaries of FGBNMS to include portions of 14 additional reefs and banks in the sanctuary, adding approximately 104 square miles, bringing the total area to 160.4 square miles. The proposed boundary changes were selected through a public process to identify and assess marine areas that could more effectively complement current management authorities or enhance natural and cultural resource values. Collectively, these new areas capture a greater diversity of habitats and biological resources than currently protected by FGBNMS. Inclusion of these areas within the sanctuary system would provide additional regulatory protection, resources for management, and improved public awareness of their natural resource values. Detailed maps of these proposed changes are available on our website at 
                    <E T="03">https://flowergarden.noaa.gov/management/expansionnpr.html.</E>
                </P>
                <P>Under this action NOAA is proposing to expand the boundaries of the sanctuary from 56.2 square miles to 160.4 square miles as follows:</P>
                <FP SOURCE="FP-2">
                    <E T="03">a. Stetson Bank</E>
                    —increase of area by 0.6 square miles from 0.8 square miles to 1.4 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">b. West Flower Garden Bank</E>
                    —increase of area by 7.2 square miles from 29.9 square miles to 37.2 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">c. East Flower Garden Bank</E>
                    —increase of area by 2.4 square miles from 25.4 square miles to 27.8 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">d. Horseshoe</E>
                     Bank—28.7 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">e. MacNeil Bank</E>
                    —2.7 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">f. Rankin/28 Fathom Banks</E>
                    —5.6 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">g. Bright Bank</E>
                    — 7.7 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">h. Geyer Bank</E>
                    —11.5 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">i. Elvers Bank</E>
                    —4.6 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">j. McGrail Bank</E>
                    —4.7 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">k. Sonnier Bank</E>
                    —3.1 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">l. Bouma Bank</E>
                    —7.7 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">m. Rezak Bank</E>
                    —3.7 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">n. Sidner Bank</E>
                    —2.0 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">o. Alderdice Bank</E>
                    —5.0 square miles
                </FP>
                <FP SOURCE="FP-2">
                    <E T="03">p. Parker Bank</E>
                    —7.0 square miles
                </FP>
                <HD SOURCE="HD3">2. Apply the Existing Sanctuary Regulations and Management Action to the Expanded Area</HD>
                <P>NOAA also proposes to apply the existing sanctuary regulations (including regulatory prohibitions set forth in section 922.122) and management action to the expanded sanctuary boundary in order to provide for more comprehensive management and protection of sensitive underwater features and marine habitats associated with continental shelf-edge reefs and banks in the northwestern Gulf of Mexico. Accordingly, 15 CFR 922.122(e) would be updated to reflect the effective date of the sanctuary expansion, and no further amendments of the regulatory text in 15 CFR part 922 would be necessary to implement this action as proposed.</P>
                <HD SOURCE="HD3">3. Additional Amendments Based on Comments Received</HD>
                <P>As discussed in part VI, NOAA is seeking comment on the proposed boundaries and on the requests for exemption of spearfishing and pelagic longlining and may revise the final rule as appropriate.</P>
                <HD SOURCE="HD1">IV. Summary of Proposed Changes to the Sanctuary Terms of Designation Amending Subpart L</HD>
                <P>Section 304(a)(4) of the NMSA requires that the terms of designation include the geographic area of the sanctuary; the characteristics of the area that give it conservation, recreational, ecological, historical, research, educational, or aesthetic value; and the types of activities that will be subject to regulation by the Secretary of Commerce to protect these characteristics. Section 304(a)(4) also specifies that the terms of designation may be modified only by the same procedures by which the original designation was made.</P>
                <P>The terms of designation for FGBNMS was first published in 1991 (56 FR 63637), and became effective in 1994 (58 FR 65664). The terms of designation were not incorporated into the Code of Federal Regulations, and, whenever there was a proposed regulatory change, NOAA and the general public had to search the preamble of the 1991 final rule to understand the nature and scope of the terms of designation. With this action, NOAA is proposing to make the terms of designation more readily available to the general public by amending the FGBNMS regulations at 15 CFR part 922, subpart L, to incorporate the terms of designation as a new Appendix B to the FGBNMS regulations, and update Article II. Description of the Area to include Stetson Bank (added by Congress in 1996 pursuant to Pub. L. 104-283) and the additional reefs and banks proposed for expansion, add a new section relating to the U.S. Department of Defense (DoD) exemption, and (as described below) revise the “Consistency with International Law” section of the terms of designation. To read the entire terms of designation, please refer to Appendix A to Subpart L of Part 922 in the draft regulatory text. This action does not propose to change the scope of the activities subject to regulation or change the DoD exemption as set forth in the terms of designation.</P>
                <P>
                    NOAA has consulted with the State Department on the development of NMSA regulations for more than 40 years. For example, in 1979 NOAA responded to a commentator who “felt that NOAA should specify the manner in which recognized principles of international law would be applied where sanctuaries include areas outside the territorial sea,” by stating: “Following consultation with the State Department, NOAA has determined that such application must be made on a case-by-case basis to ensure conformance with the evolving principles involved.” 44 FR 44831, 44833 (July 31, 1979) (Designation and Management of Marine Sanctuaries: Final Rule). Pursuant to State Department advice, NOAA is revising Article IV, Section 2 of the FGBNMS terms of designation to reflect NOAA's long-standing interpretation of 16 U.S.C. 
                    <PRTPAGE P="25366"/>
                    1435(a). Accordingly, NOAA proposes to add language to the FGBNMS terms of designation indicating that, based on the legislative history of the NMSA, NOAA has long interpreted the text of 16 U.S.C. 1435(a) as encompassing international law, including customary international law.
                </P>
                <HD SOURCE="HD1">V. Classification</HD>
                <HD SOURCE="HD2">A. National Marine Sanctuaries Act</HD>
                <P>
                    Section 301(b) of the NMSA (16 U.S.C. 1431) provides authority for comprehensive and coordinated conservation and management of national marine sanctuaries in coordination with other resource management authorities. Section 304(a)(4) of the NMSA (16 U.S.C. 1434) requires that the procedures specified in Section 304 for designating a national marine sanctuary be followed for modifying any term of designation. This action is revising the terms of designation (
                    <E T="03">e.g.,</E>
                     scope of regulations) for the FGBNMS. In accordance with Section 304, the documents relevant to the proposed expansion of Flower Garden Banks are being submitted to the House Resources Committee and the Senate Committee on Commerce, Science, and Transportation. Section 304(a)(5) of the NMSA also requires that NOAA consult with the appropriate Federal fishery management council on any action proposing to regulate fishing in federal waters. Consultation with the Gulf of Mexico Fishery Management Council (GMFMC) is discussed above in part II sections 4 and 5, and NOAA is soliciting comments on potential exemptions for pelagic longline and spearfishing in the expanded area.
                </P>
                <HD SOURCE="HD2">B. National Environmental Policy Act</HD>
                <P>
                    In accordance with Section 304(a)(2) of the NMSA (16 U.S.C. 1434(a)(2)), and the provisions of NEPA (42 U.S.C. 4321-4370), NOAA has prepared a DEIS to evaluate the impacts of this proposed action. For more information on the DEIS and steps leading to the revised preferred alternative, please refer above to part II, section 5 of this rulemaking and the Supplemental Information Report, which is available at the FGBMNS website 
                    <E T="03">https://flowergarden.noaa.gov/management/expansionnpr.html,</E>
                     and the Supporting Documents section of the docket identified in the 
                    <E T="02">ADDRESSES</E>
                     section of this document. The DEIS contains a statement of the purpose and need for the project, description of proposed alternatives, including the no action alternative, description of the affected environment, and evaluation and comparison of environmental consequences including cumulative impacts. Upon review, NOAA finds that no significant adverse impacts to resources and the human environment are anticipated. Rather, long-term beneficial impacts are anticipated if the proposed action is implemented. Copies of the DEIS are available at the address and website listed in the 
                    <E T="02">ADDRESSES</E>
                     section of this proposed rule and on 
                    <E T="03">regulations.gov.</E>
                </P>
                <P>
                    After review of the comments received on the 2016 DEIS, NOAA is revising the 2016 preferred alternative (See part II, section 5 for more information on this revision). Compared to the 2016 Preferred Alternative (Alt. 3), the revised preferred alternative would reduce the total size of the proposed sanctuary expansion by 223 square miles (from approximately 383 mi
                    <SU>2</SU>
                     to 160 mi
                    <SU>2</SU>
                    ), reduce the number of additional banks from 15 to 14, and increase the number of new polygons from 8 larger areas (several of which encompassed multiple features) to 16 smaller areas more closely bounding the shallowest portions of the geological features of interest. This action would increase the total number of banks to 17, and increase the total number of polygons to 19. The boundaries of the revised preferred alternative include no new reefs and banks from the original preferred alternative (Alt. 3) in the 2016 DEIS. The smaller bounded areas established under the revised preferred alternative were developed from the recommendations of the FGBNMS Advisory Council (with minor corrections to the Stetson Bank Boundary consistent with Pub. L. 104-283 (Oct. 11, 1996)).
                </P>
                <P>Applying applicable NEPA regulations and guidance, NOAA finds that these revisions are within the range of the alternatives already analyzed in the 2016 DEIS, the changes reflected in the revised preferred alternative are not “substantial changes in the proposed action that are relevant to environmental concerns” (40 CFR 1502.9(c)(1)(i)), and that this revision does not constitute “significant new circumstances or information relevant to environmental concerns and bearing on the proposed action or its impacts” (40 CFR 1502.9(c)(1)(ii)). Therefore, these revisions do not require that NOAA prepare a Supplemental DEIS. NOAA will document the rationale for revising the preferred alternative in the FEIS and related Record of Decision. To further document this, NOAA prepared a Supplemental Information Report, which is summarized above in part II section 5 of this rulemaking.</P>
                <HD SOURCE="HD2">C. Executive Order 12866: Regulatory Impact</HD>
                <P>
                    The Office of Management and Budget has determined this rule is significant under Executive Order 12866. This rule is also regulatory under Executive Order 13771. NOAA anticipates the associated costs with this proposed rule will be 
                    <E T="03">de minimis</E>
                     as explained more fully in the Regulatory Flexibility Act certification.
                </P>
                <HD SOURCE="HD2">D. Executive Order 13132: Federalism Assessment</HD>
                <P>NOAA has concluded this regulatory action does not have federalism implications sufficient to warrant preparation of a federalism assessment under Executive Order 13132. The area that is the subject of the proposed rule is located entirely within federal waters outside of state or local jurisdiction. This proposed rule will not have a substantial or direct effect on states or local governments.</P>
                <HD SOURCE="HD2">E. Executive Order 13175: Consultation and Coordination With Indian Tribal Governments</HD>
                <P>This Executive Order reaffirms the Federal government's commitment to tribal sovereignty, self-determination, and self-government. Its purpose is to ensure that all Executive departments and agencies consult with Indian tribes and respect tribal sovereignty as they develop policies on issues that impact Indian communities. This proposed action is not anticipated to have substantial direct effects on one or more Indian tribes, on the relationship between the Federal government and Indian tribes, or on the distribution of power and responsibility between the Federal government and Indian tribes.</P>
                <HD SOURCE="HD2">F. Executive Order 13795: Implementing an America-First Offshore Energy Strategy</HD>
                <P>Executive Order 13795 directs the Secretary of Commerce to refrain from designating or expanding any national marine sanctuary unless the proposal includes a full accounting from the Department of the Interior (DOI) of any energy or mineral resource potential (including offshore energy from wind, oil, natural gas, methane hydrates, and any other sources that the Secretary of Commerce deems appropriate) within the proposed area, and the potential impact of the expansion on energy or mineral resource potential within the designated area. Information pursuant to this directive is included in part II section 5 of this proposed rule.</P>
                <HD SOURCE="HD2">G. Regulatory Flexibility Act</HD>
                <P>
                    The Regulatory Flexibility Act requires Federal agencies to prepare an 
                    <PRTPAGE P="25367"/>
                    analysis of a rule's impact on small entities whenever the agency is required to publish a notice of proposed rulemaking, unless the agency can certify, pursuant to 5 U.S.C. 605(b), that the action will not have a significant economic impact on a substantial number of small entities.
                </P>
                <P>This proposed rule announces that NOAA's ONMS seeks to expand the boundary of FGBNMS, and apply the existing sanctuary regulations and management actions to the expanded area. The types of small organizations that may be impacted by this proposed rule include consumptive and non-consumptive recreational charter businesses, commercial fishing businesses, sightseeing businesses, and diving businesses operating within the waters approximately 70 to 120 miles offshore of Texas and Louisiana in the northwestern Gulf of Mexico.</P>
                <P>The Small Business Administration designates a scenic, sightseeing, sports, or recreational (NAICS code 487210) business as a small business if it has annual receipts of less than $8 million (13 CFR 121.201). A finfish business (NAICS code 114111) is also designated as a small business if it has annual receipts of less than $22 million (13 CFR 121.201). Oil and gas businesses (NAICS codes 21311 and 213112) are designated as small businesses if they hire less than 1000 employees and have annual receipts less than $41.5 million. NOAA has not identified any small entities that are in the oil and gas sector.</P>
                <P>
                    <E T="03">Methodology.</E>
                     Due to the lack of quantitative data on the number of businesses directly affected by the proposed regulations and their levels of revenues, costs, and profits from their activities in the FGBNMS expansion area, the assessment here is qualitative. As described in the 2016 DEIS and in Leeworthy et al. (2016), using Vessel Monitoring System (VMS) data, NOAA identified 76 unique commercial fishing vessels in the northern Gulf of Mexico representing 40 fishing operators from Texas to Florida. These commercial fishing operators were surveyed (Leeworthy et al. 2016), and survey results of these operators revealed that six firms were using fishing areas in the vicinity of the banks in the 2016 DEIS, and those interests were considered as close to a census as practical of all commercial fishing operations targeting the banks in the proposed expansion areas. Therefore, NOAA determined that fishing occurred with low frequency within the proposed expansion areas of the sanctuary.
                </P>
                <P>In this analysis, NOAA concluded that impacts to the small business entities that were analyzed would be no effect or negligible. No effect means that the proposed action would have no impact on small businesses, and negligible means that the proposed action would cause less than 1% change to small businesses and no likely impact to revenue, costs, and profits.</P>
                <P>The 2016 DEIS analyzed five spatial alternatives (identified as Alternatives 1-5) for the proposed expansion of FGBNMS. Existing sanctuary regulations would apply in the newly expanded area regardless of which spatial alternative is adopted. Oil and gas regulations and other related regulations addressed in the 2016 DEIS are not discussed since the oil and gas industry operating within the northern Gulf of Mexico would not be deemed a small business under applicable SBA regulations. This analysis focuses on the application of existing sanctuary regulations to new areas that would impose fishing gear restrictions, prohibit anchoring and mooring of certain vessels in the sanctuary, and protect sanctuary resources. The proposed action is expected to have negligible impact on small entities due to the low level of fishing effort observed in the proposed expansion areas.</P>
                <P>
                    <E T="03">Fishing Gear Regulations in the Expanded Sanctuary Boundaries.</E>
                     Under the existing sanctuary regulations, which would be applied in the expanded area if the proposed rule is adopted, only conventional hook and line gear may be used in the expanded sanctuary boundaries. The term “conventional hook and line gear” means any fishing apparatus operated aboard a vessel and composed of a single line terminated by a combination of sinkers and hooks or lures and spooled upon a reel that may be hand- or electronically operated, hand-held or mounted; and this term does not include bottom longlines (15 CFR 922.3). Applying these regulations, fishing with bottom-tending gear, nets, trawls, and speargun would be prohibited in the expanded sanctuary boundaries. NOAA determined that the proposed regulations would not have a significant economic impact on a substantial number of recreational or commercial fishing entities. According to Leeworthy et al. (2016), six commercial fishing and eight for-hire recreational entities use reefs and banks in or near the proposed expansion area for some portion of their operations. Each of these firms were shown to operate in an area considerably larger than the proposed expansion area; therefore, in none of the cases studied, were the amounts of impacts a significant portion of the business of any of the firms potentially affected. This analysis is also explained in the 2016 DEIS, and the economic effects of the revised preferred alternative are bounded within the results of the DEIS alternatives.
                </P>
                <P>Moreover, fishers would likely be able to harvest from similar areas near the proposed expansion area through spatial substitution. In the DEIS, NOAA used hardbottom substrate as a proxy for habitat areas targeted by the commercial fishing industry, and estimated that for the DEIS alternatives, between 0.59% and 7.15% of hardbottom habitat in the study area (north central Gulf of Mexico) would be subject to additional fishing restrictions, and the DEIS preferred alternative overlapped with 4.01% of the hardbottom substrate in the study area. Additionally, the area of the proposed expansion, under the revised preferred alternative, is considerably smaller than the 2016 preferred alternative. As such, fishers could use areas within the same reefs and banks adjacent to the sanctuary expansion areas.</P>
                <P>For recreational fisheries, the prohibition on spearfishing in the expanded area might be similarly offset by spatial substitution. This is especially true given the fact that the banks studied showed very little spearfishing activity in the proposed action area.</P>
                <P>Increased visitation to the sanctuary for recreation and tourism could result in positive long-term regional economic impacts as a result of increased visitor spending in coastal communities from which the sanctuary is accessed.</P>
                <P>
                    <E T="03">Anchoring and Mooring Regulations in the Expanded Sanctuary Boundaries.</E>
                     The existing sanctuary regulations, which would be applied in the expanded area if the proposed rule is adopted, prohibit anchoring any vessel within the sanctuary. Mooring any vessel that is greater than 100 feet in registered length to a mooring buoy in the sanctuary is also prohibited. NOAA anticipates that the prohibition on bottom disturbing activities (such as anchoring) would reduce or eliminate opportunities to engage in some activities by commercial and recreational fishing vessels. However, the installation of mooring buoys for small vessels, measuring less than 100 feet in registered length, would potentially reduce the associated impacts. The impact of the anchoring prohibition and mooring restriction would also be none to negligible on commercial vessels (regardless of the vessel length) because commercial vessels are very unlikely to anchor or moor in the expansion area. Recreational vessels would not be 
                    <PRTPAGE P="25368"/>
                    significantly impacted by these restrictions because they would be allowed to use moorings, due to the infrequency with which they use these areas, and mitigating factors, which are described below. Additionally, a portion (14%) of the proposed expanded area, including the modified boundaries of East and West Flower Garden and Stetson Banks, and the entire area of McGrail Bank, fall within existing coral Habitat Areas of Particular Concern (HAPC), which already prohibit anchoring by fishing vessels and use of bottom tending gear. Sanctuary expansion and the extension of the sanctuary regulations to the expanded area could also benefit small business diving and recreational fishing entities by enhancing the access to these areas through mooring buoy installation.
                </P>
                <P>
                    The prohibition on the use of bottom disturbing gear (such as anchoring) would also have a negligible impact, and potential impacts may be offset by spatial substitution (
                    <E T="03">i.e.,</E>
                     fishers could operate in similar areas nearby, which is also referred to as displacement) (Leeworthy et al. 2016). Please refer to the above analysis regarding spatial substitution. This negligible impact would be further reduced by mitigating factors (
                    <E T="03">i.e.,</E>
                     potential for gear substitution, mooring buoy installations made possible by sanctuary designation). For example, though fishing for reef fish using bandit rigs would be allowed, prohibitions on anchoring may make this activity more difficult due to the need to anchor in specific locations to better target fish aggregations. Although anchoring prohibitions would make such fishing activities more difficult, NOAA concludes that the impact to relevant business is negligible because of the low intensity of fishing in the proposed expansion areas and because these areas make up a small portion of these businesses' overall area of use. Moreover, the fishing operators surveyed in Leeworthy et al. (2016) did not identify the expansion area as a primary or principle fishing area. Fishing from mooring buoys would also continue to be allowed provided the vessel does not exceed the prohibited length.
                </P>
                <P>
                    <E T="03">Regulations Protecting Sanctuary Resources.</E>
                     Existing regulations applied to the expanded sanctuary area would prohibit injury, removal (or attempt to remove), or possession (regardless of where collected, caught, harvested or removed) of any coral or other bottom formation, coralline algae or other plant, marine invertebrate, brine-seep biota or carbonate rock, or fish (except for fish caught by use of conventional hook and line gear) within the sanctuary. Recreational diving businesses may be impacted negligibly by these existing regulations if applied to the expanded sanctuary area as proposed. Spearfishing, collection of souvenirs (shells, rocks, etc.), and fish feeding by scuba or breath-hold divers may be very minimally impacted. The extent of this type of activity is unknown but thought to be extremely limited due to the fact that only 0.013% of the proposed expansion area is within typical recreational diving depth ranges (depths of 130 feet or less) and the significant distance (more than 50 miles offshore) to the expansion areas. Divers prefer to visit shallower areas where manmade structures such as oil rigs and sunken ships are present (
                    <E T="03">e.g.,</E>
                     Ditton et al. 2002). Therefore, the extent of this impact would be mitigated by spatial substitution (artificial reefs) and through the promotion of best practices for divers within the sanctuary.
                </P>
                <P>Based on the analysis presented above, the Chief Counsel for Regulations for the Department of Commerce has certified to the Office of Advocacy of the Small Business Administration that the modifications of the regulations at 15 CFR part 922 will not have a significant economic impact on a substantial number of small entities. This proposed rule also does not establish any new reporting, recordkeeping, or other compliance requirements.</P>
                <HD SOURCE="HD2">H. Paperwork Reduction Act</HD>
                <P>The existing FGBNMS regulations contain a collection-of-information requirement subject to the Paperwork Reduction Act (PRA), approved by The Office of Management and Budget (OMB), under control number 0648-0141, for collection-of-information for reporting and recordkeeping requirements under 15 CFR part 922. This proposed rule would not increase or otherwise revise the existing paperwork burdens.</P>
                <P>
                    The public reporting burden for national marine sanctuary general permit applications is estimated to average 1 hour 30 minutes per application, including the time for reviewing the application instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. For special use permits, a collection-of information requirement is necessary to determine whether the proposed activities are consistent with the terms and conditions of special use permits prescribed by the NMSA. The public reporting burden for this collection of information is estimated to average twenty four (24) hours per response (application, annual report, and financial report), including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. This estimate does not include additional time that may be required should the applicant be required to provide information to NOAA for the preparation of documentation that may be required under NEPA (16 U.S.C. 1431 
                    <E T="03">et seq.</E>
                    ).
                </P>
                <P>NOAA does not expect that this proposed rule would appreciably change the average annual number of respondents or the reporting burden for the information requirements supporting special use or research permits because few activities requiring new permits are expected for the proposed areas. Much of the research is expected to be conducted by the sanctuary, and other uses that require permits are anticipated with very low intensity in the proposed expansion areas. NOAA believes that the proposed regulations do not necessitate a modification to its information collection approval by the Office of Management and Budget under the Paperwork Reduction Act. However, an increase in the number of ONMS permit requests would require a change to the reporting burden certified for OMB control number 0648-0141. While not expected, if such permit requests do increase, an update to this control number for the processing of ONMS permits would be requested.</P>
                <P>
                    Comments regarding this burden estimate, or any other aspect of this data collection, including suggestions for reducing the burden, may be sent to NOAA (see 
                    <E T="02">ADDRESSES</E>
                     above) and to the Office of Management and Budget (OMB) by email to 
                    <E T="03">OIRA_submission@omb.eop.gov</E>
                     or fax to (202) 395-7285. Before an agency submits a collection of information to OMB for approval, the agency shall provide 60-day notice in the 
                    <E T="04">Federal Register</E>
                    , and otherwise consult with members of the public and affected agencies concerning each proposed collection of information, to solicit comments to:
                </P>
                <P>(i) Evaluate whether the proposed collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility;</P>
                <P>
                    (ii) Evaluate the accuracy of the agency's estimate of the burden of the proposed collection of information, including the validity of the methodology and assumptions used;
                    <PRTPAGE P="25369"/>
                </P>
                <P>(iii) Enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>
                    (iv) Minimize the burden of the collection of information on those who are to respond, including through the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of responses.
                </P>
                <HD SOURCE="HD2">I. National Historic Preservation Act</HD>
                <P>
                    The National Historic Preservation Act (NHPA; 
                    <E T="03">16 U.S.C. 470 et seq.</E>
                    ) is intended to preserve historical and archaeological sites in the United States of America. The act created the National Register of Historic Places, the list of National Historic Landmarks, and the State Historic Preservation Offices. Section 106 of the NHPA requires Federal agencies to take into account the effects of their undertakings on historic properties, and afford the Advisory Council on Historic Preservation (ACHP) a reasonable opportunity to comment. The historic preservation review process mandated by Section 106 is outlined in regulations issued by ACHP (
                    <E T="03">36 CFR part 800</E>
                    ).
                </P>
                <P>
                    In coordinating its responsibilities under the NHPA, NOAA has solicited for and identified consulting parties, and will complete the identification of historic properties and the assessment of the effects of the undertaking on such properties in scheduled consultations with those identified parties. By this notice, NOAA seeks to solicit public input, particularly regarding the identification of historic properties within the proposed areas of potential effect. Pursuant to 
                    <E T="03">36 CFR 800.16</E>
                    (l)(1), historic properties includes: “any prehistoric or historic district, site, building, structure or object included in, or eligible for inclusion in the National Register of Historic Places maintained by the Secretary of the Interior.” The term includes artifacts, records, and remains that are related to and located within such properties. Responses to comments received on this proposed rule and results of Section 106 consultations will be published in the Final Environmental Impact Statement and in the final rule.
                </P>
                <HD SOURCE="HD2">J. Coastal Zone Management Act</HD>
                <P>Section 307 of the Coastal Zone Management Act (CZMA; 16 U.S.C. 1456) requires Federal agencies to consult with a state's coastal program on potential Federal regulations having an effect on state waters. Copies of the Draft Environmental Impact Statement were provided to the Gulf Coast States, soliciting feedback on reasonably foreseeable effects on coastal resources and uses. Responses were received from Mississippi Department of Marine Resources and the Texas General Land Office indicating no objection to the proposed boundary changes or the DEIS. The information received from these states will be used by NOAA to prepare determinations, as appropriate, in compliance with the CZMA.</P>
                <HD SOURCE="HD1">VI. Request for Comments</HD>
                <P>Comments are welcome on any and all aspects of the proposed rule, and we request any data that may further inform impacts of the proposed action. We specifically solicit information on the following elements for consideration.</P>
                <HD SOURCE="HD3">1. Changes to the Proposed Boundaries in the Revised Preferred Alternative</HD>
                <P>Based on the Sanctuary Advisory Council recommendations in response to the DEIS, NOAA has made a number of changes to the boundaries of the polygons surrounding the banks and submerged features. NOAA is soliciting public comment on the revised boundaries.</P>
                <HD SOURCE="HD3">2. Pelagic Longline Exemption Request</HD>
                <P>Existing protections for FGBNMS include a prohibition on the possession and use of fishing gear with the exception of conventional hook and line gear. Pelagic longline gear is used to target yellowfin tuna and swordfish in the Gulf of Mexico, including in the proposed sanctuary expansion areas. NOAA's National Marine Fisheries Service, Atlantic Highly Migratory Species Management Division, has submitted a request for an exemption for pelagic longline gear to be added to the current exemption for conventional hook and line gear in the sanctuary. NOAA is soliciting public input on this request.</P>
                <HD SOURCE="HD3">3. Spearfishing Exemption Request</HD>
                <P>Existing protections for FGBNMS include a prohibition on the possession and use of spearfishing equipment. During the public comment period for the DEIS, NOAA received several requests for an exemption to this prohibition for new expansion areas. Additionally, the Sanctuary Advisory Council's 2018 recommendation for sanctuary expansion also included a recommendation to allow free-diving spearfishing at all new banks, but not within the 3 banks of the existing sanctuary. Additionally, the SAC requested an exemption for the possession of spearguns (stowed and not available for immediate use) on board a vessel within the boundaries of the current FGBNMS, but the vessel may not be in possession of any reef fish species (with the exception of bait fish). Finally, the GMFMC also recommended that NOAA consider an exemption for the possession and use of spearfishing equipment in the sanctuary. NOAA is soliciting public input on this request.</P>
                <P>Accordingly, for the reasons set forth above, NOAA is proposing to amend Part 922, title 15 of the Code of Federal Regulations as follows:</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 15 CFR Part 922</HD>
                    <P>Administrative practice and procedure, Coastal zone, Fishing gear, Marine resources, Natural resources, Penalties, Recreation and recreation areas, Wildlife.</P>
                </LSTSUB>
                <SIG>
                    <NAME>Nicole R. LeBoeuf,</NAME>
                    <TITLE>Acting Assistant Administrator for Ocean Services and Coastal Zone Management,National Ocean Service.</TITLE>
                </SIG>
                <PART>
                    <HD SOURCE="HED">PART 922—NATIONAL MARINE SANCTUARY PROGRAM REGULATIONS</HD>
                </PART>
                <AMDPAR>1. The authority citation for part 922 continues to read as follows:</AMDPAR>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                         16 U.S.C. 1431 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <SUBPART>
                    <HD SOURCE="HED">Subpart L—Flower Garden Banks National Marine Sanctuary</HD>
                </SUBPART>
                <AMDPAR>2. Revise § 922.120 to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 922.120 </SECTNO>
                    <SUBJECT>Boundary.</SUBJECT>
                    <P>The Flower Garden Banks National Marine Sanctuary (Sanctuary) boundary encompasses a total area of approximately 121 square nautical miles (160.35 square miles) of offshore ocean waters, and submerged lands thereunder, along the continental shelf and shelf edge in the northwestern Gulf of Mexico. The entire sanctuary boundary is comprised of 19 unique polygons. The precise boundary coordinates for each polygon are listed in Appendix A to this subpart.</P>
                    <STARS/>
                </SECTION>
                <AMDPAR>3. In § 922.121 revise the term “No Activity Zone” to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 922.121 </SECTNO>
                    <SUBJECT>Definitions.</SUBJECT>
                    <STARS/>
                    <P>
                        <E T="03">No Activity Zone</E>
                         (applicable only to oil and gas industry activities) means the geographic areas delineated by the Department of the Interior in Topographic Features Stipulations for Outer Continental Shelf (OCS) lease sales as defined by a bathymetric contour (isobath) ranging from 55-85m in depth, with the exception of Stetson Bank (52m) and East and West Flower Garden Banks (100m). The Notice to Lessees (NTL) No. 2009-039 provides 
                        <PRTPAGE P="25370"/>
                        and consolidates guidance for the avoidance and protection of biologically sensitive features and areas (
                        <E T="03">i.e.</E>
                         topographic features, pinnacles, live bottoms (low relief features)) and other potentially sensitive biological features (PSBFs) when conducting operations in water depths shallower than 980 feet (300 meters) in the Gulf of Mexico. NTL 2009-039 remains in effect pursuant to NTL No. 2015-N02. The no-activity zones are based on depth contours as noted for the following Banks: Stetson Bank (52 meters), MacNeil Bank (82 meters), Rankin Banks (including 28 Fathom Bank) (85 meters), Bright Bank (85 meters), Geyer Bank (85 meters), Elvers Bank (85 meters), McGrail Bank (85 meters), Bouma Bank (85 meters), Rezak Bank (85 meters), Sidner Bank (85 meters), Sonnier Bank (55 meters), Alderdice Bank (80 meters), and Parker Bank (85 meters). For East and West Flower Garden Banks, the no-activity zones are based on the “
                        <FR>1/4</FR>
                          
                        <FR>1/4</FR>
                          
                        <FR>1/4</FR>
                        ” aliquot system formerly used by the Department of the Interior, a method that delineates a specific portion of a block rather than the actual underlying isobath. The precise aliquot part description of these areas around East and West Flower Garden Banks are provided in Appendix A of this subpart.
                    </P>
                    <STARS/>
                </SECTION>
                <AMDPAR>4. Revise § 922.122 paragraph (e)(1) to read as follows:</AMDPAR>
                <SECTION>
                    <SECTNO>§ 922.122 </SECTNO>
                    <SUBJECT>Prohibited or otherwise regulated activities.</SUBJECT>
                    <STARS/>
                    <P>(e)(1) The prohibitions in paragraphs (a)(2) through (11) of this section do not apply to activities being carried out by the Department of Defense as of the effective date of Sanctuary designation (EFFECTIVE DATE OF REGULATIONS). Such activities shall be carried out in a manner that minimizes any adverse impact on Sanctuary resources or qualities. The prohibitions in paragraphs (a)(2) through (11) of this section do not apply to any new activities carried out by the Department of Defense that do not have the potential for any significant adverse impact on Sanctuary resources or qualities. Such activities shall be carried out in a manner that minimizes any adverse impact on Sanctuary resources or qualities. New activities with the potential for significant adverse impact on Sanctuary resources or qualities may be exempted from the prohibitions in paragraphs (a)(2) through (11) of this section by the Director after consultation between the Director and the Department of Defense. If it is determined that an activity may be carried out, such activity shall be carried out in a manner that minimizes any adverse impact on Sanctuary resources or qualities.</P>
                    <STARS/>
                </SECTION>
                <AMDPAR>5. Revise Appendix A to Subpart L of Part 922 to read as follows:</AMDPAR>
                <HD SOURCE="HD1">Appendix A to Subpart L of Part 922—Flower Garden Banks National Marine Sanctuary Boundary Coordinates</HD>
                <HD SOURCE="HD1">Flower Garden Banks National Marine Sanctuary</HD>
                <P>Coordinates listed in this appendix are unprojected (Geographic Coordinate System) and based on the North American Datum of 1983 (NAD83).</P>
                <GPOTABLE COLS="5" OPTS="L2,tp0,i1" CDEF="xs54,xs54,r50,12,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Point ID No.</CHED>
                        <CHED H="1">Polygon ID No.</CHED>
                        <CHED H="1">Bank(s)</CHED>
                        <CHED H="1">Latitude</CHED>
                        <CHED H="1">Longitude</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.15673</ENT>
                        <ENT>−94.29673</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.15661</ENT>
                        <ENT>−94.30312</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.15862</ENT>
                        <ENT>−94.30888</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.16950</ENT>
                        <ENT>−94.30839</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.17386</ENT>
                        <ENT>−94.30257</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.17583</ENT>
                        <ENT>−94.29445</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.17543</ENT>
                        <ENT>−94.29327</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.17284</ENT>
                        <ENT>−94.28952</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.16924</ENT>
                        <ENT>−94.28677</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.16428</ENT>
                        <ENT>−94.28681</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.16274</ENT>
                        <ENT>−94.28756</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.15796</ENT>
                        <ENT>−94.29047</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">13</ENT>
                        <ENT>1</ENT>
                        <ENT>Stetson Bank</ENT>
                        <ENT>28.15673</ENT>
                        <ENT>−94.29673</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.84363</ENT>
                        <ENT>−93.78549</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.81750</ENT>
                        <ENT>−93.81056</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.81752</ENT>
                        <ENT>−93.84752</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.83069</ENT>
                        <ENT>−93.86271</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.81735</ENT>
                        <ENT>−93.87490</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.83220</ENT>
                        <ENT>−93.89185</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.85854</ENT>
                        <ENT>−93.89369</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.87925</ENT>
                        <ENT>−93.87853</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.92626</ENT>
                        <ENT>−93.82011</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.92620</ENT>
                        <ENT>−93.81759</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.91801</ENT>
                        <ENT>−93.80801</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.90969</ENT>
                        <ENT>−93.77939</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.88644</ENT>
                        <ENT>−93.77939</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">14</ENT>
                        <ENT>2</ENT>
                        <ENT>West Flower Garden Bank</ENT>
                        <ENT>27.84363</ENT>
                        <ENT>−93.78549</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.82317</ENT>
                        <ENT>−93.62789</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.80927</ENT>
                        <ENT>−93.63578</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.80568</ENT>
                        <ENT>−93.65541</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.79429</ENT>
                        <ENT>−93.66555</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.78357</ENT>
                        <ENT>−93.68846</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.79640</ENT>
                        <ENT>−93.70534</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.81855</ENT>
                        <ENT>−93.75198</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.82742</ENT>
                        <ENT>−93.74743</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.81868</ENT>
                        <ENT>−93.68868</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.83143</ENT>
                        <ENT>−93.68941</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.84699</ENT>
                        <ENT>−93.70079</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.87165</ENT>
                        <ENT>−93.73947</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25371"/>
                        <ENT I="01">13</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.88602</ENT>
                        <ENT>−93.73294</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.87252</ENT>
                        <ENT>−93.64648</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">15</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.85861</ENT>
                        <ENT>−93.63908</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">16</ENT>
                        <ENT>3</ENT>
                        <ENT>Horseshoe Bank</ENT>
                        <ENT>27.82317</ENT>
                        <ENT>−93.62789</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.89455</ENT>
                        <ENT>−93.57040</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.87999</ENT>
                        <ENT>−93.61309</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.88003</ENT>
                        <ENT>−93.62961</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.89330</ENT>
                        <ENT>−93.64172</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.92101</ENT>
                        <ENT>−93.64747</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.95899</ENT>
                        <ENT>−93.64490</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.97485</ENT>
                        <ENT>−93.63086</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.98177</ENT>
                        <ENT>−93.60996</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.98554</ENT>
                        <ENT>−93.58188</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.95206</ENT>
                        <ENT>−93.57810</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.92151</ENT>
                        <ENT>−93.56880</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">12</ENT>
                        <ENT>4</ENT>
                        <ENT>East Flower Garden Bank</ENT>
                        <ENT>27.89455</ENT>
                        <ENT>−93.57040</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.00226</ENT>
                        <ENT>−93.51550</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>27.99707</ENT>
                        <ENT>−93.52669</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.00136</ENT>
                        <ENT>−93.52423</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.00518</ENT>
                        <ENT>−93.52425</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.01694</ENT>
                        <ENT>−93.52233</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.01883</ENT>
                        <ENT>−93.51264</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.03670</ENT>
                        <ENT>−93.50300</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.03724</ENT>
                        <ENT>−93.49844</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.03113</ENT>
                        <ENT>−93.49199</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.01300</ENT>
                        <ENT>−93.49624</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.00331</ENT>
                        <ENT>−93.50725</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">12</ENT>
                        <ENT>5</ENT>
                        <ENT>MacNeil Bank</ENT>
                        <ENT>28.00226</ENT>
                        <ENT>−93.51550</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.92554</ENT>
                        <ENT>−93.40593</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.92039</ENT>
                        <ENT>−93.41021</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.92035</ENT>
                        <ENT>−93.42474</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.91387</ENT>
                        <ENT>−93.43165</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.90829</ENT>
                        <ENT>−93.42234</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.90641</ENT>
                        <ENT>−93.42535</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.90489</ENT>
                        <ENT>−93.44219</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.89549</ENT>
                        <ENT>−93.44396</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.88892</ENT>
                        <ENT>−93.43403</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.88072</ENT>
                        <ENT>−93.42805</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.87676</ENT>
                        <ENT>−93.42787</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.88449</ENT>
                        <ENT>−93.44458</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.88803</ENT>
                        <ENT>−93.45159</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.88794</ENT>
                        <ENT>−93.45905</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">15</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.89234</ENT>
                        <ENT>−93.46410</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">16</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.89971</ENT>
                        <ENT>−93.45571</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">17</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.90910</ENT>
                        <ENT>−93.45343</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">18</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.92847</ENT>
                        <ENT>−93.45335</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">19</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.93407</ENT>
                        <ENT>−93.44743</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">20</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.93599</ENT>
                        <ENT>−93.44215</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">21</ENT>
                        <ENT>6</ENT>
                        <ENT>Rankin Bank &amp; 28-Fathom Bank</ENT>
                        <ENT>27.92554</ENT>
                        <ENT>−93.40593</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.87310</ENT>
                        <ENT>−93.27056</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.86549</ENT>
                        <ENT>−93.29462</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.87300</ENT>
                        <ENT>−93.31055</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.89058</ENT>
                        <ENT>−93.32193</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.89839</ENT>
                        <ENT>−93.31987</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.90336</ENT>
                        <ENT>−93.30953</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.91010</ENT>
                        <ENT>−93.30562</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.91634</ENT>
                        <ENT>−93.29292</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.91263</ENT>
                        <ENT>−93.28816</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.90354</ENT>
                        <ENT>−93.28386</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.90253</ENT>
                        <ENT>−93.27238</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.89927</ENT>
                        <ENT>−93.26729</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">13</ENT>
                        <ENT>7</ENT>
                        <ENT>Bright Bank</ENT>
                        <ENT>27.87310</ENT>
                        <ENT>−93.27056</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.78848</ENT>
                        <ENT>−93.07794</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.79458</ENT>
                        <ENT>−93.08448</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.83313</ENT>
                        <ENT>−93.07913</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.85306</ENT>
                        <ENT>−93.08279</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.86328</ENT>
                        <ENT>−93.07885</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.86908</ENT>
                        <ENT>−93.06974</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25372"/>
                        <ENT I="01">7</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.86556</ENT>
                        <ENT>−93.05944</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.85211</ENT>
                        <ENT>−93.05391</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.83713</ENT>
                        <ENT>−93.05725</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.82540</ENT>
                        <ENT>−93.04312</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.82490</ENT>
                        <ENT>−93.04276</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.80846</ENT>
                        <ENT>−93.03412</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.78997</ENT>
                        <ENT>−93.04096</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.78602</ENT>
                        <ENT>−93.05384</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">15</ENT>
                        <ENT>8</ENT>
                        <ENT>Geyer Bank</ENT>
                        <ENT>27.78848</ENT>
                        <ENT>−93.07794</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.82285</ENT>
                        <ENT>−92.88605</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.82087</ENT>
                        <ENT>−92.88600</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.82009</ENT>
                        <ENT>−92.88670</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.81869</ENT>
                        <ENT>−92.89235</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.81690</ENT>
                        <ENT>−92.89404</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.81615</ENT>
                        <ENT>−92.89653</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.80645</ENT>
                        <ENT>−92.90884</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.81221</ENT>
                        <ENT>−92.92082</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.81599</ENT>
                        <ENT>−92.93908</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.81934</ENT>
                        <ENT>−92.93940</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.82250</ENT>
                        <ENT>−92.92465</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.82809</ENT>
                        <ENT>−92.91359</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.83973</ENT>
                        <ENT>−92.89876</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.83972</ENT>
                        <ENT>−92.88038</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">15</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.83003</ENT>
                        <ENT>−92.86983</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">16</ENT>
                        <ENT>9A</ENT>
                        <ENT>Elvers Bank—A</ENT>
                        <ENT>27.82285</ENT>
                        <ENT>−92.88605</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>9B</ENT>
                        <ENT>Elvers Bank—B</ENT>
                        <ENT>27.85645</ENT>
                        <ENT>−92.92310</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>9B</ENT>
                        <ENT>Elvers Bank—B</ENT>
                        <ENT>27.85662</ENT>
                        <ENT>−92.91922</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>9B</ENT>
                        <ENT>Elvers Bank—B</ENT>
                        <ENT>27.85334</ENT>
                        <ENT>−92.91631</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>9B</ENT>
                        <ENT>Elvers Bank—B</ENT>
                        <ENT>27.85076</ENT>
                        <ENT>−92.91727</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>9B</ENT>
                        <ENT>Elvers Bank—B</ENT>
                        <ENT>27.84903</ENT>
                        <ENT>−92.92097</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>9B</ENT>
                        <ENT>Elvers Bank—B</ENT>
                        <ENT>27.85145</ENT>
                        <ENT>−92.92524</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">7</ENT>
                        <ENT>9B</ENT>
                        <ENT>Elvers Bank—B</ENT>
                        <ENT>27.85645</ENT>
                        <ENT>−92.92310</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.97684</ENT>
                        <ENT>−92.58489</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.97749</ENT>
                        <ENT>−92.57716</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.97475</ENT>
                        <ENT>−92.56753</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.97304</ENT>
                        <ENT>−92.56191</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.95173</ENT>
                        <ENT>−92.53902</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.94849</ENT>
                        <ENT>−92.54254</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.96632</ENT>
                        <ENT>−92.56116</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.96792</ENT>
                        <ENT>−92.58152</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.95989</ENT>
                        <ENT>−92.58187</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.95409</ENT>
                        <ENT>−92.57057</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.94951</ENT>
                        <ENT>−92.57135</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.94920</ENT>
                        <ENT>−92.57994</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.95846</ENT>
                        <ENT>−92.60274</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.97286</ENT>
                        <ENT>−92.61901</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">15</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.98096</ENT>
                        <ENT>−92.60158</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">16</ENT>
                        <ENT>10A</ENT>
                        <ENT>McGrail Bank—A</ENT>
                        <ENT>27.97684</ENT>
                        <ENT>−92.58489</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.94116</ENT>
                        <ENT>−92.54750</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.94180</ENT>
                        <ENT>−92.54543</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.94010</ENT>
                        <ENT>−92.54202</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.93616</ENT>
                        <ENT>−92.54151</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.93481</ENT>
                        <ENT>−92.54398</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.93529</ENT>
                        <ENT>−92.54803</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.93859</ENT>
                        <ENT>−92.54901</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">8</ENT>
                        <ENT>10B</ENT>
                        <ENT>McGrail Bank—B</ENT>
                        <ENT>27.94116</ENT>
                        <ENT>−92.54750</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.07909</ENT>
                        <ENT>−92.47305</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.07370</ENT>
                        <ENT>−92.44900</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.07370</ENT>
                        <ENT>−92.44891</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.06544</ENT>
                        <ENT>−92.43518</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.05162</ENT>
                        <ENT>−92.43380</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.03846</ENT>
                        <ENT>−92.44065</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.03463</ENT>
                        <ENT>−92.45289</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.03114</ENT>
                        <ENT>−92.45537</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.02915</ENT>
                        <ENT>−92.46338</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.03154</ENT>
                        <ENT>−92.47259</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.04166</ENT>
                        <ENT>−92.47229</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.04525</ENT>
                        <ENT>−92.46717</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25373"/>
                        <ENT I="01">13</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.04751</ENT>
                        <ENT>−92.47310</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.04676</ENT>
                        <ENT>−92.48308</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">15</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.04866</ENT>
                        <ENT>−92.48462</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">16</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.05687</ENT>
                        <ENT>−92.48145</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">17</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.06388</ENT>
                        <ENT>−92.49262</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">18</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.07018</ENT>
                        <ENT>−92.49141</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">19</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.06974</ENT>
                        <ENT>−92.48613</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">20</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.06594</ENT>
                        <ENT>−92.48098</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">21</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.07109</ENT>
                        <ENT>−92.47708</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">22</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.07683</ENT>
                        <ENT>−92.48071</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">23</ENT>
                        <ENT>11</ENT>
                        <ENT>Bouma Bank</ENT>
                        <ENT>28.07909</ENT>
                        <ENT>−92.47305</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.32652</ENT>
                        <ENT>−92.45356</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.32495</ENT>
                        <ENT>−92.45647</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.32501</ENT>
                        <ENT>−92.45965</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.32796</ENT>
                        <ENT>−92.46626</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.33523</ENT>
                        <ENT>−92.47536</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.34453</ENT>
                        <ENT>−92.47511</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.34840</ENT>
                        <ENT>−92.47439</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.35256</ENT>
                        <ENT>−92.47181</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.35416</ENT>
                        <ENT>−92.46784</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.35456</ENT>
                        <ENT>−92.46135</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.35351</ENT>
                        <ENT>−92.45729</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.35174</ENT>
                        <ENT>−92.45107</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.34852</ENT>
                        <ENT>−92.44564</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.34303</ENT>
                        <ENT>−92.44045</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">15</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.34048</ENT>
                        <ENT>−92.44024</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">16</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.33584</ENT>
                        <ENT>−92.44669</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">17</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.33068</ENT>
                        <ENT>−92.44985</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">18</ENT>
                        <ENT>12</ENT>
                        <ENT>Sonnier Bank</ENT>
                        <ENT>28.32652</ENT>
                        <ENT>−92.45356</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.95420</ENT>
                        <ENT>−92.36641</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.95847</ENT>
                        <ENT>−92.37739</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.95629</ENT>
                        <ENT>−92.38599</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.97297</ENT>
                        <ENT>−92.39248</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.97892</ENT>
                        <ENT>−92.39845</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.98869</ENT>
                        <ENT>−92.39964</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.99372</ENT>
                        <ENT>−92.38244</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.98603</ENT>
                        <ENT>−92.36697</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.98022</ENT>
                        <ENT>−92.36429</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.97442</ENT>
                        <ENT>−92.36996</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.96006</ENT>
                        <ENT>−92.36854</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">12</ENT>
                        <ENT>13</ENT>
                        <ENT>Rezak Bank</ENT>
                        <ENT>27.95420</ENT>
                        <ENT>−92.36641</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.93046</ENT>
                        <ENT>−92.36762</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.91368</ENT>
                        <ENT>−92.37398</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.91462</ENT>
                        <ENT>−92.38530</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.91976</ENT>
                        <ENT>−92.39427</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.92306</ENT>
                        <ENT>−92.38792</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.94525</ENT>
                        <ENT>−92.38305</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.94166</ENT>
                        <ENT>−92.37565</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.94231</ENT>
                        <ENT>−92.37189</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">9</ENT>
                        <ENT>14</ENT>
                        <ENT>Sidner Bank</ENT>
                        <ENT>27.93046</ENT>
                        <ENT>−92.36762</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.95067</ENT>
                        <ENT>−92.00294</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.94177</ENT>
                        <ENT>−91.99762</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.93547</ENT>
                        <ENT>−91.99568</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.92937</ENT>
                        <ENT>−91.99981</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.93224</ENT>
                        <ENT>−92.02999</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.93401</ENT>
                        <ENT>−92.03946</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.93958</ENT>
                        <ENT>−92.05015</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.95012</ENT>
                        <ENT>−92.05050</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.96214</ENT>
                        <ENT>−92.05407</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.96630</ENT>
                        <ENT>−92.04745</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.96869</ENT>
                        <ENT>−92.04120</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.96925</ENT>
                        <ENT>−92.02758</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.96678</ENT>
                        <ENT>−92.02175</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">14</ENT>
                        <ENT>15A</ENT>
                        <ENT>Parker Bank—A</ENT>
                        <ENT>27.95067</ENT>
                        <ENT>−92.00294</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.96082</ENT>
                        <ENT>−91.99450</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.96432</ENT>
                        <ENT>−91.99285</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.96566</ENT>
                        <ENT>−91.99014</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.96385</ENT>
                        <ENT>−91.98600</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25374"/>
                        <ENT I="01">5</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.96149</ENT>
                        <ENT>−91.98639</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.95931</ENT>
                        <ENT>−91.98760</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.95824</ENT>
                        <ENT>−91.99183</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">8</ENT>
                        <ENT>15B</ENT>
                        <ENT>Parker Bank—B</ENT>
                        <ENT>27.96082</ENT>
                        <ENT>−91.99450</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">1</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09726</ENT>
                        <ENT>−91.99328</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">2</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09474</ENT>
                        <ENT>−91.98619</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09569</ENT>
                        <ENT>−91.97526</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09184</ENT>
                        <ENT>−91.97361</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">5</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.08410</ENT>
                        <ENT>−91.97273</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">6</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.07506</ENT>
                        <ENT>−91.97457</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">7</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.07053</ENT>
                        <ENT>−91.98465</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">8</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.06959</ENT>
                        <ENT>−91.99347</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">9</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.06819</ENT>
                        <ENT>−92.00512</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">10</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.07026</ENT>
                        <ENT>−92.01321</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">11</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.07562</ENT>
                        <ENT>−92.02032</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">12</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.08058</ENT>
                        <ENT>−92.02436</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">13</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.08463</ENT>
                        <ENT>−92.02577</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">14</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09024</ENT>
                        <ENT>−92.02296</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">15</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09487</ENT>
                        <ENT>−92.01231</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">16</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09627</ENT>
                        <ENT>−92.00735</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">17</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09507</ENT>
                        <ENT>−92.00008</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">18</ENT>
                        <ENT>16</ENT>
                        <ENT>Alderdice Bank</ENT>
                        <ENT>28.09726</ENT>
                        <ENT>−91.99328</ENT>
                    </ROW>
                </GPOTABLE>
                <P>6. Revise Appendix B to Subpart L of Part 922 to read as follows:</P>
                <HD SOURCE="HD1">Appendix B to Subpart L of Part 922 Flower Garden Banks National Marine Sanctuary—Terms of Designation</HD>
                <HD SOURCE="HD1">Preamble</HD>
                <P>
                    Under the authority of title III of the Marine Protection, Research, and Sanctuaries Act, as amended (“the Act”), 16 U.S.C. 1431 
                    <E T="03">et seq.,</E>
                     19 separate unique polygon areas of ocean waters and the submerged lands thereunder, along the continental shelf and shelf edge in the northwestern Gulf of Mexico, as described in Article II, are hereby designated as Flower Garden Banks National Marine Sanctuary for the purposes of protecting and managing the conservation, ecological, recreation, research, education, historic and aesthetic resources and qualities of these areas.
                </P>
                <HD SOURCE="HD1">Article I—Effect of Designation</HD>
                <P>The Act authorizes the Secretary of Commerce to issue such final regulations as are necessary and reasonable to implement the designation, including managing and protecting the conservation, recreational, ecological, historical, research, educational, and esthetic resources and qualities of a sanctuary. Section 1 of Article IV of this Designation Document lists those activities that may be regulated on the effective date of designation or at some later date in order to protect Sanctuary resources and qualities. Thus, the act of designation empowers the Secretary of Commerce to regulate the activities listed in Section 1. Listing does not necessarily mean that an activity will be regulated; however, if an activity is not listed it may not be regulated, except on an emergency basis, unless Section 1 of Article IV is amended by the same procedures by which the original designation was made.</P>
                <HD SOURCE="HD1">Article II—Description of the Area</HD>
                <P>The Flower Garden Banks National Marine Sanctuary (Sanctuary) boundary encompasses a total area of approximately 121 square nautical miles (160 square miles) of offshore ocean waters, and submerged lands thereunder, along the continental shelf and shelf edge in the northwestern Gulf of Mexico. The entire sanctuary boundary is composed of 19 unique polygons. The precise boundary coordinates for each polygon are listed in Appendix A to this subpart.</P>
                <P>
                    The sanctuary boundary for Polygon 1 begins at Point 1 and continues in numerical order to Point 13 and contains the submerged feature of Stetson Bank with an area of approximately 1.1 square nautical miles (1.5 square miles), located approximately 71 nautical miles (82 miles) south-southeast of Galveston, Texas. The sanctuary boundary for Polygon 2 begins at Point 1 and continues in numerical order to Point 14 and contains the submerged feature of West Flower Garden Bank with an area of approximately 28.0 square nautical miles (37.1 square miles), located approximately 97 nautical miles (111 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 3 begins at Point 1 and continues in numerical order to Point 16 and contains the submerged feature of Horseshoe Bank with an area of approximately 21.7 square nautical miles (28.7 square miles), located approximately 102 nautical miles (117 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 4 begins at Point 1 and continues in numerical order to Point 12 and contains the submerged feature of East Flower Garden Bank with an area of approximately 21.0 square nautical miles (27.8 square miles), located approximately 101 nautical miles (116 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 5 begins at Point 1 and continues in numerical order to Point 12 and contains the submerged feature of MacNeil Bank with an area of approximately 2.1 square nautical miles (2.7 square miles), located approximately 103 nautical miles (118 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 6 begins at Point 1 and continues in numerical order to Point 21 and contains the submerged features of Rankin Bank and 28 Fathom Bank with an area of approximately 4.2 square nautical miles (5.6 square miles), located approximately 109 nautical miles (126 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 7 begins at Point 1 and continues in numerical order to Point 13 and contains the submerged features of Bright Bank with an area of approximately 5.8 square nautical miles (7.6 square miles), located approximately 115 nautical miles (133 
                    <PRTPAGE P="25375"/>
                    miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 8 begins at Point 1 and continues in numerical order to Point 15 and contains the submerged feature of Geyer Bank within an area of approximately 8.7 square nautical miles (11.5 square miles), located approximately 126 nautical miles (145 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 9A begins at Point 1 and continues in numerical order to Point 16 and contains part of the submerged feature of Elvers Bank within an area of approximately 3.3 square nautical miles (4.4 square miles), located approximately 134 nautical miles (154 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 9B begins at Point 1 and continues in numerical order to Point 7 and also contains part of the submerged feature of Elvers Bank within an area of approximately 0.1 square nautical miles (0.2 square miles), located approximately 133 nautical miles (153 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 10A begins at Point 1 and continues in numerical order to Point 16 and contains part of the submerged feature of McGrail Bank with an area of approximately 3.4 square nautical miles (4.5 square miles), located approximately 142 nautical miles (163 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 10B begins at Point 1 and continues in numerical order to Point 8 and also contains part of the submerged feature of McGrail Bank with an area of approximately 0.1 square nautical miles (0.2 square miles), located approximately 146 nautical miles (168 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 11 begins at Point 1 and continues in numerical order to Point 23 and contains the submerged feature of Bouma Bank with an area of approximately 5.8 square nautical miles (7.7 square miles), located approximately 145 nautical miles (167 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 12 begins at Point 1 and continues in numerical order to Point 18 and contains the submerged feature of Sonnier Bank with an area of approximately 2.3 square nautical miles (3.1 square miles), located approximately 138 nautical miles (159 miles) east-southeast of Galveston, Texas. The sanctuary boundary for Polygon 13 begins at Point 1 and continues in numerical order to Point 12 and contains the submerged feature of Rezak Bank with an area of approximately 2.8 square nautical miles (3.7 square miles), located approximately 151 nautical miles (174 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 14 begins at Point 1 and continues in numerical order to Point 9 and contains the submerged feature of Sidner Bank with an area of approximately 1.5 square nautical miles (2.0 square miles), located approximately 153 nautical miles (177 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 15A begins at Point 1 and continues in numerical order to Point 14 and contains part of the submerged feature of Parker Bank within an area of approximately 5.2 square nautical miles (6.8 square miles), located approximately 168 nautical miles (194 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 15B begins at Point 1 and continues in numerical order to Point 8 and also contains part of the submerged feature of Parker Bank within an area of approximately 0.1 square nautical miles (0.2 square miles), located approximately 171 nautical miles (197 miles) southeast of Galveston, Texas. The sanctuary boundary for Polygon 16 begins at Point 1 and continues in numerical order to Point 18 and contains the submerged feature of Alderdice Bank within an area of approximately 3.8 square nautical miles (5.0 square miles), located approximately 166 nautical miles (191 miles) east-southeast of Galveston, Texas.
                </P>
                <HD SOURCE="HD1">Article III—Characteristics of Area That Give it Particular Value</HD>
                <P>The Sanctuary contains a series of underwater features located along the edge of the continental shelf in the northwestern Gulf of Mexico. These features are of interest from both a geological and biological perspective. Formed as the result of the movement of underlying salt deposits (also called salt domes or salt diapirs), and bathed by waters of tropical origin, they contain important geological features, biological habitats and other marine resources of national significance. They contain highly productive marine ecosystems that support a variety of fish and invertebrate communities of biological and economic importance.</P>
                <P>
                    The reefs and banks of the northwestern Gulf of Mexico are structurally complex and contain a range of marine habitats, including coral reefs, coralline algal reefs, algal nodule beds, mesophotic and deepwater reefs, and softbottom communities. The composition, diversity and vertical distribution of benthic communities on the banks are strongly influenced by the physical environment, including water temperature, turbidity and current regime. Geological features of interest include brine seeps, exposed basalt, methane seeps, and mud volcanoes. East and West Flower Garden Banks, the most well-known of the features, sustain the northernmost living coral reefs on the U.S. continental shelf, considered among the healthiest coral reefs in the Caribbean and Western Atlantic region. A deeper water coral reef also exists at McGrail Bank, consisting primarily of large heads of blushing star coral (
                    <E T="03">Stephanocoenia intersepta</E>
                    ) at depths between 140 and 160 feet. These coral reefs are isolated from other reef systems by over 300 nautical miles (342 miles) and exist under hydrographic conditions generally near the northern limit for tropical reef formation. Several other banks, including Stetson, Sonnier, Geyer, and Bright Banks, contain various combinations of non-reef building coral species known collectively as coral communities, comprised of sponges, stony corals, fire coral, leafy algae and coralline algae. The deeper portions of the banks host thriving mid-depth (or “mesophotic”) coral habitats characterized by the presence of both light-dependent and deepwater corals, including black corals, gorgonian corals, and associated organisms. Biological communities are distributed among several interrelated biotic zones, including a coralline algae zone, deep reef rocky outcrops, and soft bottom communities. The complex and biologically productive ecological communities of the banks offer a combination of aesthetic appeal and recreational and research opportunity matched in few other ocean areas.
                </P>
                <P>The following are qualitative descriptions of the individual reefs and banks within the Sanctuary; specific boundary coordinates can be found in Appendix A.</P>
                <HD SOURCE="HD3">a. Stetson Bank, Depth Range 56ft-194ft</HD>
                <P>Boundaries encompass a claystone/siltstone ring feature of mesophotic coral habitat revealed by high resolution multibeam bathymetric surveys, and subsequently ground-truthed by remotely operated vehicle surveys. These features are surface expressions of the salt dome associated with the feature, and provide habitat for sponges, gorgonians, stony branching corals, black corals, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">b. West Flower Garden Bank, Depth Range 59ft-545ft</HD>
                <P>
                    Boundaries encompass mesophotic coral patch reefs to the north, 
                    <PRTPAGE P="25376"/>
                    southwest, and east of the existing sanctuary. These reefs provide coralline algae reef habitat for black corals, gorgonians, stony branching corals, and associated fish and mobile invertebrates.
                </P>
                <HD SOURCE="HD3">c. East Flower Garden Bank, Depth Range 52ft-446ft</HD>
                <P>Boundaries to encompass mesophotic coral patch reefs to the north and southeast of the existing sanctuary. These reefs provide deep coral habitat for dense populations of black corals, gorgonians, stony branching corals, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">d. Horseshoe Bank, Depth Range 243ft-614ft</HD>
                <P>Extensive deepwater habitat and coralline algae reefs in the form of hundreds of patchy outcroppings covering an area of approximately 1.9miles (3km) wide and having 16.4-49.2ft (5-15m) of relief above the seafloor, with dense assemblages of mesophotic black coral, gorgonians, stony branching corals, sponges, algae invertebrates, and fish; several conical-shaped mud volcanoes clustered near the center of the feature, with one rising 328ft (100m) above the sea floor.</P>
                <HD SOURCE="HD3">e. MacNeil Bank, Depth Range 210ft-315ft</HD>
                <P>Deep reef bedrock outcrops and coralline algae patch reefs harboring populations of black corals and gorgonians, sponges, fish, and mobile invertebrates.</P>
                <HD SOURCE="HD3">f. Rankin/28 Fathom Banks, Depth Range 164ft-571ft</HD>
                <P>Rankin Bank is just north of 28 Fathom Bank, and separated from it by a long trough, approximately 1,640-foot (500 m) wide, approximately 6,070-foot (1,850 m) which extends to a depth of approximately 570ft (174 m). The boundaries encompass the shallowest portions of Rankin and 28 Fathom Banks, which harbor coral algae reefs and deep coral reefs with populations of gorgonians, black corals, sponges, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">g. Bright Bank, Depth Range 112ft-384ft</HD>
                <P>Bright Bank previously harbored a coral reef on the very shallowest portions of the bank, which sustained extensive damage from salvage and mining activities employing dynamite for excavation activities. The cap is now considered a coral community, and in spite of these impacts, nine species of shallow water scleractinian corals survive, along with two deeper water species. The feature also harbors extensive coralline algae reefs, providing habitat for populations of gorgonians, black corals, sponges, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">h. Geyer Bank, Depth Range 128ft-722ft</HD>
                <P>Geyer Bank is a broad, relatively flat fault-bounded structure situated on an active salt diaper. This feature supports a coral community, as well as extensive coralline algae reefs and fields of algal nodules including dense fields of macro-algae, black corals, gorgonians, sponges, and associated fish and mobile invertebrates. Seasonal spawning aggregations of fish are associated with this bank, including enormous numbers of reef butterflyfish.</P>
                <HD SOURCE="HD3">i. Elvers Bank, Depth Range 213ft-686ft</HD>
                <P>Two discreet polygons have been developed to protect portions of Elvers Bank: A larger polygon encompassing 4.43 square miles on the south side of the feature, and a small polygon, encompassing 0.19 square miles on the north side of the feature. The shallow areas of the bank feature coralline algae reefs and algal nodule fields, and the deeper areas in the southern polygon harbor large deep reef outcroppings, both providing habitat for black corals, gorgonians, sponges, and associated fish and mobile invertebrates. The deep reefs also harbor glass sponge fields, a feature not documented in any other areas of the sanctuary, as well as a previously undescribed species of black coral.</P>
                <HD SOURCE="HD3">j. McGrail Bank, Depth Range 144ft-512ft</HD>
                <P>
                    Two discreet polygons have been developed to protect portions of McGrail Bank: A larger claw shaped polygon reaching from northwest to southeast, encompassing 4.54 square miles, and a smaller polygon, encompassing 0.17 square miles, situated on the southeast of the feature that wraps around a conical shaped mound. This bank features unique areas of coral reefs dominated by large colonies of the blushing star coral, 
                    <E T="03">Stephanocoenia intersepta,</E>
                     with 28% live coral cover in discrete areas (no other known coral reef is dominated by this species). Pinnacles varying in diameter from ~80 to 395 feet (24-120 m) and as tall as ~25 feet (8 m) are found on the southwest rim of the main feature, along east- and southeast-trending scarps leading away from the bank and in concentric fields to the south and southeast of the bank. A significant portion of the depth zone between 145 and 170 feet is dominated by coral colonies up to 5 feet tall, covering an area of approximately 37 acres. At least 14 species of stony corals have been recorded. Deeper portions of this site harbor mesophotic coral habitat for deep coral, coralline algae reefs, and fields of algal nodules. Dense populations of black corals, gorgonians, macro-algae fields, and associated fish and mobile invertebrates are present.
                </P>
                <HD SOURCE="HD3">k. Sonnier Bank, Depth Range 62ft-210ft</HD>
                <P>Sonnier Bank consists of a series of isolated clusters of pinnacles comprised of uplifted siltstone and claystone, that rise mostly around the perimeter of a single, roughly circular ring 1.9miles (3.2km) in diameter. Two peaks are accessible and popular with recreational scuba divers. The peaks are dominated by coral communities featuring fire coral, sponges, and algae. The deeper portions of the feature are fairly heavily silted, but provide habitat for black corals, gorgonians, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">l. Bouma Bank, Depth Range 187ft-322ft</HD>
                <P>Bouma Bank is dominated by coralline algae reefs and algal nodule fields, providing habitat for populations of black corals, gorgonians, algae, branching stony coral, clusters of cup coral, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">m. Rezak Bank, Depth Range 197ft-430ft</HD>
                <P>Rezak Bank is dominated by coralline algae reefs and extensive algal nodule fields, providing habitat for populations of black corals, gorgonians, algae, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">n. Sidner Bank, Depth Range 190ft-420ft</HD>
                <P>Dominated by coralline algae reefs and extensive algal nodule fields providing habitat for populations of black corals, gorgonians, algae, sponges, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">o. Alderdice Bank, Depth Range 200ft-322ft</HD>
                <P>This feature includes spectacular basalt outcrops of Late Cretaceous origin (approximately 77 million years old) representing the oldest rock exposed on the continental shelf offshore of Louisiana and Texas. The outcrops at Alderdice Bank bear diverse, extremely dense assemblages of gorgonians and black corals, sponges, and swarms of reef fish. Mesophotic coralline algae reef habitats below the spires, silted over in areas, provide habitat for dense populations of black corals, gorgonians, sponges, branching stony corals, fields of macro-algae, and associated fish and mobile invertebrates.</P>
                <HD SOURCE="HD3">p. Parker Bank, Depth Range 187ft-387ft</HD>
                <P>
                    Two discreet polygons have been developed to protect portions of Parker 
                    <PRTPAGE P="25377"/>
                    Bank. A larger polygon bounding the central portion of the features, encompassing 6.82 square miles, and a smaller polygon to the east, encompassing 0.14 square miles. These boundaries protect the shallowest portions of the bank, which harbor coralline algae reefs and algal nodule fields and support populations of plating stony corals, black corals, gorgonians, sponges, macro-algae, and associated fish and mobile invertebrates.
                </P>
                <HD SOURCE="HD1">Article IV—Scope of Regulations</HD>
                <HD SOURCE="HD2">Section 1. Activities Subject to Regulation</HD>
                <P>The following activities are subject to regulation, including prohibition, to the extent necessary and reasonable to ensure the protection and management of the conservation, recreational, ecological, historical, research, educational and esthetic resources and qualities of the area:</P>
                <P>a. Anchoring or otherwise mooring within the Sanctuary;</P>
                <P>b. Discharging or depositing, from within the boundaries of the Sanctuary, any material or other matter;</P>
                <P>c. Discharging or depositing, from beyond the boundaries of the Sanctuary, any material or other matter;</P>
                <P>d. Drilling into, dredging or otherwise altering the seabed of the Sanctuary; or constructing, placing or abandoning any structure, material or other matter on the seabed of the Sanctuary;</P>
                <P>e. Exploring for, developing or producing oil, gas or minerals within the Sanctuary;</P>
                <P>f. Taking, removing, catching, collecting, harvesting, feeding, injuring, destroying or causing the loss of, or attempting to take, remove, catch, collect, harvest, feed, injure, destroy or cause the loss of, a Sanctuary resource;</P>
                <P>g. Possessing within the Sanctuary a Sanctuary resource or any other resource, regardless of where taken, removed, caught, collected or harvested, that, if it had been found within the Sanctuary, would be a Sanctuary resource.</P>
                <P>h. Possessing or using within the Sanctuary any fishing gear, device, equipment or other apparatus.</P>
                <P>i. Possessing or using airguns or explosives or releasing electrical charges within the Sanctuary.</P>
                <P>j. Interfering with, obstructing, delaying or preventing an investigation, search, seizure or disposition of seized property in connection with enforcement of the Act or any regulation or permit issued under the Act.</P>
                <HD SOURCE="HD2">Section 2. Consistency With International Law</HD>
                <P>
                    Any regulation of activities listed in Section 1 of this Article will be applied and enforced as mandated by 16 U.S.C. 1435(a).
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Based on the legislative history of the NMSA, NOAA has long interpreted the text of 16 U.S.C. 1435(a) as encompassing international law, including customary international law.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">Section 3. Emergency Regulations</HD>
                <P>Where necessary to prevent or minimize the destruction of, loss of, or injury to a Sanctuary resource or quality, or minimize the imminent risk of such destruction, loss or injury, any and all activities, including those not listed in section 1 of this Article, are subject to immediate temporary regulation, including prohibition.</P>
                <HD SOURCE="HD1">Article V—Effect on Other Regulations, Leases, Permits, Licenses, and Rights</HD>
                <HD SOURCE="HD2">Section 1. Fishing Regulations, Licenses, and Permits</HD>
                <P>
                    The regulation of fishing is authorized under Article IV. All regulatory programs pertaining to fishing, including fishery management plans promulgated under the Magnuson Fishery Conservation and Management Act, 16 U.S.C. 1801 
                    <E T="03">et seq.,</E>
                     shall remain in effect. Where a valid regulation promulgated under these programs conflicts with a Sanctuary regulation, the regulation deemed by the Secretary of Commerce or designee as more protective of Sanctuary resources and qualities shall govern.
                </P>
                <HD SOURCE="HD2">Section 2. Other Licenses, Regulations, and Permits</HD>
                <P>If any valid regulation issued by any Federal authority of competent jurisdiction, regardless of when issued, conflicts with a Sanctuary regulation, the regulation deemed by the Secretary of Commerce or designee as more protective of Sanctuary resources and qualities shall govern.</P>
                <P>Pursuant to section 304(c)(1) of the Act, 16 U.S.C. 1434(c)(1), no valid lease, permit, license, approval, or other authorization issued by any Federal authority of competent jurisdiction, or any valid right of subsistence use or access, may be terminated by the Secretary of Commerce or designee as a result of this designation or as a result of any Sanctuary regulation if such authorization or right was in existence on the effective date of this designation. However, the Secretary of Commerce or designee may regulate the exercise of such authorization or right consistent with the purposes for which the Sanctuary is designated.</P>
                <P>
                    Accordingly, the prohibitions set forth in the Sanctuary regulations shall not apply to any activity authorized by any valid lease, permit, license, approval, or other authorization in existence on the effective date of Sanctuary designation and issued by any Federal authority of competent jurisdiction, or by any valid right of subsistence use or access in existence on the effective date of Sanctuary designation, provided that the holder of such authorization or right complies with Sanctuary regulations regarding the certification of such authorizations and rights (
                    <E T="03">e.g.,</E>
                     notifies the Secretary or designee of the existence of, requests certification of, and provides requested information regarding such authorization or right) and complies with any terms and conditions on the exercise of such authorization or right imposed as a condition of certification by the Secretary or designee as he or she deems necessary to achieve the purposes for which the Sanctuary was designated.
                </P>
                <P>Pending final agency action on the certification request, such holder may exercise such authorization or right without being in violation of any prohibitions set forth in the Sanctuary regulations, provided the holder is in compliance with Sanctuary regulations regarding certifications.</P>
                <P>The prohibitions set forth in the Sanctuary regulations shall not apply to any activity conducted in accordance with the scope, purpose, terms, and conditions of the National Marine Sanctuary permit issued by the Secretary or designee in accordance with the Sanctuary regulations. Such permits may only be issued if the Secretary or designee finds that the activity for which the permit is applied will: Further research related to Sanctuary resources; further the educational, natural or historical resource value of the Sanctuary; further salvage or recovery operations in or near the Sanctuary in connection with a recent air or marine casualty; or assist in managing the Sanctuary.</P>
                <P>
                    The prohibitions set forth in the sanctuary regulations shall not apply to any activity conducted in accordance with the scope, purpose, terms, and conditions of a Special Use permit issued by the Secretary or designee in accordance with section 310 of the Act. However, in areas where sanctuary regulations prohibit oil, gas, or mineral exploration, development or production, the Secretary or designee may in no event, permit or otherwise, approve such activities in that area. Any leases, licenses, permits, approvals, or other authorizations issued after [EFFECTIVE DATE SANCTUARY 
                    <PRTPAGE P="25378"/>
                    DESIGNATION] authorizing the exploration or production of oil, gas, or minerals in that area shall be invalid.
                </P>
                <HD SOURCE="HD2">Section 3. Department of Defense Activities</HD>
                <P>The prohibitions in § 922.122(a)(2) through (11) do not apply to activities being carried out by the Department of Defense as of the effective date of Sanctuary designation [insert effective date of Sanctuary expansion]. Such activities shall be carried out in a manner that minimizes any adverse impact on Sanctuary resources and qualities. The prohibitions in paragraphs (a)(2) through (11) of this section do not apply to any new activities carried out by the Department of Defense that do not have the potential for any significant adverse impact on Sanctuary resources and qualities. Such activities shall be carried out in a manner that minimizes any adverse impact on Sanctuary resources and qualities. New activities with the potential for significant adverse impact on Sanctuary resources and qualities may be exempted from the prohibitions in paragraphs (a)(2) through (11) of this section by the Director after consultation between the Director and the Department of Defense. If it is determined that an activity may be carried out, such activity shall be carried out in a manner that minimizes any adverse impact on Sanctuary resources and qualities. In the event of threatened or actual destruction of, loss of, or injury to a Sanctuary resource or quality resulting from an untoward incident, including but not limited to spills and groundings, caused by a component of the Department of Defense, the cognizant component shall promptly coordinate with the Director for the purpose of taking appropriate actions to respond to and mitigate the harm and, if possible, restore or replace the Sanctuary resource or quality.</P>
                <HD SOURCE="HD1">Article VI—Alterations to This Designation</HD>
                <P>The terms of designation may be modified only by the same procedures by which the original designation is made, including public hearings, consultation with any appropriate Federal, State, regional and local agencies, review by the appropriate Congressional committees and approval by the Secretary of Commerce or designee.</P>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08128 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-NK-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF THE TREASURY</AGENCY>
                <SUBAGY>Internal Revenue Service</SUBAGY>
                <CFR>26 CFR Part 1</CFR>
                <DEPDOC>[REG-105495-19]</DEPDOC>
                <RIN>RIN 1545-BP21</RIN>
                <SUBJECT>Guidance Related to the Allocation and Apportionment of Deductions and Foreign Taxes, Financial Services Income, Foreign Tax Redeterminations, Foreign Tax Credit Disallowance Under Section 965(g), and Consolidated Groups; Hearing</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Internal Revenue Service (IRS), Treasury.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule; notification of hearing.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This document provides a notice of public hearing on proposed regulations that provide guidance relating to the allocation and apportionment of deductions and creditable foreign taxes, the definition of financial services income, foreign tax redeterminations, availability of foreign tax credits under the transition tax, and the application of the foreign tax credit limitation to consolidated groups.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The public hearing is being held on Wednesday, May 20, 2020, at 10:00 a.m. The IRS must receive speakers' outlines of the topics to be discussed at the public hearing by Monday, May 11, 2020. If no outlines are received by May 11, 2020, the public hearing will be cancelled.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The public hearing is being held by teleconference. Individuals who want to testify (by telephone) at the public hearing must send an email to 
                        <E T="03">publichearings@irs.gov</E>
                         to receive the telephone number and access code for the hearing. The subject line of the email must contain the regulation number REG-105495-19 and the word TESTIFY. For example, the subject line may say: Request to TESTIFY at Hearing for REG-105495-19. The email should also include a copy of the speaker's public comments and outline of topics. The email must be received by May 11, 2020.
                    </P>
                    <P>
                        Individuals who want to attend (by telephone) the public hearing must also send an email to 
                        <E T="03">publichearings@irs.gov</E>
                         to receive the telephone number and access code for the hearing. The subject line of the email must contain the regulation number REG-105495-19 and the word ATTEND. For example, the subject line may say: Request to ATTEND Hearing for REG-105495-19. The email requesting to attend the public hearing must be received by 5:00 p.m. two (2) business days before the date that the hearing is scheduled.
                    </P>
                    <P>
                        The telephonic hearing will be made accessible to people with disabilities. To request special assistance during the telephonic hearing please contact the Publications and Regulations Branch of the Office of Associate Chief Counsel (Procedure and Administration) by sending an email to 
                        <E T="03">publichearings@irs.gov</E>
                         (preferred) or by telephone at (202) 317-5177 (not a toll-free number) at least three (3) days prior to the date that the telephonic hearing is scheduled.
                    </P>
                    <P>
                        Any questions regarding speaking at or attending a public hearing may also be emailed to 
                        <E T="03">publichearings@irs.gov.</E>
                    </P>
                    <P>
                        Send outline submissions electronically via the Federal eRulemaking Portal at 
                        <E T="03">www.regulations.gov</E>
                         (IRS REG-105495-19).
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Concerning the proposed regulations, Jeffrey Cowan at (202) 317- 4924; concerning submissions of comments, the hearing and/access code to attend the hearing by teleconferencing, Regina Johnson at (202) 317-5177 (not toll-free numbers) or 
                        <E T="03">publichearings@irs.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The subject of the public hearing is the notice of proposed rulemaking REG-105495-19 that was published in the 
                    <E T="04">Federal Register</E>
                     on December 17, 2019, 84 FR 69124.
                </P>
                <P>The rules of 26 CFR 601.601(a)(3) apply to the hearing. Persons who wish to present oral comments telephonically at the hearing that submitted written comments by February 18, 2020, must submit an outline of the topics to be addressed and the amount of time to be devoted to each topic by May 11, 2020.</P>
                <P>
                    A period of 10 minutes is allotted to each person for presenting oral comments. After the deadline for receiving outlines has passed, the IRS will prepare an agenda containing the schedule of speakers. Copies of the agenda will be made available, on 
                    <E T="03">Regulations.gov,</E>
                     search IRS and REG-105495-19, or by emailing your request to 
                    <E T="03">publichearings@irs.gov.</E>
                </P>
                <P>Please put “REG-105495-19 Agenda Request” in the subject line of the email.</P>
                <SIG>
                    <NAME>Martin V. Franks,</NAME>
                    <TITLE>Branch Chief, Publications and Regulations Branch, Legal Processing Division, Associate Chief Counsel, (Procedure and Administration).</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08842 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4830-01-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <PRTPAGE P="25379"/>
                <AGENCY TYPE="N">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 52</CFR>
                <DEPDOC>[EPA-R09-OAR-2019-0633; FRL-10008-01—Region 9]</DEPDOC>
                <SUBJECT>Air Plan Approval; Arizona; Maricopa County Air Quality Department and Pima County Department of Environmental Quality</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Environmental Protection Agency (EPA) is proposing to approve revisions to the Maricopa County Air Quality Department (MCAQD) and Pima County Department of Environmental Quality (PDEQ) portion of the Arizona State Implementation Plan (SIP). These revisions concern emissions of particulate matter (PM) from nonmetallic mineral processing, inactive mineral tailings and slag storage. We are proposing to approve local rules to regulate these emission sources under the Clean Air Act (CAA or the Act). We are taking comments on this proposal and plan to follow with a final action.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before June 1, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit your comments, identified by Docket ID No. EPA-R09-OAR-2019-0633 at 
                        <E T="03">https://www.regulations.gov.</E>
                         For comments submitted at 
                        <E T="03">Regulations.gov,</E>
                         follow the online instructions for submitting comments. Once submitted, comments cannot be edited or removed from 
                        <E T="03">Regulations.gov.</E>
                         The EPA may publish any comment received to its public docket. Do not submit electronically any information you consider to be Confidential Business Information (CBI) or other information whose disclosure is restricted by statute. Multimedia submissions (audio, video, etc.) must be accompanied by a written comment. The written comment is considered the official comment and should include discussion of all points you wish to make. The EPA will generally not consider comments or comment contents located outside of the primary submission (
                        <E T="03">i.e.</E>
                         on the web, cloud, or other file sharing system). For additional submission methods, please contact the person identified in the 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section. For the full EPA public comment policy, information about CBI or multimedia submissions, and general guidance on making effective comments, please visit 
                        <E T="03">https://www.epa.gov/dockets/commenting-epa-dockets.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Christine Vineyard, EPA Region IX, 75 Hawthorne St., San Francisco, CA 94105. By phone: (415) 947-4125 or by email at 
                        <E T="03">vineyard.christine@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Throughout this document, “we,” “us” and “our” refer to the EPA.</P>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. The State's Submittal</FP>
                    <FP SOURCE="FP1-2">A. What rules did the State submit?</FP>
                    <FP SOURCE="FP1-2">B. Are there other versions of these rules?</FP>
                    <FP SOURCE="FP1-2">C. What is the purpose of the submitted rule and rule revision?</FP>
                    <FP SOURCE="FP-2">II. The EPA's Evaluation and Action</FP>
                    <FP SOURCE="FP1-2">A. How is the EPA evaluating the rules?</FP>
                    <FP SOURCE="FP1-2">B. Do the rules meet the evaluation criteria?</FP>
                    <FP SOURCE="FP1-2">C. Public Comment and Proposed Action</FP>
                    <FP SOURCE="FP-2">III. Incorporation by Reference</FP>
                    <FP SOURCE="FP-2">IV. Statutory and Executive Order Reviews</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. The State's Submittal</HD>
                <HD SOURCE="HD2">A. What rules did the State submit?</HD>
                <P>Table 1 lists the rules addressed by this proposal with the dates that they were adopted by the local air agencies and submitted by the Arizona Department of Environmental Quality (ADEQ).</P>
                <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="xls50,r50,r100,12,12">
                    <TTITLE>Table 1—Submitted Rules</TTITLE>
                    <BOXHD>
                        <CHED H="1">Local agency</CHED>
                        <CHED H="1">Rule #</CHED>
                        <CHED H="1">Rule title</CHED>
                        <CHED H="1">
                            Adopted/
                            <LI>revised</LI>
                        </CHED>
                        <CHED H="1">Submitted</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">MCAQD</ENT>
                        <ENT>316</ENT>
                        <ENT>Nonmetallic Mineral Processing</ENT>
                        <ENT>11/07/18</ENT>
                        <ENT>11/19/18</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PDEQ</ENT>
                        <ENT>Pima County Code (PCC) Section 17.16.125</ENT>
                        <ENT>
                            Inactive Mineral Tailings Impoundment and Slag Storage Area within the Ajo PM
                            <E T="52">10</E>
                             Planning Area
                        </ENT>
                        <ENT>
                            <SU>1</SU>
                             01/22/19
                        </ENT>
                        <ENT>
                            <SU>2</SU>
                             05/10/19
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    On October 22, 2019,
                    <FTREF/>
                     the EPA determined that the submittal for PCC Section 17.16.125 met the completeness criteria in 40 CFR part 51 Appendix V, which must be met before formal EPA review.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         Pima County Board of Supervisors adopted PCC Section 17.16.125 on January 22, 2019 with an effective date of February 21, 2019.
                    </P>
                    <P>
                        <SU>2</SU>
                         ADEQ submitted PCC Section 17.16.125 as part of a larger SIP revision submittal titled “SIP Revision: Ajo PM
                        <E T="52">10</E>
                         Redesignation Request and Maintenance Plan (May 3, 2019)” (herein referred to as the “Ajo PM
                        <E T="52">10</E>
                         SIP”). More specifically, appendix C of the Ajo PM
                        <E T="52">10</E>
                         SIP includes PCC Section 17.16.125 and the related adoption materials. ADEQ submitted the Ajo PM
                        <E T="52">10</E>
                         SIP electronically on May 10, 2019 under cover of a transmittal letter dated May 8, 2019. Herein, EPA proposes action on the PCC Section 17.16.125 portion of the Ajo PM
                        <E T="52">10</E>
                         SIP. The EPA will be taking action on the rest of the Ajo PM
                        <E T="52">10</E>
                         Plan in a separate action.
                    </P>
                </FTNT>
                <P>On May 19, 2019, the submittal for MCAQD Rule 316 was deemed by operation of law to meet the completeness criteria in 40 CFR part 51 Appendix V, which must be met before formal EPA review.</P>
                <HD SOURCE="HD2">B. Are there other versions of these rules?</HD>
                <P>There is no previous version of PCC Section 17.16.125 in the SIP.</P>
                <P>We approved an earlier version of MCAQD Rule 316 into the SIP on November 13, 2009 (74 FR 58553). The MCAQD adopted a revision to the SIP-approved version on November 7, 2018, and ADEQ submitted it to us on November 19, 2019.</P>
                <HD SOURCE="HD2">C. What is the purpose of the submitted rule and rule revision?</HD>
                <P>
                    Emissions of PM, including PM equal to or less than 2.5 microns in diameter (PM
                    <E T="52">2.5</E>
                    ) and PM equal to or less than 10 microns in diameter (PM
                    <E T="52">10</E>
                    ), contribute to effects that are harmful to human health and the environment, including premature mortality, aggravation of respiratory and cardiovascular disease, decreased lung function, visibility impairment, and damage to vegetation and ecosystems. Section 110(a) of the CAA requires states to submit regulations that control PM emissions. MCAQD Rule 316 controls emissions of PM from commercial and/or industrial nonmetallic mineral processing plants and related operations. MCAQD adopted amendments to Rule 316 in 2018 to clarify the requirements and applicability of the rule and to improve the overall effectiveness of the rule. The Pima County Board of Supervisors adopted PCC Section 17.16.125 to provide permanence and enforceability for control measures that have already been implemented in the Ajo PM
                    <E T="52">10</E>
                     nonattainment area. Under PCC Section 17.16.125, the owner or operator of the mineral tailings impoundment and slag storage area in the Ajo PM
                    <E T="52">10</E>
                     planning area is required to implement and 
                    <PRTPAGE P="25380"/>
                    maintain PM
                    <E T="52">10</E>
                     control measures to meet visible emissions and stabilization requirements to ensure continued PM emissions reductions. The EPA's technical support documents (TSDs) have more information about these rules.
                </P>
                <HD SOURCE="HD1">II. The EPA's Evaluation and Action</HD>
                <HD SOURCE="HD2">A. How is the EPA evaluating the rules?</HD>
                <P>Rules in the SIP must be enforceable (see CAA section 110(a)(2)), must not interfere with applicable requirements concerning attainment and reasonable further progress or other CAA requirements (see CAA section 110(l)), and must not modify certain SIP control requirements in nonattainment areas without ensuring equivalent or greater emissions reductions (see CAA section 193).</P>
                <P>
                    Generally, SIP rules must implement reasonably available control measures (RACM), including reasonably available control technology (RACT), in Moderate PM
                    <E T="52">10</E>
                     nonattainment areas (see CAA sections 172(c)(1) and 189(a)(1)(C)) and Best Available Control Measures (BACM), including Best Available Control Technology (BACT), in Serious PM
                    <E T="52">10</E>
                     nonattainment areas (see CAA section 189(b)(1)(B)). The PDEQ regulates two PM
                    <E T="52">10</E>
                     nonattainment areas classified as Moderate for the PM
                    <E T="52">10</E>
                     national ambient air quality standards (NAAQS) (40 CFR 81.303), one of which is the Ajo PM
                    <E T="52">10</E>
                     planning area. A RACM and RACT evaluation is generally performed in context of a broader attainment plan. The MCAQD regulates the Maricopa County portion of a PM
                    <E T="52">10</E>
                     nonattainment area (
                    <E T="03">i.e.,</E>
                     the Phoenix planning area) classified as Serious for the PM
                    <E T="52">10</E>
                     NAAQS (40 CFR 81.303). A BACM and BACT evaluation is generally performed in context of a broader attainment plan.
                </P>
                <P>Guidance and policy documents that we used to evaluate enforceability, revision/relaxation and rule stringency requirements for the applicable criteria pollutants include the following:</P>
                <P>1. “State Implementation Plans; General Preamble for the Implementation of Title I of the Clean Air Act Amendments of 1990,” 57 FR 13498 (April 16, 1992); 57 FR 18070 (April 28, 1992).</P>
                <P>2. “Issues Relating to VOC Regulation Cutpoints, Deficiencies, and Deviations,” EPA, May 25, 1988 (the Bluebook, revised January 11, 1990).</P>
                <P>3. “Guidance Document for Correcting Common VOC &amp; Other Rule Deficiencies,” EPA Region 9, August 21, 2001 (the Little Bluebook).</P>
                <P>4. “State Implementation Plans for Serious PM-10 Nonattainment Areas, and Attainment Date Waivers for PM-10 Nonattainment Areas Generally; Addendum to the General Preamble for the Implementation of Title I of the Clean Air Act Amendments of 1990,” 59 FR 41998 (August 16, 1994).</P>
                <P>5. “PM-10 Guideline Document,” EPA 452/R-93-008, April 1993.</P>
                <P>6. “Fugitive Dust Background Document and Technical Information Document for Best Available Control Measures,” EPA 450/2-92-004, September 1992.</P>
                <HD SOURCE="HD2">B. Do the rules meet the evaluation criteria?</HD>
                <P>
                    These rules are consistent with CAA requirements and relevant guidance regarding enforceability, RACM or BACM, and SIP revisions. More specifically, with respect to MCAQD Rule 316, we previously determined that the rule implemented BACM for nonmetallic mineral processing within the Phoenix planning area, and we find that the 2018 amendments to the rule relax no control requirements and generally clarify and enhance the effectiveness of the rule. With respect to PCC Section 17.16.125, we find that the rule provides a means to ensure the permanence and enforceability of the fugitive dust controls that have already been implemented in the Ajo PM
                    <E T="52">10</E>
                     planning area and that have brought the area into attainment of the PM
                    <E T="52">10</E>
                     NAAQS. The TSDs have more information on our evaluation.
                </P>
                <HD SOURCE="HD2">C. Public Comment and Proposed Action</HD>
                <P>
                    Pursuant to section 110(k)(3) of the Act, the EPA proposes to fully approve MCAQD Rule 316,
                    <SU>3</SU>
                    <FTREF/>
                     as submitted on November 19, 2018, and PCC Section 17.16.125, as submitted on May 10, 2019, because they fulfill all relevant requirements. We will accept comments from the public on this proposal until June 1, 2020. If we take final action to approve the submitted rules, our final action will incorporate these rules into the federally enforceable SIP.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Final approval of MCAQD Rule 316, as submitted on November 19, 2018, would replace the version of MCAQD Rule 316 that was approved by the EPA at 74 FR 58553 (November 13, 2009) in the Maricopa County portion of the applicable SIP for the State of Arizona.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">III. Incorporation by Reference</HD>
                <P>
                    In this rule, the EPA is proposing to include in a final EPA rule regulatory text that includes incorporation by reference. In accordance with requirements of 1 CFR 51.5, the EPA is proposing to incorporate by reference PCC Section 17.16.125 and MCAQD Rule 316 described in Table 1 of this preamble. The EPA has made, and will continue to make, these materials available through 
                    <E T="03">https://www.regulations.gov</E>
                     and at the EPA Region IX Office (please contact the person identified in the 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                     section of this preamble for more information).
                </P>
                <HD SOURCE="HD1">IV. Statutory and Executive Order Reviews</HD>
                <P>Under the Clean Air Act, the Administrator is required to approve a SIP submission that complies with the provisions of the Act and applicable Federal regulations. 42 U.S.C. 7410(k); 40 CFR 52.02(a). Thus, in reviewing SIP submissions, the EPA's role is to approve state choices, provided that they meet the criteria of the Clean Air Act. Accordingly, this proposed action merely proposes to approve state law as meeting federal requirements and does not impose additional requirements beyond those imposed by state law. For that reason, this proposed action:</P>
                <P>• Is not a “significant regulatory action” subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011);</P>
                <P>• Is not an Executive Order 13771 (82 FR 9339, February 2, 2017) regulatory action because SIP approvals are exempted under Executive Order 12866;</P>
                <P>
                    • Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    • Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4);</P>
                <P>• Does not have federalism implications as specified in Executive Order 13132 (64 FR 43255, August 10, 1999);</P>
                <P>• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);</P>
                <P>• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);</P>
                <P>
                    • Is not subject to requirements of Section 12(d) of the National Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because application of those requirements would be inconsistent with the Clean Air Act; and
                    <PRTPAGE P="25381"/>
                </P>
                <P>• Does not provide the EPA with the discretionary authority to address disproportionate human health or environmental effects with practical, appropriate, and legally permissible methods under Executive Order 12898 (59 FR 7629, February 16, 1994).</P>
                <P>In addition, the SIP is not approved to apply on any Indian reservation land or in any other area where the EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rule does not have tribal implications and will not impose substantial direct costs on tribal governments or preempt tribal law as specified by Executive Order 13175 (65 FR 67249, November 9, 2000).</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 52</HD>
                    <P>Environmental protection, Air pollution control, Incorporation by reference, Intergovernmental relations, Particulate matter, Reporting and recordkeeping requirements.</P>
                </LSTSUB>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                        42 U.S.C. 7401 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <SIG>
                    <DATED>Dated: April 17, 2020.</DATED>
                    <NAME>John Busterud,</NAME>
                    <TITLE>Regional Administrator, Region IX.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08667 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <CFR>40 CFR Part 52</CFR>
                <DEPDOC>[EPA-R04-OAR-2020-0069; FRL-10008-02-Region 4]</DEPDOC>
                <SUBJECT>Air Plan Approval; Georgia: Air Quality Control, VOC Definition</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed rule.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Environmental Protection Agency (EPA) is proposing to approve a State Implementation Plan (SIP) revision submitted by the State of Georgia through the Georgia Environmental Protection Division on October 18, 2019. This revision modifies the State's air quality regulations as incorporated into the SIP by changing the definition of “volatile organic compound” (VOC) to be consistent with federal regulations. EPA is proposing to approve this SIP revision because the State has demonstrated that these changes are consistent with the Clean Air Act (CAA or Act).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received on or before June 1, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit your comments, identified by Docket ID No. EPA-R04-OAR-2020-0069 at 
                        <E T="03">www.regulations.gov.</E>
                         Follow the online instructions for submitting comments. Once submitted, comments cannot be edited or removed from 
                        <E T="03">Regulations.gov</E>
                        . EPA may publish any comment received to its public docket. Do not submit electronically any information you consider to be Confidential Business Information (CBI) or other information whose disclosure is restricted by statute. Multimedia submissions (audio, video, etc.) must be accompanied by a written comment. The written comment is considered the official comment and should include discussion of all points you wish to make. EPA will generally not consider comments or comment contents located outside of the primary submission (
                        <E T="03">i.e.,</E>
                         on the web, cloud, or other file sharing system). For additional submission methods, the full EPA public comment policy, information about CBI or multimedia submissions, and general guidance on making effective comments, please visit 
                        <E T="03">www2.epa.gov/dockets/commenting-epa-dockets.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Sarah LaRocca, Air Regulatory Management Section, Air Planning and Implementation Branch, Air and Radiation Division, U.S. Environmental Protection Agency, Region 4, 61 Forsyth Street SW, Atlanta, Georgia 30303-8960. The telephone number is (404) 562-8994. Ms. LaRocca can also be reached via electronic mail at 
                        <E T="03">larocca.sarah@epa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Background</HD>
                <P>
                    EPA is proposing to approve the change to the Georgia SIP submitted by the State of Georgia through a letter dated October 18, 2019 
                    <SU>1</SU>
                    <FTREF/>
                     that revises the definition of “volatile organic compound” at subparagraph (llll) of Rule 391-3-1-.01—“Definitions” by adding cis-1,1,1,4,4,4-hexafluorobut-2-ene (HFO-1336mzz-Z) to the list of organic compounds having negligible photochemical reactivity.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         EPA received Georgia's SIP revision on October 24, 2019.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         On October 18, 2019, Georgia submitted other SIP revisions which will be addressed in separate actions.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">II. Analysis of State Submission</HD>
                <P>
                    Tropospheric ozone, commonly known as smog, occurs when VOC and nitrogen oxides (NO
                    <E T="52">X</E>
                    ) react in the atmosphere in the presence of sunlight. Because of the harmful health effects of ozone, EPA and state governments implement rules to limit the amount of certain VOC and NO
                    <E T="52">X</E>
                     that can be released into the atmosphere. VOC have different levels of reactivity; they do not react at the same speed or form ozone to the same extent. The CAA requires the regulation of VOC for various purposes. Section 302(s) of the CAA specifies that EPA has the authority to define the meaning of “VOC” under the Act and, hence, what compounds shall be treated as VOC for regulatory purposes.
                </P>
                <P>
                    EPA determines whether a given carbon compound has “negligible” reactivity by comparing the compound's reactivity to the reactivity of ethane. It is EPA's policy that compounds of carbon with negligible reactivity be excluded from the regulatory definition of VOC. 
                    <E T="03">See</E>
                     42 FR 35314 (July 8, 1977), 70 FR 54046 (September 13, 2005). EPA lists these compounds in its regulations at 40 CFR 51.100(s) and excludes them from the definition of VOC. The chemicals on this list are often called “negligibly reactive.” EPA may periodically revise the list of negligibly reactive compounds to add or delete compounds. Georgia submitted this SIP revision in response to EPA adding 
                    <E T="03">cis</E>
                    -1,1,1,4,4,4-hexafluorobut-2-ene to the exclusion list at 40 CFR 51.100(s). 
                    <E T="03">See</E>
                     83 FR 61127 (January 28, 2019). EPA proposes to find that this change to the SIP will not interfere with attainment or maintenance of any national ambient air quality standard, reasonable further progress, or any other applicable requirement of the CAA, consistent with CAA section 110(l), because EPA has found this chemical to be negligibly reactive.
                </P>
                <HD SOURCE="HD1">III. Incorporation by Reference</HD>
                <P>
                    In this document, EPA is proposing to include in a final EPA rule regulatory text that includes incorporation by reference. In accordance with requirements of 1 CFR 51.5, EPA is proposing to incorporate by reference Georgia Rule 391-3-1-.01—“Definitions,” Subparagraph (llll)—“Volatile organic compound,” state-effective September 26, 2019, to revise this definition by adding cis-1,1,1,4,4,4- hexafluorobut-2-ene (HFO-1336mzz-Z) to the list of organic compounds having negligible photochemical reactivity. EPA has made, and will continue to make, these materials generally available through 
                    <E T="03">www.regulations.gov</E>
                     and at the EPA Region 4 office (please contact the person identified in the 
                    <E T="02">For Further Information Contact</E>
                     section of this preamble for more information).
                </P>
                <HD SOURCE="HD1">IV. Proposed Action</HD>
                <P>
                    EPA is proposing to approve Georgia's October 18, 2019 SIP submission that revises the definition of “volatile organic compound” at Rule 391-3-1-
                    <PRTPAGE P="25382"/>
                    .01(llll) to be consistent with federal regulations and CAA requirements.
                </P>
                <HD SOURCE="HD1">V. Statutory and Executive Order Reviews</HD>
                <P>
                    Under the CAA, the Administrator is required to approve a SIP submission that complies with the provisions of the Act and applicable Federal regulations. 
                    <E T="03">See</E>
                     42 U.S.C. 7410(k); 40 CFR 52.02(a). Thus, in reviewing SIP submissions, EPA's role is to approve state choices, provided that they meet the criteria of the CAA. This action merely proposes to approve state law as meeting Federal requirements and does not impose additional requirements beyond those imposed by state law. For that reason, this proposed action:
                </P>
                <P>• Is not a significant regulatory action subject to review by the Office of Management and Budget under Executive Orders 12866 (58 FR 51735, October 4, 1993) and 13563 (76 FR 3821, January 21, 2011;</P>
                <P>• Is not an Executive Order 13771 (82 FR 9339, February 2, 2017) regulatory action because SIP approvals are exempted under Executive Order 12866;</P>
                <P>
                    • Does not impose an information collection burden under the provisions of the Paperwork Reduction Act (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>
                    • Is certified as not having a significant economic impact on a substantial number of small entities under the Regulatory Flexibility Act (5 U.S.C. 601 
                    <E T="03">et seq.);</E>
                </P>
                <P>• Does not contain any unfunded mandate or significantly or uniquely affect small governments, as described in the Unfunded Mandates Reform Act of 1955 (Pub. L. 104-4);</P>
                <P>• Does not have Federalism implications as specified in the Executive Order 13132 (64 FR 43255, August 10, 1999);</P>
                <P>• Is not an economically significant regulatory action based on health or safety risks subject to Executive Order 13045 (62 FR 19885, April 23, 1997);</P>
                <P>• Is not a significant regulatory action subject to Executive Order 13211 (66 FR 28355, May 22, 2001);</P>
                <P>• Is not subject to requirements of Section 12(d) of the national Technology Transfer and Advancement Act of 1995 (15 U.S.C. 272 note) because application of those requirements would be inconsistent with the CAA; and</P>
                <P>• Does not provide EPA with the discretionary authority to address, as appropriate, disproportionate human health or environmental effects, using practicable and legally permissible methods, under Executive Order 12898 (59 FR 7629, February 16, 1994). The SIP is not approved to apply on any Indian reservation land or any other area where EPA or an Indian tribe has demonstrated that a tribe has jurisdiction. In those areas of Indian country, the rule does not have tribal implications as specified by Executive Order 13175 (65 FR 67249, November 9, 2000), nor will it impose substantial direct costs on tribal governments or preempt tribal law.</P>
                <LSTSUB>
                    <HD SOURCE="HED">List of Subjects in 40 CFR Part 52</HD>
                    <P>Environmental protection, Air pollution control, Incorporation by reference, Intergovernmental relations, Ozone, Reporting and recordkeeping requirements, Volatile organic compounds.</P>
                </LSTSUB>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                        42 U.S.C. 7401 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <SIG>
                    <NAME>Mary Walker,</NAME>
                    <TITLE>Regional Administrator, Region 4.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08903 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 6560-50-P</BILCOD>
        </PRORULE>
        <PRORULE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL COMMUNICATIONS COMMISSION</AGENCY>
                <CFR>47 CFR Part 54</CFR>
                <DEPDOC>[WC Docket Nos. 19-126 and 10-90; Report No. 3146; FRS 16673]</DEPDOC>
                <SUBJECT>Petitions for Reconsideration of Action in Proceedings</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Communications Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Petitions for Reconsideration.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Petitions for Reconsideration (Petitions) have been filed in the Commission's proceedings by Cynthia B. Schultz, on behalf of Illinois Office of Broadband; Doug Boone, on behalf of Heartland Telecommunications Company of Iowa d/b/a Premier Communications; and Sarah L.J. Aceves on behalf of Vermont Department of Public Service.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Oppositions to the Petitions must be filed on or before May 18, 2020. Replies to an opposition must be filed on or before May 26, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Federal Communications Commission, 445 12th Street SW, Washington, DC 20554.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Ian Forbes, Wireline Competition Bureau, Telecommunications Access Policy Division, (202) 418-7400.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    This is a summary of the Commission's document, Report No. 3146, released April 14, 2020. Petitions may be accessed online via the Commission's Electronic Comment Filing System at: 
                    <E T="03">http://apps.fcc.gov/ecfs/.</E>
                     The Commission will not send a Congressional Review Act (CRA) submission to Congress or the Government Accountability Office pursuant to the CRA, 5 U.S.C. because no rules are being adopted by the Commission.
                </P>
                <P>
                    <E T="03">Subject:</E>
                     Rural Digital Opportunity Fund, Connect America Fund, FCC 20-5, published at 85 FR 13773, March 10, 2020 in WC Docket Nos. 19-126 and 10-90. This document is being published pursuant to 47 CFR 1.429(e). 
                    <E T="03">See also</E>
                     47 CFR 1.4(b)(1) and 1.429(f), (g).
                </P>
                <P>
                    <E T="03">Number of petitions filed:</E>
                     3.
                </P>
                <SIG>
                    <FP>Federal Communications Commission.</FP>
                    <NAME>Marlene Dortch,</NAME>
                    <TITLE>Secretary, Office of the Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-08721 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 6712-01-P</BILCOD>
        </PRORULE>
    </PRORULES>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Notices</UNITNAME>
    <NOTICES>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="25383"/>
                <AGENCY TYPE="F">DEPARTMENT OF AGRICULTURE</AGENCY>
                <SUBAGY>Agricultural Marketing Service</SUBAGY>
                <DEPDOC>[Doc. No. AMS-LP-20-0025]</DEPDOC>
                <SUBJECT>Request for Extension and Revision of a Currently Approved Information Collection</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Agricultural Marketing Service, USDA.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; request for comments.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995, this notice announces the U.S. Department of Agriculture (USDA) Agricultural Marketing Service's (AMS) intent to request approval from the Office of Management and Budget (OMB), for an extension of and revision to the currently approved information collection used in support of the voluntary grading and certification of meat, meat products, shell eggs, poultry products, rabbit products, and Quality Systems Verification Programs (OMB 0581-0128).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit comments on or before June 30, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit comments concerning this notice by using the electronic process available at 
                        <E T="03">www.regulations.gov.</E>
                         Written comments may also be submitted to Quality Assessment Division; Livestock and Poultry Program; Agricultural Marketing Service, USDA; 1400 Independence Avenue SW, Stop 0258; Washington, DC 20250-0258; or by facsimile to (202) 690-2746. All comments should reference the docket number AMS-LP-20-0025, the date of submission, and the page number of this issue of the 
                        <E T="04">Federal Register</E>
                        . All comments received will be posted without change, including any personal information provided, and will be made available for public inspection at the above physical address during regular business hours.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Julie Hartley, Branch Chief, Quality Assessment Division, at (202) 720-7316, or email 
                        <E T="03">julie.hartley@usda.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Overview of This Information Collection</HD>
                <P>
                    (1) 
                    <E T="03">Agency:</E>
                     USDA, AMS.
                </P>
                <P>
                    (2) 
                    <E T="03">Title:</E>
                     Regulations for Voluntary Grading, Certification, and Standards—7 CFR 54, 56, 62, and 70.
                </P>
                <P>
                    (3) 
                    <E T="03">OMB Number:</E>
                     0581-0128.
                </P>
                <P>
                    (4) 
                    <E T="03">Expiration Date of Approval:</E>
                     August 31, 2020.
                </P>
                <P>
                    (5) 
                    <E T="03">Type of Request:</E>
                     Request for extension of and revision of a currently approved information collection.
                </P>
                <P>
                    (6) 
                    <E T="03">Abstract:</E>
                     The Agricultural Marketing Act of 1946 (AMA) (7 U.S.C. 1621-1627) directs and authorizes the USDA to develop and improve standards of quality, grades, grading programs, and certification services which facilitate the marketing of agricultural products. To provide programs and services, section 203(h) of the AMA (7 U.S.C. 1622(h)) directs and authorizes the Secretary of Agriculture to inspect, certify, and identify the class, quality, quantity, and condition of agricultural products under such rules and regulations as the Secretary may prescribe, including assessment and collection of fees for the cost of service. The regulations in 7 CFR 54, 56, and 70 provide a voluntary program for grading, certification and standards of meats, prepared meats, meat products, shell eggs, poultry products, and rabbit products. The regulation in 7 CFR 62—Quality Systems Verification Programs (QSVP) provides for a collection of voluntary, audit-based, user-fee funded programs that allow applicants to have program documentation and program processes assessed by AMS auditor(s) and other USDA officials.
                </P>
                <P>AMS also provides other types of voluntary services under these regulations, including contract and specification acceptance services and verification of product, processing, further processing, temperature, and quantity. Because this is a voluntary program, respondents request or apply for the specific service they wish, and in doing so, they provide information. The information collected is used only by authorized representatives of USDA (AMS, Livestock and Poultry Program's QAD national and field staff, which includes state agencies) and is used to conduct services requested by respondents. Information collected includes but is not limited to: Total received volume in pounds or cases, volume in pounds of graded, processed and reprocessed products, case volume of graded product, applicant's name, billing and facility address, scheduled hours, and requests for approval of commodity specifications or chemical compounds. AMS is the primary user of the information.</P>
                <P>The information collection requirements in this request are essential to carry out the intent of the AMA, to provide the respondents the type of service they request, and to administer the program.</P>
                <P>
                    (7) 
                    <E T="03">Estimate of Burden:</E>
                     Public reporting burden for this collection of information is estimated to average 0.179 hours per response.
                </P>
                <P>
                    (8) 
                    <E T="03">Respondents:</E>
                     Livestock, meat, poultry, shell egg industries, or other agricultural enterprises; state or local governments; or other businesses or organizations.
                </P>
                <P>
                    (9) 
                    <E T="03">Estimated Number of Respondents:</E>
                     1,639.
                </P>
                <P>
                    (10) 
                    <E T="03">Estimated Number of Responses per Respondent:</E>
                     31.56.
                </P>
                <P>
                    (11) 
                    <E T="03">Estimated Total Annual Responses:</E>
                     51,734.
                </P>
                <P>
                    (12) 
                    <E T="03">Estimated Total Annual Burden on Respondents:</E>
                     9,264.62 hours.
                </P>
                <P>Comments are invited on: (1) Whether the proposed collection of information is necessary for the proper performance of the functions of AMS, including whether the information will have practical utility; (2) the accuracy of AMS' estimate of the burden of the proposed collection of information including the validity of the methodology and assumptions used; (3) ways to enhance the quality, utility, and clarity of the information to be collected; and (4) ways to minimize the burden of the collection of information on those who are to respond, including the use of appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology.</P>
                <P>
                    All responses to this notice will be summarized and included in the request for OMB approval. All responses will become a matter of public record, 
                    <PRTPAGE P="25384"/>
                    including any personal information provided.
                </P>
                <SIG>
                    <NAME>Bruce Summers,</NAME>
                    <TITLE>Administrator, Agricultural Marketing Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09350 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF AGRICULTURE</AGENCY>
                <SUBJECT>Submission for OMB Review; Comment Request</SUBJECT>
                <DATE>April 28, 2020.</DATE>
                <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 June 1, 2020 will be considered. Written comments and recommendations for the proposed information collection should be submitted within 30 days of the publication of this notice on the following website 
                    <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                     Find this particular information collection by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function
                </P>
                <P>An agency may not conduct or sponsor a collection of information unless the collection of information displays a currently valid OMB control number and the agency informs potential persons who are to respond to the collection of information that such persons are not required to respond to the collection of information unless it displays a currently valid OMB control number.</P>
                <HD SOURCE="HD1">Food Safety and Inspection Service</HD>
                <P>
                    <E T="03">Title:</E>
                     Sanitation SOP's Pathogen Reduction/Hazard Analysis and Critical Control Point (HACCP).
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0583-0103.
                </P>
                <P>
                    <E T="03">Summary of Collection:</E>
                     The Food Safety and Inspection Service (FSIS) has been delegated the authority to exercise the functions of the Secretary as provided in the Federal Meat Inspection Act (FMIA) (21 U.S.C. 601) and the Poultry Products Inspection Act (PPIA) (21 U.S.C. 451). These statutes mandate that FSIS protect the public by verifying that meat and poultry products are safe, wholesome, unadulterated, and properly labeled and packaged. FSIS has established requirements applicable to meat and poultry establishments designed to reduce the occurrence and numbers of pathogenic microorganisms on meat and poultry products, reduce the incidence of foodborne illness associated with the consumption of those products, and provide a new framework for modernization of the current system of meat and poultry inspection.
                </P>
                <P>
                    <E T="03">Need and Use of the Information:</E>
                     FSIS will collect information to ensure that (1) establishments have developed and maintained a standard operating plan for sanitation that is used by inspection personnel in performing monitoring regulations; (2) establishments have developed written procedures outlining specimen collection and handling for 
                    <E T="03">E.coli</E>
                     process control verification testing; (3) establishments developed written HAACP plans; (4) establishments will keep records for measurements during slaughter and processing, corrective action, verification check results, and related activities that contain the identity of the product, the product code or slaughter production lot, and the date the record was made; (5) establishments may have prerequisite programs that are designed to provide the basic environmental and operating conditions necessary for the production of safe, wholesome food; and (6) establishments maintain and are able to supply upon request the following information concerning the suppliers of source materials; the name, point of contact, and phone number for the establishment supplying the source materials for the lot of ground beef sampled; and the supplier lot numbers, production dates, and other information that would be useful to know about suppliers.
                </P>
                <P>
                    <E T="03">Description of Respondents:</E>
                     Business or other for-profit.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     6,087.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     Recordkeeping; Reporting: On occasion; Other (daily).
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     7,045,283.
                </P>
                <HD SOURCE="HD1">Food Safety and Inspection Service</HD>
                <P>
                    <E T="03">Title:</E>
                     Procedures for the Notification of New Technology.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0583-0127.
                </P>
                <P>
                    <E T="03">Summary of Collection:</E>
                     The Food Safety and Inspection Service (FSIS) has been delegated the authority to exercise the functions of the Secretary as provided in the Federal Meat Inspection Act (FMIA) (21 U.S.C. 601 
                    <E T="03">et seq.</E>
                    ), the Poultry Products Inspection Act (PPIA) (21 U.S.C. 451 
                    <E T="03">et seq.</E>
                    ), and the Egg Products Inspection Act (EPIA) (21 U.S.C. 1031 
                    <E T="03">et seq.</E>
                    ). These statutes mandate that FSIS protect the public by ensuring that meat, poultry and egg products are safe, wholesome, unadulterated, and properly labeled and packaged. FSIS established flexible procedures to actively encourage the development and use of new technologies in meat and poultry establishments and egg products plants. These procedures facilitate notification to the Agency of any new technology that is intended for use in meat and poultry establishments and egg products plants so that the Agency can decide whether the new technology requires a pre-use review. A pre-use review often includes an in-plant trail.
                </P>
                <P>
                    <E T="03">Need and Use of the Information:</E>
                     FSIS will collect information to determine if a pre-use review is needed, FSIS will request that the firm submit a protocol for an in-plant trial of the new technology. The firm then must submit a protocol that is designed to collect relevant data to support the use of the new technology. To not collect this information would reduce the effectiveness of the meat, poultry, and egg products inspection program.
                </P>
                <P>
                    <E T="03">Description of Respondents:</E>
                     Business or other for-profit.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     210.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     Recordkeeping; Reporting: on occasion.
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     12,800.
                </P>
                <HD SOURCE="HD1">Food Safety and Inspection Service</HD>
                <P>
                    <E T="03">Title:</E>
                     Advanced Meat Recovery Systems.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0583-0130.
                </P>
                <P>
                    <E T="03">Summary of Collection:</E>
                     The Food Safety and Inspection Service (FSIS) has been delegated the authority to exercise the functions of the Secretary as provided in the Federal Meat Inspection Act (FMIA) (21 U.S.C. 601 
                    <E T="03">et seq.</E>
                    ) This statutes mandate that FSIS protect the public by ensuring that meat products are safe, wholesome, not adulterated, and properly labeled and packaged. FSIS requires that official establishments that produce meat from Advanced Meat Recovery (AMR) systems ensure that bones used for AMR 
                    <PRTPAGE P="25385"/>
                    systems do not contain brain, trigeminal ganglia, or spinal cord; to test for calcium (at a different level than previously required), iron, spinal cord, and dorsal root ganglia (DRG); to document their testing protocols, to assess manner that does not cause product to be misbranded or adulterated; and to maintain records of their documentation and test results.
                </P>
                <P>
                    <E T="03">Need and Use of the Information:</E>
                     FSIS will collect information from establishments to ensure that the meat product produced by the use of AMR systems is free from Bovine Spongiform Encephalopathy (BSE).
                </P>
                <P>
                    <E T="03">Description of Respondents:</E>
                     Business or other for-profit.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     47.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     Recordkeeping; Reporting: On occasion.
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     21,259.
                </P>
                <HD SOURCE="HD1">Food Safety and Inspection Service</HD>
                <P>
                    <E T="03">Title:</E>
                     Nutrition Labeling of Major Cuts of Single-Ingredient Raw Meat or Poultry Products. and Ground or Chopped Meat and Poultry Products
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0583-0148.
                </P>
                <P>
                    <E T="03">Summary of Collection:</E>
                     The Food Safety and Inspection Service (FSIS) has been delegated the authority to exercise the functions of the Secretary as provided in the Federal Meat Inspection Act (FMIA) (21 U. S.C. 601 et. seq.) and the Poultry Products Inspection Act (PPIA) (21 U.S.C. 451, 
                    <E T="03">et seq.</E>
                    ) These statutes mandate that FSIS protect the public by verifying that meat and, poultry products are safe, wholesome, not adulterated, and properly labeled and packaged. FSIS requires nutrition labeling of the major cuts of single-ingredients, raw meat and poultry products, unless an exemption applies. FSIS also requires nutrition labels on all ground or chopped meat and poultry products, with or without added seasonings, unless an exemption applies. Further, the nutrition labeling requirements for all ground or chopped meat and poultry products are consistent with the nutrition labeling requirements for multi-ingredient and heat processed products. (9 CFR 381.400(a), 9 CFR 317.300(a), 9 CFR 317.301(a), 9 CFR 381.401(a))
                </P>
                <P>
                    <E T="03">Need and Use of the Information:</E>
                     FSIS requires nutrition labeling of major cuts of single-ingredient, raw meat and poultry products, all ground or chopped meat and poultry products to ensure that consumers will use this information to make better informed nutrition choices when purchasing these meat and poultry products. 
                </P>
                <P>
                    <E T="03">Description of Respondents:</E>
                     Business or other for-profit.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     76,439.
                </P>
                <P>
                    <E T="03">Frequency of Responses:</E>
                     Reporting: On occasion.
                </P>
                <P>
                    <E T="03">Total Burden Hours:</E>
                     67,861.
                </P>
                <SIG>
                    <NAME>Ruth Brown,</NAME>
                    <TITLE>Departmental Information Collection Clearance Officer.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09278 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3410-DM-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF AGRICULTURE</AGENCY>
                <SUBAGY>National Agricultural Statistics Service</SUBAGY>
                <SUBJECT>Notice of Intent To Request Revision and Extension of a Currently Approved Information Collection</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Agricultural Statistics Service, USDA.</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 this notice announces the intention of the National Agricultural Statistics Service (NASS) to request revision to the currently approved information collection, the Honey and Honey Bee survey docket (0535-0153. Revision to burden hours will be needed due to changes in the size of the target population, sample design, and the discontinuation of the Bee and Honey Survey for operations with less than five colonies.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments on this notice must be received by June 30, 2020 to be assured of consideration.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by docket number 0535-0153, by any of the following methods:</P>
                    <P>
                        • 
                        <E T="03">Email: ombofficer@nass.usda.gov.</E>
                         Include docket number above in the subject line of the message.
                    </P>
                    <P>
                        • 
                        <E T="03">Efax:</E>
                         (855) 838-6382.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Mail any paper, disk, or CD-ROM submissions to: David Hancock, NASS Clearance Officer, U.S. Department of Agriculture, Room 5336 South Building, 1400 Independence Avenue SW, Washington, DC 20250-2024.
                    </P>
                    <P>
                        • 
                        <E T="03">Hand Delivery/Courier:</E>
                         Hand deliver to: David Hancock, NASS Clearance Officer, U.S. Department of Agriculture, Room 5336 South Building, 1400 Independence Avenue SW, Washington, DC 20250-2024.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kevin L. Barnes, Associate Administrator, National Agricultural Statistics Service, U.S. Department of Agriculture, (202)720-2707. Copies of this information collection and related instructions can be obtained without charge from David Hancock, NASS—OMB Clearance Officer, at (202)690-2388 or at 
                        <E T="03">ombofficer@nass.usda.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    <E T="03">Title:</E>
                     Honey and Honey Bee Surveys.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0535-0153.
                </P>
                <P>
                    <E T="03">Expiration Date of Approval:</E>
                     November 30, 2020.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     Intent to revise and extend a currently approved information collection for a period of three years.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     The primary objective of the National Agricultural Statistics Service (NASS) is to prepare and issue state and national estimates of crop and livestock production, livestock products, prices, and disposition; as well as economic statistics, environmental statistics related to agriculture, and also to conduct the Census of Agriculture.
                </P>
                <P>In this request for renewal of the Honey and Honey Bee (0535-0153) docket, NASS will keep the Bee and Honey Inquiry (operations with 5 or more colonies) and the Quarterly Colony Loss survey relatively the same. The samples are adjusted so that the same group of operators who qualify for the honey production survey also qualify for the colony loss survey. The Bee and Honey Production and Loss Inquiry (operations with less than 5 colonies) was discontinued and last published in 2018.</P>
                <P>As pollinators, honey bees are vital to the agricultural industry for producing food for the world's population. Additional data is needed to accurately describe the costs associated with pest/disease control, wintering fees, and replacement worker and queen bees. USDA and the Environmental Protection Agency (EPA), in consultation with other relevant Federal partners, are scaling up efforts to address the decline of honey bee health with a goal of ensuring the recovery of this critical subset of pollinators. NASS supports the Pollinator Research Action Plan, published May 19, 2015, which emphasizes the importance of coordinated action to identify the extent and causal factors in honey bee mortality.</P>
                <P>
                    <E T="03">Authority:</E>
                     These data will be collected under the authority of 7 U.S.C. 2204(a). Individually identifiable data collected under this authority are governed by Section 1770 of the Food Security Act of 1985, 7 U.S.C. 2276, which requires USDA to afford strict confidentiality to non-aggregated data provided by respondents. This notice is submitted in accordance with the Paperwork Reduction Act of 1995 Public Law 104-13 (44 U.S.C. 3501, 
                    <E T="03">et seq.</E>
                    ) and Office of Management and Budget regulations at 5 CFR part 1320. 
                    <PRTPAGE P="25386"/>
                    NASS also complies with OMB Implementation Guidance, “Implementation Guidance for Title V of the E-Government Act, Confidential Information Protection and Statistical Efficiency Act of 2002 (CIPSEA),” 
                    <E T="04">Federal Register</E>
                    , Vol. 72, No. 115, June 15, 2007, p. 33362.
                </P>
                <P>
                    <E T="03">Estimate of Burden:</E>
                     Public reporting burden for this collection of information for operations with five or more colonies is estimated to average 20 minutes per response for the annual Bee and Honey survey and 15 minutes per respondent for the quarterly Colony Loss Survey. Operations with less than five colonies will be excluded from this renewal request which will reduce overall respondent burden by an estimated 2,100 hours. Publicity materials and instruction sheets will account for 5 minutes of additional burden per respondent. Respondents who refuse to complete a survey will be allotted 2 minutes of burden per attempt to collect the data.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Farmers.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     12,200.
                </P>
                <P>
                    <E T="03">Estimated Total Annual Burden on Respondents:</E>
                     With an estimated response rate of approximately 80%, we estimate the total burden to be approximately 7,500 hours.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     Comments are invited on: (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 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 those who are to respond, through the use of appropriate automated, electronic, mechanical, technological or other forms of information technology collection methods.
                </P>
                <P>All responses to this notice will become a matter of public record and be summarized in the request for OMB approval.</P>
                <SIG>
                    <DATED>Signed at Washington, DC, April 23, 2020.</DATED>
                    <NAME>Kevin L. Barnes,</NAME>
                    <TITLE>Associate Administrator.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09272 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3410-20-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF AGRICULTURE</AGENCY>
                <SUBAGY>Office of Partnerships and Public Engagement</SUBAGY>
                <SUBJECT>Advisory Committee on Beginning Farmers and Ranchers</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Partnerships and Public Engagement (OPPE), U.S. Department of Agriculture (USDA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of public teleconference.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Notice is hereby given, pursuant to the provisions of the rules and regulations of the Department of Agriculture and the Federal Advisory Committee Act (FACA), that a public teleconference of the Advisory Committee on Beginning Farmers and Ranchers (ACBFR) will be held to discuss the impact of COVID-19 on beginning farmers and ranchers. The purpose of the ACBFR meeting is to deliberate upon matters concerning beginning farmers and ranchers that provide advice and recommendations for the Secretary.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The public conference call will be held on May 19, 2020 at 2:00-4:00 Eastern Standard Time (EST).</P>
                    <P>
                        <E T="03">Public Call-in Information:</E>
                         Interested members of the public may listen to the discussion by calling the following toll-free conference call-in number: Conference call-in number: Dial: 866-816-7252 Conference ID: 6188761.
                    </P>
                    <P>Please be advised that before placing them into the conference call, the operator will ask callers to provide their names, their organizational affiliations (if any), and email addresses (so that callers may be notified of future meetings). Callers can expect to incur charges for calls they initiate over wireless lines, and the USDA will not refund any incurred charges. Callers will incur no charge for calls they initiate over land-line connections to the toll-free conference call-in number.</P>
                    <P>
                        <E T="03">Public Comments:</E>
                         Written comments for the Committee's consideration may be submitted to email: 
                        <E T="03">ACBeginningFarmersandRanchers@usda.gov.</E>
                         Written comments must be received by May 18, 2020.
                    </P>
                    <P>Public written comments will be considered by the Advisory Committee on Beginning Farmers and Ranchers at the meeting. Also, these written comments will be available in the notes/minutes of the May 19, 2020 conference call meeting and will be maintained in the public record of the federal advisory committee at USDA.</P>
                    <P>
                        <E T="03">Availability of Materials for the Meeting:</E>
                         General information about the ACBFR as well as any updates concerning the meeting announced in this notice, may be found on the ACBFR website at 
                        <E T="03">https://www.usda.gov/partnerships/advisory-committee-on-beginning-farmers-and-ranchers.</E>
                    </P>
                    <P>
                        <E T="03">Accessibility:</E>
                         USDA is committed to ensuring that all persons are included in our programs and events. If you are a person with a disability and require reasonable accommodations to participate in this meeting Please contact Maria Goldberg at 
                        <E T="03">maria.goldberg@usda.gov</E>
                         or at (202)720-6350.
                    </P>
                    <P>Individuals who use telecommunication devices for the deaf (TDD) may call the Federal Information Relay Service (FIRS) at 1-800-877-8339 between 8:00 a.m. and 8:00 p.m., Eastern Standard Time, Monday through Friday.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Any member of the public wishing to obtain information concerning this public meeting may contact Maria Goldberg, Designated Federal Officer (DFO), at 
                        <E T="03">Maria.goldberg@usda.gov</E>
                         or at (202) 720-6350.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Committee was originally established pursuant to Section 5(b) of the Agricultural Credit Improvement Act of 1992, 7 U.S.C. 1929 note (2008) ACBFR, as amended; and is established and managed in accordance with the provisions of the Federal Advisory Committee Act (FACA), as amended, 5 U.S.C. App. 2.</P>
                <P>The Committee is to meet and review comments on beginning farmer and rancher policy and program issues and collaborate to make recommendations to the Secretary. The Committee shall advise the Secretary on matters broadly affecting new farmers and ranchers. The Committee shall consider Department goals and objectives necessary to implement prior recommendations and develop and recommend a framework and overall strategy.</P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Cikena Reid,</NAME>
                    <TITLE>USDA Committee Management Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09292 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <SUBJECT>Initiation of Five-Year (Sunset) 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>
                        In accordance with the Tariff Act of 1930, as amended (the Act), the 
                        <PRTPAGE P="25387"/>
                        Department of Commerce (Commerce) is automatically initiating the five-year reviews (Sunset Reviews) of the antidumping and countervailing duty (AD/CVD) order(s) listed below. The International Trade Commission (the ITC) is publishing concurrently with this notice its notice of 
                        <E T="03">Institution of Five-Year Reviews</E>
                         which covers the same order(s).
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable May 1, 2020.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Commerce official identified in the 
                        <E T="03">Initiation of Review</E>
                         section below at AD/CVD Operations, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230. For information from the ITC, contact Mary Messer, Office of Investigations, U.S. International Trade Commission at (202) 205-3193.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    Commerce's procedures for the conduct of Sunset Reviews are set forth in its 
                    <E T="03">Procedures for Conducting Five-Year (Sunset) Reviews of Antidumping and Countervailing Duty Orders,</E>
                     63 FR 13516 (March 20, 1998) and 70 FR 62061 (October 28, 2005). Guidance on methodological or analytical issues relevant to Commerce's conduct of Sunset Reviews is set forth in 
                    <E T="03">Antidumping Proceedings: Calculation of the Weighted-Average Dumping Margin and Assessment Rate in Certain Antidumping Duty Proceedings; Final Modification,</E>
                     77 FR 8101 (February 14, 2012).
                </P>
                <HD SOURCE="HD1">Initiation of Review</HD>
                <P>In accordance with section 751(c) of the Act and 19 CFR 351.218(c), we are initiating the Sunset Reviews of the following antidumping and countervailing duty order(s):</P>
                <GPOTABLE COLS="5" OPTS="L2,tp0,i1" CDEF="xs54,12,xs54,r50,r50">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">DOC case No.</CHED>
                        <CHED H="1">ITC case No.</CHED>
                        <CHED H="1">Country</CHED>
                        <CHED H="1">Product</CHED>
                        <CHED H="1">Commerce contact</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">A-122-853 </ENT>
                        <ENT>731-TA-1151 </ENT>
                        <ENT>Canada </ENT>
                        <ENT>Citric Acid and Certain Citrate Salts (2nd Review)</ENT>
                        <ENT>Matthew Renkey; (202) 482-2312.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">A-570-937 </ENT>
                        <ENT>731-TA-1152 </ENT>
                        <ENT>China </ENT>
                        <ENT>Citric Acid and Certain Citrate Salts (2nd Review)</ENT>
                        <ENT>Matthew Renkey; (202) 482-2312.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">C-570-938 </ENT>
                        <ENT>701-TA-456 </ENT>
                        <ENT>China </ENT>
                        <ENT>Citric Acid and Certain Citrate Salts (2nd Review)</ENT>
                        <ENT>Mary Kolberg; (202) 482-1785.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Filing Information</HD>
                <P>
                    As a courtesy, we are making information related to sunset proceedings, including copies of the pertinent statute and Commerce's regulations, Commerce's schedule for Sunset Reviews, a listing of past revocations and continuations, and current service lists, available to the public on Commerce's website at the following address: 
                    <E T="03">https://enforcement.trade.gov/sunset/.</E>
                     All submissions in these Sunset Reviews must be filed in accordance with Commerce's regulations regarding format, translation, and service of documents. These rules, including electronic filing requirements via Enforcement and Compliance's Antidumping and Countervailing Duty Centralized Electronic Service System (ACCESS), can be found at 19 CFR 351.303.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See also Antidumping and Countervailing Duty Proceedings: Electronic Filing Procedures; Administrative Protective Order Procedures,</E>
                         76 FR 39263 (July 6, 2011).
                    </P>
                </FTNT>
                <P>
                    Any party submitting factual information in an AD/CVD proceeding must certify to the accuracy and completeness of that information.
                    <SU>2</SU>
                    <FTREF/>
                     Parties must use the certification formats provided in 19 CFR 351.303(g).
                    <SU>3</SU>
                    <FTREF/>
                     Commerce intends to reject factual submissions if the submitting party does not comply with applicable revised certification requirements.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See</E>
                         section 782(b) of the Act.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See also Certification of Factual Information to Import Administration During Antidumping and Countervailing Duty Proceedings,</E>
                         78 FR 42678 (July 17, 2013) (
                        <E T="03">Final Rule</E>
                        ). Answers to frequently asked questions regarding the 
                        <E T="03">Final Rule</E>
                         are available at 
                        <E T="03">http://enforcement.trade.gov/tlei/notices/factual_info_final_rule_FAQ_07172013.pdf.</E>
                    </P>
                </FTNT>
                <P>
                    On April 10, 2013, Commerce modified two regulations related to AD/CVD proceedings: the definition of factual information (19 CFR 351.102(b)(21)), and the time limits for the submission of factual information (19 CFR 351.301).
                    <SU>4</SU>
                    <FTREF/>
                     Parties are advised to review the final rule, available at 
                    <E T="03">https://enforcement.trade.gov/frn/2013/1304frn/2013-08227.txt,</E>
                     prior to submitting factual information in these segments. To the extent that other regulations govern the submission of factual information in a segment (such as 19 CFR 351.218), these time limits will continue to be applied. Parties are also advised to review the final rule concerning the extension of time limits for submissions in AD/CVD proceedings, available at 
                    <E T="03">https://enforcement.trade.gov/frn/2013/1309frn/2013-22853.txt,</E>
                     prior to submitting factual information in these segments.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See Definition of Factual Information and Time Limits for Submission of Factual Information: Final Rule,</E>
                         78 FR 21246 (April 10, 2013).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See Extension of Time Limits,</E>
                         78 FR 57790 (September 20, 2013).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Letters of Appearance and Administrative Protective Orders</HD>
                <P>
                    Pursuant to 19 CFR 351.103(d), Commerce will maintain and make available a public service list for these proceedings. Parties wishing to participate in any of these five-year reviews must file letters of appearance as discussed at 19 CFR 351.103(d)). To facilitate the timely preparation of the public service list, it is requested that those seeking recognition as interested parties to a proceeding submit an entry of appearance within 10 days of the publication of the Notice of Initiation. Because deadlines in Sunset Reviews can be very short, we urge interested parties who want access to proprietary information under administrative protective order (APO) to file an APO application immediately following publication in the 
                    <E T="04">Federal Register</E>
                     of this notice of initiation. Commerce's regulations on submission of proprietary information and eligibility to receive access to business proprietary information under APO can be found at 19 CFR 351.304-306. Note that Commerce has temporarily modified certain of its requirements for serving documents containing business proprietary information, until May 19, 2020, unless extended.
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See Temporary Rule Modifying AD/CVD Service Requirements Due to</E>
                         COVID-19, 85 FR 17006 (March 26, 2020).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Information Required From Interested Parties</HD>
                <P>
                    Domestic interested parties, as defined in section 771(9)(C), (D), (E), (F), and (G) of the Act and 19 CFR 351.102(b), wishing to participate in a Sunset Review must respond not later than 15 days after the date of publication in the 
                    <E T="04">Federal Register</E>
                     of this notice of initiation by filing a notice of intent to participate. The required contents of the notice of intent to 
                    <PRTPAGE P="25388"/>
                    participate are set forth at 19 CFR 351.218(d)(1)(ii). In accordance with Commerce's regulations, if we do not receive a notice of intent to participate from at least one domestic interested party by the 15-day deadline, Commerce will automatically revoke the order without further review.
                    <SU>7</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         19 CFR 351.218(d)(1)(iii).
                    </P>
                </FTNT>
                <P>
                    If we receive an order-specific notice of intent to participate from a domestic interested party, Commerce's regulations provide that 
                    <E T="03">all parties</E>
                     wishing to participate in a Sunset Review must file complete substantive responses not later than 30 days after the date of publication in the 
                    <E T="04">Federal Register</E>
                     of this notice of initiation. The required contents of a substantive response, on an order-specific basis, are set forth at 19 CFR 351.218(d)(3). Note that certain information requirements differ for respondent and domestic parties. Also, note that Commerce's information requirements are distinct from the ITC 's information requirements. Consult Commerce's regulations for information regarding Commerce's conduct of Sunset Reviews. Consult Commerce's regulations at 19 CFR part 351 for definitions of terms and for other general information concerning antidumping and countervailing duty proceedings at Commerce.
                </P>
                <P>This notice of initiation is being published in accordance with section 751(c) of the Act and 19 CFR 351.218(c).</P>
                <SIG>
                    <DATED>Dated: April 21, 2020.</DATED>
                    <NAME>James Maeder,</NAME>
                    <TITLE>Deputy Assistant Secretary for Antidumping and Countervailing Duty Operations.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09330 Filed 4-30-20; 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>North American Free Trade Agreement (NAFTA), Article 1904 Binational Panel Review: Notice of Request for Panel Review</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>United States Section, NAFTA Secretariat, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of NAFTA Request for Panel Review in the matter of Certain Fabricated Structural Steel from Canada; injury determination (Secretariat file number: USA-CDA-2020-1904-05).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        A Request for Panel Review was filed on behalf of the Government of Canada, Canadian Institute of Steel Construction, Canam Group, Inc., Canatal Industries, Inc., and Walters Inc. with the United States Section of the NAFTA Secretariat on April 17, 2020, pursuant to NAFTA Article 1904. Panel Review was requested of the U.S. International Trade Commission's final negative injury determination regarding Certain Fabricated Structural Steel from Canada. The final determination was published in the 
                        <E T="04">Federal Register</E>
                         on March 20, 2020. The NAFTA Secretariat has assigned case number USA-CDA-2020-1904-05 to this request.
                    </P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Paul E. Morris, United States Secretary, NAFTA Secretariat, Room 2061, 1401 Constitution Avenue NW, Washington, DC 20230, 202-482-5438.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Chapter 19 of Article 1904 of NAFTA provides a dispute settlement mechanism involving trade remedy determinations issued by the Government of the United States, the Government of Canada, and the Government of Mexico. Following a Request for Panel Review, a Binational Panel is composed to review the trade remedy determination being challenged and issue a binding Panel Decision. There are established NAFTA 
                    <E T="03">Rules of Procedure for Article 1904 Binational Panel Reviews,</E>
                     which were adopted by the three governments for panels requested pursuant to Article 1904(2) of NAFTA which requires Requests for Panel Review to be published in accordance with Rule 35. For the complete Rules, please see 
                    <E T="03">https://www.nafta-sec-alena.org/Home/Texts-of-the-Agreement/Rules-of-Procedure/Article-1904.</E>
                </P>
                <P>The Rules provide that:</P>
                <P>(a) A Party or interested person may challenge the final determination in whole or in part by filing a Complaint in accordance with Rule 39 within 30 days after the filing of the first Request for Panel Review (the deadline for filing a Complaint is May 18, 2020);</P>
                <P>(b) A Party, investigating authority or interested person that does not file a Complaint but that intends to appear in support of any reviewable portion of the final determination may participate in the panel review by filing a Notice of Appearance in accordance with Rule 40 within 45 days after the filing of the first Request for Panel Review (the deadline for filing a Notice of Appearance is June 1, 2020); and</P>
                <P>(c) The panel review shall be limited to the allegations of error of fact or law, including challenges to the jurisdiction of the investigating authority, that are set out in the Complaints filed in the panel review and to the procedural and substantive defenses raised in the panel review.</P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Paul E. Morris,</NAME>
                    <TITLE>U.S. Secretary, NAFTA Secretariat.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09314 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-GT-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <SUBJECT>North American Free Trade Agreement (NAFTA), Article 1904; Binational Panel Review: Notice of Request for Panel Review</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>United States Section, NAFTA Secretariat, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of NAFTA Request for Panel Review in the matter of Certain Fabricated Structural Steel from Mexico; injury determination (Secretariat file number: USA-MEX-2020-1904-04).</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        Requests for Panel Review were filed on behalf of BlueScope Buildings North America Inc. and Butler de Mexico; Cornerstone Building Brands, Inc. and Building Systems de Mexico, S.A. de C.V. and the Government of Mexico; and Corey S.A. de C.V. with the United States Section of the NAFTA Secretariat on April 16, 17, and 20, 2020 respectively, pursuant to NAFTA Article 1904. Panel Reviews were requested of the U.S. International Trade Commission's final negative injury determination regarding Certain Fabricated Structural Steel Injury from Mexico. The final determination was published in the 
                        <E T="04">Federal Register</E>
                         on March 20, 2020. The NAFTA Secretariat has assigned case number USA-MEX-2020-1904-04 to this request.
                    </P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Paul E. Morris, United States Secretary, NAFTA Secretariat, Room 2061, 1401 Constitution Avenue NW, Washington, DC 20230, 202-482-5438.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Chapter 19 of Article 1904 of NAFTA provides a dispute settlement mechanism involving trade remedy determinations issued by the Government of the United States, the Government of Canada, and the Government of Mexico. Following a Request for Panel Review, a Binational Panel is composed to review the trade remedy determination being challenged and issue a binding Panel Decision. There are established NAFTA 
                    <E T="03">Rules of Procedure for Article 1904 Binational Panel Reviews,</E>
                     which were adopted by the three governments for panels requested pursuant to Article 1904(2) of 
                    <PRTPAGE P="25389"/>
                    NAFTA which requires Requests for Panel Review to be published in accordance with Rule 35. For the complete Rules, please see 
                    <E T="03">https://www.nafta-sec-alena.org/Home/Texts-of-the-Agreement/Rules-of-Procedure/Article-1904.</E>
                </P>
                <P>The Rules provide that:</P>
                <P>(a) A Party or interested person may challenge the final determination in whole or in part by filing a Complaint in accordance with Rule 39 within 30 days after the filing of the first Request for Panel Review (the deadline for filing a Complaint is May 18, 2020);</P>
                <P>(b) A Party, investigating authority or interested person that does not file a Complaint but that intends to appear in support of any reviewable portion of the final determination may participate in the panel review by filing a Notice of Appearance in accordance with Rule 40 within 45 days after the filing of the first Request for Panel Review (the deadline for filing a Notice of Appearance is June 1, 2020); and</P>
                <P>(c) The panel review shall be limited to the allegations of error of fact or law, including challenges to the jurisdiction of the investigating authority, that are set out in the Complaints filed in the panel review and to the procedural and substantive defenses raised in the panel review.</P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Paul E. Morris,</NAME>
                    <TITLE>U.S. Secretary, NAFTA Secretariat. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09341 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 3510-GT-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[A-489-837]</DEPDOC>
                <SUBJECT>Certain Quartz Surface Products From the Republic of Turkey: Final Determination of Sales at Less Than Fair Value and Final Negative Determination of Critical Circumstances</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 Department of Commerce (Commerce) determines that certain quartz surface products (quartz surface products) from the Republic of Turkey (Turkey), are being or are likely to be, sold in the United States at less than fair value (LTFV) during the period of investigation (POI) April 1, 2018 through March 31, 2019.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable May 1, 2020.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Laurel LaCivita or Kyle Clahane, 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-4243 or (202) 482-5449, respectively.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On December 13, 2019, Commerce published the 
                    <E T="03">Preliminary Determination</E>
                     in this investigation.
                    <SU>1</SU>
                    <FTREF/>
                     A summary of the events that occurred since Commerce published the 
                    <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, which is hereby adopted by this notice.
                    <SU>2</SU>
                    <FTREF/>
                     A list of the issues raised in this memorandum is attached to this notice as Appendix II.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Certain Quartz Surface Products from the Republic of Turkey: Preliminary Affirmative Determination of Sales at Less Than Fair Value, Preliminary Negative Determination of Critical Circumstances, Postponement of Final Determination, and Extension of Provisional Measures,</E>
                         84 FR 68111 (December 13, 2019) (
                        <E T="03">Preliminary Determination</E>
                        ) and accompanying Preliminary Decision Memorandum.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Issues and Decision Memorandum for the Final Affirmative Determination in the Antidumping Duty Investigation of Certain Quartz Surface Products from the Republic of Turkey,” dated concurrently with, and hereby adopted by, this notice (Issues and Decision Memorandum).
                    </P>
                </FTNT>
                <P>
                    The Issues and Decision Memorandum is a public document and is available 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 at 
                    <E T="03">http://enforcement.trade.gov/frn/index.html.</E>
                     The signed and electronic versions of the Issues and Decision Memorandum are identical in content.
                </P>
                <HD SOURCE="HD1">Period of Investigation</HD>
                <P>The POI is April 1, 2018 through March 31, 2019.</P>
                <HD SOURCE="HD1">Scope of the Investigation</HD>
                <P>
                    The products covered by this investigation are quartz surface products from Turkey. For a full description of the scope of this investigation, 
                    <E T="03">see</E>
                     the “Scope of the Investigation” in Appendix I of this notice.
                </P>
                <HD SOURCE="HD1">Scope Comments</HD>
                <P>
                    On December 4, 2019, we issued a Preliminary Scope Memorandum.
                    <SU>3</SU>
                    <FTREF/>
                     We received no scope case briefs from interested parties. Therefore, Commerce has made no changes to the scope of this investigation since the 
                    <E T="03">Preliminary Determination.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Certain Quartz Surface Products from India and Turkey: Preliminary Scope Decision Memorandum,” dated December 4, 2019.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Analysis of Comments Received</HD>
                <P>All issues raised in the case briefs and rebuttal briefs submitted by interested parties in this proceeding are discussed in the Issues and Decision Memorandum. A list of the issues raised by parties and responded to by Commerce in the Issues and Decision Memorandum is attached at Appendix II.</P>
                <HD SOURCE="HD1">Verification</HD>
                <P>As provided in section 782(i) of the Tariff Act of 1930, as amended (the Act), Commerce verified the sales and cost data reported by Belenco dis Tikaret A.Ş. (Belenco), and Ermaş Madencilik Turizm Sanayi Ve Ticaret Anonim Şirketi (Ermaş) for use in our final determination. We used standard verification procedures, including an examination of relevant accounting and production records, and original source documents provided by the respondents.</P>
                <HD SOURCE="HD1">Changes Since the Preliminary Determination</HD>
                <P>
                    Based on our analysis of the comments received and our findings at verification, we made certain changes to the margin calculations for Belenco and Ermaş since the 
                    <E T="03">Preliminary Determination.</E>
                     For a discussion of these changes, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <HD SOURCE="HD1">Final Negative Determination of Critical Circumstances</HD>
                <P>
                    Commerce preliminarily determined that critical circumstances do not exist for mandatory respondents, Belenco, Ermaş, or with respect to all other producers/exporters. No parties submitted comments regarding our negative preliminary critical circumstances determination and the factual basis for the preliminary negative finding remains unchanged for this final determination. Therefore, in accordance with sections 733(e)(1) and 735(a)(3) of the Act and 19 CFR 351.206, Commerce finds that critical circumstances do not exist for Belenco, Ermaş, or all other producers/exporters. For a full description of the 
                    <PRTPAGE P="25390"/>
                    methodology and results of Commerce's critical circumstances analysis, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <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 producers and exporters not individually investigated shall be equal to the weighted average of the estimated weighted-average dumping margins established for individually investigated exporters and producers, excluding any margins that are zero or 
                    <E T="03">de minimis</E>
                     or any margins determined entirely under section 776 of the Act. Belenco is the only respondent for which Commerce calculated an estimated weighted-average dumping margin that is not zero, 
                    <E T="03">de minimis,</E>
                     or based entirely on facts otherwise available. Therefore, for purposes of determining the all-others rate, and pursuant to section 735(c)(5)(A) of the Act, we are using the estimated weighted-average dumping margin calculated for Belenco, as referenced in the “Final Determination” section.
                </P>
                <HD SOURCE="HD1">Final Determination</HD>
                <P>The estimated weighted-average dumping margins are as follows:</P>
                <GPOTABLE COLS="3" OPTS="L2,tp0,i1" CDEF="s100,12,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Exporter/producer</CHED>
                        <CHED H="1">
                            Weighted-
                            <LI>average </LI>
                            <LI>margins </LI>
                            <LI>(percent)</LI>
                        </CHED>
                        <CHED H="1">
                            Cash deposit rate
                            <LI>(adjusted for</LI>
                            <LI>subsidy </LI>
                            <LI>offset(s))</LI>
                            <LI>(percent)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Belenco dis Tikaret A.Ş.; and Peker Yüzey Tasarımları Sanayi ve Ticaret A.Ş</ENT>
                        <ENT>5.17</ENT>
                        <ENT>5.13</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Ermaş Madencilik Turizm Sanayi Ve Ticaret Anonim Şirketi</ENT>
                        <ENT>0.00</ENT>
                        <ENT>Not Applicable</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">All Others</ENT>
                        <ENT>5.17</ENT>
                        <ENT>5.13</ENT>
                    </ROW>
                </GPOTABLE>
                <P>Consistent with section 735(a)(4) of the Act, based on the zero rate for Ermaş, Commerce determines that Ermaş has not sold merchandise which it produced and exported at LTFV.</P>
                <HD SOURCE="HD1">Disclosure</HD>
                <P>We intend 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 accordance with 19 CFR 351.224(b).</P>
                <HD SOURCE="HD1">Continuation of Suspension of Liquidation</HD>
                <P>
                    In accordance with section 735(c)(1)(B) of the Act, we will instruct U.S. Customs and Border Protection (CBP) to continue the suspension of liquidation of all appropriate entries of quartz surface products from Turkey, as described in Appendix I of this notice, which were entered, or withdrawn from warehouse, for consumption on or after December 13, 2019, the date of publication of the 
                    <E T="03">Preliminary Determination</E>
                     of this investigation in the 
                    <E T="04">Federal Register</E>
                    . Further, Commerce will instruct CBP to require a cash deposit equal to the estimated amount by which the normal value exceeds the U.S. price as shown above. Because the estimated weighted-average dumping margin for Ermaş is zero, entries of shipments of subject merchandise both produced and exported by Ermaş will not be subject to suspension of liquidation or cash deposit requirements. In such situations, Commerce applies the exclusion to the provisional measures to the producer/exporter combination that was examined in the investigation. Accordingly, Commerce is directing CBP to not suspend merchandise produced and exported by Ermaş. However, entries of subject merchandise in any other producer/exporter combination, 
                    <E T="03">e.g.,</E>
                     merchandise produced by a third party and exported by Ermaş, or produced by Ermaş and exported by a third party, are subject to the cash deposit requirements at the all-others rate.
                </P>
                <P>To determine the cash deposit rate, Commerce normally adjusts estimated the weighted-average dumping margin by the amount of export subsidies countervailed in a companion countervailing duty (CVD) proceeding, when CVD provisional measures are in effect. In this case, we have made an affirmative determination for countervailable export subsidies for certain respondents, and, thus, we have offset the estimated weighted-average dumping margin by the appropriate CVD rate. Any such adjusted rates may be found in the table above. However, suspension of liquidation for provisional measures in the companion CVD case has been discontinued; therefore, we are not instructing CBP to collect cash deposits based upon the adjusted estimated weighted-average dumping margin for those subsidies at this time.</P>
                <P>Furthermore, other than for entries of subject merchandise produced and exported by Ermaş, pursuant to section 735(c)(1)(B)(ii) of the Act and 19 CFR 351.210(d), Commerce will instruct CBP to require a cash deposit for such entries of merchandise equal to the estimated weighted-average dumping margin or the estimated all-others rate, as follows: (1) The cash deposit rate for the respondents listed above will be equal to the respondent-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 respondent-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. These suspension of liquidation instructions will remain in effect until further notice.</P>
                <HD SOURCE="HD1">International Trade Commission Notification</HD>
                <P>
                    In accordance with section 735(d) of the Act, we will notify the International Trade Commission (ITC) of the final affirmative determination of sales at LTFV. Because the final determination in this proceeding 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 quartz surface products from Turkey no later than 45 days after our final determination. If the ITC determines that material injury or threat of material injury does not exist, the proceeding will be terminated, and all cash deposits will be refunded. If the ITC determines that material injury or threat of material 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, other than those produced and exported by Ermaş 
                    <PRTPAGE P="25391"/>
                    (because its rate is zero), entered, or withdrawn from warehouse, for consumption on or after the effective date of the suspension of liquidation.
                </P>
                <HD SOURCE="HD1">Notification Regarding Administrative Protective Orders</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>We are issuing and publishing this determination and notice in accordance with sections 735(d) and 777(i) of the Act and 19 CFR 351.210(c).</P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Jeffrey I. Kessler,</NAME>
                    <TITLE>Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix I—Scope of the Investigation</HD>
                <EXTRACT>
                    <P>
                        The merchandise covered by the investigation is certain quartz surface products. Quartz surface products consist of slabs and other surfaces created from a mixture of materials that includes predominately silica (
                        <E T="03">e.g.,</E>
                         quartz, quartz powder, cristobalite, glass powder) as well as a resin binder (
                        <E T="03">e.g.,</E>
                         an unsaturated polyester). The incorporation of other materials, including, but not limited to, pigments, cement, or other additives does not remove the merchandise from the scope of the investigation. However, the scope of the investigation only includes products where the silica content is greater than any other single material, by actual weight. Quartz surface products are typically sold as rectangular slabs with a total surface area of approximately 45 to 60 square feet and a nominal thickness of one, two, or three centimeters. However, the scope of the investigation includes surface products of all other sizes, thicknesses, and shapes. In addition to slabs, the scope of the investigation includes, but is not limited to, other surfaces such as countertops, backsplashes, vanity tops, bar tops, work tops, tabletops, flooring, wall facing, shower surrounds, fire place surrounds, mantels, and tiles. Certain quartz surface products are covered by the investigation whether polished or unpolished, cut or uncut, fabricated or not fabricated, cured or uncured, edged or not edged, finished or unfinished, thermoformed or not thermoformed, packaged or unpackaged, and regardless of the type of surface finish. In addition, quartz surface products are covered by the investigation whether or not they are imported attached to, or in conjunction with, non-subject merchandise such as sinks, sink bowls, vanities, cabinets, and furniture. If quartz surface products are imported attached to, or in conjunction with, such non-subject merchandise, only the quartz surface product is covered by the scope.
                    </P>
                    <P>Subject merchandise includes material matching the above description that has been finished, packaged, or otherwise fabricated in a third country, including by cutting, polishing, curing, edging, thermoforming, attaching to, or packaging with another product, or any other finishing, packaging, or fabrication that would not otherwise remove the merchandise from the scope of the investigation if performed in the country of manufacture of the quartz surface products. The scope of the investigation does not cover quarried stone surface products, such as granite, marble, soapstone, or quartzite. Specifically excluded from the scope of the investigation are crushed glass surface products. Crushed glass surface products must meet each of the following criteria to qualify for this exclusion: (1) The crushed glass content is greater than any other single material, by actual weight; (2) there are pieces of crushed glass visible across the surface of the product; (3) at least some of the individual pieces of crushed glass that are visible across the surface are larger than 1 centimeter wide as measured at their widest cross-section (Glass Pieces); and (4) the distance between any single Glass Piece and the closest separate Glass Piece does not exceed three inches.</P>
                    <P>The products subject to the scope are currently classified in the Harmonized Tariff Schedule of the United States (HTSUS) under the following subheading: 6810.99.0010. Subject merchandise may also enter under subheadings 6810.11.0010, 6810.11.0070, 6810.19.1200, 6810.19.1400, 6810.19.5000, 6810.91.0000, 6810.99.0080, 6815.99.4070, 2506.10.0010, 2506.10.0050, 2506.20.0010, 2506.20.0080, and 7016.90.1050. The HTSUS subheadings set forth above are provided for convenience and U.S. Customs purposes only. The written description of the scope is dispositive.</P>
                </EXTRACT>
                <APPENDIX>
                    <HD SOURCE="HED">Appendix II—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. Scope Comments</FP>
                    <FP SOURCE="FP-2">IV. Scope of the Investigation</FP>
                    <FP SOURCE="FP-2">V. Final Negative Determination of Critical Circumstances</FP>
                    <FP SOURCE="FP-2">VI. Changes Since the Preliminary Determination</FP>
                    <FP SOURCE="FP-2">VII. Discussion of the Issues</FP>
                    <FP SOURCE="FP1-2">Comment 1: Industry Support for the Petition</FP>
                    <FP SOURCE="FP1-2">Comment 2: Application of Adverse Facts Available (AFA) to Belenco</FP>
                    <FP SOURCE="FP1-2">Comment 3: Whether Belenco Attempted to Change Reported Cost Information at Verification Without Alerting Commerce to the Change</FP>
                    <FP SOURCE="FP1-2">Comment 4: Affiliation Between Belenco and its Home Market Customer, SRA Dış Ticaret (SRA)</FP>
                    <FP SOURCE="FP1-2">Comment 5: Belenco's Discounts and Rebates in the U.S. and Home Markets</FP>
                    <FP SOURCE="FP1-2">Comment 6: Inclusion of Product Grade as a Control Number (CONNUM) Characteristic for Belenco</FP>
                    <FP SOURCE="FP1-2">Comment 7: Belenco's Proof of Payment for Home Market Sales</FP>
                    <FP SOURCE="FP1-2">Comment 8: Belenco's Shipment Date and Payment Date Methodology for U.S. Sales</FP>
                    <FP SOURCE="FP1-2">Comment 9: Programming Errors with Respect to Home Market Advertising Expense (ADVERTH) and Certain Duplicated Surrogate Costs for Belenco</FP>
                    <FP SOURCE="FP1-2">Comment 10: Whether Commerce Must Address Ermaş's Missing Information or Apply AFA</FP>
                    <FP SOURCE="FP1-2">Comment 11: Differential Pricing Analysis for Ermaş</FP>
                    <FP SOURCE="FP1-2">Comment 12: The Inclusion of Sample Sales for Little or No Compensation in the Determination of Normal Value for Ermaş</FP>
                    <FP SOURCE="FP1-2">Comment 13: Erma's Cost of Production for Sample Slabs Sold in the Home Market</FP>
                    <FP SOURCE="FP1-2">Comment 14: The Applicable Interest Rate in Ermaş's Credit Adjustment</FP>
                    <FP SOURCE="FP1-2">Comment 15: Other Adjustments to Ermaş's Reported Costs</FP>
                    <FP SOURCE="FP-2">VIII. Recommendation</FP>
                </APPENDIX>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09328 Filed 4-30-20; 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-533-889]</DEPDOC>
                <SUBJECT>Certain Quartz Surface Products From India: Final Determination of Sales at Less Than Fair Value and Final Negative Determination of Critical Circumstances</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 Department of Commerce (Commerce) determines that certain quartz surface products from India are being, or are likely to be, sold in the United States at less than fair value (LTFV) during the period of investigation (POI) April 1, 2018 through March 31, 2019.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable May 1, 2020.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Charles Doss, 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-4474.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On December 13, 2019, Commerce published the 
                    <E T="03">Preliminary Determination</E>
                     in this investigation.
                    <SU>1</SU>
                    <FTREF/>
                     A 
                    <PRTPAGE P="25392"/>
                    summary of the events that occurred since Commerce published the 
                    <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>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">
                            Certain Quartz Surface Products from India: Preliminary Affirmative Determination of Sales at 
                            <PRTPAGE/>
                            Less Than Fair Value, Preliminary Negative Determination of Critical Circumstances, Postponement of Final Determination, and Extension of Provisional Measures,
                        </E>
                         84 FR 68123 (December 13, 2019) (
                        <E T="03">Preliminary Determination</E>
                        ), and accompanying Preliminary Decision Memorandum.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Issues and Decision Memorandum for the Final Determination in the Antidumping Duty Investigation of Certain Quartz Surface Products from India,” dated concurrently with, and hereby adopted by, this notice (Issues and Decision Memorandum).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Period of Investigation</HD>
                <P>The POI is April 1, 2018 through March 31, 2019.</P>
                <HD SOURCE="HD1">Scope of the Investigation</HD>
                <P>
                    The products covered by this investigation are certain quartz surface products from India. For a full description of the scope of this investigation, 
                    <E T="03">see</E>
                     Appendix I of this notice.
                </P>
                <HD SOURCE="HD1">Scope Comments</HD>
                <P>
                    On December 4, 2019, we issued a Preliminary Scope Memorandum.
                    <SU>3</SU>
                    <FTREF/>
                     We received no scope case briefs from interested parties. Therefore, Commerce has made no changes to the scope of this investigation since the 
                    <E T="03">Preliminary Determination</E>
                    .
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Certain Quartz Surface Products from India and Turkey: Preliminary Scope Decision Memorandum,” dated December 4, 2019.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Analysis of Comments Received</HD>
                <P>
                    All issues raised in the case briefs and rebuttal briefs submitted by interested parties in this proceeding are discussed in the Issues and Decision Memorandum. A list of the issues raised by parties and responded to by Commerce in the Issues and Decision Memorandum is attached to this notice as Appendix II. The Issues and Decision Memorandum is a public document and is available 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">http://enforcement.trade.gov/frn/index.html</E>
                    . The signed and electronic versions of the Issues and Decision Memorandum are identical in content.
                </P>
                <HD SOURCE="HD1">Verification</HD>
                <P>
                    As provided in section 782(i) of the Tariff Act of 1930, as amended (the Act), Commerce verified the sales and cost data reported by mandatory respondents Pokarna Engineered Stone Limited (PESL) and the Antique Group 
                    <SU>4</SU>
                    <FTREF/>
                     for use in our final determination. We used standard verification procedures, including an examination of relevant accounting and production records, and original source documents provided by the respondents.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         The Antique Group is comprised of Antique Marbonite Private Limited, India (Antique Marbonite or AMPL) and its affiliates Shivam Enterprises (Shivam) and Prism Johnson Limited (Prism Johnson).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Changes Since the Preliminary Determination</HD>
                <P>
                    Based on our analysis of the comments received and our findings at verification, we made certain changes to the margin calculations for PESL and the Antique Group since the 
                    <E T="03">Preliminary Determination</E>
                    . For a discussion of these changes, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <HD SOURCE="HD1">Final Negative Determination of Critical Circumstances</HD>
                <P>
                    Commerce preliminarily determined that critical circumstances do not exist for the mandatory respondents, PESL and the Antique Group, or with respect to all other producers/exporters. No parties submitted comments regarding our negative preliminary critical circumstances determination and the factual basis for the preliminary negative finding remains unchanged for this final determination. Therefore, in accordance with sections 733(e)(1) and 735(a)(3) of the Act, and 19 CFR 351.206, Commerce finds that critical circumstances do not exist for PESL, the Antique Group, or all other producers/exporters. For a full description of the methodology and results of Commerce's critical circumstances analysis, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <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 producers and exporters not individually investigated shall be equal to the weighted average of the estimated weighted-average dumping margins established for individually investigated exporters and producers, excluding any margins that are zero or 
                    <E T="03">de minimis</E>
                     or any margins determined entirely under section 776 of the Act.
                </P>
                <P>
                    In this investigation, Commerce calculated estimated weighted-average dumping margins for PESL and Antique Group that are not zero, 
                    <E T="03">de minimis,</E>
                     or based entirely on facts otherwise available. Commerce calculated the all-others rate using a weighted average of the estimated weighted-average dumping margins calculated for the examined respondents using each company's publicly-ranged values for the merchandise under consideration.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See, e.g., Ball Bearings and Parts Thereof from France, Germany, Italy, Japan, and the United Kingdom: Final Results of Antidumping Duty Administrative Reviews, Final Results of Changed-Circumstances Review, and Revocation of an Order in Part,</E>
                         75 FR 53661, 53663 (September 1, 2010); 
                        <E T="03">see also</E>
                         Memorandum, “Certain Quartz Surface Products from India: Calculation of All-Others' Rate in Final Determination,” dated concurrently with this notice.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Final Determination</HD>
                <P>The estimated weighted-average dumping margins are as follows:</P>
                <GPOTABLE COLS="03" OPTS="L2,tp0,i1" CDEF="s100,16,16">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Exporter/producer</CHED>
                        <CHED H="1">
                            Estimated 
                            <LI>weighted-average </LI>
                            <LI>dumping margin </LI>
                            <LI>(percent)</LI>
                        </CHED>
                        <CHED H="1">
                            Cash deposit rate (adjusted for 
                            <LI>subsidy offset(s)) </LI>
                            <LI>(percent)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Antique Marbonite Private Limited, India; Shivam Enterprises (Shivam); and Prism Johnson Limited (Prism Johnson)</ENT>
                        <ENT>5.15</ENT>
                        <ENT>3.58</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Pokarna Engineered Stone Limited</ENT>
                        <ENT>2.67</ENT>
                        <ENT>0.33</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">All Others</ENT>
                        <ENT>3.19</ENT>
                        <ENT>1.02</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Disclosure</HD>
                <P>
                    We intend 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 to parties in this proceeding in accordance with 19 CFR 351.224(b).
                    <PRTPAGE P="25393"/>
                </P>
                <HD SOURCE="HD1">Continuation of Suspension of Liquidation</HD>
                <P>
                    In accordance with section 735(c)(1)(B) of the Act, we will instruct U.S. Customs and Border Protection (CBP) to continue the suspension of liquidation of all appropriate entries of certain quartz surface products, as described in Appendix I of this notice, which were entered, or withdrawn from warehouse, for consumption on or after December 13, 2019, the date of publication of the 
                    <E T="03">Preliminary Determination</E>
                     of this investigation in the 
                    <E T="04">Federal Register</E>
                    . Further, Commerce will instruct CBP to require a cash deposit equal to the estimated amount by which the normal value exceeds the U.S. price as shown above.
                </P>
                <P>To determine the cash deposit rate, Commerce normally adjusts the estimated weighted-average dumping margin by the amount of export subsidies countervailed in a companion countervailing duty (CVD) proceeding, when CVD provisional measures are in effect. In this case, we have made an affirmative determination for countervailable export subsidies for certain respondents, and, thus, we have offset the estimated weighted-average dumping margin by the appropriate CVD rate. Any such adjusted rates may be found in the table above. However, suspension of liquidation for provisional measures in the companion CVD case has been discontinued; therefore, we are not instructing CBP to collect cash deposits based upon the adjusted estimated weighted-average dumping margin for those subsidies at this time.</P>
                <P>Pursuant to section 735(c)(1)(B)(ii) of the Act, we will instruct CBP to require a cash deposit equal to the estimated amount by which the normal value exceeds the U.S. price as follows: (1) The cash deposit rates for the respondents listed above will be equal to the respondent-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 respondent-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. These suspension of liquidation instructions will remain in effect until further notice.</P>
                <HD SOURCE="HD1">International Trade Commission Notification</HD>
                <P>In accordance with section 735(d) of the Act, we will notify the International Trade Commission (ITC) of the final affirmative determination of sales at LTFV. Because the final determination in this proceeding 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 certain quartz surface products no later than 45 days after our final determination. If the ITC determines that material injury or threat of material injury does not exist, the proceeding will be terminated, and all cash deposits will be refunded. If the ITC determines that material injury or threat of material 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.</P>
                <HD SOURCE="HD1">Notification Regarding Administrative Protective Orders</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>We are issuing and publishing this determination and notice in accordance with sections 735(d) and 777(i) of the Act and 19 CFR 351.210(c).</P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Jeffrey I. Kessler,</NAME>
                    <TITLE>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 merchandise covered by the investigation is certain quartz surface products. Quartz surface products consist of slabs and other surfaces created from a mixture of materials that includes predominately silica (
                        <E T="03">e.g.,</E>
                         quartz, quartz powder, cristobalite, glass powder) as well as a resin binder (
                        <E T="03">e.g.,</E>
                         an unsaturated polyester). The incorporation of other materials, including, but not limited to, pigments, cement, or other additives does not remove the merchandise from the scope of the investigation. However, the scope of the investigation only includes products where the silica content is greater than any other single material, by actual weight. Quartz surface products are typically sold as rectangular slabs with a total surface area of approximately 45 to 60 square feet and a nominal thickness of one, two, or three centimeters. However, the scope of the investigation includes surface products of all other sizes, thicknesses, and shapes. In addition to slabs, the scope of the investigation includes, but is not limited to, other surfaces such as countertops, backsplashes, vanity tops, bar tops, work tops, tabletops, flooring, wall facing, shower surrounds, fireplace surrounds, mantels, and tiles. Certain quartz surface products are covered by the investigation whether polished or unpolished, cut or uncut, fabricated or not fabricated, cured or uncured, edged or not edged, finished or unfinished, thermoformed or not thermoformed, packaged or unpackaged, and regardless of the type of surface finish. In addition, quartz surface products are covered by the investigation whether or not they are imported attached to, or in conjunction with, non-subject merchandise such as sinks, sink bowls, vanities, cabinets, and furniture. If quartz surface products are imported attached to, or in conjunction with, such non-subject merchandise, only the quartz surface product is covered by the scope.
                    </P>
                    <P>Subject merchandise includes material matching the above description that has been finished, packaged, or otherwise fabricated in a third country, including by cutting, polishing, curing, edging, thermoforming, attaching to, or packaging with another product, or any other finishing, packaging, or fabrication that would not otherwise remove the merchandise from the scope of the investigation if performed in the country of manufacture of the quartz surface products. The scope of the investigation does not cover quarried stone surface products, such as granite, marble, soapstone, or quartzite. Specifically excluded from the scope of the investigation are crushed glass surface products. Crushed glass surface products must meet each of the following criteria to qualify for this exclusion: (1) The crushed glass content is greater than any other single material, by actual weight; (2) there are pieces of crushed glass visible across the surface of the product; (3) at least some of the individual pieces of crushed glass that are visible across the surface are larger than 1 centimeter wide as measured at their widest cross-section (Glass Pieces); and (4) the distance between any single Glass Piece and the closest separate Glass Piece does not exceed three inches.</P>
                    <P>
                        The products subject to the scope are currently classified in the Harmonized Tariff Schedule of the United States (HTSUS) under the following subheading: 6810.99.0010. Subject merchandise may also enter under subheadings 6810.11.0010, 6810.11.0070, 6810.19.1200, 6810.19.1400, 6810.19.5000, 6810.91.0000, 6810.99.0080, 6815.99.4070, 
                        <PRTPAGE P="25394"/>
                        2506.10.0010, 2506.10.0050, 2506.20.0010, 2506.20.0080, and 7016.90.1050. The HTSUS subheadings set forth above are provided for convenience and U.S. Customs purposes only. The written description of the scope 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. Scope Comments</FP>
                    <FP SOURCE="FP-2">IV. Scope of the Investigation</FP>
                    <FP SOURCE="FP-2">V. Final Negative Determination of Critical Circumstances</FP>
                    <FP SOURCE="FP-2">VI. Changes Since the Preliminary Determination</FP>
                    <FP SOURCE="FP-2">VII. Discussion of the Issues</FP>
                    <FP SOURCE="FP1-2">Comment 1: Whether to Apply Adverse Inference Regarding PESL's Date of Sale Reporting</FP>
                    <FP SOURCE="FP1-2">Comment 2: Whether to Cap PESL's Freight, Insurance and Packing Revenue</FP>
                    <FP SOURCE="FP1-2">Comment 3: Treatment of PESL's Warranty Expenses</FP>
                    <FP SOURCE="FP1-2">Comment 4: Whether to Exclude PESL's Paid U.S. Sample Sales</FP>
                    <FP SOURCE="FP1-2">Comment 5: Whether to Rely on Antique Group's Profit Rate and Selling Expenses to Calculate Constructed Value (CV) for PESL</FP>
                    <FP SOURCE="FP1-2">Comment 6: Whether to Adjust PESL's General and Administrative (G&amp;A) Expense Ratio</FP>
                    <FP SOURCE="FP1-2">Comment 7: Whether to Allocate the Costs of PESL's Non-prime Products to Prime Products</FP>
                    <FP SOURCE="FP1-2">Comment 8: Treatment of Antique Group's Reported Credit Expenses</FP>
                    <FP SOURCE="FP1-2">Comment 9: Treatment of Antique Group's Reported Quality Discounts</FP>
                    <FP SOURCE="FP1-2">Comment 10: Whether the Arms-Length Test Was Appropriately Applied with Respect to Antique Group's Collapsed Affiliate</FP>
                    <FP SOURCE="FP1-2">Comment 11: Ministerial Error Regarding Application of Antique Group's Reported Billing Adjustments</FP>
                    <FP SOURCE="FP1-2">Comment 12: Whether the Initiation of the Investigation was Contrary to Law</FP>
                    <FP SOURCE="FP-2">VIII. Recommendation</FP>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09407 Filed 4-30-20; 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>Antidumping or Countervailing Duty Order, Finding, or Suspended Investigation; Advance Notification of Sunset Review</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Background</HD>
                <P>Every five years, pursuant to the Tariff Act of 1930, as amended (the Act), the Department of Commerce (Commerce) and the International Trade Commission automatically initiate and conduct reviews to determine whether revocation of a countervailing or antidumping duty order or termination of an investigation suspended under section 704 or 734 of the Act would be likely to lead to continuation or recurrence of dumping or a countervailable subsidy (as the case may be) and of material injury.</P>
                <HD SOURCE="HD1">Upcoming Sunset Reviews for June 2020</HD>
                <P>
                    Pursuant to section 751(c) of the Act, the following Sunset Reviews are scheduled for initiation in June 2020 and will appear in that month's 
                    <E T="03">Notice of Initiation of Five-Year Sunset Reviews</E>
                     (Sunset Review).
                </P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s100,xs150">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Department contact</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Antidumping Duty Proceedings</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Steel Nails from Malaysia (A-557-815) (1st Review) </ENT>
                        <ENT>Jacqueline Arrowsmith; (202) 482-5255.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Steel Nails from Oman (A-523-808) (1st Review) </ENT>
                        <ENT>Jacqueline Arrowsmith; (202) 482-5255.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Steel Nails from Republic of Korea (A-580-874) (1st Review) </ENT>
                        <ENT>Jacqueline Arrowsmith; (202) 482-5255.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Steel Nails from Socialist Republic of Vietnam (A-552-818) (1st Review) </ENT>
                        <ENT>Jacqueline Arrowsmith; (202) 482-5255.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Steel Nails from Taiwan (A-583-854) (1st Review) </ENT>
                        <ENT>Jacqueline Arrowsmith; (202) 482-5255.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Countervailing Duty Proceedings</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Steel Nails from Socialist Republic of Vietnam (A-552-819) (1st Review) </ENT>
                        <ENT>Jacqueline Arrowsmith; (202) 482-5255.</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Suspended Investigations</HD>
                <P>No Sunset Review of suspended investigations is scheduled for initiation in June 2020.</P>
                <P>
                    Commerce's procedures for the conduct of Sunset Review are set forth in 19 CFR 351.218. The 
                    <E T="03">Notice of Initiation of Five-Year</E>
                     (
                    <E T="03">Sunset) Review</E>
                     provides further information regarding what is required of all parties to participate in Sunset Review.
                </P>
                <P>Pursuant to 19 CFR 351.103(c), Commerce will maintain and make available a service list for these proceedings. To facilitate the timely preparation of the service list(s), it is requested that those seeking recognition as interested parties to a proceeding contact Commerce in writing within 10 days of the publication of the Notice of Initiation.</P>
                <P>Please note that if Commerce receives a Notice of Intent to Participate from a member of the domestic industry within 15 days of the date of initiation, the review will continue.</P>
                <P>Thereafter, any interested party wishing to participate in the Sunset Review must provide substantive comments in response to the notice of initiation no later than 30 days after the date of initiation.</P>
                <P>This notice is not required by statute but is published as a service to the international trading community.</P>
                <SIG>
                    <DATED>Dated: April 22, 2020.</DATED>
                    <NAME>James Maeder,</NAME>
                    <TITLE>Deputy Assistant Secretary for Antidumping and Countervailing Duty Operations.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09329 Filed 4-30-20; 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>Antidumping or Countervailing Duty Order, Finding, or Suspended Investigation; Opportunity To Request Administrative Review</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Enforcement and Compliance, International Trade Administration, Department of Commerce.</P>
                </AGY>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Brenda E. Brown, Office of AD/CVD Operations, Customs Liaison Unit, Enforcement and Compliance, International Trade Administration, U.S. Department of Commerce, 1401 Constitution Avenue NW, Washington, DC 20230, telephone: (202) 482-4735.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    <PRTPAGE P="25395"/>
                </P>
                <HD SOURCE="HD1">Background</HD>
                <P>Each year during the anniversary month of the publication of an antidumping or countervailing duty order, finding, or suspended investigation, an interested party, as defined in section 771(9) of the Tariff Act of 1930, as amended (the Act), may request, in accordance with 19 CFR 351.213, that the Department of Commerce (Commerce) conduct an administrative review of that antidumping or countervailing duty order, finding, or suspended investigation.</P>
                <P>All deadlines for the submission of comments or actions by Commerce discussed below refer to the number of calendar days from the applicable starting date.</P>
                <HD SOURCE="HD1">Respondent Selection</HD>
                <P>
                    In the event Commerce limits the number of respondents for individual examination for administrative reviews initiated pursuant to requests made for the orders identified below, Commerce intends to select respondents based on U.S. Customs and Border Protection (CBP) data for U.S. imports during the period of review. We intend to release the CBP data under Administrative Protective Order (APO) to all parties having an APO within five days of publication of the initiation notice and to make our decision regarding respondent selection within 21 days of publication of the initiation 
                    <E T="04">Federal Register</E>
                     notice. Therefore, we encourage all parties interested in commenting on respondent selection to submit their APO applications on the date of publication of the initiation notice, or as soon thereafter as possible. Commerce invites comments regarding the CBP data and respondent selection within five days of placement of the CBP data on the record of the review.
                </P>
                <P>In the event Commerce decides it is necessary to limit individual examination of respondents and conduct respondent selection under section 777A(c)(2) of the Act:</P>
                <P>
                    In general, Commerce finds that determinations concerning whether particular companies should be “collapsed” (
                    <E T="03">i.e.,</E>
                     treated as a single entity for purposes of calculating antidumping duty rates) require a substantial amount of detailed information and analysis, which often require follow-up questions and analysis. Accordingly, Commerce will not conduct collapsing analyses at the respondent selection phase of a review and will not collapse companies at the respondent selection phase unless there has been a determination to collapse certain companies in a previous segment of this antidumping proceeding (
                    <E T="03">i.e.,</E>
                     investigation, administrative review, new shipper review or changed circumstances review). For any company subject to a review, if Commerce determined, or continued to treat, that company as collapsed with others, Commerce will assume that such companies continue to operate in the same manner and will collapse them for respondent selection purposes. Otherwise, Commerce will not collapse companies for purposes of respondent selection. Parties are requested to (a) identify which companies subject to review previously were collapsed, and (b) provide a citation to the proceeding in which they were collapsed. Further, if companies are requested to complete a Quantity and Value Questionnaire for purposes of respondent selection, in general each company must report volume and value data separately for itself. Parties should not include data for any other party, even if they believe they should be treated as a single entity with that other party. If a company was collapsed with another company or companies in the most recently completed segment of a proceeding where Commerce considered collapsing that entity, complete quantity and value data for that collapsed entity must be submitted.
                </P>
                <HD SOURCE="HD1">Deadline for Withdrawal of Request for Administrative Review</HD>
                <P>Pursuant to 19 CFR 351.213(d)(1), a party that requests a review may withdraw that request within 90 days of the date of publication of the notice of initiation of the requested review. The regulation provides that Commerce may extend this time if it is reasonable to do so. Determinations by Commerce to extend the 90-day deadline will be made on a case-by-case basis.</P>
                <HD SOURCE="HD1">Deadline for Particular Market Situation Allegation</HD>
                <P>
                    Section 504 of the Trade Preferences Extension Act of 2015 amended the Act by adding the concept of particular market situation (PMS) for purposes of constructed value under section 773(e) of the Act.
                    <SU>1</SU>
                    <FTREF/>
                     Section 773(e) of the Act states that “if a particular market situation exists such that the cost of materials and fabrication or other processing of any kind does not accurately reflect the cost of production in the ordinary course of trade, the administering authority may use another calculation methodology under this subtitle or any other calculation methodology.” When an interested party submits a PMS allegation pursuant to section 773(e) of the Act, Commerce will respond to such a submission consistent with 19 CFR 351.301(c)(2)(v). If Commerce finds that a PMS exists under section 773(e) of the Act, then it will modify its dumping calculations appropriately.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Trade Preferences Extension Act of 2015, Public Law 114-27, 129 Stat. 362 (2015).
                    </P>
                </FTNT>
                <P>Neither section 773(e) of the Act nor 19 CFR 351.301(c)(2)(v) set a deadline for the submission of PMS allegations and supporting factual information. However, in order to administer section 773(e) of the Act, Commerce must receive PMS allegations and supporting factual information with enough time to consider the submission. Thus, should an interested party wish to submit a PMS allegation and supporting new factual information pursuant to section 773(e) of the Act, it must do so no later than 20 days after submission of initial Section D responses.</P>
                <P>
                    <E T="03">Opportunity to Request a Review:</E>
                     Not later than the last day of May 2020,
                    <SU>2</SU>
                    <FTREF/>
                     interested parties may request administrative review of the following orders, findings, or suspended investigations, with anniversary dates in May for the following periods:
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         Or the next business day, if the deadline falls on a weekend, federal holiday or any other day when Commerce is closed.
                    </P>
                </FTNT>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s200,15">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">Period</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Antidumping Duty Proceedings</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">AUSTRIA: Carbon and Alloy Steel Cut-To-Length Plate, A-433-812 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">BELGIUM: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Cut-To-Length Plate, A-423-812 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Stainless Steel Plate in Coils, A-423-808 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">BRAZIL: Iron Construction Castings, A-351-503 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">CANADA: </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25396"/>
                        <ENT I="03">Citric Acid and Certain Citrate Salts, A-122-853 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Large Diameter Welded Pipe, A-122-863 </ENT>
                        <ENT>8/27/18-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Polyethylene Terephthalate Resin, A-122-855 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">FRANCE: Carbon and Alloy Steel Cut-To-Length Plate, A-427-828 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">GERMANY: Carbon and Alloy Steel Cut-To-Length Plate, A-428-844</ENT>
                        <ENT> 5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">GREECE: Large Diameter Welded Pipe, A-484-803 </ENT>
                        <ENT>8/27/18-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">INDIA: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Certain Welded Carbon Steel Standard Pipes and Tubes, A-533-502 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Polyethylene Terephthalate Resin, A-533-861 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Silicomanganese, A-533-823 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">INDONESIA: Polyethylene Retail Carrier Bags, A-560-822 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">ITALY: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Cut-To-Length Plate, A-475-834 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Wire Rod, A-475-836 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">JAPAN: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Cut-To-Length Plate, A-588-875 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Diffusion-Annealed Nickel-Plated Flat-Rolled Steel Products, A-588-869 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Gray Portland Cement and Cement Clinker, A-588-815 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">KAZAKHSTAN: Silicomanganese, A-834-807 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">OMAN: Polyethylene Terephthalate Resin, A-523-810 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">REPUBLIC OF KOREA: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Cut-To-Length Plate, A-580-887 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Wire Rod, A-580-891 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Ferrovanadium, A-580-886 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Large Diameter Welded Pipe, A-580-897 </ENT>
                        <ENT>8/27/18-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Polyester Staple Fiber, A-580-839 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SOCIALIST REPUBLIC OF VIETNAM: Polyethylene Retail Carrier Bags, A-552-806 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SOUTH AFRICA: Stainless Steel Plate in Coils, A-791-805 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SPAIN: Carbon and Alloy Steel Wire Rod, A-469-816 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">TAIWAN: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Cut-To-Length Plate, A-583-858 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Certain Circular Welded Carbon Steel Pipes and Tubes, A-583-008 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Polyester Staple Fiber, A-583-833 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Polyethylene Retail Carrier Bags, A-583-843 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Stainless Steel Plate in Coil, A-583-830 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Stilbenic Optical Brightening Agents, A-583-848 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">THE PEOPLE'S REPUBLIC OF CHINA: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">1-Hydroxyethylidene-1, 1-Diphoshonic Acid (HEDP), A-570-045 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Aluminum Extrusions, A-570-967 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Cast Iron Soil Pipe, A-570-079 </ENT>
                        <ENT>8/31/18-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carton-Closing Staples, A-570-055 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Certain Steel Wheels, A-570-082 </ENT>
                        <ENT>10/30/18-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Circular Welded Carbon Quality Steel Line Pipe, A-570-935 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Citric Acid and Certain Citrate Salts, A-570-937 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Iron Construction Castings, A-570-502 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Oil Country Tubular Goods, A-570-943 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Polyethylene Terephthalate Resin, A-570-024 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Pure Magnesium, A-570-832 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Stilbenic Optical Brightening Agents, A-570-972 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">TURKEY: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Wire Rod, A-489-831</ENT>
                        <ENT> 5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Circular Welded Carbon Steel Pipes and Tubes, A-489-501 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Large Diameter Welded Pipe,  A-489-833 </ENT>
                        <ENT>8/27/18-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Light-Walled Rectangular Pipe and Tube, A-489-815 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">UNITED ARAB EMIRATES: Certain Steel Nails, A-520-804 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">THE UNITED KINGDOM: Carbon and Alloy Steel Wire Rod, A-412-826 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">VENEZUELA: Silicomanganese, A-307-820 </ENT>
                        <ENT>5/1/19-4/30/20</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Countervailing Duty Proceedings</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">BRAZIL: Iron Construction Castings, C-351-504 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">INDIA: Polyethylene Terephthalate Resin, C-533-862 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ITALY: Carbon and Alloy Steel Wire Rod, C-475-837 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">REPUBLIC OF KOREA: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Carbon and Alloy Steel Cut-To-Length Plate, C-580-888 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Large Diameter Welded Pipe, C-580-898 </ENT>
                        <ENT>6/29/18-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SOCIALIST REPUBLIC OF VIETNAM: Polyethylene Retail Carrier Bags, C-552-805 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SOUTH AFRICA: Stainless Steel Plate in Coils, C-791-806 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">THE PEOPLE'S REPUBLIC OF CHINA: </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">1-Hydroxyethylidene-1, 1-Diphoshonic Acid (HEDP), C-570-046 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Aluminum Extrusions, C-570-968 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Cast Iron Soil Pipe, C-570-080 </ENT>
                        <ENT>7/2/18-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Certain Steel Wheels, C-570-083 </ENT>
                        <ENT>8/31/18-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Citric Acid and Certain Citrate Salts, C-570-938 </ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Polyethylene Terephthalate Resin, C-570-025</ENT>
                        <ENT> 1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22">TURKEY: </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25397"/>
                        <ENT I="03">Carbon and Alloy Steel Wire Rod, C-489-832</ENT>
                        <ENT>1/1/19-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Large Diameter Welded Pipe, C-489-837 </ENT>
                        <ENT>8/27/18-12/31/19</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">
                            Steel Concrete Reinforcing Bar,
                            <SU>3</SU>
                             C-489-819
                        </ENT>
                        <ENT>1/1/18-12/31/18</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Suspension Agreements</HD>
                <P>
                    None.
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         The opportunity notice that published on November 1, 2019 (84 FR 58690) referenced the incorrect case number for this administrative review. The correct case number is referenced above.
                    </P>
                </FTNT>
                <P>In accordance with 19 CFR 351.213(b), an interested party as defined by section 771(9) of the Act may request in writing that the Secretary conduct an administrative review. For both antidumping and countervailing duty reviews, the interested party must specify the individual producers or exporters covered by an antidumping finding or an antidumping or countervailing duty order or suspension agreement for which it is requesting a review. In addition, a domestic interested party or an interested party described in section 771(9)(B) of the Act must state why it desires the Secretary to review those particular producers or exporters. If the interested party intends for the Secretary to review sales of merchandise by an exporter (or a producer if that producer also exports merchandise from other suppliers) which was produced in more than one country of origin and each country of origin is subject to a separate order, then the interested party must state specifically, on an order-by-order basis, which exporter(s) the request is intended to cover.</P>
                <P>Note that, for any party Commerce was unable to locate in prior segments, Commerce will not accept a request for an administrative review of that party absent new information as to the party's location. Moreover, if the interested party who files a request for review is unable to locate the producer or exporter for which it requested the review, the interested party must provide an explanation of the attempts it made to locate the producer or exporter at the same time it files its request for review, in order for the Secretary to determine if the interested party's attempts were reasonable, pursuant to 19 CFR 351.303(f)(3)(ii).</P>
                <P>
                    As explained in 
                    <E T="03">Antidumping and Countervailing Duty Proceedings: Assessment of Antidumping Duties,</E>
                     68 FR 23954 (May 6, 2003), and 
                    <E T="03">Non-Market Economy Antidumping Proceedings: Assessment of Antidumping Duties,</E>
                     76 FR 65694 (October 24, 2011), Commerce clarified its practice with respect to the collection of final antidumping duties on imports of merchandise where intermediate firms are involved. The public should be aware of this clarification in determining whether to request an administrative review of merchandise subject to antidumping findings and orders.
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         the Enforcement and Compliance website at 
                        <E T="03">https://legacy.trade.gov/enforcement/.</E>
                    </P>
                </FTNT>
                <P>
                    Commerce no longer considers the non-market economy (NME) entity as an exporter conditionally subject to an antidumping duty administrative reviews.
                    <SU>5</SU>
                    <FTREF/>
                     Accordingly, the NME entity will not be under review unless Commerce specifically receives a request for, or self-initiates, a review of the NME entity.
                    <SU>6</SU>
                    <FTREF/>
                     In administrative reviews of antidumping duty orders on merchandise from NME countries where a review of the NME entity has not been initiated, but where an individual exporter for which a review was initiated does not qualify for a separate rate, Commerce will issue a final decision indicating that the company in question is part of the NME entity. However, in that situation, because no review of the NME entity was conducted, the NME entity's entries were not subject to the review and the rate for the NME entity is not subject to change as a result of that review (although the rate for the individual exporter may change as a function of the finding that the exporter is part of the NME entity). Following initiation of an antidumping administrative review when there is no review requested of the NME entity, Commerce will instruct CBP to liquidate entries for all exporters not named in the initiation notice, including those that were suspended at the NME entity rate.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See Antidumping Proceedings: Announcement of Change in Department Practice for Respondent Selection in Antidumping Duty Proceedings and Conditional Review of the Nonmarket Economy Entity in NME Antidumping Duty Proceedings,</E>
                         78 FR 65963 (November 4, 2013).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         In accordance with 19 CFR 351.213(b)(1), parties should specify that they are requesting a review of entries from exporters comprising the entity, and to the extent possible, include the names of such exporters in their request.
                    </P>
                </FTNT>
                <P>
                    All requests must be filed electronically in Enforcement and Compliance's Antidumping and Countervailing Duty Centralized Electronic Service System (ACCESS) on Enforcement and Compliance's ACCESS website at 
                    <E T="03">https://access.trade.gov.</E>
                    <SU>7</SU>
                    <FTREF/>
                     Further, in accordance with 19 CFR 351.303(f)(l)(i), a copy of each request must be served on the petitioner and each exporter or producer specified in the request. Note that Commerce has temporarily modified certain of its requirements for serving documents containing business proprietary information, until May 19, 2020, unless extended.
                    <SU>8</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See Antidumping and Countervailing Duty Proceedings: Electronic Filing Procedures; Administrative Protective Order Procedures,</E>
                         76 FR 39263 (July 6, 2011).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See Temporary Rule Modifying AD/CVD Service Requirements Due to COVID-19,</E>
                         85 FR 17006 (March 26, 2020).
                    </P>
                </FTNT>
                <P>
                    Commerce will publish in the 
                    <E T="04">Federal Register</E>
                     a notice of “Initiation of Administrative Review of Antidumping or Countervailing Duty Order, Finding, or Suspended Investigation” for requests received by the last day of May 2020. If Commerce does not receive, by the last day of May 2020, a request for review of entries covered by an order, finding, or suspended investigation listed in this notice and for the period identified above, Commerce will instruct CBP to assess antidumping or countervailing duties on those entries at a rate equal to the cash deposit of estimated antidumping or countervailing duties required on those entries at the time of entry, or withdrawal from warehouse, for consumption and to continue to collect the cash deposit previously ordered.
                </P>
                <P>For the first administrative review of any order, there will be no assessment of antidumping or countervailing duties on entries of subject merchandise entered, or withdrawn from warehouse, for consumption during the relevant provisional-measures “gap” period of the order, if such a gap period is applicable to the period of review.</P>
                <P>This notice is not required by statute but is published as a service to the international trading community.</P>
                <SIG>
                    <DATED>Dated: April 22, 2020.</DATED>
                    <NAME>James Maeder,</NAME>
                    <TITLE>Deputy Assistant Secretary for Antidumping and Countervailing Duty Operations.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09331 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="25398"/>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>International Trade Administration</SUBAGY>
                <DEPDOC>[C-533-890]</DEPDOC>
                <SUBJECT>Certain Quartz Surface Products From India: Final Affirmative Countervailing Duty Determination and Final Affirmative Determination of Critical Circumstances, In Part</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 Department of Commerce (Commerce) determines that countervailable subsidies are being provided to producers and exporters of certain quartz surface products (quartz surface products) from India.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable May 1, 2020.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Kristen Johnson or Stephanie Moore, 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-4793 or (202) 482-3692, respectively.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On October 11, 2019, Commerce published the 
                    <E T="03">Preliminary Determination</E>
                     of the countervailing duty (CVD) investigation, which aligned the final determination in this CVD investigation with the final determination in the companion antidumping duty investigation of quartz surface products from India.
                    <SU>1</SU>
                    <FTREF/>
                     On November 20, 2019, Commerce published the 
                    <E T="03">Amended Preliminary Determination</E>
                     in this investigation.
                    <SU>2</SU>
                    <FTREF/>
                     On March 12, 2020, we issued a Post-Preliminary Determination.
                    <SU>3</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Certain Quartz Surface Products from India: Preliminary Affirmative Countervailing Duty Determination, Preliminary Affirmative Critical Circumstances Determination, In Part, and Alignment of Final Determination With Final Antidumping Duty Determination,</E>
                         84 FR 54838 (October 11, 2019) (
                        <E T="03">Preliminary Determination</E>
                        ), and accompanying Preliminary Decision Memorandum (PDM).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See Certain Quartz Surface Products from India: Amended Preliminary Affirmative Countervailing Duty Determination, Preliminary Affirmative Critical Circumstances Determination, In Part, and Alignment of Final Determination With Final Antidumping Duty Determination,</E>
                         84 FR 64047 (November 20, 2019) (
                        <E T="03">Amended Preliminary Determination</E>
                        ), and accompanying Amended PDM.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Post-Preliminary Analysis Memorandum in the Countervailing Duty Investigation of Certain Quartz Surface Products from India,” dated March 11, 2020 (Post-Preliminary Determination).
                    </P>
                </FTNT>
                <P>
                    A summary of the events that occurred since Commerce published the 
                    <E T="03">Amended Preliminary Determination,</E>
                     as well as a full discussion of the issues raised by parties for this final determination, are discussed in the Issues and Decision Memorandum, which is hereby adopted by this notice.
                    <SU>4</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">http://access.trade.gov.</E>
                     In addition, a complete version of the Issues and Decision Memorandum can be accessed directly at 
                    <E T="03">http://enforcement.trade.gov/frn/index.html.</E>
                     The signed and electronic versions of the Issues and Decision Memorandum are identical in content.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Issues and Decisions Memorandum for the Final Determination of the Countervailing Duty Investigation of Certain Quartz Surface Products from India,” dated concurrently with, and hereby adopted by, this notice (Issues and Decisions Memorandum).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Period of Investigation</HD>
                <P>The period of investigation is April 1, 2018 through March 31, 2019.</P>
                <HD SOURCE="HD1">Scope of the Investigation</HD>
                <P>
                    The products covered by this investigation are quartz surface products from India. For a complete description of the scope of this investigation, 
                    <E T="03">see</E>
                     Appendix I.
                </P>
                <HD SOURCE="HD1">Scope Comments</HD>
                <P>
                    On December 4, 2019, Commerce issued a Preliminary Scope Memorandum.
                    <SU>5</SU>
                    <FTREF/>
                     We received no scope case briefs from interested parties. Therefore, Commerce has made no changes to the scope of this investigation since the 
                    <E T="03">Preliminary Determination.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Certain Quartz Surface Products from India and Turkey: Preliminary Scope Decision Memorandum,” dated December 4, 2019.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Analysis of Subsidy Programs and Comments Received</HD>
                <P>The subsidy programs under investigation and the issues raised in the case and rebuttal briefs by parties in this investigation are discussed in the Issues and Decision Memorandum. A list of the issues that parties raised is attached to this notice as Appendix II.</P>
                <HD SOURCE="HD1">Methodology</HD>
                <P>
                    Commerce conducted this investigation in accordance with section 701 of the Tariff Act of 1930, as amended (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>6</SU>
                    <FTREF/>
                     Additionally, consistent with the Post-Preliminary Determination, we relied on facts available with an adverse inference (AFA) in accordance with sections 776(a) and (b) of the Act, for certain determinations with respect to the Government of India. 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>6</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">Verification</HD>
                <P>
                    As provided in section 782(i) of the Act, in December 2019 and February 2020, we conducted verification of the information submitted by Antique Marbonite Private Limited (Antique Marbonite) and Pokarna Engineered Stone Limited (Pokarna), respectively, for use in Commerce's final determination. We used standard verification procedures, including an examination of relevant accounting records and original source documents provided by the respondents.
                    <SU>7</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Verification of the Questionnaire Responses of Antique Marbonite Private Limited and its responding cross-owned affiliated companies,” dated January 8, 2020; 
                        <E T="03">see also</E>
                         Memorandum, “Verification of the Questionnaire Responses of Pokarna Engineered Stone Limited and Pokarna Limited,” dated March 11, 2020.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Changes Since the Preliminary Determination</HD>
                <P>
                    Based on our review and analysis of the comments received from parties and our verification findings, we made certain changes to the subsidy rate calculations for Pokarna. For a discussion of these changes, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <HD SOURCE="HD1">Final Affirmative Determination of Critical Circumstances, In Part</HD>
                <P>
                    Pursuant to section 705(a)(2) of the Act, Commerce determines that critical circumstances exist for imports of quartz surface products from India for all other companies. For further information on Commerce's critical circumstances analysis, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <HD SOURCE="HD1">All-Others Rate</HD>
                <P>
                    In accordance with section 705(c)(1)(B)(i)(I) of the Act, we calculated an individual estimated subsidy rate for Antique Marbonite and Pokarna. Section 705(c)(5)(A)(i) of the Act states that for companies not individually investigated, we will 
                    <PRTPAGE P="25399"/>
                    determine an all-others rate equal to the weighted average of the countervailable subsidy rates established for exporters and producers individually investigated, excluding any zero and 
                    <E T="03">de minimis</E>
                     countervailable subsidy rates, and any rates based entirely on AFA under section 776 of the Act, by exports of subject merchandise to the United States. Therefore, the all-others rate is a weighted average of the Antique Marbonite and Pokarna rates.
                    <SU>8</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Certain Quartz Surface Products from India: All Others Rate,” dated concurrently with this notice.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Final Determination</HD>
                <P>We determine the total estimated net countervailable subsidy rates to be:</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s75,9">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Producer/exporter</CHED>
                        <CHED H="1">
                            Subsidy rate
                            <LI>(percent)</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            Antique Marbonite Private Limited 
                            <SU>9</SU>
                        </ENT>
                        <ENT>
                            <SU>10</SU>
                             1.57
                        </ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">
                            Pokarna Engineered Stone Limited 
                            <SU>11</SU>
                        </ENT>
                        <ENT>2.34</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">All Others</ENT>
                        <ENT>2.17</ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">Disclosure</HD>
                <P>
                    We intend to
                    <FTREF/>
                     disclose to
                    <FTREF/>
                     interested parties the
                    <FTREF/>
                     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 to parties in this proceeding in accordance with 19 CFR 351.224(b).
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         The company's legal name is Antique Marbonite Private Limited and trade name is Antique Marbonite Pvt. Ltd. Commerce finds the following companies to be cross owned with Antique Marbonite Private Limited: Antique Granito Shareholders Trust (Antique Trust), Prism Johnson Limited (Prism Johnson), and Shivam Enterprise (Shivam).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         Unlike at the 
                        <E T="03">Preliminary Determination,</E>
                         Antique Marbonite's subsidy rate is not 
                        <E T="03">de minimis</E>
                         for this final determination. On February 10, 2020, the United States Trade Representative published in the 
                        <E T="04">Federal Register</E>
                         revised designations of developing and least-developed countries under the CVD law. Effective as of February 10, 2020, India is no longer designated as a developing country and now has a 
                        <E T="03">de minimis</E>
                         rate of 1.0 percent. 
                        <E T="03">See Designations of Developing and Least-Developed Countries Under the Countervailing Duty Law,</E>
                         85 FR 7613 (February 10, 2020).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         Commerce finds the following company to be cross owned with Pokarna: Pokarna Limited.
                    </P>
                </FTNT>
                <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 suspend liquidation of entries of subject merchandise, as described in the scope of the investigation section, that was entered or withdrawn from warehouse for consumption on or after October 11, 2019, the date of publication of the 
                    <E T="03">Preliminary Determination</E>
                     in the 
                    <E T="04">Federal Register</E>
                    , for Pokarna. For all other companies, Commerce instructed CBP to suspend liquidation of entries of subject merchandise that was entered or withdrawn from warehouse for consumption on or after July 13, 2019, because Commerce determined that critical circumstances exist for imports of subject merchandise from all producers and/or exporters not individually examined.
                </P>
                <P>
                    Because the preliminary subsidy rate for Antique Marbonite was 
                    <E T="03">de minimis,</E>
                     Commerce directed CBP not to suspend liquidation of entries of the subject merchandise produced by Antique Marbonite and exported by Antique Marbonite, Antique Trust, Prism Johnson, or Shivam. However, because the final subsidy rate for Antique Marbonite is above 
                    <E T="03">de minimis,</E>
                     in accordance with section 705(c)(1)(C) of the Act, we are directing CBP to suspend liquidation of all entries of quartz surface products from India produced and/or exported by Antique Marbonite that are entered, or withdrawn from warehouse, for consumption on or after the date of the publication of this notice in the 
                    <E T="04">Federal Register</E>
                     and to require a cash deposit for such entries of merchandise in the amount indicated above.
                </P>
                <P>
                    As a result of the 
                    <E T="03">Amended Preliminary Determination,</E>
                     on November 21, 2019, Commerce instructed CBP to suspend liquidation of entries of subject merchandise, that was entered or withdrawn from warehouse for consumption on or after November 20, 2019, the date of publication of the 
                    <E T="03">Amended Preliminary Determination</E>
                     in the 
                    <E T="04">Federal Register</E>
                    , at a different cash deposit rate for Pokarna and all other producers/exports (
                    <E T="03">i.e.,</E>
                     other than Antique Marbonite) than the cash deposit rates in the 
                    <E T="03">Preliminary Determination.</E>
                </P>
                <P>In accordance with section 703(d) of the Act, we issued instructions to CBP to discontinue the suspension of liquidation for CVD purposes for subject merchandise entered, or withdrawn from warehouse, on or after February 8, 2020, but to continue the suspension of liquidation of all entries from October 11, 2019 through February 7, 2020 for Pokarna and July 13, 2019 through February 7, 2020, for all producers and/or exporters not individually examined.</P>
                <P>If the U.S. International Trade Commission (ITC) issues a final affirmative injury determination, we will issue a CVD order, reinstate the suspension of liquidation under section 706(a) of the Act, and will require a cash deposit of estimated countervailing duties for such entries of subject merchandise in the amounts indicated above. 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">ITC Notification</HD>
                <P>In accordance with section 705(d) of the Act, we will notify the ITC of our determination. 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 quartz surface products from India no later than 45 days after our final determination. If the ITC determines that material injury or threat of material injury does not exist, the proceeding will be terminated and all cash deposits will be refunded. If the ITC determines that material injury or threat of material injury does exist, Commerce will issue a CVD order directing CBP to assess, upon further instruction by Commerce, countervailing 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 “Continuation of Suspension of Liquidation” section.</P>
                <HD SOURCE="HD1">Notification Regarding Administrative Protective Orders</HD>
                <P>In the event the ITC issues a final negative injury determination, this notice serves 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 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 subject to sanction.</P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>This determination is issued and published pursuant to sections 705(d) and 777(i) of the Act and 19 CFR 351.210(c).</P>
                <SIG>
                    <PRTPAGE P="25400"/>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Jeffrey I. Kessler,</NAME>
                    <TITLE>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 merchandise covered by the investigation is certain quartz surface products. Quartz surface products consist of slabs and other surfaces created from a mixture of materials that includes predominately silica (
                        <E T="03">e.g.,</E>
                         quartz, quartz powder, cristobalite, glass powder) as well as a resin binder (
                        <E T="03">e.g.,</E>
                         an unsaturated polyester). The incorporation of other materials, including, but not limited to, pigments, cement, or other additives does not remove the merchandise from the scope of the investigation. However, the scope of the investigation only includes products where the silica content is greater than any other single material, by actual weight. Quartz surface products are typically sold as rectangular slabs with a total surface area of approximately 45 to 60 square feet and a nominal thickness of one, two, or three centimeters. However, the scope of this investigation includes surface products of all other sizes, thicknesses, and shapes. In addition to slabs, the scope of this investigation includes, but is not limited to, other surfaces such as countertops, backsplashes, vanity tops, bar tops, work tops, tabletops, flooring, wall facing, shower surrounds, fire place surrounds, mantels, and tiles. Certain quartz surface products are covered by the investigation whether polished or unpolished, cut or uncut, fabricated or not fabricated, cured or uncured, edged or not edged, finished or unfinished, thermoformed or not thermoformed, packaged or unpackaged, and regardless of the type of surface finish.
                    </P>
                    <P>In addition, quartz surface products are covered by the investigation whether or not they are imported attached to, or in conjunction with, non-subject merchandise such as sinks, sink bowls, vanities, cabinets, and furniture. If quartz surface products are imported attached to, or in conjunction with, such non-subject merchandise, only the quartz surface product is covered by the scope.</P>
                    <P>Subject merchandise includes material matching the above description that has been finished, packaged, or otherwise fabricated in a third country, including by cutting, polishing, curing, edging, thermoforming, attaching to, or packaging with another product, or any other finishing, packaging, or fabrication that would not otherwise remove the merchandise from the scope of the investigation if performed in the country of manufacture of the quartz surface products.</P>
                    <P>The scope of the investigation does not cover quarried stone surface products, such as granite, marble, soapstone, or quartzite. Specifically excluded from the scope of the investigation are crushed glass surface products. Crushed glass surface products must meet each of the following criteria to qualify for this exclusion: (1) The crushed glass content is greater than any other single material, by actual weight; (2) there are pieces of crushed glass visible across the surface of the product; (3) at least some of the individual pieces of crushed glass that are visible across the surface are larger than 1 centimeter wide as measured at their widest cross-section (“Glass Pieces”); and (4) the distance between any single Glass Piece and the closest separate Glass Piece does not exceed three inches.</P>
                    <P>The products subject to the scope are currently classified in the Harmonized Tariff Schedule of the United States (HTSUS) under the following subheading: 6810.99.0010. Subject merchandise may also enter under subheadings 6810.11.0010, 6810.11.0070, 6810.19.1200, 6810.19.1400, 6810.19.5000, 6810.91.0000, 6810.99.0080, 6815.99.4070, 2506.10.0010, 2506.10.0050, 2506.20.0010, 2506.20.0080, and 7016.90.1050. The HTSUS subheadings set forth above are provided for convenience and U.S. Customs purposes only. The written description of the scope is dispositive.</P>
                </EXTRACT>
                <HD SOURCE="HD1">Appendix II</HD>
                <EXTRACT>
                    <HD SOURCE="HD1">List of Topics Discussed in the Final Decision Memorandum</HD>
                    <FP SOURCE="FP-2">I. Summary</FP>
                    <FP SOURCE="FP-2">II. Background</FP>
                    <FP SOURCE="FP-2">III. Scope Comments</FP>
                    <FP SOURCE="FP-2">IV. Scope of the Investigation</FP>
                    <FP SOURCE="FP-2">V. Affirmative Final Determination of Critical Circumstances</FP>
                    <FP SOURCE="FP-2">VI. Use of Facts Otherwise Available and Adverse Inferences</FP>
                    <FP SOURCE="FP-2">VII. Subsidies Valuation</FP>
                    <FP SOURCE="FP-2">VIII. Analysis of Programs</FP>
                    <FP SOURCE="FP-2">IX. Analysis of Comments</FP>
                    <FP SOURCE="FP1-2">
                        Comment 1: Appropriate 
                        <E T="03">De Minimis</E>
                         Threshold for India
                    </FP>
                    <FP SOURCE="FP1-2">Comment 2: Application of AFA for the Provision of Natural Gas for Less Than Adequate Remuneration (LTAR)</FP>
                    <FP SOURCE="FP1-2">Comment 3: Whether Commerce Should Select Imports of Liquified Natural Gas as the Natural Gas Benchmark</FP>
                    <FP SOURCE="FP1-2">Comment 4: Whether Commerce's Natural Gas AFA Determination Rewards Non- Compliance</FP>
                    <FP SOURCE="FP1-2">Comment 5: Inclusion of the Integrated Goods and Services Tax in the Natural Gas Benchmark</FP>
                    <FP SOURCE="FP1-2">Comment 6: Whether Commerce Should Countervail the Duty Drawback Scheme</FP>
                    <FP SOURCE="FP1-2">Comment 7: Whether Commerce Should Countervail the Interest Equalization Scheme for Export Financing</FP>
                    <FP SOURCE="FP1-2">Comment 8: Whether Special Economic Zone (SEZ) Programs Which Pokarna Used Are Countervailable</FP>
                    <FP SOURCE="FP1-2">Comment 9: Whether Pokarna's Lease of Land from the Andhra Pradesh Industrial Investment Corporation (APIIC) Constitutes a Countervailable Subsidy</FP>
                    <FP SOURCE="FP1-2">Comment 10: Whether Commerce Used the Correct Benchmark to Determine Whether the APIIC Allotted Land to Pokarna for LTAR</FP>
                    <FP SOURCE="FP1-2">Comment 11: Whether Pokarna Misrepresented Its Purchase of Land and Fixed Assets Originally Owned by Indo Rock Granite Private Limited (Indo Rock) That Warrants the Application of Adverse Facts Available</FP>
                    <FP SOURCE="FP1-2">Comment 12: Whether Commerce Used an Incorrect Sales Denominator When Calculating the Net Subsidy Rate for a Countervailable Subsidy Attributable to Pokarna Limited</FP>
                    <FP SOURCE="FP1-2">Comment 13: Whether Commerce's Initiation of this Investigation Was Contrary to Law</FP>
                    <FP SOURCE="FP-2">X. Recommendation</FP>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09409 Filed 4-30-20; 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-489-838]</DEPDOC>
                <SUBJECT>Certain Quartz Surface Products From the Republic of Turkey: Final Affirmative Countervailing Duty Determination and Final Affirmative Determination of Critical Circumstances, In Part</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 Department of Commerce (Commerce) determines that countervailable subsidies are being provided to producers and exporters of certain quartz surface products (quartz surface products) from the Republic of Turkey (Turkey).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Applicable May 1, 2020.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Stephanie Berger or Peter Zukowski, 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-2483 or (202) 482-0189, respectively.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Background</HD>
                <P>
                    On October 11, 2019, Commerce published the 
                    <E T="03">Preliminary Determination</E>
                     of the countervailing duty (CVD) investigation, which aligned the final determination in this CVD investigation with the final determination in the companion antidumping duty (AD) investigation of quartz surface products from Turkey.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See Certain Quartz Surface Products from the Republic of Turkey: Preliminary Affirmative Countervailing Duty Determination, Preliminary Affirmative Critical Circumstances Determination, and Alignment of Final Determination with Final Antidumping Duty Determination,</E>
                         84 FR 54843 (October 11, 2019) (
                        <E T="03">Preliminary Determination</E>
                        ), and accompanying Preliminary Decision Memorandum (PDM).
                    </P>
                </FTNT>
                <P>
                    A summary of the events that occurred since Commerce published the 
                    <E T="03">Preliminary Determination,</E>
                     as well as a full discussion of the issues raised by parties for this final determination, are discussed in the Issues and Decision 
                    <PRTPAGE P="25401"/>
                    Memorandum, which is hereby adopted by this notice.
                    <SU>2</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">http://enforcement.trade.gov/frn/index.html.</E>
                     The signed and electronic versions of the Issues and Decision Memorandum are identical in content.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Issues and Decisions Memorandum for the Final Determination of the Countervailing Duty Investigation of Certain Quartz Surface Products from Turkey,” dated concurrently with, and hereby adopted by, this notice (Issues and Decisions Memorandum).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Period of Investigation</HD>
                <P>The period of investigation is January 1, 2018 through December 31, 2018.</P>
                <HD SOURCE="HD1">Scope of the Investigation</HD>
                <P>
                    The products covered by this investigation are quartz surface products from Turkey. For a complete description of the scope of this investigation, 
                    <E T="03">see</E>
                     Appendix I.
                </P>
                <HD SOURCE="HD1">Scope Comments</HD>
                <P>
                    On December 4, 2019, we issued a Preliminary Scope Memorandum.
                    <SU>3</SU>
                    <FTREF/>
                     We received no scope case briefs from interested parties. Therefore, Commerce has made no changes to the scope of this investigation since the 
                    <E T="03">Preliminary Determination.</E>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Certain Quartz Surface Products from India and Turkey: Preliminary Scope Decision Memorandum,” dated December 4, 2019.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Analysis of Subsidy Programs and Comments Received</HD>
                <P>The subsidy programs under investigation and the issues raised in the case and rebuttal briefs by parties in this investigation are discussed in the Issues and Decision Memorandum. A list of the issues that parties raised is attached to this notice as Appendix II.</P>
                <HD SOURCE="HD1">Methodology</HD>
                <P>
                    Commerce conducted this investigation in accordance with section 701 of the Tariff Act of 1930, as amended (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>4</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>4</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">Verification</HD>
                <P>
                    As provided in section 782(i) of the Act, in December 2019, we conducted verification of the information submitted by the Government of Turkey 
                    <SU>5</SU>
                    <FTREF/>
                     and the mandatory respondent, Belenco Diş Ticaret A.Ş. (Belenco), for use in Commerce's final determination. We used standard verification procedures, including an examination of relevant accounting records and original source documents provided by the respondents.
                    <SU>6</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Verification of the Questionnaire Responses of the Republic of Turkey,” dated January 23, 2020.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See</E>
                         Memorandum, “Verification of the Questionnaire Responses of Belenco Diş Ticaret A Ş.,” dated January 23, 2020.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Changes Since the Preliminary Determination</HD>
                <P>
                    Based on our review and analysis of the comments received from parties and our verification findings, we made certain changes to the subsidy rate calculations for Belenco. For a discussion of these changes, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <HD SOURCE="HD1">Final Affirmative Determination of Critical Circumstances, In Part</HD>
                <P>
                    In accordance with section 703(e)(1)(B) of the Act, Commerce preliminarily determined that critical circumstances existed for all imports of quartz surface products from Turkey.
                    <SU>7</SU>
                    <FTREF/>
                     Upon further analysis of the data following the 
                    <E T="03">Preliminary Determination,</E>
                     we are modifying our findings for the final determination.
                    <SU>8</SU>
                    <FTREF/>
                     Specifically, in accordance with section 705(a)(2) of the Act, we find that critical circumstances do not exist with respect to imports from Belenco. We continue to find, as we did in the 
                    <E T="03">Preliminary Determination,</E>
                     that critical circumstances exist with respect to imports from all other companies. For a full description of the methodology and results of Commerce's analysis, 
                    <E T="03">see</E>
                     the Issues and Decision Memorandum.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See Preliminary Determination.</E>
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See</E>
                         Issues and Decisions Memorandum at 2-3.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">All-Others Rate</HD>
                <P>
                    We continue to assign the countervailable subsidy rate calculated for Belenco as the all-others rate applicable to all exporters and/or producers not individually examined.
                    <SU>9</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See Preliminary Determination.</E>
                    </P>
                </FTNT>
                <HD SOURCE="HD1">Final Determination</HD>
                <P>In accordance with section 705(c)(1)(B)(i)(I) of the Act, we calculated an individual estimated subsidy rate for Belenco. We determine the total estimated net countervailable subsidy rate to be:</P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s100,9">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Producer/exporter</CHED>
                        <CHED H="1">Subsidy rate (%)</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            Belenco Diş Ticaret A.Ş. and Peker Yüzey Tasarıları Sanayi ve Tic. A.Ş.
                            <SU>10</SU>
                        </ENT>
                        <ENT>2.43 </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">All Others</ENT>
                        <ENT>2.43 </ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD1">
                    Disclosure
                    <FTREF/>
                </HD>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         As discussed in the 
                        <E T="03">Preliminary Determination,</E>
                         Commerce found the following company to be cross-owned with Belenco Dis Ticaret AS: Peker Yüzey Tasarıları Sanayi ve Tic. A.Ş. No party commented on this finding in the case briefs.
                    </P>
                </FTNT>
                <P>We intend to disclose to interested parties the calculations and analysis performed in this final determination within five days of the date of the publication of this notice 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)(I)(B) and (d)(2) of the Act, Commerce instructed U.S. Customs and Border Protection (CBP) to suspend liquidation of entries of subject merchandise, as described in the scope of the investigation section, that was entered or withdrawn from warehouse for consumption on or after August 13, 2019, which is 90 days prior to the 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 for countervailing duty (CVD) purposes for subject merchandise entered, or withdrawn from warehouse, on or after February 8, 2020 but to continue the suspension of liquidation of all entries from August 13, 2019 through February 7, 2020.
                </P>
                <P>
                    Because we find critical circumstances do not exist for Belenco, we will direct CBP to terminate the retroactive suspension of liquidation ordered at the 
                    <E T="03">Preliminary Determination</E>
                     and release any cash deposits that were required prior to October 11, 2019, the date of publication of the 
                    <E T="03">Preliminary Determination</E>
                     in the 
                    <E T="04">Federal Register</E>
                    , consistent with section 705(c)(3) of the Act.
                </P>
                <P>
                    If the U.S. International Trade Commission (ITC) issues a final affirmative injury determination, we will issue a CVD order, reinstate the suspension of liquidation under section 706(a) of the Act, and will require a cash 
                    <PRTPAGE P="25402"/>
                    deposit of estimated countervailing duties for such entries of subject merchandise in the amounts indicated above. 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">ITC Notification</HD>
                <P>In accordance with section 705(d) of the Act, we will notify the ITC of our determination. 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 quartz surface products from Turkey no later than 45 days after our final determination. If the ITC determines that material injury or threat of material injury does not exist, the proceeding will be terminated and all cash deposits will be refunded. If the ITC determines that material injury or threat of material injury does exist, Commerce will issue a CVD order directing CBP to assess, upon further instruction by Commerce, countervailing 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 “Continuation of Suspension of Liquidation” section.</P>
                <HD SOURCE="HD1">Notification Regarding Administrative Protective Orders</HD>
                <P>In the event the ITC issues a final negative injury determination, this notice serves 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 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 subject to sanction.</P>
                <HD SOURCE="HD1">Notification to Interested Parties</HD>
                <P>This determination is issued and published pursuant to sections 705(d) and 777(i) of the Act and 19 CFR 351.210(c).</P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Jeffrey I. Kessler,</NAME>
                    <TITLE>Assistant Secretary for Enforcement and Compliance.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix I—Scope of the Investigation</HD>
                <EXTRACT>
                    <P>
                        The merchandise covered by the investigation is certain quartz surface products. Quartz surface products consist of slabs and other surfaces created from a mixture of materials that includes predominately silica (
                        <E T="03">e.g.,</E>
                         quartz, quartz powder, cristobalite, glass powder) as well as a resin binder (
                        <E T="03">e.g.,</E>
                         an unsaturated polyester). The incorporation of other materials, including, but not limited to, pigments, cement, or other additives does not remove the merchandise from the scope of the investigation. However, the scope of the investigation only includes products where the silica content is greater than any other single material, by actual weight. Quartz surface products are typically sold as rectangular slabs with a total surface area of approximately 45 to 60 square feet and a nominal thickness of one, two, or three centimeters. However, the scope of this investigation includes surface products of all other sizes, thicknesses, and shapes. In addition to slabs, the scope of this investigation includes, but is not limited to, other surfaces such as countertops, backsplashes, vanity tops, bar tops, work tops, tabletops, flooring, wall facing, shower surrounds, fire place surrounds, mantels, and tiles. Certain quartz surface products are covered by the investigation whether polished or unpolished, cut or uncut, fabricated or not fabricated, cured or uncured, edged or not edged, finished or unfinished, thermoformed or not thermoformed, packaged or unpackaged, and regardless of the type of surface finish.
                    </P>
                    <P>In addition, quartz surface products are covered by the investigation whether or not they are imported attached to, or in conjunction with, non-subject merchandise such as sinks, sink bowls, vanities, cabinets, and furniture. If quartz surface products are imported attached to, or in conjunction with, such non-subject merchandise, only the quartz surface product is covered by the scope.</P>
                    <P>Subject merchandise includes material matching the above description that has been finished, packaged, or otherwise fabricated in a third country, including by cutting, polishing, curing, edging, thermoforming, attaching to, or packaging with another product, or any other finishing, packaging, or fabrication that would not otherwise remove the merchandise from the scope of the investigation if performed in the country of manufacture of the quartz surface products.</P>
                    <P>The scope of the investigation does not cover quarried stone surface products, such as granite, marble, soapstone, or quartzite. Specifically excluded from the scope of the investigation are crushed glass surface products. Crushed glass surface products must meet each of the following criteria to qualify for this exclusion: (1) The crushed glass content is greater than any other single material, by actual weight; (2) there are pieces of crushed glass visible across the surface of the product; (3) at least some of the individual pieces of crushed glass that are visible across the surface are larger than 1 centimeter wide as measured at their widest cross-section (“Glass Pieces”); and (4) the distance between any single Glass Piece and the closest separate Glass Piece does not exceed three inches.</P>
                    <P>The products subject to the scope are currently classified in the Harmonized Tariff Schedule of the United States (HTSUS) under the following subheading: 6810.99.0010. Subject merchandise may also enter under subheadings 6810.11.0010, 6810.11.0070, 6810.19.1200, 6810.19.1400, 6810.19.5000, 6810.91.0000, 6810.99.0080, 6815.99.4070, 2506.10.0010, 2506.10.0050, 2506.20.0010, 2506.20.0080, and 7016.90.1050. The HTSUS subheadings set forth above are provided for convenience and U.S. Customs purposes only. The written description of the scope is dispositive.</P>
                </EXTRACT>
                <HD SOURCE="HD1">Appendix II—List of Topics Discussed in the Final Decision Memorandum</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Summary</FP>
                    <FP SOURCE="FP-2">II. Background</FP>
                    <FP SOURCE="FP-2">III. Scope Comments</FP>
                    <FP SOURCE="FP-2">IV. Scope of the Investigation</FP>
                    <FP SOURCE="FP-2">V. Final Determination of Critical Circumstances</FP>
                    <FP SOURCE="FP-2">VI. Subsidies Valuation Information</FP>
                    <FP SOURCE="FP-2">VII. Analysis of Programs</FP>
                    <FP SOURCE="FP-2">VIII. Analysis of Comments</FP>
                    <FP SOURCE="FP1-2">Comment 1: Whether Commerce Should Apply Adverse Facts Available (AFA) to the Local Fair Support Program</FP>
                    <FP SOURCE="FP1-2">Comment 2: Whether Commerce Should Countervail the Value-Added Tax (VAT) Exemption Granted Under the Regional Investment Incentive Scheme (RIIS)</FP>
                    <FP SOURCE="FP-2">IX. Recommendation</FP>
                </EXTRACT>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09408 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-DS-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <SUBJECT>Agency Information Collection Activities; Submission for OMB Review; Comment Request</SUBJECT>
                <P>The Department of Commerce will submit 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 (44 U.S.C. Chapter 35).</P>
                <P>
                    <E T="03">Agency:</E>
                     National Oceanic and Atmospheric Administration (NOAA).
                </P>
                <P>
                    <E T="03">Title:</E>
                     Applications and Reports for Registration as an Agent or Tanner.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     0648-0179.
                </P>
                <P>
                    <E T="03">Form Number(s):</E>
                     None.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     Regular (extension of an existing collection).
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                     14.
                </P>
                <P>
                    <E T="03">Average Hours per Response:</E>
                     Annual report—2 hours per response; permit applications—2 hours per response.
                    <PRTPAGE P="25403"/>
                </P>
                <P>
                    <E T="03">Burden Hours:</E>
                     42.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     This request is for the extension of a currently approved information collection. The Marine Mammal Protection Act exempts Alaskan natives from the prohibitions on taking, killing, or injuring marine mammals if the taking is done for subsistence or for creating and selling authentic native articles of handicraft or clothing. The natives need no permit, but non-natives who wish to act as a tanner or agent for such native products must register with NOAA and maintain and submit certain records. The information is necessary for law enforcement purposes.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Business or other for-profit organizations; state, local or tribal government.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Annually and on occasion.
                </P>
                <P>
                    <E T="03">Respondent's Obligation:</E>
                     Mandatory.
                </P>
                <P>
                    <E T="03">Legal Authority:</E>
                     US Code: 16 U.S.C. 1361 Name of Law: Marine Mammal Protection Act.
                </P>
                <P>This information collection request may be viewed at reginfo.gov. Follow the instructions to view Department of Commerce collections currently under review by OMB.</P>
                <P>
                    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 and entering either the title of the collection or the OMB Control Number 0648-0179.
                </P>
                <SIG>
                    <NAME>Sheleen Dumas,</NAME>
                    <TITLE>Department PRA Clearance Officer, Office of the Chief Information Officer, Commerce Department.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09351 Filed 4-30-20; 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 Exploration Advisory Board (OEAB)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Ocean Exploration and Research (OER) 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 for a meeting of the Ocean Exploration Advisory Board (OEAB). OEAB members will discuss and provide advice on Federal ocean exploration programs, with a particular emphasis on the topics identified in the section on Matters to Be Considered.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The announced meeting is scheduled for Wednesday, May 27, 2020, from 1:00 p.m. to 5:00 p.m. EDT and Thursday, May 28, 2020, from 1:00 p.m. to 5:00 p.m. EDT.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        This will be a virtual meeting. Information about how to participate will be posted to the OEAB website at 
                        <E T="03">http://oeab.noaa.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>Mr. David McKinnie, Designated Federal Officer, Ocean Exploration Advisory Board, National Oceanic and Atmospheric Administration, 7600 Sand Point Way NE, Seattle, WA 98115, (206) 526-6950.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>NOAA established the OEAB under the Federal Advisory Committee Act (FACA) and legislation that gives the agency statutory authority to operate an ocean exploration program and to coordinate a national program of ocean exploration. The OEAB advises NOAA leadership on strategic planning, exploration priorities, competitive ocean exploration grant programs and other matters as the NOAA Administrator requests.</P>
                <P>OEAB members represent government agencies, the private sector, academic institutions, and not-for-profit institutions involved in all facets of ocean exploration—from advanced technology to citizen exploration.</P>
                <P>In addition to advising NOAA leadership, NOAA expects the OEAB to help to define and develop a national program of ocean exploration—a network of stakeholders and partnerships advancing national priorities for ocean exploration.</P>
                <P>
                    <E T="03">Matters To Be Considered:</E>
                     The OEAB will discuss the following topics: (1) The draft recommendations to NOAA from the OEAB Blue Economy Subcommittee; (2) responses to NOAA's requests from the recently ended April 8-9, 2020 meeting; (3) plans for the next meeting; (4) annual certification of the OER competitive grants program; and (5) other matters as described in the agenda. The agenda and other meeting materials will be made available on the OEAB website at 
                    <E T="03">http://oeab.noaa.gov.</E>
                </P>
                <P>
                    <E T="03">Status:</E>
                     The meeting will be open to the public with a 15-minute public comment period on Wednesday, May 27, 2020, from 3:00 p.m. to 3:15 p.m. EDT (please check the final agenda on the OEAB website to confirm the time). The public may listen to the meeting and provide comments during the public comment period via teleconference. Participation information will be on the meeting agenda on the OEAB website.
                </P>
                <P>The OEAB expects that public statements 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 three minutes. The Designated Federal Officer must receive written comments by May 20, 2020, to provide sufficient time for OEAB review. Written comments received after May 20, 2020, will be distributed to the OEAB but may not be reviewed prior to the meeting date.</P>
                <P>
                    <E T="03">Special Accommodations:</E>
                     Requests for sign language interpretation or other auxiliary aids should be directed to the Designated Federal Officer by May 20, 2020.
                </P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>David Holst,</NAME>
                    <TITLE>Chief Financial Officer/Administrative Officer, Office of Oceanic and Atmospheric Research, National Oceanic and Atmospheric Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09270 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-KA-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF COMMERCE</AGENCY>
                <SUBAGY>National Oceanic and Atmospheric Administration</SUBAGY>
                <DEPDOC>[RTID 0648-XA151]</DEPDOC>
                <SUBJECT>North Pacific Fishery Management Council; Public Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>National Marine Fisheries Service (NMFS), National Oceanic and Atmospheric Administration (NOAA), Commerce.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of meeting.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The North Pacific Fishery Management Council's (Council) Fishery Monitoring Advisory Committee (FMAC) will meet May 19, 2020.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be held on Tuesday, May 19, 2020, from 8 a.m. to 4 p.m., Alaska Daylight Time.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will be a webconference. Join online through the link at 
                        <E T="03">https://meetings.npfmc.org/Meeting/Details/1464.</E>
                    </P>
                    <P>
                        <E T="03">Council address:</E>
                         North Pacific Fishery Management Council, 1007 W 3rd Ave, Anchorage, AK 99501-2252; telephone: (907) 271-2809. Instructions for attending the meeting are given under 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         below.
                    </P>
                </ADD>
                <FURINF>
                    <PRTPAGE P="25404"/>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Kate Haapala, Council staff; email: 
                        <E T="03">kate.haapala@noaa.gov.</E>
                         For technical support please contact Maria Davis, Council staff, email: 
                        <E T="03">maria.davis@noaa.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Agenda</HD>
                <HD SOURCE="HD2">Tuesday, May 19, 2020</HD>
                <P>The May 2020 FMAC meeting will focus on COVID-19 issues related to observer deployment and data collection in the full and partial coverage fleets, providing a forum for dialogue among multiple stakeholders and agency staff to address challenges. The agenda will include: (a) Introduction and updates since the last FMAC meeting; (b) observer deployment and sampling protocols related to COVID-19; (c) vessel inspection updates; (d) discussion of full and partial coverage issues; (e) the 2021 Annual Deployment Plan and 2019 Annual Report; and (f) other business.</P>
                <P>
                    The agenda is subject to change, and the latest version will be posted at 
                    <E T="03">https://meetings.npfmc.org/Meeting/Details/1464</E>
                     prior to the meeting, along with meeting materials.
                </P>
                <HD SOURCE="HD1">Connection Information</HD>
                <P>
                    You can attend the meeting online using a computer, tablet, or smart phone; or by phone only. Connection information will be posted online at: 
                    <E T="03">https://meetings.npfmc.org/Meeting/Details/1464.</E>
                </P>
                <HD SOURCE="HD1">Public Comment</HD>
                <P>
                    Public comment letters will be accepted and should be submitted electronically to 
                    <E T="03">https://meetings.npfmc.org/Meeting/Details/1464.</E>
                </P>
                <HD SOURCE="HD1">Special Accommodations</HD>
                <P>The meeting is physically accessible to people with disabilities. Requests should be directed to Shannon Gleason at (907) 271-2809 at least 7 working days prior to the meeting date.</P>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                        16 U.S.C. 1801 
                        <E T="03">et seq.</E>
                    </P>
                </AUTH>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Tracey L. Thompson,</NAME>
                    <TITLE>Acting Deputy Director, Office of Sustainable Fisheries, National Marine Fisheries Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09383 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 3510-22-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">COMMITTEE FOR PURCHASE FROM PEOPLE WHO ARE BLIND OR SEVERELY DISABLED</AGENCY>
                <SUBJECT>Procurement List; Additions and Deletions</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Committee for Purchase From People Who Are Blind or Severely Disabled.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Additions to and deletions from the Procurement List.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This action adds products to the Procurement List that will be furnished by nonprofit agencies employing persons who are blind or have other severe disabilities, and deletes products and services from the Procurement List previously furnished by such agencies.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Date added to and deleted from the Procurement List:</E>
                         May 31, 2020
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Committee for Purchase From People Who Are Blind or Severely Disabled, 1401 S Clark Street, Suite 715, Arlington, Virginia 22202-4149.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Michael R. Jurkowski, Telephone: (703) 603-2117, Fax: (703) 603-0655, or email 
                        <E T="03">CMTEFedReg@AbilityOne.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published pursuant to 41 U.S.C. 8503 (a)(2) and 41 CFR 51-2.3. Its purpose is to provide interested persons an opportunity to submit comments on the proposed actions.</P>
                <HD SOURCE="HD1">Additions</HD>
                <P>On 8/16/2019, 9/6/2019, 3/20/2020 and 3/27/2020, the Committee for Purchase From People Who Are Blind or Severely Disabled published notice of proposed additions to the Procurement List. This notice is published pursuant to 41 U.S.C. 8503 (a)(2) and 41 CFR 51-2.3.</P>
                <P>After consideration of the material presented to it concerning capability of qualified nonprofit agencies to provide the products and impact of the additions on the current or most recent contractors, the Committee has determined that the products listed below are suitable for procurement by the Federal Government under 41 U.S.C. 8501-8506 and 41 CFR 51-2.4.</P>
                <HD SOURCE="HD2">Regulatory Flexibility Act Certification</HD>
                <P>I certify that the following action will not have a significant impact on a substantial number of small entities. The major factors considered for this certification were:</P>
                <P>1. The action will not result in any additional reporting, recordkeeping or other compliance requirements for small entities other than the small organizations that will furnish the products to the Government.</P>
                <P>2. The action will result in authorizing small entities to furnish the products to the Government.</P>
                <P>3. There are no known regulatory alternatives which would accomplish the objectives of the Javits-Wagner-O'Day Act (41 U.S.C. 8501-8506) in connection with the products proposed for addition to the Procurement List.</P>
                <HD SOURCE="HD2">End of Certification</HD>
                <P>Accordingly, the following products are added to the Procurement List:</P>
                <EXTRACT>
                    <HD SOURCE="HD2">Products</HD>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">6515-01-NIB-0262—Gloves, Patient Examination and Treatment, Sand, Large, For CLS 6545-01-677-4906 Only</FP>
                    <FP SOURCE="FP1-2">6510-01-NIB-2275—Bandage Kit, Elastic, For CLS 6545-01-677-4906 Only</FP>
                    <FP SOURCE="FP1-2">6515-01-NIB-1877—Shield, Eye, Surgical with Garter Shield Cover, White, For CLS 6545-01-677-4906 Only</FP>
                    <FP SOURCE="FP1-2">6510-01-NIB-2117—Bandage Gauze, For CLS 6545-01-677-4906 Only</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Lighthouse Works, Orlando, FL
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Defense Logistics Agency, DLA Troop Support
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">9150-00-231-6689—Lubricating Oil, Utility, 1 Qt.</FP>
                    <FP SOURCE="FP1-2">9150-00-281-2060—Lubricating Oil, Utility</FP>
                    <FP SOURCE="FP1-2">9150-00-231-9045—Lubricating Oil, Utility, MMPV, 1 Gal.</FP>
                    <FP SOURCE="FP1-2">9150-00-231-9062—Lubricating Oil, Utility, CN/5 Gal.</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         The Lighthouse for the Blind, St. Louis, MO
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Defense Logistics Agency, DLA Aviation
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSN—Product Name:</E>
                    </FP>
                    <FP SOURCE="FP1-2">MR 13116—Pan, Fry, Non-stick, Silicone Handle, 11 Inches</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Winston-Salem Industries for the Blind, Inc., Winston-Salem, NC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Military Resale-Defense Commissary Agency
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0237—Illuminating Grip Wrap, Roll, 1-1/2” x 5'</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0238—Illuminating Grip Wrap, Roll, 1-1/2” x 10'</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0239—Self-Contained Breathing Apparatus Identifier Tags</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0240—One-Sided Exit Sign, Silver with Photo Luminescent Letters and Silver Frame, Post Mount</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0241—Two-Sided Exit Sign, Silver with Photo Luminescent letters and Silver Frame, Post Mount</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0242—One-Sided Exit Sign, Silver with Photo Luminescent Letters and Silver Frame, Wall Mount Bracket</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0243—One-Sided Exit Sign with Photo Luminescent Letters, No Frame or Mount</FP>
                    <FP SOURCE="FP1-2">
                        4240-00-NIB-0244—Illuminating Multipurpose Adhesive Tape, Roll, 1-1/4” x 25'
                        <PRTPAGE P="25405"/>
                    </FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0245—Illuminating Multipurpose Adhesive Tape, Roll, 1-1/4” x 50'</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0246—Illuminating Multipurpose Adhesive Tape with Directional Arrows, Roll, 1-1/4” x 25'</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0247—Illuminating Multipurpose Adhesive Tape with Directional Arrows, Roll, 1-1/4” x 50'</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0248—Illuminating Helmet Band, 11-1/2” x 1-1/2”</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0269—Sign, “EXIT”, Clear Lucite with Mounting Bracket, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0270—Sign, “EXIT”, Mirrored Lucite with Mounting Bracket, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0271—Kit, Conversion, Mirrored Lucite “EXIT”, Double Sided, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0272—Label, “STANDPIPE”, Adhesive Back, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0273—Label, “EMERGENCY EXIT”, Adhesive Back, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0274—Sign, “RUNNING MAN” with Directional Arrow, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0275—Sign, “FIRE EXTINGUISHER”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0276—Label, Custom, SBCA ID, Adhesive Back, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0282—Sign, “FLOOR 1”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0283—Sign, “FLOOR 2”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0284—Sign, “FLOOR 3”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0285—Sign, “FLOOR 4”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0286—Sign, “FLOOR 5”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0287—Sign, “FLOOR 6”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0288—Sign, “FLOOR 7”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0289—Sign, “FLOOR 8”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0290—Sign, “FLOOR 9”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0291—Sign, “FLOOR 10”, Stairwell Identifier, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0292—Sign, Side Directional Arrow, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0293—Sign, Corner Directional Arrow, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0294—Sign, “NOT AN EXIT”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0295—Sign, “EXIT LEFT”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0296—Sign, “EXIT RIGHT”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0297—Sign, “STAIRS”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0298—Sign, Custom Printed, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0299—Sign, “DOOR REMAINED UNLOCKED”</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0300—Sign, “FIRE DOOR KEEP CLOSED”</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0301—Sign, “NO SMOKING”</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0302—Sign, Custom Eco Solvent Printed</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0303—Sign, “EXIT”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0304—Sign, “TIME DELAYED DOOR”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0305—Sign, “IN CASE OF FIRE”, Photoluminescent</FP>
                    <FP SOURCE="FP1-2">4240-00-NIB-0306—Sign, Custom Printed, Photoluminescent</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Cincinnati Association for the Blind, Cincinnati, OH
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Defense Logistics Agency, DLA Troop Support
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">NSNs 8405-01-683-3986 through 8405-01-683-4516, 111 sizes—Shirt, Army Green Service Uniform, Men's, L/S, Athletic Fit, Heritage Tan</FP>
                    <FP SOURCE="FP1-2">
                        <E T="03">NSNs 8405-01-683-2858 through 8405-01-683-3435, 135 sizes</E>
                        —Shirt, Army Green Service Uniform, Men's, L/S, Classic Fit, Heritage Tan
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Goodwill Industries of South Florida, Inc., Miami, FL
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Dept of the Army, W6QK ACC-APG Natick
                    </FP>
                </EXTRACT>
                <HD SOURCE="HD1">Deletions</HD>
                <P>On 3/27/2020, the Committee for Purchase From People Who Are Blind or Severely Disabled published notice of proposed deletions from the Procurement List.</P>
                <P>After consideration of the relevant matter presented, the Committee has determined that the products and services listed below are no longer suitable for procurement by the Federal Government under 41 U.S.C. 8501-8506 and 41 CFR 51-2.4.</P>
                <HD SOURCE="HD2">Regulatory Flexibility Act Certification</HD>
                <P>I certify that the following action will not have a significant impact on a substantial number of small entities. The major factors considered for this certification were:</P>
                <P>1. The action will not result in additional reporting, recordkeeping or other compliance requirements for small entities.</P>
                <P>2. The action may result in authorizing small entities to furnish the products and services to the Government.</P>
                <P>3. There are no known regulatory alternatives which would accomplish the objectives of the Javits-Wagner-O'Day Act (41 U.S.C. 8501-8506) in connection with the products and services deleted from the Procurement List.</P>
                <HD SOURCE="HD2">End of Certification</HD>
                <P>Accordingly, the following products and services are deleted from the Procurement List:</P>
                <EXTRACT>
                    <HD SOURCE="HD2">Products</HD>
                    <FP SOURCE="FP-2">
                        <E T="03">NSN—Product Name:</E>
                    </FP>
                    <FP SOURCE="FP1-2">7510-01-317-4219—Dispenser, Clip System, Paper, Desktop, Medium</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         San Antonio Lighthouse for the Blind, San Antonio, TX
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         GSA/FAS Admin Svcs Acquisition BR(2, New York, NY
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">7360-01-J19-2026—Dining Packet</FP>
                    <FP SOURCE="FP1-2">7360-01-J19-2030—Dining Packet</FP>
                    <FP SOURCE="FP1-2">7360-01-J19-2062—Dining Packet</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         LC Industries, Inc., Durham, NC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         DLA Troop Support, Philadelphia, PA
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">8415-01-315-9765—Ruff, Cold Weather Parka, White Synthetic Fur and Woodland Camouflage, X-Small</FP>
                    <FP SOURCE="FP1-2">8415-01-315-9766—Ruff, Cold Weather Parka, White Synthetic Fur and Woodland Camouflage, Small</FP>
                    <FP SOURCE="FP1-2">8415-01-315-9767—Ruff, Cold Weather Parka, White Synthetic Fur and Woodland Camouflage, Medium</FP>
                    <FP SOURCE="FP1-2">8415-01-315-9768—Ruff, Cold Weather Parka, White Synthetic Fur and Woodland Camouflage, Large</FP>
                    <FP SOURCE="FP1-2">8415-01-315-9769—Ruff, Cold Weather Parka, White Synthetic Fur and Woodland Camouflage, X-Large</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         RLCB, Inc., Raleigh, NC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         DLA Troop Support, Philadelphia, PA
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">MR 10647—Saver, Herb, Includes Shipper 20647</FP>
                    <FP SOURCE="FP1-2">MR 11088—Blanket, Pet, Large</FP>
                    <FP SOURCE="FP1-2">MR 11302—Cooler, Styrofoam, Handled, 22 Qt.</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Winston-Salem Industries for the Blind, Inc., Winston-Salem, NC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Military Resale-Defense Commissary Agency
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSN—Product Name:</E>
                    </FP>
                    <FP SOURCE="FP1-2">8010-00-848-9272—Enamel, Aerosol, Ammunition and Metals, Flat Olive Drab</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         The Lighthouse for the Blind, St. Louis, MO
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         FAS Heartland Regional Administrato, Kansas City, MO
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSN—Product Name:</E>
                    </FP>
                    <FP SOURCE="FP1-2">6230-01-641-0756—Flashlight, Tactical, Lithium-Ion Rechargeable, Multi-color LEDs</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Central Association for the Blind &amp; Visually Impaired, Utica, NY
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         DLA Troop Support, Philadelphia, PA
                    </FP>
                    <HD SOURCE="HD2">Services</HD>
                    <FP SOURCE="FP-2">
                        <E T="03">Service Type:</E>
                         Maintenance Service Re-lamping
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory for:</E>
                         Department of Interior—South: Office of Surface Mining, Washington, DC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         ServiceSource, Inc., Oakton, VA
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Office of Policy, Management, and Budget, NBC Acquisition Services Division
                    </FP>
                </EXTRACT>
                <SIG>
                    <NAME>Michael R. Jurkowski,</NAME>
                    <TITLE>Deputy Director, Business &amp; PL Operations.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09327 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 6353-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="25406"/>
                <AGENCY TYPE="S">COMMITTEE FOR PURCHASE FROM PEOPLE WHO ARE BLIND OR SEVERELY DISABLED</AGENCY>
                <SUBJECT>Procurement List; Proposed Additions and Deletions</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Committee for Purchase From People Who Are Blind or Severely Disabled.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Proposed Additions to and Deletions From the Procurement List.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Committee is proposing to add products and a service to the Procurement List that will be furnished by nonprofit agencies employing persons who are blind or have other severe disabilities, and deletes products and services previously furnished by such agencies.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Comments must be received on or before:</E>
                         May 31, 2020.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Committee for Purchase From People Who Are Blind or Severely Disabled, 1401 S Clark Street, Suite 715, Arlington, Virginia, 22202-4149.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        For further information or to submit comments contact: Michael R. Jurkowski, Telephone: (703) 603-2117, Fax: (703) 603-0655, or email 
                        <E T="03">CMTEFedReg@AbilityOne.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice is published pursuant to 41 U.S.C. 8503 (a)(2) and 41 CFR 51-2.3. Its purpose is to provide interested persons an opportunity to submit comments on the proposed actions.</P>
                <HD SOURCE="HD1">Additions</HD>
                <P>If the Committee approves the proposed additions, the entities of the Federal Government identified in this notice will be required to procure the products and service listed below from nonprofit agencies employing persons who are blind or have other severe disabilities.</P>
                <P>The following products and service are proposed for addition to the Procurement List for production by the nonprofit agencies listed:</P>
                <EXTRACT>
                    <HD SOURCE="HD2">Products</HD>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0002—3D Printer Filament, Acrylonitrile Butadiene Styrene, Black,1kg of 1.75 mm</FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0003—3D Printer Filament, Acrylonitrile Butadiene Styrene, White 1kg of 1.75 mm</FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0004—3D Printer Filament, Acrylonitrile Butadiene Styrene, Natural,1kg of 1.75 mm</FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0005—3D Printer Filament, Polylactic Acid, Black,1kg of 1.75 mm</FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0006—3D Printer Filament, Polylactic Acid, White,1kg of 1.75 mm</FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0007—3D Printer Filament, Polylactic Acid, Natural,1kg of 1.75 mm</FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0008—3D Printer Filament, Nylon, Black,1kg of 1.75 mm</FP>
                    <FP SOURCE="FP1-2">3612-00-NIB-0010—3D Printer Filament, Nylon, Natural,1kg of 1.75 mm</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         North Central Sight Services, Inc., Williamsport, PA
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory For:</E>
                         Total Government Requirement
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Federal Acquisition Service, GSA/FAS Furniture Systems MGT DIV
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">MR 13052—Bento Box, 1 Compartment</FP>
                    <FP SOURCE="FP1-2">MR 13053—Bento Box, 2 Compartments</FP>
                    <FP SOURCE="FP1-2">MR 13054—Bento Box, 3 Compartments</FP>
                    <FP SOURCE="FP1-2">MR 13055—Bento Box, Round, 2 Compartments</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Winston-Salem Industries for the Blind, Inc., Winston-Salem, NC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Military Resale-Defense Commissary Agency
                    </FP>
                    <HD SOURCE="HD2">Service</HD>
                    <FP SOURCE="FP-2">
                        <E T="03">Service Type:</E>
                         Facility Maintenance Support Services
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory for:</E>
                         U.S. Marshalls Service, Marshalls Service Tactical Operations Center, Camp Beauregard, Pineville, LA
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Rising Star Resource Development Corporation, Dallas, TX
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         U.S. Dept of Justice, USMS
                    </FP>
                </EXTRACT>
                <HD SOURCE="HD1">Deletions</HD>
                <P>The following products and services are proposed for deletion from the Procurement List:</P>
                <EXTRACT>
                    <HD SOURCE="HD2">Products</HD>
                    <FP SOURCE="FP-2">
                        <E T="03">NSN—Product Name:</E>
                    </FP>
                    <FP SOURCE="FP1-2">6160-01-184-0643—Retainer Battery</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         The Lighthouse for the Blind, Inc. (Seattle Lighthouse), Seattle, WA
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         DLA Aviation, Richmond, VA
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSN—Product Name:</E>
                    </FP>
                    <FP SOURCE="FP1-2">MR 13110—Cake Cutter, Slice N' Easy</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Winston-Salem Industries for the Blind, Inc., Winston-Salem, NC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Military Resale-Defense Commissary Agency
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">NSNs—Product Names:</E>
                    </FP>
                    <FP SOURCE="FP1-2">7340-00-J19-1300—Spoon, Picnic, Plastic</FP>
                    <FP SOURCE="FP1-2">7340-00-J19-1300a—Spoon, Picnic, Plastic</FP>
                    <FP SOURCE="FP1-2">7340-00-J19-2052a—Spoon, Picnic, Plastic</FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         LC Industries, Inc., Durham, NC
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         DLA Troop Support, Philadelphia, PA
                    </FP>
                    <HD SOURCE="HD2">Services</HD>
                    <FP SOURCE="FP-2">
                        <E T="03">Service Type:</E>
                         Mailroom Operation
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory for:</E>
                         14th U.S. Coast Guard District, 300 Ala Moana Boulevard, Honolulu, HI
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Goodwill Contract Services of Hawaii, Inc., Honolulu, HI
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         U.S. Coast Guard, SILC BSS
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Service Type:</E>
                         Food Service Attendants
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory for:</E>
                         New Hampshire Air National Guard, Pease Air National Guard Base, Pease ANGB, NH
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         CW Resources, Inc., New Britain, CT
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Dept of the Army, W7NN USPFO Activity NH ARNG
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Service Type:</E>
                         Janitorial/Custodial
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory for:</E>
                         US Army, IL027 Forest Park AFRC, Forest Park, IL
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Mandatory Source of Supply:</E>
                         Jewish Child and Family Services, Chicago, IL
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Contracting Activity:</E>
                         Dept of the Army, W6QM MICC FT McCoy (RC)
                    </FP>
                </EXTRACT>
                <SIG>
                    <NAME>Michael R. Jurkowski,</NAME>
                    <TITLE>Deputy Director, Business &amp; PL Operations.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09326 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 6353-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY> Department of the Air Force</SUBAGY>
                <DEPDOC>[Docket ID: USAF-2020-HQ-0004]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Department of the Air Force, DoD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>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 June 30, 2020.</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>
                         DoD cannot receive written comments at this time due to the COVID-19 pandemic. Comments should be sent electronically to the docket listed above.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All submissions received must include the agency name, docket 
                        <PRTPAGE P="25407"/>
                        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 contact Ms. Angela James, Office of Information Management, Department of Defense, at 571-372-7574, or 
                        <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>
                     Automated Civil Engineer System (ACES) Electronic Records; OMB Control Number 0701-ACES.
                </P>
                <P>
                    <E T="03">Needs and uses:</E>
                     Information is required for five categories of respondents (ACES Unit Account Manager, ACES User, Civil Engineer (CE) Personnel supporting facility maintenance, warfighters, and Facility Managers). For ACES Unit Account Managers, PII data is required to establish roles for individuals to manage their unit's accounts. For ACES Users, PII data is required to establish accounts. For CE Personnel, PII data is required to identify CE Personnel for assignments to cost centers for the purpose of work order labor reporting and the calculations of shop rates. For warfighters, PII data is critical to ensure all warfighters are prepared for deployment. ACES is the authoritative source for Chemical, Biological, Radiological, Nuclear (CBRN) and Combat Arms training. For Facilities Managers, PII data is required for work orders and after hour emergencies.
                </P>
                <P>
                    <E T="03">Affected public:</E>
                     Individuals or Households.
                </P>
                <P>
                    <E T="03">Annual burden hours:</E>
                </P>
                <P>Electronic Form (eForm): 25.86 hours.</P>
                <P>Face-to-Face Interview: 122.23 hours.</P>
                <P>Total Burden Hours: 148.09 hours.</P>
                <P>
                    <E T="03">Number of respondents:</E>
                </P>
                <P>eForm: 862.</P>
                <P>Face-to-Face Interview: 719.</P>
                <P>Total Number of Respondents: 1,581.</P>
                <P>
                    <E T="03">Responses per respondent:</E>
                </P>
                <P>eForm: 1.</P>
                <P>Face-to-Face Interview: 1.</P>
                <P>
                    <E T="03">Annual responses:</E>
                </P>
                <P>eForm: 862.</P>
                <P>Face-to-Face Interview: 719.</P>
                <P>Total Annual Responses: 1,581.</P>
                <P>
                    <E T="03">Average burden per response:</E>
                </P>
                <P>eForm: 0.03 hours.</P>
                <P>Face-to-Form: 0.17 hours.</P>
                <P>
                    <E T="03">Frequency:</E>
                     On occasion.
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Morgan E. Park,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09269 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 5001-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY> Office of the Secretary</SUBAGY>
                <DEPDOC>[Docket ID: DOD-2020-OS-0046]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Under Secretary of Defense for Personnel &amp; Readiness, DoD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>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 Under Secretary of Defense for Personnel &amp; Readiness 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 June 30, 2020.</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:</E>
                          
                        <E T="03">http://www.regulations.gov.</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        <E T="03">Mail:</E>
                         DoD cannot receive written comments at this time due to the COVID-19 pandemic. Comments should be sent electronically to the docket listed above.
                    </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 contact Ms. Angela James, Office of Information Management, Department of Defense, at 571-372-7574, or 
                        <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 SOURCE="NPAR">
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Department of Defense Child Development Program Request for Care Record (DD FORM 2606) &amp; Application for Department of Defense Child Care Fees (DD FORM 2652); OMB Control Number 0704-0515.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                     The DoD requires the information in the proposed collection for program planning and management purposes. This rule includes two collection instruments to include DD Form 2606, “Department of Defense Child Development Program Request for Care Record” and DD Form 2652 “Application for Department of Defense Child Care Fees”. DoD is seeking clearance of DD Form 2606 and DD Form 2652 with this submission.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or Households.
                </P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                </P>
                <P>DD 2606: 1,042 hours.</P>
                <P>DD 2652: 4,167 hours.</P>
                <P>
                    <E T="03">Number of Respondents:</E>
                </P>
                <P>DD 2606: 12,500.</P>
                <P>DD 2652: 50,000.</P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                </P>
                <P>DD 2606: 1</P>
                <P>DD 2652: 1</P>
                <P>
                    <E T="03">Annual Responses:</E>
                </P>
                <P>DD 2606: 12,500.</P>
                <P>DD 2652: 50,000.</P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                </P>
                <P>DD 2606: 5 minutes.</P>
                <P>DD 2652: 5 minutes.</P>
                <P>
                    <E T="03">Frequency:</E>
                     Biennially.
                </P>
                <P>Respondents for the information collection through DD Form 2606 and DD Form 2652 are patrons requesting child care and patrons enrolled in CDPs. The DoD CDP requires the information in the proposed collections for program planning, management purposes and the determination of child care fees.</P>
                <P>The DD Form 2606 is used to collect information for the type of care needed and sponsor status which determines eligibility and priority for child development program services. It is also used to assist management in the planning of present and future program requirements. The information from the DD Form 2652 is used to determine total family income to determine child care fees for families enrolled in the DoD CDP.</P>
                <SIG>
                    <PRTPAGE P="25408"/>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Morgan E. Park,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense. </TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09267 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 5001-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <SUBJECT>Board of Visitors, National Defense University; Notice of Federal Advisory Committee Meeting</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Chairman Joint Chiefs of Staff, 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 Board of Visitors, National Defense University will take place.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Monday, May 11, 2020 from 10:00 a.m. to 1:30 p.m. and Tuesday, May 12, 2020 from 10:00 a.m. to 11:45 a.m.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The meeting will be held online. Please see the Meeting Accessibility paragraph in the 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         section for more information.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Dr. Brian R. Shaw, (202) 685-2358 (Voice), (202) 685-3920 (Facsimile), 
                        <E T="03">brian.r.shaw8.civ@mail.mil; brian.r.shaw.civ@ndu.edu; joycelyn.a.stevens.civ@mail.mil; stevensj7@ndu.edu</E>
                         (Email). Mailing address is National Defense University, Fort McNair, Washington, DC 20319-5066. Website: 
                        <E T="03">http://www.ndu.edu/About/Board-of-Visitors/.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Due to circumstances beyond the control of the Department of Defense and the Designated Federal Officer, the Board of Visitors, National Defense University, was unable to provide public notification required by 41 CFR 102-3.150(a) concerning the meeting for May 11, 2020 through May 12, 2020. Accordingly, the Advisory Committee Management Officer for the Department of Defense, pursuant to 41 CFR 102-3.150(b), waives the 15-calendar day notification requirement.</P>
                <P>This meeting is being held under the provisions of the Federal Advisory Committee Act (FACA) of 1972 (5 U.S.C., Appendix, as amended), the Government in the Sunshine Act of 1976 (5 U.S.C. 552b, as amended), and 41 CFR 102-3.140 and 102-3.150. Pursuant to 5 U.S.C. 552b and 41 CFR 102-3.140 through 102-3.165, this meeting is open to the public.</P>
                <P>
                    <E T="03">Purpose of the Meeting:</E>
                     The purpose of the meeting will include discussion on accreditation compliance, organizational management, strategic planning, resource management, and other matters of interest to the National Defense University.
                </P>
                <P>
                    <E T="03">Agenda:</E>
                     Monday, May 11, 2020 from 10:00 a.m. to 1:30 p.m. (Eastern Time): Call to Order and Administrative Notes; State of the University Address; Transforming NDU; Curriculum Redesign; and Supporting the Academic Mission. Tuesday, May 12, 2020 from 10:00 a.m. to 11:45 a.m. (Eastern Time): NDU Succession Plan; Public Comment; Board of Visitors Member Deliberation and Feedback and Wrap-up and Closing Remarks.
                </P>
                <P>
                    <E T="03">Meeting Accessibility:</E>
                     The link to the virtual meeting will be posted on the NDU Board of Visitors website at 
                    <E T="03">https://www.ndu.edu/About/Board-of-Visitors/BOV-May-11-12-2020/</E>
                     by May 4, one week prior to the meeting. The most up to-date changes to the meeting agenda as well as additional supporting documents including instructions on how to log into the meeting will also be posted there.
                </P>
                <P>
                    <E T="03">Written Statements:</E>
                     Pursuant to 41 CFR 102-3.105(j) and 102-3.140, and section 10(a)(3) of the Federal Advisory Committee Act of 1972, written statements to the committee may be submitted to the committee at any time or in response to a stated planned meeting agenda by FAX or email to Ms. Joycelyn Stevens at (202) 685-0079, Fax (202) 685-3920 or 
                    <E T="03">StevensJ7@ndu.edu.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Aaron T. Siegel,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09343 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 5001-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <DEPDOC>[Docket ID: DOD-2011-OS-0127]</DEPDOC>
                <SUBJECT>Submission for OMB Review; Comment Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Under Secretary of Defense for Personnel and Readiness, 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 Office of Military Community and Family Policy, Department of Defense has submitted to 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 June 1, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Written comments and recommendations for the proposed information collection should be sent within 30 days of publication of this notice to 
                        <E T="03">www.reginfo.gov/public/do/PRAMain.</E>
                         Find this particular information collection by selecting “Currently under 30-day Review—Open for Public Comments” or by using the search function.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Angela James, 571-372-7574, or 
                        <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    <E T="03">Title; Associated Form; and OMB Number:</E>
                     Exceptional Family Member Program; DD 2792 “Family Member Medical Summary,” DD 2792-1 “Special Education/Early Intervention Summary,” OMB Control Number 0704-0411.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     Renewal.
                </P>
                <P>
                    <E T="03">Number of Respondents:</E>
                </P>
                <P>DD 2792:</P>
                <P>Family Members: 55,828.</P>
                <P>Medical Providers: 11,166.</P>
                <P>DD 2792-1:</P>
                <P>Family Members: 16,906.</P>
                <P>Special Education Teachers: 14,708.</P>
                <P>
                    <E T="03">Total Respondents:</E>
                     98,608.
                </P>
                <P>
                    <E T="03">Responses per Respondent:</E>
                </P>
                <P>DD 2792:</P>
                <P>Family Members: 1.</P>
                <P>Medical Providers: 1.</P>
                <P>DD 2792-1:</P>
                <P>Family Members: 1.</P>
                <P>Special Education Teachers: 1.</P>
                <P>
                    <E T="03">Annual Responses:</E>
                </P>
                <P>DD 2792:</P>
                <P>Family Members: 55,828.</P>
                <P>Medical Providers: 11,166.</P>
                <P>DD 2792-1:</P>
                <P>Family Members: 16,906.</P>
                <P>Special Education Teachers: 14,708.</P>
                <P>
                    <E T="03">Total Annual Responses:</E>
                     98,608.
                </P>
                <P>
                    <E T="03">Average Burden per Response:</E>
                </P>
                <P>DD 2792:</P>
                <P>Family Member: 5 minutes.</P>
                <P>Medical Provider: 25 minutes.</P>
                <P>DD 2792-1:</P>
                <P>Family Member: 5 minutes.</P>
                <P>Special Education Teacher: 20 minutes.</P>
                <P>
                    <E T="03">Annual Burden Hours:</E>
                </P>
                <P>DD 2792: 9,156 hours.</P>
                <P>DD 2792-1: 6,206 hours.</P>
                <P>
                    <E T="03">Total Respondent Burden Hours:</E>
                     15,362.
                </P>
                <P>
                    <E T="03">Needs and Uses:</E>
                </P>
                <P>
                    The Individuals with Disabilities Education Act, (Sections 1400 
                    <E T="03">et seq.</E>
                     of title 20, United States Code) and the Defense Dependents Education Act, 
                    <PRTPAGE P="25409"/>
                    (Sections 921 
                    <E T="03">et seq.</E>
                     of title 20, United States Code) require the Department of Defense to provide early intervention services to developmentally delayed infants and toddlers (birth through 2) and special education and medically related services to children with disabilities from 3 through 21 years of age who are eligible to attend a DoD school. In order to ensure the availability of necessary medical and educational services for family members, the Department must identify those who have special health or educational needs. Medical and educational needs are also considered when approving family travel to an overseas or remote location where DoD must provide the services.
                </P>
                <P>The Health Insurance Portability and Accountability Act (HIPAA) of 1996 (Pub. L. 94-191) requires specific language to advise the individuals that personally identifiable health information shall not be used or disclosed except for specifically permitted purposes, unless informed consent is provided by the individual. The Department is standardizing the information collection to ensure that appropriate information is collected and that it meets the data collection HIPAA requirements.</P>
                <P>The National Defense Authorization Act (NDAA) for Fiscal Year 2010 (Pub. L. 111-84) requires procedures to identify members of the Uniformed Services who are members of military families with special needs, mechanisms to ensure their timely and accurate evaluations and enrollment.</P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households, businesses or on for-profit.
                </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:</E>
                      
                    <E T="03">http://www.regulations.gov.</E>
                     Follow the instructions for submitting comments.
                </P>
                <P>
                    <E T="03">Instructions:</E>
                     All submissions received must include the agency name, Docket ID number, and title for this 
                    <E T="04">Federal Register</E>
                     document. The general policy for comments and other submissions from members of the public is to make these submissions available for public viewing on the internet at 
                    <E T="03">http://www.regulations.gov</E>
                     as they are received without change, including any personal identifiers or contact information.
                </P>
                <P>
                    <E T="03">DOD Clearance Officer:</E>
                     Ms. Angela James.
                </P>
                <P>
                    Requests for copies of the information collection proposal should be sent to Ms. James at 
                    <E T="03">whs.mc-alex.esd.mbx.dd-dod-information-collections@mail.mil.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Morgan E. Park,</NAME>
                    <TITLE>Alternate OSD Federal Register Liaison Officer, Department of Defense.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09268 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 5001-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF DEFENSE</AGENCY>
                <SUBAGY>Department of the Army, Corps of Engineers</SUBAGY>
                <SUBJECT>Proposals by Non-Federal Interests, for Feasibility Studies, Proposed Modifications to Authorized Water Resources Development Projects and Feasibility Studies, and Proposed Modifications for an Environmental Infrastructure Program for Inclusion in the Annual Report to Congress on Future Water Resources Development</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>U.S. Army Corps of Engineers, DoD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Section 7001 of Water Resources Reform and Development Act (WRRDA) 2014, as amended, requires that the Secretary of the Army annually submit to the Congress a report (Annual Report) that identifies feasibility reports, proposed feasibility studies submitted by non-Federal interests, proposed modifications to authorized water resources development projects or feasibility studies, and proposed modifications to environmental infrastructure program authorities that meet certain criteria. The Annual Report is to be based, in part, upon requests for proposals submitted by non-Federal interests.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Proposals must be submitted online by August 31, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Submit proposals online at: 
                        <E T="03">https://www.usace.army.mil/Missions/Civil-Works/Project-Planning/WRRDA-7001-Proposals/.</E>
                         If a different method of submission is required, use the further information below to arrange an alternative submission process.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Send an email to the help desk at 
                        <E T="03">WRRDA7001Proposal@usace.army.mil</E>
                         or call Stuart McLean, Planning and Policy Division, Headquarters, USACE, Washington, DC at 202-761-4931.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Section 7001 of WRRDA 2014 (33 U.S.C. 2282d), as amended, requires the publication of a notice in the 
                    <E T="04">Federal Register</E>
                     annually to request proposals by non-Federal interests for feasibility studies, modifications to authorized USACE water resources development projects or feasibility studies, and modifications to environmental infrastructure program authorities. Project feasibility reports that have signed Chief's Reports, but have not been authorized will be included in the Annual Report table by the Secretary of the Army and these proposals do not need to be submitted in response to this notice.
                </P>
                <P>Proposals by non-Federal interests must be entered online and require the following information:</P>
                <P>1. The name of the non-Federal interest, or all non-Federal interests in the case of a modification to an environmental infrastructure program authority, including any non-Federal interest that has contributed to or is expected to contribute toward the non-Federal share of the proposed feasibility study, project modification or environmental infrastructure program.</P>
                <P>2. State if this proposal is for authorization of a feasibility study, a modification to an authorized USACE water resources development project, a modification to an authorized USACE water resources feasibility study, or a modification to a USACE environmental infrastructure program authority. If a modification of an existing authority, specify the authorized water resources development project, study, or environmental infrastructure program authority that is proposed for modification.</P>
                <P>3. State the specific project purpose(s) of the proposed study or modification.</P>
                <P>4. Provide an estimate, to the extent practicable, of the total cost, and the Federal and non-Federal share of those costs, of the proposed study and, separately, an estimate of the cost of construction or modification.</P>
                <P>5. Describe, to the extent applicable and practicable, an estimate of the anticipated monetary and non-monetary benefits of the proposal with regard to benefits to the protection of human life and property; improvement to transportation; the national economy; the environment; or the national security interests of the United States.</P>
                <P>6. Proposals for modifications to environmental infrastructure program authorities must also include a description of assistance provided to date and the total Federal cost of assistance provided to date.</P>
                <P>7. State if the non-Federal interest has the financial ability to provide the required cost share, reference Engineer Regulation 1105- 2-100, Planning Guidance Notebook.</P>
                <P>
                    8. Describe if local support exists for the proposal.
                    <PRTPAGE P="25410"/>
                </P>
                <P>9. Upload a letter or statement of support for the proposal from each associated non- Federal interest.</P>
                <P>All provided information may be included in the Annual Report to Congress on Future Water Resources Development. Therefore, information that is Confidential Business Information, information that should not be disclosed because of statutory restrictions, or other information that a non-Federal interest would not want to appear in the Annual Report should not be included.</P>
                <P>
                    <E T="03">Process:</E>
                     Proposals received within the time frame set forth in this notice will be reviewed by the Army and will be presented in one of two tables. The first table will be in the Annual Report itself, and the second table will be in an appendix. To be included in the Annual Report table, the proposals must meet the following five criteria:
                </P>
                <P>1. Are related to the missions and authorities of the USACE; involve a proposed or existing USACE water resources project or effort whose primary purpose is flood and storm damage reduction, commercial navigation, or aquatic ecosystem restoration. Following long-standing USACE practice, related proposals such as for recreation, hydropower, or water supply, are eligible for inclusion if undertaken in conjunction with such a project or effort.</P>
                <P>2. Require specific congressional authorization, including by an Act of Congress:</P>
                <P>
                    a. 
                    <E T="03">Requires Construction Authorization:</E>
                </P>
                <P>• Feasibility reports that have successfully passed the Tentatively Selected Plan Milestone in the USACE plan formulation process;</P>
                <P>• Non-Federal feasibility reports submitted to the Secretary of the Army under Section 203 of WRDA 1986, as amended, under Administration review;</P>
                <P>• Proposed modifications to authorized water resources development projects requested by non-Federal interests.</P>
                <P>• Note: reports that have signed Chief's Reports, but have not been authorized, will be included in the Annual Report table and these proposals do not need to be submitted in response to this notice.</P>
                <P>
                    b. 
                    <E T="03">Seeking Study Authorization:</E>
                </P>
                <P>• New feasibility studies proposed by non-Federal interests through the Section 7001 of WRRDA 2014 process will be evaluated by the USACE to determine whether or not there is existing study authority, and</P>
                <P>• Proposed modifications to studies requested by non Federal interests through the Section 7001 of WRRDA 2014 process will be evaluated by the USACE to determine whether or not there is existing study authority.</P>
                <P>
                    c. 
                    <E T="03">The following cases are NOT ELIGIBLE to be included in the Annual Report and will be included in the appendix for transparency:</E>
                </P>
                <P>• Proposals for modifications to non-Federal projects under program authorities where USACE has provided previous technical assistance. Authorization to provide technical assistance does not provide authorization of a water resources development project.</P>
                <P>• Proposals for construction of a new water resources development project that is not the subject of a currently authorized USACE project or a complete or ongoing feasibility study.</P>
                <P>• Proposals that do not include a request for a potential future water resources development project through completed feasibility reports, proposed feasibility studies, and proposed modifications to authorized projects or studies.</P>
                <P>3. Have not been congressionally authorized;</P>
                <P>4. Have not been included in the Annual Report table of any previous Annual Report to Congress on Future Water Resources Development; and</P>
                <P>• If the proposal was included in the Annual Report table in a previous Report to Congress on Future Water Resources Development, then the proposal is not eligible to be included in the Annual Report table. If a proposal was previously included in an appendix it may be re-submitted.</P>
                <P>5. If authorized, could be carried out by the USACE.</P>
                <P>• Whether following the USACE Chief's Report process or Section 7001 of WRRDA 2014, a proposal for a project or a project modification would need a current decision document to provide updated information on the scope of the potential project and demonstrate a clear Federal interest. This determination would include an assessment of whether the proposal is:</P>
                <P>—Technically sound, economically viable and environmentally acceptable.</P>
                <P>—Compliant with environmental and other laws including but not limited to National Environmental Policy Act, Endangered Species Act, Coastal Zone Management Act, and the National Historic Preservation Act.</P>
                <P>—Compliant with statutes and regulations related to water resources development including various water resources provisions related to the authorized cost of projects, level of detail, separable elements, fish and wildlife mitigation, project justification, matters to be addressed in planning, and the 1958 Water Supply Act.</P>
                <P>Environmental infrastructure proposals are an exception to the criteria. To be included in the table within the Annual Report the proposal must be for a modification to a project that was authorized prior to the date of enactment of the Water Resources Development Act of 2016 (December 16, 2016) pursuant to Section 219 of WRDA 1992, as amended or must identify a programmatic modification to an environmental infrastructure assistance program and it has not been included in any previous annual report.</P>
                <P>Feasibility study proposals submitted by non-Federal interests are for study authorization only. If Congressional authorization of a feasibility study results from inclusion in the Annual Report, it is anticipated that such authorization would be for the study, not for construction. Once a decision document is completed in accordance with Executive Branch policies and procedures, the Secretary will determine whether to recommend the project for authorization.</P>
                <P>All USACE water resources development projects must meet certain requirements before proceeding to construction. These requirements include: (1) That the project is authorized for construction by Congress; (2) that the Secretary, or other appropriate official, has approved a current decision document; and, (3) that the funds for project construction have been appropriated and are available.</P>
                <P>Section 902 of WRDA 1986, as amended, (33 U.S.C. 2280) establishes a maximum authorized cost for projects (902 limit). A Post Authorization Change Report (PACR) is required to be completed to support potential modifications, updates to project costs, and an increase to the 902 limit. Authority to undertake a 902 study is inherent in the project authority, so no additional authority is required to proceed with the study. Since these PACRs support project modifications, they may be considered for inclusion in the Annual Report if a report's recommendation requires Congressional authorization.</P>
                <P>
                    The Secretary shall include in the Annual Report to Congress on Future Water Resources Development a certification stating that each feasibility report, proposed feasibility study, and proposed modification to an authorized water resources development project, feasibility study, or proposed modifications to an environmental infrastructure program authority included in the Annual Report meets 
                    <PRTPAGE P="25411"/>
                    the criteria established in Section 7001 of WRRDA 2014, as amended.
                </P>
                <P>Please contact the appropriate district office or use the contact information above for assistance in researching and identifying existing authorizations and existing USACE decision documents. Those proposals that do not meet the criteria will be included in an appendix table included in the Annual Report to Congress on Future Water Resources Development. Proposals in the appendix table will include a description of why those proposals did not meet the criteria.</P>
                <SIG>
                    <NAME>R.D. James,</NAME>
                    <TITLE>Assistant Secretary of the Army (Civil Works).</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09338 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 3720-58-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF EDUCATION</AGENCY>
                <DEPDOC>[Docket No.: ED-2020-SCC-0036]</DEPDOC>
                <SUBJECT>Agency Information Collection Activities; Submission to the Office of Management and Budget for Review and Approval; Comment Request; Grant Reallotment</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Special Education and Rehabilitative Services (OSERS), Department of Education (ED).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In accordance with the Paperwork Reduction Act of 1995, ED is proposing an extension of an existing information collection.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Interested persons are invited to submit comments on or before June 1, 2020.</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 “Department of Education” 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 collection activities, please contact David Steele, 202-245-6520.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Department of Education (ED), in accordance with the Paperwork Reduction Act of 1995 (PRA) (44 U.S.C. 3506(c)(2)(A)), provides the general public and Federal agencies with an opportunity to comment on proposed, revised, and continuing collections of information. This helps the Department assess the impact of its information collection requirements and minimize the public's reporting burden. It also helps the public understand the Department's information collection requirements and provide the requested data in the desired format. ED is soliciting comments on the proposed information collection request (ICR) that is described below. The Department of Education is especially interested in public comment addressing the following issues: (1) Is this collection necessary to the proper functions of the Department; (2) will this information be processed and used in a timely manner; (3) is the estimate of burden accurate; (4) how might the Department enhance the quality, utility, and clarity of the information to be collected; and (5) how might the Department minimize the burden of this collection on the respondents, including through the use of information technology. Please note that written comments received in response to this notice will be considered public records.</P>
                <P>
                    <E T="03">Title of Collection:</E>
                     Grant Reallotment.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1820-0692.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     An extension of an existing information collection.
                </P>
                <P>
                    <E T="03">Respondents/Affected Public:</E>
                     State, Local, and Tribal Governments.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Responses:</E>
                     323.
                </P>
                <P>
                    <E T="03">Total Estimated Number of Annual Burden Hours:</E>
                     11.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     The Rehabilitation Act of 1973, as amended (the Act), authorizes the Rehabilitation Services Administration (RSA) Commissioner to reallot to other grant recipients that portion of a recipient's annual grant that cannot be used. To maximize the use of appropriated funds under the formula grant programs, RSA has established a reallotment process for the State Vocational Rehabilitation Services (VR); State Supported Employment Services (Supported Employment); Independent Living Services for Older Individuals Who Are Blind (OIB); Client Assistance Program (CAP); and Protection and Advocacy of Individual Rights (PAIR) programs. The authority for RSA to reallot formula grant funds is found at sections 110(b)(2) (VR), 603(b) (Supported Employment), 752(i)(4) (OIB), 112(e)(2) (CAP), and 509(e) (PAIR) of the Act.
                </P>
                <P>This request is to extend the use of the form for an additional 3 years. The information will be used by the RSA State Monitoring and Program Improvement Division (SMPID) to reallot formula grant funds for the awards mentioned above. This permits RSA to maximize the use of Federal funds to meet the needs of individuals with disabilities.</P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Kate Mullan,</NAME>
                    <TITLE>PRA Coordinator,Strategic Collections and Clearance Governance and Strategy Division, Office of Chief Data Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09303 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4000-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF EDUCATION</AGENCY>
                <SUBJECT>Notice Inviting Applications (NIA) for the FY 2020; Education Stabilization Fund-Rethink K-12 Education Models (ESF-REM) Discretionary Grant Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Elementary and Secondary Education, Department of Education.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Education (Department) is issuing an NIA for eligible applicants for the FY 2020 ESF-REM Grants program under section 18001(a)(3) of Division B of the Coronavirus Aid, Relief, and Economic Security Act (CARES Act), Catalog of Federal Domestic Assistance (CFDA) number 84.425B. This notice relates to the approved information collection under OMB control number 1894-0006.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">Applications Available:</E>
                         April 30, 2020.
                    </P>
                    <P>
                        <E T="03">Deadline for Notice of Intent to Apply:</E>
                         May 19, 2020.
                    </P>
                    <P>
                        <E T="03">Deadline for Transmittal of Applications:</E>
                         June 29, 2020.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        For the addresses for obtaining and submitting an application, please refer to our Common Instructions for Applicants to Department of Education Discretionary Grant Programs, published in the 
                        <E T="04">Federal Register</E>
                         on February 13, 2019 (84 FR 3768) and available at 
                        <E T="03">www.govinfo.gov/content/pkg/FR-2019-02-13/pdf/2019-02206.pdf.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jennifer Todd, U.S. Department of Education, 400 Maryland Avenue SW, room 3E303, Washington, DC 20202. Telephone: (202) 453-6984. Email: 
                        <E T="03">ESF-REM@ed.gov.</E>
                         Website: 
                        <E T="03">https://oese.ed.gov/offices/education-stabilization-fund/states-highest-coronavirus-burden/.</E>
                    </P>
                    <P>If you use a telecommunications device for the deaf (TDD) or a text telephone (TTY), call the Federal Relay Service (FRS), toll free, at 1-800-877-8339.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">
                    SUPPLEMENTARY INFORMATION:
                    <PRTPAGE P="25412"/>
                </HD>
                <HD SOURCE="HD1">Full Text of Announcement</HD>
                <HD SOURCE="HD1">I. Funding Opportunity Description</HD>
                <P>
                    <E T="03">Purpose of Program:</E>
                     The purpose of the ESF-REM Grants program is to provide support through discretionary grants to State educational agencies (SEAs) (as defined in this notice) in States with the highest coronavirus burden (as defined in this notice) to address specific educational needs of students, their parents, and teachers in public and non-public elementary and secondary schools in accordance with section 18001(a)(3) of the CARES Act.
                </P>
                <P>
                    <E T="03">Background:</E>
                     The Education Stabilization Fund (ESF) is a new appropriation of approximately $30.75 billion that creates funding streams for several distinct education programs that address the impact of the Novel Coronavirus Disease 2019 (COVID-19) on educational services across the Nation. Under all of these Department programs including the ESF-REM grants, the Department will make awards to States for a variety of activities to help 
                    <E T="03">prevent, prepare for, and respond to</E>
                     the devastating effects of COVID-19. The coronavirus pandemic has resulted in not only a public health crisis, but school closures across the country impacting over 40 million students. For that reason, responding effectively to coronavirus must include addressing remote learning (as defined in this notice) needs of students throughout the United States. In addition to this NIA, the Department is also publishing a notice elsewhere in the 
                    <E T="04">Federal Register</E>
                     for Education Stabilization Fund—Reimagining Workforce Preparation (ESF-RWP) Discretionary Grant program, which will help States and communities respond to coronavirus by creating new opportunities for unemployed individuals to regain their economic security through small business creation and career pathways that lead to a recognized postsecondary credential.
                </P>
                <P>The ESF-REM Grants competition includes three absolute priorities of which the applicant addresses one priority. An SEA may only submit one application to the ESF-REM Grants competition.</P>
                <P>Under Absolute Priority 1, applicants must provide funding through microgrants (as defined in this notice) to allow parents (as defined in this notice) to meet the educational needs of their school-age children, through increased access to high-quality remote learning to support their educational needs, as these terms are defined in this notice. This priority is intended to address the individual needs of students and promote continuity of learning. In their applications, States would identify proposed uses of funds including the types of education and related services, expenses, and providers that would be available through microgrants.</P>
                <P>Absolute Priority 2 encourages the development and/or expansion of a high-quality course-access program (as these terms are defined in this notice) or statewide virtual school (as defined in this notice). Course-access programs enable students to select from different courses offered by any public school in the State or by third-party providers, regardless of a student's assigned school. Research has shown that expanding online access to advanced coursework not otherwise available is an effective way to broaden access and may increase the likelihood of these students taking other advanced courses. (Heppen, J.B., Walters, K., Clements, M., Faria, A., Tobey, C., Sorensen, N., &amp; Culp, K. (2012)) Virtual schools can offer flexibility to students who may have difficulty accessing or attending brick-and-mortar schools, especially given school closures. One study of a statewide virtual school in the southern U.S. suggested a virtual school may produce similar outcomes at a lower overall cost than traditional schooling and that students may in fact be more productive in a virtual school environment. (Chingos, M. and Schwert, G. (2014))</P>
                <P>Absolute Priority 3 allows applicants to propose their own educational strategies that demonstrate a rationale (as defined in this notice) to address the specific educational needs of their States, as related to remote learning.</P>
                <P>
                    <E T="03">Priorities:</E>
                     This notice contains three absolute priorities. We are establishing these priorities for the FY 2020 grant competition, and any subsequent year in which we make awards from the list of unfunded applications from this competition, in accordance with section 437(d)(1) of the General Education Provisions Act (GEPA), 20 U.S.C. 1232(d)(1).
                </P>
                <P>
                    <E T="03">Absolute Priorities:</E>
                     These priorities are absolute priorities. Under 34 CFR 75.105(c)(3) we consider only applications that meet one of these absolute priorities. The Secretary intends to award grants under each of the absolute priorities for which applications of sufficient quality are submitted. Because applications will be placed in rank order separately by absolute priority, applicants must clearly identify the specific absolute priority that the proposed project addresses. Each State may submit only one application under this competition that addresses one absolute priority. In selecting grantees across Absolute Priorities 1-3, the Department may fund applications from one absolute priority with a higher or lower score than an application from another absolute priority and may also reallocate among these priorities based on the quality of applications.
                </P>
                <P>These priorities are:</P>
                <P>
                    <E T="03">Absolute Priority 1—Continued Learning Parent Microgrants.</E>
                </P>
                <P>Applications that propose microgrants to allow a parent to access high-quality remote learning options from a list of education and related services, expenses, and providers, which may include any needed connectivity and devices, that meets the student's educational needs. A State must—</P>
                <P>(a) Provide the parents and students with a list of service providers from which the parents and students may select.</P>
                <P>(b) Include more than one education service for remote learning that parents and students may choose, which may include—</P>
                <P>(1) Tuition and fees for a public or private course or program, especially online;</P>
                <P>(2) Concurrent and dual enrollment at a postsecondary institution particularly for career and technical education experiences;</P>
                <P>(3) Special education and related services including therapies;</P>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>Any services provided do not alter a local educational agency's (LEA's) obligation to provide supports and services to a child with a disability under Part B of the Individuals with Disabilities Act (IDEA) and under Section 504 of the Rehabilitation Act of 1973.</P>
                </NOTE>
                <P>(4) Contracted educational services provided by a public or nonpublic school;</P>
                <P>(5) Tutoring;</P>
                <P>(6) Summer or afterschool education programs;</P>
                <P>(7) Testing preparation and examination fees, including Advanced Placement examinations, industry certification exams, state licensure exams, and any examinations related to college or university admission;</P>
                <P>(8) Academic, college, and career counseling services;</P>
                <P>(9) Application fees, including for public and non-public school students;</P>
                <P>(10) Textbooks, curriculum, or other instructional materials; and</P>
                <P>(11) Other education-related services and materials that are reasonable and necessary, which may include, but cannot be the only microgrant account use—</P>
                <P>(i) Computer hardware, software, or other technological devices including adaptive devices;</P>
                <P>
                    (ii) internet access or hotspots;
                    <PRTPAGE P="25413"/>
                </P>
                <P>(iii) Textbooks, curriculum, or other instructional materials; and</P>
                <P>(c) Provide an online and other method to enable parents and students to select services and ensure that the parent's microgrant account is established within the project period of the grant and the parent is aware of how much funds are available. Such a method must—</P>
                <P>(1) Reach out to the most disadvantaged students and parents;</P>
                <P>(2) Ensure that funds will be transferred directly from the State to the selected service provider;</P>
                <P>(3) Include multiple service providers including non-government service providers; and</P>
                <P>(4) Provide tools to help parents choose the most appropriate and effective services for their children.</P>
                <P>(d) Include a parent involvement and feedback process that—</P>
                <P>(1) Describes a way for parents to request services or providers that are not currently offered and provide input on services provided in the creation of the list and through the project, and describes how the grantee will provide parents with written responses to requests within 30 days; and</P>
                <P>(2) Support the grantee in outreach to parents and to assist parents, which may include a parent liaison, and the grantee with the process by which a parent can request services or providers, including services or providers not already specified by the State;</P>
                <P>
                    (3) Include a fair and documented process to choose students to be served, such as a lottery or other transparent criteria (
                    <E T="03">e.g.,</E>
                     based on particular types of need such as disability status or family income), in the event that the number of requests from parents of public and non-public school students for services under the project exceeds the available capacity, with regard to the number or intensity of services offered; and
                </P>
                <P>(4) Ensure that at least 80 percent of grant funds are used for services directly utilized by public and non-public school students under the microgrants, and no more than five percent of grant funds are used for administrative costs (as defined in this notice).</P>
                <P>
                    <E T="03">Absolute Priority 2—Statewide Virtual Learning and Course Access Programs.</E>
                </P>
                <P>Applications that propose projects to—</P>
                <P>(a) Develop a statewide virtual learning or course access program, such as by—</P>
                <P>(1) Designing and assembling high-quality educational content; and</P>
                <P>(2) Creating and launching the platform of a statewide virtual learning or course-access program; or</P>
                <P>(b) Expand an existing statewide virtual learning or high-quality course access program, such as by—</P>
                <P>(1) Serving more students;</P>
                <P>(2) Adding new courses based on student and parent interest or alignment with workforce development needs; and</P>
                <P>
                    (3) Implementing new instructional strategies (
                    <E T="03">e.g.</E>
                     competency-based instruction).
                </P>
                <P>In addition to addressing (a) or (b), an application must propose to—</P>
                <P>(c) Implement a statewide course-access program or virtual school;</P>
                <P>(d) Widely disseminate information on the availability of course-access programs or virtual school programs; and</P>
                <P>(e) Include a parent involvement and feedback process that—</P>
                <P>(1) Describes a way for parents to request courses or programming that are not currently offered and provide input on services provided through the project, and how the State will carefully consider such comments;</P>
                <P>
                    (2) May include a parent liaison to support the grantee in outreach to parents and to assist parents and the grantee with the process by which a parent can request courses and programming; and (3) Include a fair and documented process to choose students to be served, such as a lottery or other transparent criteria (
                    <E T="03">e.g.,</E>
                     based on particular types of need such as disability status or family income), in the event that the number of requests from parents of public and non-public school students for services under the project exceeds the available capacity, with regard to the number or intensity of services offered.
                </P>
                <P>To meet this absolute priority, the applicant must describe how its course-access program as a whole would make a broad range of courses widely available and free for all students in the State, though a particular course need not be available to every student in the State, or how a statewide virtual school would be established or significantly expanded providing both a full-time education program or supplemental education available to all students in the State. Applicants should describe how they will determine which courses or programming to develop or expand, based on students' needs and how it will ensure the courses it offers are high-quality.</P>
                <P>
                    Applicants are encouraged to design programs using common schema and linked data standards compatible with interoperable learning records, as defined in the American Workforce Policy Advisory Board, “White Paper on Interoperable Learning Records,” September 2019, available at: 
                    <E T="03">www.commerce.gov/sites/default/files/2019-09/ILR_White_Paper_FINAL_EBOOK.pdf.</E>
                </P>
                <P>
                    <E T="03">Absolute Priority 3—Field-Initiated Projects for Educational Models for Remote Learning to Improve Student Outcomes.</E>
                </P>
                <P>Applications that propose projects that demonstrate a rationale and that are designed to create, develop, implement, replicate, or take to scale field-initiated educational models for remote learning. Projects should address specific needs pertaining to accessing high-quality remote learning opportunities.</P>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>An applicant addressing any one of absolute priorities must ensure equitable access (as defined in this notice) for non-public school students.</P>
                </NOTE>
                <P>
                    <E T="03">Definitions:</E>
                     The definitions of “local educational agency,” “parent,” and “State educational agency” are from section 8101 of the ESEA (20 U.S.C. 7801). The definitions for “ambitious,” “baseline,” “demonstrates a rationale,” “logic model,” “performance measure,” “performance target,” “project component,” and “relevant outcome” are from 34 CFR 77.1. We are establishing the definitions for “administrative costs,” “coronavirus burden,” “course-access program,” “equitable access,” “high-quality,” “microgrant,” “remote learning,” and “statewide virtual school” for the FY 2020 grant competition and any subsequent year in which we make awards from the list of unfunded applications from this competition in accordance with section 437(d)(1) of GEPA, 20 U.S.C. 1232(d)(1).
                </P>
                <P>
                    <E T="03">Administrative costs</E>
                     mean expenses that include costs (direct and indirect) involved in the proper and efficient performance and administration of this Federal grant.
                </P>
                <P>
                    <E T="03">Ambitious</E>
                     means promoting continued, meaningful improvement for program participants or for other individuals or entities affected by the grant or representing a significant advancement in the field of education research, practices, or methodologies. When used to describe a performance target (as defined in this notice), whether a performance target is ambitious depends upon the context of the relevant performance measure (as defined in this notice) and the baseline (as defined in this notice) for that measure.
                </P>
                <P>
                    <E T="03">Baseline</E>
                     means the starting point from which performance is measured and targets are set.
                </P>
                <P>
                    <E T="03">Coronavirus burden</E>
                     means burden on a State from coronavirus based on the measures in the application package and any measures identified by the 
                    <PRTPAGE P="25414"/>
                    applicant in response to Application Requirement 3.
                </P>
                <P>
                    <E T="03">Course-access program</E>
                     means a program that—
                </P>
                <P>(1) Provides students the option to enroll in one or more courses that are not currently offered virtually or otherwise available in the student's school;</P>
                <P>(2) Includes courses offered by multiple providers, from which students, or parents on behalf of students, may choose;</P>
                <P>(3) Makes available courses for remote learning;</P>
                <P>(4) Ensures that coursework materials and the formats and technologies by which they are made available are accessible to students with disabilities; and</P>
                <P>(5) Is available to all students in the State, including non-public school students on an equitable basis.</P>
                <P>
                    <E T="03">Demonstrates a rationale</E>
                     means a key project component included in the project's logic model (as defined in this notice) is informed by research or evaluation findings that suggest the project component is likely to improve relevant outcomes.
                </P>
                <P>
                    <E T="03">Equitable access</E>
                     means a grantee must provide students enrolled in non-public schools with the same opportunity to access program benefits as students attending public schools, which may include proportional provision of services to both public and non-public school students.
                </P>
                <P>
                    <E T="03">High-quality</E>
                     means the project described in the grant application should consider available research in the design of the project and collect and disseminate information about the results of the project, such as student outcomes, student participation and parental satisfaction.
                </P>
                <P>
                    <E T="03">Local educational agency (LEA)</E>
                     means—
                </P>
                <P>(a) A public board of education or other public authority legally constituted within a State for either administrative control or direction of, or to perform a service function for, public elementary schools or secondary schools in a city, county, township, school district, or other political subdivision of a State, or of or for a combination of school districts or counties that is recognized in a State as an administrative agency for its public elementary schools or secondary schools.</P>
                <P>(b) The term includes any other public institution or agency having administrative control and direction of a public elementary school or secondary school.</P>
                <P>(c) The term includes an elementary school or secondary school funded by the Bureau of Indian Education but only to the extent that including the school makes the school eligible for programs for which specific eligibility is not provided to the school in another provision of law and the school does not have a student population that is smaller than the student population of the LEA (as defined in this notice) receiving assistance under the ESEA with the smallest student population, except that the school shall not be subject to the jurisdiction of any SEA other than the Bureau of Indian Education.</P>
                <P>(d) The term includes educational service agencies and consortia of those agencies.</P>
                <P>(e) The term includes the SEA in a State in which the SEA is the sole educational agency for all public schools.</P>
                <P>
                    <E T="03">Logic model</E>
                     (also referred to as a theory of action) means a framework that identifies key project components of the proposed project (
                    <E T="03">i.e.,</E>
                     the active “ingredients” that are hypothesized to be critical to achieving the relevant outcomes) and describes the theoretical and operational relationships among the key project components and relevant outcomes.
                </P>
                <P>
                    <E T="03">Microgrant</E>
                     means an account established for a parent that provides funds directly to service providers to expand educational choice. The parent must have easy access to and visibility into the account and it must allow the parent to select particular education services, expenses, or materials, to expand the ability to choose high-quality educational opportunities to meet their needs.
                </P>
                <P>
                    <E T="03">Parent</E>
                    —The term “parent” includes a legal guardian or other person standing in loco parentis (such as a grandparent or stepparent with whom the child lives, or a person who is legally responsible for the child's welfare).
                </P>
                <P>
                    <E T="03">Performance measure</E>
                     means any quantitative indicator, statistic, or metric used to gauge program or project performance.
                </P>
                <P>
                    <E T="03">Performance target</E>
                     means a level of performance that an applicant would seek to meet during the course of a project or as a result of a project.
                </P>
                <P>
                    <E T="03">Project component</E>
                     means an activity, strategy, intervention, process, product, practice, or policy included in a project. Evidence may pertain to an individual project component or to a combination of project components (
                    <E T="03">e.g.,</E>
                     training teachers on instructional practices for English learners and follow-on coaching for these teachers).
                </P>
                <P>
                    <E T="03">Relevant outcome</E>
                     means the student outcome(s) or other outcome(s) the key project component is designed to improve, consistent with the specific goals of the program.
                </P>
                <P>
                    <E T="03">Remote learning</E>
                     means educational or instructional programming that mostly occurs away from the physical school building and is delivered in a student-focused manner that addresses a student's educational needs. This includes both non-technology-based learning (
                    <E T="03">e.g.,</E>
                     paper packets, in-person tutoring) and “distance education” as defined in section 103(7) of the Higher Education Act of 1965, as amended, and “distance learning” as defined in ESEA section 8101(14).
                </P>
                <P>
                    <E T="03">State educational agency (SEA)</E>
                     means the agency primarily responsible for the State supervision of public elementary or secondary schools.
                </P>
                <P>
                    <E T="03">Statewide virtual school</E>
                     means an online education program available to public and non-public school students that provides full-time education and supplemental coursework to students in other full-time education programs.
                </P>
                <P>
                    <E T="03">Application Requirements:</E>
                     The following application requirements are established for the FY 2020 ESF-REM Grants competition and any subsequent year in which we make awards from the list of unfunded applications from this competition in accordance with section 437(d)(1) of GEPA, 20 U.S.C. 1232(d)(1). Applicants must address the following application requirements:
                </P>
                <P>(1) Describe the applicant's approach to addressing one of the three absolute priorities contained in this notice. This description should include an implementation plan and timeline for key grant activities and a plan for how the applicant will assess the number of students served, and, if applying for Absolute Priority 1, how the grantee will select parents to receive microgrants; how the applicant will assess parent satisfaction with the State's grant-related remote learning offerings; and the number and different types, as defined by the grantee, of new remote learning options provided in order to address the performance measures for the grant.</P>
                <P>(2) Provide an analysis of the immediate needs in the State to support remote learning and describe how the proposed project will address those needs.</P>
                <P>
                    (3) Include a description of the State's coronavirus burden based on indicators and information factors other than those provided in the application package that demonstrate the significance of the impact of COVID-19 on students, parents, and schools in the State. This description may include additional data, including other public health measures such as coronavirus-related 
                    <PRTPAGE P="25415"/>
                    deaths per capita, or any other relevant education, labor or demographic data.
                </P>
                <P>(4) Provide an analysis of State assets and collaborative efforts made by the State (including supports already provided from Federal and non-Federal sources) to improve outcomes for students during this national emergency, including, at a minimum, parent and student supports and collaborations with nonprofits, local businesses, LEAs, institutions of higher education, and other relevant stakeholders. At a minimum this analysis should also include the following:</P>
                <P>(a) A description of the steps the State is taking at the time of the application to address the State's immediate education needs.</P>
                <P>(b) A description of the barriers the State has faced in meeting such needs.</P>
                <P>(5) Provide an assurance that the applicant will provide information to the Secretary, as requested, for evaluations that the Secretary may carry out. This may include, but is not limited to, working with grantees at the outset of the grant to establish common performance measures.</P>
                <P>This may include, but is not limited to, working with grantees at the outset of the grant to establish common performance measures, data elements, or data definitions.</P>
                <P>(6) Demonstrate support for the proposed project by the Governor of the State, such as through a letter signed by the Governor.</P>
                <P>
                    <E T="03">Exemption from Rulemaking:</E>
                     Under the Administrative Procedure Act (5 U.S.C. 553) the Department generally offers interested parties the opportunity to comment on proposed priorities, selection criteria, definitions, and other requirements. Section 437(d)(1) of GEPA, however, allows the Secretary to exempt from rulemaking requirements regulations governing the first grant competition under a new or substantially revised program authority. This is the first grant competition for this program under section 18001(a)(3) of the CARES Act, and therefore qualifies for this exemption. In order to ensure timely grant awards, the Secretary has decided to forgo public comment on the priorities, requirements, definitions, and selection criteria under section 437(d)(1) of GEPA.
                </P>
                <P>
                    <E T="03">Program Authority:</E>
                     Section 18001(a)(3) of Title VIII of Division B of the CARES Act, Public Law 116-36 (enacted March 27, 2020).
                </P>
                <P>
                    <E T="03">Applicable Regulations:</E>
                     (a) The Education Department General Administrative Regulations in 34 CFR parts 75, 77, 79, 81, 82, 84, 97, 98, and 99. (b) The Office of Management and Budget Guidelines to Agencies on Governmentwide Debarment and Suspension (Nonprocurement) in 2 CFR part 180, as adopted and amended as regulations of the Department in 2 CFR part 3485. (c) The Uniform Administrative Requirements, Cost Principles, and Audit Requirements for Federal Awards in 2 CFR part 200, as adopted and amended as regulations of the Department in 2 CFR part 3474.
                </P>
                <HD SOURCE="HD1">II. Award Information</HD>
                <P>
                    <E T="03">Estimated Available Funds:</E>
                     $180,000,000.
                </P>
                <P>These estimated available funds are the amount available for ESF-REM grants under the FY 2020 CARES Act. The Department will determine the number of awards to be made under each absolute priority based on the quality of applications received consistent with the selection criteria and priorities. It will also determine the size of an award made to an eligible applicant based on a review of the eligible applicant's budget. The Department may use any unused funds designated for this competition to make awards under the ESF-REM program.</P>
                <P>
                    <E T="03">Estimated Range of Awards:</E>
                     $5,000,000-$20,000,000.
                </P>
                <P>
                    <E T="03">Estimated Average Size of Awards:</E>
                     $15,000,000.
                </P>
                <P>
                    <E T="03">Estimated Number of Awards:</E>
                     13-14; 4 awards under each absolute priority, dependent on sufficient quality.
                </P>
                <P>
                    <E T="03">Note:</E>
                     The Department is not bound by any estimates in this notice.
                </P>
                <P>
                    <E T="03">Project Period:</E>
                     Up to 36 months.
                </P>
                <HD SOURCE="HD1">III. Eligibility Information</HD>
                <P>
                    1. 
                    <E T="03">Eligible Applicants:</E>
                     SEAs.
                </P>
                <P>
                    2. 
                    <E T="03">Cost Sharing or Matching:</E>
                     This program does not require cost sharing or matching.
                </P>
                <P>
                    3. 
                    <E T="03">Subgrantees:</E>
                     A grantee under this competition may not award subgrants to entities to directly carry out project activities described in its application.
                </P>
                <HD SOURCE="HD1">IV. Application and Submission Information</HD>
                <P>
                    1. 
                    <E T="03">Application Submission Instructions:</E>
                     Applicants are required to follow the Common Instructions for Applicants to Department of Education Discretionary Grant Programs, published in the 
                    <E T="04">Federal Register</E>
                     on February 13, 2019 (84 FR 3768) and available at 
                    <E T="03">www.govinfo.gov/content/pkg/FR-2019-02-13/pdf/2019-02206.pdf,</E>
                     which contain requirements and information on how to submit an application. 
                    <E T="03">Grants.gov</E>
                     has relaxed the requirement for applicants to have an active registration in the System for Award Management (SAM) in order to apply for funding. In the event a registration expires before an award is issued, the Department will relax the active registration requirement and not delay funds due to the COVID-19 crisis.
                </P>
                <P>
                    2. 
                    <E T="03">Intergovernmental Review:</E>
                     This program is subject to Executive Order 12372 and the regulations in 34 CFR part 79. However, under 34 CFR 79.8(a), we waive intergovernmental review in order to make timely awards.
                </P>
                <P>
                    3. 
                    <E T="03">Funding Restrictions:</E>
                     We reference regulations outlining funding restrictions in the 
                    <E T="03">Applicable Regulations</E>
                     section of this notice. Each eligible entity may charge an amount of administrative costs that is reasonable and necessary to effectively administer the program consistent with cost principles in 2 CFR part 200, subpart E of the Uniform Administrative Requirements, Cost Principles, and Audit Requirements for Federal Awards (Uniform Guidance). Administrative costs include costs (direct and indirect) involved in the proper and efficient performance and administration of this Federal grant. However, to maximize the funds available for services to students and the public, the Department encourages each eligible entity to minimize the amount of administrative costs charged to the program.
                </P>
                <P>
                    4. 
                    <E T="03">Recommended Page Limit:</E>
                     The application narrative (Part III of the application) is where you, the applicant, address the selection criteria and priority that reviewers use to evaluate your application. We recommend that you (1) limit the application narrative to no more than 25 pages and (2) use the following standards:
                </P>
                <P>• A “page” is 8.5” x 11”, on one side only, with 1” margins at the top, bottom, and both sides.</P>
                <P>• Double space (no more than three lines per vertical inch) all text in the application narrative, including titles, headings, footnotes, quotations, references, and captions.</P>
                <P>• Use a font that is either 12 point or larger or no smaller than 10 pitch (characters per inch).</P>
                <P>• Use one of the following fonts: Times New Roman, Courier, Courier New, or Arial.</P>
                <P>The recommended page limit does not apply to Part I, the cover sheet; Part II, the budget section, including the narrative budget justification; Part IV, the assurances and certifications; or the one-page abstract, the resumes, the letters of support, or the appendices. However, the recommended page limit does apply to all of the application narrative.</P>
                <P>
                    5. 
                    <E T="03">Notice of Intent to Apply:</E>
                     We will be able to develop a more efficient process for reviewing grant applications 
                    <PRTPAGE P="25416"/>
                    if we know the approximate number of applicants that intend to apply for funding under this competition. Therefore, the Secretary strongly encourages each potential applicant to notify us of the applicant's intent to submit an application by sending an email to 
                    <E T="03">ESF-REM@ed.gov</E>
                     with 
                    <E T="03">ESF-REM Intent to Apply</E>
                     in the subject line. Applicants that do not send a notice of intent to apply may still apply for funding.
                </P>
                <HD SOURCE="HD1">V. Application Review Information</HD>
                <P>
                    1. 
                    <E T="03">Selection Criteria:</E>
                     The selection criteria for this competition are either from 34 CFR 75.210, or are being established for the FY 2020 grant competition and any subsequent year in which we make awards from the list of unfunded applications from this competition in accordance with section 437(d)(1) of GEPA, 20 U.S.C. 1232(d)(1). The points assigned to each criterion are indicated in the parentheses next to the criterion. An applicant may earn up to a total of 100 points based on the selection criteria for the application.
                </P>
                <P>
                    A. 
                    <E T="03">Highest Coronavirus Burden (up to 40 points).</E>
                </P>
                <P>In determining the States with the highest coronavirus burden, the Secretary considers the extent to which the State has a high coronavirus burden as follows:</P>
                <P>(1) The extent to which the applicant, based on the factors listed in the application package, when weighted equally, is in the—</P>
                <P>(i) Up to 20th percentile of coronavirus burden (4 points);</P>
                <P>(ii) 21st to 40th percentile of coronavirus burden (8 points);</P>
                <P>(iii) 41st to 60th percentile of coronavirus burden (12 points);</P>
                <P>(iv) 61st to 80th percentile of coronavirus burden (16 points); or</P>
                <P>(v) 81st to 100th percentile of coronavirus burden. (20 points) (GEPA Waiver)</P>
                <P>(2) The extent to which the applicant has a high coronavirus burden based on indicators and information factors identified by the applicant in response to Application Requirement 3. (20 points) (GEPA Waiver)</P>
                <P>
                    B. 
                    <E T="03">Quality of Project Services and Project Plan (up to 35 points).</E>
                </P>
                <P>The Secretary considers the quality of project services and project plan.</P>
                <P>In determining the quality of the project services and project plan, the Secretary considers the quality and sufficiency of strategies for ensuring equal access and treatment for eligible project participants who are members of groups that have traditionally been underrepresented based on race, color, national origin, gender, age, or disability. (up to 5 points)</P>
                <P>In addition, the Secretary considers—</P>
                <P>(1) The extent to which the proposed project is an exceptional approach to absolute priority being addressed and includes a detailed project plan for addressing the absolute priority. (up to 10 points) (GEPA waiver)</P>
                <P>(2) The extent to which specific gaps or weaknesses in services, infrastructure, or opportunities have been identified and will be addressed by the proposed project to respond to the needs of students. (up to 10 points) (GEPA waiver)</P>
                <P>(3) The likelihood that the services to be provided by the proposed project will expand access to remote learning options and lead to improvements in student outcomes. (up to 5 points) (GEPA waiver)</P>
                <P>(4) The extent to which the services to be provided by the proposed project reflect up-to-date knowledge from research and effective practice. (up to 5 points) (GEPA waiver)</P>
                <P>
                    C. 
                    <E T="03">Quality of the Management Plan and Adequacy of Resources (up to 25 points).</E>
                </P>
                <P>The Secretary considers the quality of the management plan and adequacy of resources. In determining the quality of the management plan and adequacy of resources, the Secretary considers—</P>
                <P>(1) The adequacy of the management plan to achieve the objectives of the proposed project on time and within budget, including clearly defined responsibilities, timelines, and milestones for accomplishing project tasks. (up to 5 points) (34 CFR 75.210)</P>
                <P>(2) The extent to which the proposed use of funds will adequately support the proposed project. (up to 5 points) (GEPA waiver)</P>
                <P>(3) The extent to which the costs are reasonable in relation to the objectives, design, and potential significance of the proposed project. (up to 5 points) (34 CFR 75.210)</P>
                <P>(4) The extent to which the costs are reasonable in relation to the number of persons to be served and to the anticipated results and benefits. (up to 10 points) (34 CFR 75.210)</P>
                <P>
                    2. 
                    <E T="03">Review and Selection Process:</E>
                     The Department will announce awards within 30 days of the deadline for transmittal of applications of this competition. We remind potential applicants that in reviewing applications in any discretionary grant competition, the Secretary may consider, under 34 CFR 75.217(d)(3), the past performance of the applicant in carrying out a previous award, such as the applicant's use of funds, achievement of project objectives, and compliance with grant conditions. The Secretary may also consider whether the applicant failed to submit a timely performance report or submitted a report of unacceptable quality.
                </P>
                <P>In addition, in making a competitive grant award, the Secretary requires various assurances, including those applicable to Federal civil rights laws that prohibit discrimination in programs or activities receiving Federal financial assistance from the Department (34 CFR 100.4, 104.5, 106.4, 108.8, and 110.23).</P>
                <P>Before making awards, we will screen applications submitted in accordance with the requirements in this notice to determine whether applications have met eligibility and other requirements. This screening process may occur at various stages of the process; applicants that are determined to be ineligible will not receive a grant, regardless of peer reviewer scores or comments.</P>
                <P>Peer reviewers will read, prepare a written evaluation of, and score the assigned applications, using the selection criteria provided in this notice.</P>
                <P>
                    3. 
                    <E T="03">Risk Assessment and Specific Conditions:</E>
                     Consistent with 2 CFR 200.205, before awarding grants under this competition the Department conducts a review of the risks posed by applicants. Under 2 CFR 3474.10, the Secretary may impose specific conditions and, in appropriate circumstances, high-risk conditions on a grant if the applicant or grantee is not financially stable; has a history of unsatisfactory performance; has a financial or other management system that does not meet the standards in 2 CFR part 200, subpart D; has not fulfilled the conditions of a prior grant; or is otherwise not responsible.
                </P>
                <P>
                    4. 
                    <E T="03">Integrity and Performance System:</E>
                     If you are selected under this competition to receive an award that over the course of the project period may exceed the simplified acquisition threshold (currently $250,000), under 2 CFR 200.205(a)(2), we must make a judgment about your integrity, business ethics, and record of performance under Federal awards—that is, the risk posed by you as an applicant—before we make an award. In doing so, we must consider any information about you that is in the integrity and performance system (currently referred to as the Federal Awardee Performance and Integrity Information System (FAPIIS)), accessible through the System for Award Management. You may review and comment on any information about yourself that a Federal agency previously entered and that is currently in FAPIIS.
                    <PRTPAGE P="25417"/>
                </P>
                <P>Please note that, if the total value of your currently active grants, cooperative agreements, and procurement contracts from the Federal Government exceeds $10,000,000, the reporting requirements in 2 CFR part 200, Appendix XII, require you to report certain integrity information to FAPIIS semiannually. Please review the requirements in 2 CFR part 200, Appendix XII, if this grant plus all the other Federal funds you receive exceed $10,000,000.</P>
                <HD SOURCE="HD1">VI. Award Administration Information</HD>
                <P>
                    1. 
                    <E T="03">Award Notices:</E>
                     If your application is successful, we notify your U.S. Representative and U.S. Senators and send you a Grant Award Notification (GAN); or we may send you an email containing a link to access an electronic version of your GAN. We may notify you informally, also.
                </P>
                <P>If your application is not evaluated or not selected for funding, we notify you.</P>
                <P>
                    2. 
                    <E T="03">Administrative and National Policy Requirements:</E>
                     We identify administrative and national policy requirements in the application package and reference these and other requirements in the 
                    <E T="03">Applicable Regulations</E>
                     section of this notice.
                </P>
                <P>
                    We reference the regulations outlining the terms and conditions of an award in the 
                    <E T="03">Applicable Regulations</E>
                     section of this notice and include these and other specific conditions in the GAN. The GAN also incorporates your approved application as part of your binding commitments under the grant.
                </P>
                <P>
                    3. 
                    <E T="03">Open Licensing Requirements:</E>
                     Unless an exception applies, if you are awarded a grant under this competition, you will be required to openly license to the public grant deliverables created in whole, or in part, with Department grant funds. When the deliverable consists of modifications to pre-existing works, the license extends only to those modifications that can be separately identified and only to the extent that open licensing is permitted under the terms of any licenses or other legal restrictions on the use of pre-existing works. Additionally, a grantee that is awarded competitive grant funds must have a plan to disseminate these public grant deliverables. This dissemination plan can be developed and submitted after your application has been reviewed and selected for funding. For additional information on the open licensing requirements please refer to 2 CFR 3474.20(c).
                </P>
                <P>
                    4. 
                    <E T="03">Reporting:</E>
                     (a) If you apply for a grant under this competition, you must ensure that you have in place the necessary processes and systems to comply with the reporting requirements in 2 CFR part 170 should you receive funding under the competition. This does not apply if you have an exception under 2 CFR 170.110(b).
                </P>
                <P>(b) In addition to annual performance reporting, a grantee must submit to the Department a quarterly report that provides data and information meeting the requirements of section 15011 of the CARES Act.</P>
                <P>
                    (c) At the end of your project period, you must submit a final performance report, including financial information, as directed by the Secretary. If you receive a multiyear award, you must submit an annual performance report that provides the most current performance and financial expenditure information as directed by the Secretary under 34 CFR 75.118. The Secretary may also require more frequent performance reports under 34 CFR 75.720(c). For specific requirements on reporting, please go to 
                    <E T="03">www.ed.gov/fund/grant/apply/appforms/appforms.html.</E>
                </P>
                <P>(d) Under 34 CFR 75.250(b), the Secretary may provide a grantee with additional funding for data collection analysis and reporting. In this case the Secretary establishes a data collection period.</P>
                <P>
                    5. 
                    <E T="03">Performance Measures:</E>
                     We have established the following performance measures for the ESF-REM Grants program: (1) The number of students served by the project; (2) the percentage of parents who reported satisfaction with the remote learning options available; and (3) the number and different types, as defined by the grantee, of new remote learning options provided.
                </P>
                <P>In addition, applicants must propose project-specific performance measures and performance targets consistent with the objectives of the proposed project, which must include at least one student-based educational outcome measure.</P>
                <P>Applicants must provide the following information as directed under 34 CFR 75.110(b) and (c):</P>
                <P>(a) Performance Measures. How each proposed performance measure would accurately measure the performance of the project and how the proposed performance measures would be consistent with the performance measures established for the program funding the competition.</P>
                <P>(b) Baseline Data.</P>
                <P>(i) Why each proposed baseline is valid; or</P>
                <P>(ii) If the applicant has determined that there are no established baseline data for a particular performance measure, an explanation of why there is no established baseline and of how and when, during the project period, the applicant would establish a valid baseline for the performance measure.</P>
                <P>(c) Performance Targets. Why each proposed performance target is ambitious (as defined in this notice) yet achievable compared to the baseline for the performance measure and when, during the project period, the applicant would meet the performance target(s).</P>
                <P>(d) Data Collection and Reporting.</P>
                <P>(i) The data collection and reporting methods the applicant would use and why those methods are likely to yield reliable, valid, and meaningful performance data; and</P>
                <P>(ii) The applicant's capacity to collect and report reliable, valid, and meaningful performance data, as evidenced by high-quality data collection, analysis, and reporting in other projects or research.</P>
                <P>All grantees must submit an annual performance report with information that is responsive to these performance measures.</P>
                <HD SOURCE="HD1">VII. Other Information</HD>
                <P>
                    <E T="03">Accessible Format:</E>
                     Individuals with disabilities can obtain this document and a copy of the application package in an accessible format (
                    <E T="03">e.g.,</E>
                     braille, large print, audiotape, or compact disc) on request to the program contact person listed under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    .
                </P>
                <P>
                    <E T="03">Electronic Access to This Document:</E>
                     The official version of this document is the document published in the 
                    <E T="04">Federal Register</E>
                    <E T="03">.</E>
                     You may access the official edition of the 
                    <E T="04">Federal Register</E>
                     and the Code of Federal Regulations at 
                    <E T="03">www.govinfo.gov.</E>
                     At this site you can view this document, as well as all other documents of this Department published in the 
                    <E T="04">Federal Register</E>
                    , in text or Portable Document Format (PDF). To use PDF you must have Adobe Acrobat Reader, which is available free at the site.
                </P>
                <P>
                    You may also access documents of the Department published in the 
                    <E T="04">Federal Register</E>
                     by using the article search feature at 
                    <E T="03">www.federalregister.gov.</E>
                     Specifically, through the advanced search feature at this site, you can limit your search to documents published by the Department.
                </P>
                <SIG>
                    <NAME>Frank Brogan,</NAME>
                    <TITLE>Assistant Secretary for Elementary and Secondary Education.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09274 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4000-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="25418"/>
                <AGENCY TYPE="S">DEPARTMENT OF EDUCATION</AGENCY>
                <DEPDOC>[Docket ED-2019-OESE-0147]</DEPDOC>
                <SUBJECT>Final Priorities—Competitive Grants for State Assessments Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Elementary and Secondary Education, Department of Education.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Final priorities.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Assistant Secretary for Elementary and Secondary Education announces priorities under the Competitive Grants for State Assessments (CGSA) program, Catalog of Federal Domestic Assistance (CFDA) number 84.368A. The Assistant Secretary may use these priorities for a competition in fiscal year (FY) 2020 and in later years. We take this action to focus Federal financial assistance related to student assessments on innovative assessments. We intend the priorities to increase the number of States requesting and, then, using flexibility under the Innovative Assessment Demonstration Authority (IADA) and to support high-quality work among those States that do so. Given the national emergency related to the novel coronavirus (COVID-19), flexible approaches to education, including innovative, formative, and competency-based assessments such as those that these priorities will support, are essential for students, parents, and educators.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>These priorities are effective June 1, 2020.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Donald Peasley, U.S. Department of Education, 400 Maryland Avenue SW, Room 3W106, Washington, DC 20202. Telephone: (202) 453-7982. Email: 
                        <E T="03">ESEA.Assessment@ed.gov.</E>
                    </P>
                    <P>If you use a telecommunications device for the deaf (TDD) or a text telephone (TTY), call the Federal Relay Service (FRS), toll free, at 1-800-877-8339.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>Catalog of Federal Domestic Assistance (CFDA) number 84.368A</P>
                <P>
                    <E T="03">Purpose of Program:</E>
                     The purpose of the CGSA program is to support States' efforts to improve the technical quality of their assessment systems—both the quality of individual State assessments and the overall field of State assessments.
                </P>
                <P>
                    <E T="03">Program Authority:</E>
                     Section 1203 of the Elementary and Secondary Education Act of 1965, as amended by the Every Student Succeeds Act (Pub. L. 114-95) (ESEA). We published a notice of proposed priorities for this program in the 
                    <E T="04">Federal Register</E>
                     on January 8, 2020 (85 FR 853) (the NPP). That document contained background information and our reasons for proposing two priorities for the CGSA program.
                </P>
                <P>There are two minor technical differences between the proposed priorities and these final priorities, as explained below.</P>
                <P>These priorities are for use in addition to those published in the 2016 NFP, the 2011 notice of final priorities, requirements, definitions, and selection criteria (76 FR 21985) (2011 NFP), and the 2013 notice of final priorities, requirement, definitions, and selection criteria for this program (78 FR 31343) (2013 NFP).</P>
                <P>
                    <E T="03">Public Comment:</E>
                     In response to our invitation in the NPP, ten parties submitted comments on the proposed priorities. We group major issues according to subject. Generally, we do not address comments that are outside the scope of the proposed priorities (
                    <E T="03">e.g.,</E>
                     we do not address proposed changes to the IADA regulations).
                </P>
                <P>
                    <E T="03">Analysis of Comments and Changes:</E>
                     An analysis of the comments and of any changes in the priorities since publication of the NPP follows.
                </P>
                <P>
                    <E T="03">General Comments:</E>
                     Among the ten comments received, five commenters indicated overall support for the focus on IADA planning and implementation projects, while two expressed opposition to the use of the proposed priorities as further described later. Two additional commenters expressed concerns regarding the CGSA program but did not explicitly address the proposed priorities. One commenter did not address the CGSA program at all.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     We appreciate the support for these proposed priorities.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     Two commenters opposed focusing future CGSA competitions on supporting IADA planning and implementation. The commenters reasoned that, because the ESEA does not directly authorize funding for IADA, CGSA funds should not be used to fund IADA projects. These commenters also contended that CGSA funds should not be used to support States implementing IADA because a published report regarding one State's implementation of its IADA raised concerns that the assessment was not providing valid and reliable data for students with disabilities.
                </P>
                <P>These same commenters also encouraged the Department to focus future CGSA competitions instead on other priorities, such as improving alternate assessments for students with the most significant cognitive disabilities; making assessments more accessible for all students through the use of Universal Design for Learning (UDL); and producing culturally responsive assessments for English learners (ELs).</P>
                <P>
                    <E T="03">Discussion:</E>
                     We appreciate these commenters' perspective and agree that the assessment needs of students with disabilities and ELs represent important topic areas for assessment development. The majority of grants funded by the CGSA and its predecessor, the Enhanced Assessments Grants (EAG) program, supported projects that addressed students with disabilities and ELs. Specifically, since 2002, the Department has made a total of 63 awards to States through the EAG and CGSA programs. Thirty-eight of those awards (60 percent) have had at least one primary goal of researching, developing, or validating assessments for students with disabilities. Thirty (48 percent) of those awards have had at least one primary goal of researching, developing, or validating assessments for ELs. In addition, the Department provides substantial annual support through formula grants to support State assessments. Three of the allowed uses of those formula grant funds specifically apply to improving valid and reliable assessments for students with disabilities or ELs (section 1201(a)(2)(A), (C), and (I) of the ESEA), and we expect States that receive IADA-related CGSA awards to appropriately include ELs and students with disabilities in the innovative assessments.
                </P>
                <P>The Department agrees that it is critical for assessments to be accessible for all students, including, to the extent practicable, using the principles of UDL. The Department notes this is a requirement for all State assessments under section 1111(b)(2)(B)(vii) and (xiii) of the ESEA. All State assessments (including any proposed under the IADA) must meet this requirement, which is evaluated by the Department through the assessment peer review process.</P>
                <P>The Department does not agree with the two commenters that IADA-related projects are not authorized to receive funding from the CGSA. Nothing in the statute precludes a State from receiving CGSA funds while it plans for or implements an IADA-focused project, as long as the proposed projects align with one or more of the CGSA statutory uses of funds in section 1201(a)(2)(C), (H), (I), (J), (K), and (L) of the ESEA, which are summarized below=:</P>
                <P>
                    • Developing or improving assessments for English learners;
                    <PRTPAGE P="25419"/>
                </P>
                <P>• Developing or improving models to measure and assess student progress or student growth;</P>
                <P>• Developing or improving assessments for students with disabilities;</P>
                <P>• Collaborating with institutions of higher education or other research institutions to improve the quality, validity, and reliability of assessments;</P>
                <P>• Measuring student academic achievement using multiple measures from multiple sources; and</P>
                <P>• Evaluating student academic achievement through comprehensive academic assessments that leverage a competency-based model.</P>
                <P>We anticipate that any IADA project would address one or more of these uses of funds. Furthermore, the Department believes that the use of IADA flexibility may further innovative CGSA projects aligned with the statutory uses of funds.</P>
                <P>Finally, these two commenters raised a concern about the validity and reliability of the data for students with disabilities from one State currently approved for the IADA. Although this comment is outside the scope of these proposed priorities, the Department notes that it monitors State implementation of the IADA. The Department hopes that supporting States during the IADA planning and implementation periods will promote high-quality assessments that meet all IADA requirements.</P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     One commenter suggested adding a third priority to emphasize two of the allowable uses of CGSA funds defined in ESEA section 1201(a)(2):
                </P>
                <P>(K) Measuring student academic achievement using multiple measures of student academic achievement from multiple sources.</P>
                <P>(L) Evaluating student academic achievement through the development of comprehensive academic assessment instruments (such as performance and technology-based academic assessments, computer adaptive assessments, projects, or extended performance task assessments) that emphasize the mastery of standards and aligned competencies in a competency-based education model.</P>
                <P>The commenter believed that while the proposed priorities incentivizing the IADA were a worthy goal, the ultimate outcome for the CGSA program should be the improvement of State assessment systems through the use of new assessment approaches that are consistent with the ESEA requirement for multiple measures that assess higher-order thinking skills. The commenter argued that including a third priority focused on the uses of funds defined in ESEA sections 1201(a)(2)(K) and (L) could support that outcome.</P>
                <P>A second commenter encouraged modifying the allowable uses of funds regarding improving assessment of student growth by including measurement models that incorporate multiple measures.</P>
                <P>
                    <E T="03">Discussion:</E>
                     The Department agrees that one of the broad purposes of the CGSA program is the development and administration of higher-quality assessments, which could include better assessing higher-order thinking skills. In any future competition, the Department may rely on the uses of funds in ESEA sections 1201(a)(2)(C), (H), (I), (J), (K), and (L) (summarized above), the previously established priorities, or these final priorities in selecting specific priorities for a competition. This document establishes priorities that can be used in any future competition but does not establish how those priorities are designated in any particular competition. In a notice published separately in this issue of the 
                    <E T="04">Federal Register</E>
                    , the Department invites applications and specifies the applicable priorities for the FY 2020 CGSA competition. The Department also notes that for any project funded under the CGSA program, including IADA-related projects, a grantee must address one or more of the uses of funds and, therefore, may use their funds to support activities directly aligned with ESEA sections 1201(a)(2)(K) or (L). With regards to the second commenter, the Department further adds that sections 1201(a)(2)(H) and (K) of the ESEA allow an SEA to use CGSA funds for improving growth models and using multiple measures of student academic achievement, respectively. Therefore, no changes to the proposed priorities are necessary.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter encouraged the Department to evaluate CGSA proposals to ensure they include assessment audits that reduce redundant assessments.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     Assessment audits can be a useful tool in ensuring that schools utilize assessments appropriately and avoid assessments that are redundant, of low quality, or unnecessary. However, the focus of the CGSA program is the statewide assessments that are required under ESEA section 1111(b)(2).
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter advocated that the Department encourage and incentivize projects that include formative assessment in development of balanced assessment systems.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     The Department agrees that formative assessments can be a vital part of a balanced assessment system and supports States, districts, and schools that choose to use them. Formative assessments that provide rapid, instructionally relevant results can be a powerful tool to aid educators in serving students. Nothing in these priorities precludes a State from including formative assessments as part of an application for CGSA. For example, activities aligned with ESEA sections 1201(a)(2)(K) or (L) may include formative assessments as part of a project's theory of action. Activities related to other allowable uses of funds or to these priorities might also support development of formative assessments.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter encouraged the coordination of CGSA reporting requirements with IADA reporting requirements if an ongoing IADA project received CGSA funding in order to reduce burden on States.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     The Department appreciates the concern regarding the coordination of various reporting requirements upon States for the IADA and the CGSA. We anticipate coordination to the greatest extent practicable (
                    <E T="03">e.g.,</E>
                     aligning reporting of certain milestones) in the event that a State that is implementing the IADA receives a CGSA award. However, there are distinct requirements for each program that are defined in statute and regulations, and there could be reporting aspects that must continue separately. The Department will work with any State approved for a CGSA grant to implement its IADA plan to individually assess where these efficiencies might be attained.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter shared a general concern that the rush to develop innovative State assessments that provide an annual proficiency determination might cause education officials to lose sight of important principles of assessment and establish systems that do not serve the best interest of student learning, for example, by undermining the validity and reliability of State accountability; dramatically constraining school and district approaches to curriculum and instruction; and compromising the value of interim assessments to support teaching and learning in that subject area.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     The ESEA requires every State to have an annual assessment of the State's challenging academic standards. The Department acknowledges that validity and reliability are a key component of any 
                    <PRTPAGE P="25420"/>
                    assessment system. Validity and reliability requirements are clearly defined in 34 CFR 200.104-108 for the IADA. In addition, the purpose of the IADA is to pilot and scale up the use of innovative assessment items and designs; at the end of the IADA period, if successful, the innovative assessment would be administered statewide and subject to all requirements for statewide assessment systems, including the Department's assessment peer review. All decisions related to curriculum and instruction are at the discretion of the State or district. Consistent with section 8527(b) of the ESEA, the Department does not endorse any curriculum approach. A State, at its discretion, may align State assessments with other State and local assessments, including any formative or interim assessments, to avoid redundant or unnecessary testing while providing useful and timely information to parents and teachers. The Department does not require interim assessments and defers to State and local discretion on their use.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>Priority 1—Implementing the Innovative Assessment Demonstration Authority (IADA).</P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter requested that the Department better align the timing of the CGSA competition with the three States that applied in January 2020 for IADA approval. The commenter expressed concern that these States may not receive the approval to begin implementing their IADA pilots in time to allow them to prepare a CGSA application during the 2020 CGSA competition period.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     The Department appreciates the commenter's concern but notes that these States may receive approval of IADA prior to the date that applications are due for the CGSA program in 2020. Alternatively, States could submit applications under multiple priorities, as outlined in the NIA published elsewhere in this issue of the 
                    <E T="04">Federal Register</E>
                    <E T="03">.</E>
                     Furthermore, once this priority has been finalized, the Department can elect to use this priority in the 2020 or any future CGSA competition. In addition, the Department notes that each State receives formula funds under the ESEA to develop and administer statewide assessments. A State approved for IADA would be able to use these formula assessment funds to implement its IADA plan.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter requested that the CGSA award period be increased from 48 months to 60 months, which would align with the five-year IADA implementation window.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     While the Department understands the commenter's recommendation, we disagree that the award period for the CGSA should match that of the IADA implementation period for several reasons. First, there are already four States that have received the IADA that are already in the midst of their five-year IADA implementation period (two States are in year two and two other States are in their first year). For these States, such an alignment is not feasible. Second, through the CGSA program, the Department intends to provide some financial support for States implementing IADA, but the Department does not believe that CGSA awards will be sufficient to completely fund IADA implementation. The Department expects that a State will need additional dedicated funds for implementation of its innovative assessment to ensure sufficient buy-in and support within the State and for sustainability of the innovative assessment. The Department assumes that States have other sources of funding that will supplement any CGSA support and will correspondingly plan a budget to maximize the use of four years of CGSA support accordingly. The Department notes that final Priority 1 does not contain any specific references regarding the timeframe for awards. Such timeframes are typically outlined in any notice inviting applications (NIA) for future competitions for CGSA. Please see the NIA for the CGSA published elsewhere in this issue of the 
                    <E T="04">Federal Register</E>
                     for details regarding expected timeframes for the 2020 CGSA competition.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>Priority 2—Planning to Apply for the Innovative Assessment Demonstration Authority (IADA).</P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter encouraged the Department to specify that planning proposals for the IADA be allowed up to 24 months of funding under this priority.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     The Department appreciates the commenter's perspective. However, the Department believes that States considering the IADA as an option for their assessment system will have already undergone some planning efforts if they apply for a planning grant under the CGSA. The Department believes that while CGSA funds can supplement a State's costs and support more substantive planning efforts, they should not be considered as the only financial support needed to sustain State planning for the IADA. In the NPP, the Department communicated that it anticipates a shorter (12 to 18 months) funding period for Priority 2 than for Priority 1. The Department continues to believe that this is a reasonable timeframe for States to conduct IADA planning efforts with CGSA support. However, the Department notes that the final Priority 2 does not contain any specific references regarding the timeframe for awards. Such timeframes are typically outlined in any NIA for future competitions for CGSA. Please see the NIA for the CGSA published elsewhere in this issue of the 
                    <E T="04">Federal Register</E>
                     for details regarding expected timeframes for the 2020 CGSA competition.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <P>
                    <E T="03">Comments:</E>
                     One commenter requested that we modify the priority to require the inclusion of assessment theories of actions. A key goal of the planning period would then be to fully flesh out this theory of action that would address, among many other processes and mechanisms, the detailed design information about the intended IADA pilot assessment. The commenter reasoned that, early in planning, development of the theory of action is critical to establishing the foundations for a State's IADA plan, and requiring the more detailed definition of specific assessment designs or item prototypes might hinder or bias the most appropriate theory of action.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     The Department agrees with the commenter that a solid theory of action is critical to properly establishing a design for an innovative assessment system. However, as noted above, the Department does not envision that the CGSA award would cover the entirety of a State's IADA planning process. The Department is interested in supporting plans that appear to have a high probability of reaching the implementation stage. To that end, the Department believes that proposals that indicate sufficient maturity to outline an assessment design (or an array of possible design choices) merit the highest consideration for CGSA support.
                </P>
                <P>
                    <E T="03">Changes:</E>
                     None.
                </P>
                <HD SOURCE="HD1">Technical Changes</HD>
                <P>
                    <E T="03">Comment:</E>
                     None.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     Under section 1203(b)(1)(B) of the ESEA, SEAs that apply for CGSA must describe how they will use CGSA funds for one or more of the statutory uses of funds. In Proposed Priorities 1 and 2, the Department included a requirement to provide such description as part of the priority. Since we are including this statutory requirement as an application requirement in the NIA published elsewhere in this issue of the 
                    <E T="04">Federal Register</E>
                    <E T="03">,</E>
                     and anticipate that we also 
                    <PRTPAGE P="25421"/>
                    would do so for future competitions, the Department is removing this duplicative language from Priority 1 and 2.
                </P>
                <P>
                    <E T="03">Change:</E>
                     The Department has removed the requirement in each priority that SEAs describe how the proposed projects align with one or more of the CGSA statutory uses of funds in section 1201(a)(2)(C), (H), (I), (J), (K), and (L) of the ESEA.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     None.
                </P>
                <P>
                    <E T="03">Discussion:</E>
                     In Proposed Priority 1 and Proposed Priority 2, the Department phrased the priorities to acknowledge that an applicant may be either an SEA or a consortium of SEAs. In the 2016 NFP, the language of the priorities referred to SEAs generally. Because these priorities could be used in NIAs along with priorities from the 2016 NFP, the Department is revising the priority to generally refer to SEAs, for consistency with the other priorities.
                </P>
                <P>
                    <E T="03">Change:</E>
                     The Department is replacing the language in the final priorities to refer to SEAs generally instead of referencing an SEA, and a consortium of SEAs.
                </P>
                <HD SOURCE="HD1">Final Priorities</HD>
                <P>Priority 1—Implementing the Innovative Assessment Demonstration Authority (IADA).</P>
                <P>Under this priority, SEAs must—</P>
                <P>(a) Be approved for IADA as of the date of their CGSA application. If applying as part of a consortium (or in partnership with other SEAs), each SEA must be approved for IADA as of the date of its CGSA application;</P>
                <P>(b) Be implementing IADA, consistent with all requirements of section 1204 of the ESEA and applicable regulations as of the date of their CGSA application. If applying for CGSA as part of a consortium (or in partnership with other SEAs), each SEA must individually meet this requirement; and</P>
                <P>(c) Describe how the SEA will use CGSA funds to implement its approved IADA plan.</P>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>Any competition that uses this priority must also include another priority under which any SEA may apply.</P>
                </NOTE>
                <P>Priority 2—Planning to Apply for the Innovative Assessment Demonstration Authority (IADA).</P>
                <P>Under this priority, SEAs must—</P>
                <P>(a) Provide an assurance by an authorized representative that the SEA intends to apply for flexibility under the IADA, when made available by the Department. If applying for CGSA as part of a consortium (or in partnership with other SEAs), each SEA must provide an assurance that it intends to apply for flexibility under the IADA;</P>
                <P>(b) If applying as a consortium of SEAs during the initial demonstration authority for IADA, not include more than four SEAs; and</P>
                <P>
                    (c) Describe their approach to innovative assessments in terms of the subjects and grades the SEA anticipates addressing, the proposed assessment design, proposed item types (
                    <E T="03">e.g.,</E>
                     item prototypes), and other relevant features.
                </P>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>Any competition that uses this priority must also include another priority under which any SEA may apply.</P>
                </NOTE>
                <HD SOURCE="HD1">Types of Priorities</HD>
                <P>
                    When inviting applications for a competition using one or more priorities, we designate the type of each priority as absolute, competitive preference, or invitational through a notice in the 
                    <E T="04">Federal Register</E>
                    . The effect of each type of priority follows:
                </P>
                <P>
                    <E T="03">Absolute priority:</E>
                     Under an absolute priority, we consider only applications that meet the priority (34 CFR 75.105(c)(3)).
                </P>
                <P>
                    <E T="03">Competitive preference priority:</E>
                     Under a competitive preference priority, we give competitive preference to an application by (1) awarding additional points, depending on the extent to which the application meets the priority (34 CFR 75.105(c)(2)(i)); or (2) selecting an application that meets the priority over an application of comparable merit that does not meet the priority (34 CFR 75.105(c)(2)(ii)).
                </P>
                <P>
                    <E T="03">Invitational priority:</E>
                     Under an invitational priority, we are particularly interested in applications that meet the priority. However, we do not give an application that meets the priority a preference over other applications (34 CFR 75.105(c)(1)).
                </P>
                <P>This document does not preclude us from proposing additional priorities, requirements, definitions, or selection criteria, subject to meeting applicable rulemaking requirements.</P>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>
                        This document does 
                        <E T="03">not</E>
                         solicit applications. In any year in which we choose to use one or more of these priorities, we invite applications through a notice in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                </NOTE>
                <HD SOURCE="HD1">Executive Orders 12866, 13563, and 13771 Regulatory Impact Analysis</HD>
                <P>Under Executive Order 12866, it must be determined whether this regulatory action is “significant” and, therefore, subject to the requirements of the Executive order and subject to review by the Office of Management and Budget (OMB). Section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action likely to result in a rule that may—</P>
                <P>(1) Have an annual effect on the economy of $100 million or more, or adversely affect a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or State, local, or Tribal governments or communities in a material way (also referred to as an “economically significant” rule);</P>
                <P>(2) Create serious inconsistency or otherwise interfere with an action taken or planned by another agency;</P>
                <P>(3) Materially alter the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or</P>
                <P>(4) Raise novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles stated in the Executive order.</P>
                <P>
                    This final regulatory action is not a significant regulatory action subject to review by OMB under section 3(f) of Executive Order 12866. Pursuant to the Congressional Review Act (5 U.S.C. 801 
                    <E T="03">et seq.</E>
                    ), the Office of Information and Regulatory Affairs designated this rule as not a “major rule,” as defined by 5 U.S.C. 804(2).
                </P>
                <P>Under Executive Order 13771, for each new rule that the Department proposes for notice and comment or otherwise promulgates that is a significant regulatory action under Executive Order 12866, and that imposes total costs greater than zero, it must identify two deregulatory actions. For Fiscal Year 2019, any new incremental costs associated with a new regulation must be fully offset by the elimination of existing costs through deregulatory actions. Because the proposed regulatory action is not significant, the requirements of Executive Order 13771 do not apply.</P>
                <P>We have also reviewed this final regulatory action under Executive Order 13563, which supplements and explicitly reaffirms the principles, structures, and definitions governing regulatory review established in Executive Order 12866. To the extent permitted by law, Executive Order 13563 requires that an agency—</P>
                <P>(1) Propose or adopt regulations only upon a reasoned determination that their benefits justify their costs (recognizing that some benefits and costs are difficult to quantify);</P>
                <P>(2) Tailor its regulations to impose the least burden on society, consistent with obtaining regulatory objectives and taking into account—among other things and to the extent practicable—the costs of cumulative regulations;</P>
                <P>
                    (3) In choosing among alternative regulatory approaches, select those approaches that maximize net benefits (including potential economic, environmental, public health and safety, and other advantages; distributive impacts; and equity);
                    <PRTPAGE P="25422"/>
                </P>
                <P>(4) To the extent feasible, specify performance objectives, rather than the behavior or manner of compliance a regulated entity must adopt; and</P>
                <P>(5) Identify and assess available alternatives to direct regulation, including economic incentives—such as user fees or marketable permits—to encourage the desired behavior, or provide information that enables the public to make choices.</P>
                <P>Executive Order 13563 also requires an agency “to use the best available techniques to quantify anticipated present and future benefits and costs as accurately as possible.” The Office of Information and Regulatory Affairs of OMB has emphasized that these techniques may include “identifying changing future compliance costs that might result from technological innovation or anticipated behavioral changes.”</P>
                <P>We are issuing these final priorities only on a reasoned determination that their benefits justify their costs. In choosing among alternative regulatory approaches, we selected those approaches that maximize net benefits. Based on the analysis that follows, the Department believes that this regulatory action is consistent with the principles in Executive Order 13563.</P>
                <P>We also have determined that this regulatory action does not unduly interfere with State, local, and Tribal governments in the exercise of their governmental functions.</P>
                <P>In accordance with these Executive orders, the Department has assessed the potential costs and benefits, both quantitative and qualitative, of this regulatory action. The potential costs are those resulting from statutory requirements and those we have determined as necessary for administering the Department's programs and activities.</P>
                <P>
                    <E T="03">Summary of Costs and Benefits:</E>
                     The Department believes that these final priorities will not impose significant costs on the SEAs eligible for CGSA funds under section 1203 of the ESEA. We also believe that the benefits of implementing the final priorities justify any associated costs.
                </P>
                <P>The Department believes that the costs imposed on an applicant by the final priorities will be largely limited to the paperwork burden related to meeting the application requirements and that the benefits of preparing an application and receiving an award will justify any costs incurred by the applicant. SEAs selected for awards under section 1203 of the ESEA will be able to pay the costs associated with implementing the proposed projects related to State assessments with grant funds. Thus, the costs of these final priorities will not be a significant burden for any eligible applicant.</P>
                <P>
                    <E T="03">Regulatory Flexibility Act Certification:</E>
                     The Secretary certifies that this final regulatory action will not have a significant economic impact on a substantial number of small entities. The U.S. Small Business Administration Size Standards define “small entities” as for-profit or nonprofit institutions with total annual revenue below $7,000,000 or, if they are institutions controlled by small governmental jurisdictions (that are comprised of cities, counties, towns, townships, villages, school districts, or special districts), with a population of less than 50,000.
                </P>
                <P>We believe that the costs imposed on an applicant by the final priorities will be limited to paperwork burden related to preparing an application and that the benefits of implementing these final priorities will outweigh any costs incurred by the applicant.</P>
                <P>Of the impacts we estimate accruing to grantees or eligible entities, all are voluntary and related mostly to an increase in the available support for meeting existing obligations to provide statewide student assessment. Therefore, we do not believe that the final priorities will significantly impact small entities beyond the potential for receiving additional support from their SEA should the SEA receive a competitive grant from the Department.</P>
                <P>
                    <E T="03">Intergovernmental Review:</E>
                     This program is subject to Executive Order 12372 and the regulations in 34 CFR part 79. One of the objectives of the Executive order is to foster an intergovernmental partnership and a strengthened federalism. The Executive order relies on processes developed by State and local governments for coordination and review of proposed Federal financial assistance.
                </P>
                <P>This document provides early notification of our specific plans and actions for this program.</P>
                <P>
                    <E T="03">Accessible Format:</E>
                     Individuals with disabilities can obtain this document in an accessible format (
                    <E T="03">e.g.,</E>
                     braille, large print, audiotape, or compact disc) on request to the program contact person listed under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    .
                </P>
                <P>
                    <E T="03">Electronic Access to This Document:</E>
                     The official version of this document is the document published in the 
                    <E T="04">Federal Register</E>
                    . You may access the official edition of the 
                    <E T="04">Federal Register</E>
                     and the Code of Federal Regulations at 
                    <E T="03">www.govinfo.gov.</E>
                     At this site you can view this document, as well as all other documents of this Department published in the 
                    <E T="04">Federal Register</E>
                    , in text or Portable Document Format (PDF). To use PDF you must have Adobe Acrobat Reader, which is available free at the site.
                </P>
                <P>
                    You may also access documents of the Department published in the 
                    <E T="04">Federal Register</E>
                     by using the article search feature at 
                    <E T="03">www.federalregister.gov.</E>
                     Specifically, through the advanced search feature at this site, you can limit your search to documents published by the Department.
                </P>
                <SIG>
                    <NAME>Frank T. Brogan,</NAME>
                    <TITLE>Assistant Secretary for Elementary and Secondary Education.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09335 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4000-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF EDUCATION</AGENCY>
                <SUBJECT>Applications for New Awards; Competitive Grants for State Assessments Program</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Elementary and Secondary Education, Department of Education.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Education (Department) is issuing a notice inviting applications for fiscal year (FY) 2020 for the Competitive Grants for State Assessments program, Catalog of Federal Domestic Assistance (CFDA) number 84.368A. This notice relates to the approved information collection under OMB control number 1894-0006.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P/>
                    <P>
                        <E T="03">Applications Available:</E>
                         May 1, 2020.
                    </P>
                    <P>
                        <E T="03">Deadline for Notice of Intent to Apply:</E>
                         June 1, 2020.
                    </P>
                    <P>
                        <E T="03">Deadline for Transmittal of Applications:</E>
                         June 30, 2020.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        For the addresses for obtaining and submitting an application, please refer to our Common Instructions for Applicants to Department of Education Discretionary Grant Programs, published in the 
                        <E T="04">Federal Register</E>
                         on February 13, 2019 (84 FR 3768) and available at 
                        <E T="03">www.govinfo.gov/content/pkg/FR-2019-02-13/pdf/2019-02206.pdf.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Donald Peasley, Office of Elementary and Secondary Education, U.S. Department of Education, 400 Maryland Avenue SW, Room 3W106, Washington, DC 20202-6132. Telephone: (202) 453-7982. Email: 
                        <E T="03">ESEA.Assessment@ed.gov.</E>
                    </P>
                    <P>If you use a telecommunications device for the deaf (TDD) or a text telephone (TTY), call the Federal Relay Service (FRS), toll free, at 1-800-877-8339.</P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">
                    SUPPLEMENTARY INFORMATION:
                    <PRTPAGE P="25423"/>
                </HD>
                <HD SOURCE="HD1">Full Text of Announcement</HD>
                <HD SOURCE="HD1">I. Funding Opportunity Description</HD>
                <P>
                    <E T="03">Purpose of Program:</E>
                     The purpose of the Competitive Grants for State Assessments (CGSA) program is to enhance the quality of assessment instruments and assessment systems used by States for measuring the academic achievement of elementary and secondary school students.
                </P>
                <P>
                    <E T="03">Background:</E>
                     The purpose of the CGSA program is to support States' efforts to improve the technical quality of their assessment systems—both the quality of individual State assessments and the overall field of State assessments. In this competition, the Department is using three absolute priorities to encourage State educational agencies (SEAs) to consider new approaches to their State assessment systems. Two of these priorities, Absolute Priorities 1 and 2, build on the flexibility in section 1204 of the Elementary and Secondary Education Act of 1965, as amended by the Every Student Succeeds Act (ESEA), which establishes the Innovative Assessment Demonstration Authority (IADA).
                </P>
                <P>Given the national emergency related to the coronavirus disease 2019 (COVID-19), flexible approaches to education, including innovative, formative, and competency-based assessments such as those that these priorities will support, are essential for students, parents, and educators.</P>
                <P>IADA provides an opportunity for an SEA to pilot a new and innovative approach to assessments by first implementing it in a subset of schools or LEAs. Students in those schools would take the innovative assessment in place of the statewide assessment and their results would be included in the State's accountability system. Over a period of five years, the SEA would scale up the innovative assessment to eventually replace the statewide assessment. Absolute Priorities 1 and 2 encourage States to use CGSA funds to improve alignment with and support related work through the IADA.</P>
                <P>In 2018 and 2019, the Department published notices inviting applications (NIAs) for IADA and approved four SEAs through this authority. During the initial demonstration period (as defined in ESEA section 1204(b)(3) and 34 CFR 200.104(d)), up to seven SEAs may be approved for IADA. After the initial demonstration period, and upon meeting the requirements in ESEA section 1204(d), the Secretary may grant IADA flexibility to additional SEAs. Absolute Priority 2 in this CGSA competition aims to support SEAs that are planning to apply for the IADA authority and Absolute Priority 1 is for SEAs that are currently implementing an approved IADA plan. Approval for a CGSA grant for those SEAs planning to apply for IADA does not imply or infer that the Department will ultimately approve that SEA to implement its subsequent IADA proposal. However, the Department believes that the work to plan for IADA will strengthen the State's assessment system, even if the SEA is not ultimately granted IADA flexibility.</P>
                <P>
                    The Department is including a third priority in this competition for States that are neither planning to apply for nor implementing the IADA. Absolute Priority 3 is from the notice of final priorities published on August 8, 2016 in the 
                    <E T="04">Federal Register</E>
                     (81 FR 52341) (2016 NFP) and focuses on States that are developing innovative assessment item types and design approaches for their assessment systems. The Department believes that innovative item types and innovative assessment approaches can allow students to gain valuable experience by demonstrating complex work and critical thinking skills. Assessments can improve student learning by providing data that can support and inform instruction, particularly if the data are timely and targeted. As such, the Department believes it is important for applicants under this priority to focus their proposals on the complex tasks of developing, evaluating, and implementing new, innovative item types or developing approaches to transforming traditional summative assessment forms into more innovative forms.
                </P>
                <P>The Department intends to fund one or more projects under each of the absolute priorities and is also establishing different project periods and budget ranges for each absolute priority. In particular, the Department will make IADA planning grants under Absolute Priority 2 available for a project period not to exceed 18 months, with a maximum budget request of $500,000 or the minimum amount specified in section 1203(b)(1)(C) of the ESEA (whichever is greater for an individual State) for the total project period. Since a planning grant is intended to provide support only during the preparation of an IADA proposal, this will give an SEA or consortium of SEAs sufficient time to prepare an application for submission. Similarly, the Department anticipates that the budget request for a planning grant will be substantially lower than for an IADA implementation grant under Absolute Priority 1, both because the project period would be shorter and because the work would be more targeted, preliminary, and smaller in scope. Grants for IADA implementation under Absolute Priority 1 or for developing innovative assessment item types and design approaches under Absolute Priority 3 are available for up to 48 months with a maximum budget request of $3,000,000 for the total project period.</P>
                <P>Section 1203(b)(1)(A) of the ESEA identifies the six allowable uses of funds under CGSA. In brief, these uses include developing or improving assessments for English learners; developing or improving models to measure and assess student progress or student growth on assessments; developing or improving assessments for children with disabilities; allowing for collaboration with institutions of higher education or other organizations to improve the quality, validity, and reliability of State academic assessments; measuring student academic achievement using multiple measures of student academic achievement from multiple sources; and evaluating student academic achievement using comprehensive academic assessment instruments (such as performance and technology-based academic assessments, computer adaptive assessments, projects, or extended performance task assessments) that emphasize the mastery of standards and aligned competencies in a competency-based education model. An SEA, or consortium of SEAs, applying for funds under any of the absolute priorities in this CGSA competition must describe in its application how it is meeting one or more of these six allowable uses of funds.</P>
                <P>
                    <E T="03">Priorities:</E>
                     This competition includes three absolute priorities. Absolute Priorities 1 and 2 are from the Department's notice of final priorities published elsewhere in this issue of the 
                    <E T="04">Federal Register</E>
                    <E T="03">.</E>
                     Absolute Priority 3 is from the 2016 NFP.
                </P>
                <P>
                    <E T="03">Absolute Priorities:</E>
                     For FY 2020 and any subsequent year in which we make awards from the list of unfunded applications from this competition, these priorities are absolute priorities. Under 34 CFR 75.105(c)(3), we consider only applications that meet one of these priorities. The Secretary intends to create three separate funding slates, one for each absolute priority. The Secretary intends to award at least one grant under each absolute priority for which applications of sufficient quality are submitted. As a result, the Secretary may fund applications out of the overall rank order. Eligible applicants must specify which absolute priority they are applying under in the project abstract.
                    <PRTPAGE P="25424"/>
                </P>
                <P>These priorities are:</P>
                <P>
                    <E T="03">Absolute Priority 1: Implementing the Innovative Assessment Demonstration Authority (IADA)</E>
                    .
                </P>
                <P>Under this priority, SEAs must—</P>
                <P>(a) Be approved for IADA as of the date of their CGSA application. If applying as part of a consortium (or in partnership with other SEAs), each SEA must be approved for IADA as of the date of its CGSA application; and</P>
                <P>(b) Be implementing IADA, consistent with all requirements of section 1204 of the ESEA and applicable regulations as of the date of their CGSA application. If applying for CGSA as part of a consortium (or in partnership with other SEAs), each SEA must individually meet this requirement; and</P>
                <P>(c) Describe how the SEA will use CGSA funds to implement its approved IADA plan.</P>
                <P>
                    <E T="03">Absolute Priority 2: Planning to Apply for the Innovative Assessment Demonstration Authority (IADA)</E>
                    .
                </P>
                <P>Under this priority, SEAs must—</P>
                <P>(a) Provide an assurance by an authorized representative that the SEA intends to apply for flexibility under the IADA, when made available by the Department. If applying for CGSA as part of a consortium (or in partnership with other SEAs), each SEA must provide an assurance that it intends to apply for flexibility under the IADA;</P>
                <P>(b) If applying as a consortium of SEAs during the initial demonstration authority for IADA, not include more than four SEAs; and</P>
                <P>
                    (c) Describe their approach to innovative assessments in terms of the subjects and grades the SEA anticipates addressing, the proposed assessment design, proposed item types (
                    <E T="03">e.g.,</E>
                     item prototypes), and other relevant features.
                </P>
                <P>Absolute Priority 3: Developing Innovative Assessment Item Types and Design Approaches.</P>
                <P>Under this priority, SEAs must:</P>
                <P>(a) Develop, evaluate, and implement new, innovative item types for use in summative assessments in reading/language arts, mathematics, or science;</P>
                <P>(1) Development of innovative item types under paragraph (a) may include, for example, performance tasks; simulations; or interactive, multi-step, technology-rich items that can support competency-based assessments or portfolio projects;</P>
                <P>(2) Projects under this priority must be designed to develop new methods for collecting evidence about a student's knowledge and abilities and ensure the quality, validity, reliability, and fairness (such as by incorporating principles of universal design for learning) of the assessment and comparability of student data; or</P>
                <P>(b) Develop new approaches to transform traditional, end-of-year summative assessment forms with many items into a series of modular assessment forms, each with fewer items than the end-of-year summative assessment.</P>
                <P>(1) To respond to paragraph (b), applicants must develop modular assessment approaches which can be used to provide timely feedback to educators and parents as well as be combined to provide a valid, reliable, and fair summative assessment of individual students.</P>
                <P>(c) Applicants proposing projects under either paragraph (a) or (b) must provide a dissemination plan to share lessons learned and best practices such that their projects can serve as models and resources that can be shared with other States.</P>
                <P>
                    <E T="03">Application Requirement:</E>
                     For FY 2020, and any subsequent year in which we make awards from the list of unfunded applications from this competition, applicants must meet the following application requirement from section 1203(b)(1)(B) of the ESEA, which refers to section 1201(a)(2)(C) and (H)-(K) of the ESEA.
                </P>
                <P>
                    <E T="03">Uses of Funds:</E>
                     Applicants must demonstrate that their proposed uses of funds for CGSA would be to carry out one or more of the following activities:
                </P>
                <P>(a) Developing or improving assessments for English learners, including assessments of English language proficiency as required under section 1111(b)(2)(G) of the ESEA and academic assessments in languages other than English to meet the State's obligations under section 1111(b)(2)(F) of the ESEA.</P>
                <P>(b) Developing or improving models to measure and assess student progress or student growth on State assessments under section 1111(b)(2) of the ESEA and other assessments not required under section 1111(b)(2) of the ESEA.</P>
                <P>(c) Developing or improving assessments for children with disabilities, including alternate assessments aligned to alternate academic achievement standards for students with the most significant cognitive disabilities described in section 1111(b)(2)(D) of the ESEA, and using the principles of universal design for learning.</P>
                <P>(d) Allowing for collaboration with institutions of higher education, other research institutions, or other organizations to improve the quality, validity, and reliability of State academic assessments beyond the requirements for such assessments described in section 1111(b)(2) of the ESEA.</P>
                <P>(e) Measuring student academic achievement using multiple measures of student academic achievement from multiple sources.</P>
                <P>(f) Evaluating student academic achievement through the development of comprehensive academic assessment instruments (such as performance and technology-based academic assessments, computer adaptive assessments, projects, or extended performance task assessments) that emphasize the mastery of standards and aligned competencies in a competency-based education model.</P>
                <P>
                    <E T="03">Definitions:</E>
                     For FY 2020 and any subsequent year in which we make awards from the list of unfunded applications from this competition, the following definitions apply. The definitions of “Child with a disability,” “English learner,” and “Universal design for learning” are from section 8101 of the ESEA (20 U.S.C. 7801). The definitions of “Demonstrates a rationale,” “Logic model,” “Project component,” and “Relevant outcome” are from 34 CFR 77.1.
                </P>
                <P>
                    <E T="03">Child with a disability,</E>
                     as defined in section 602 of the Individuals with Disabilities Education Act, means—
                </P>
                <P>(A) A child—</P>
                <P>(i) With intellectual disabilities, hearing impairments (including deafness), speech or language impairments, visual impairments (including blindness), serious emotional disturbance (referred to in the IDEA as “emotional disturbance”), orthopedic impairments, autism, traumatic brain injury, other health impairments, or specific learning disabilities; and</P>
                <P>(ii) Who, by reason thereof, needs special education and related services.</P>
                <P>(B) The term “child with a disability” for a child aged 3 through 9 (or any subset of that age range, including ages three through five), may, at the discretion of the State and the local educational agency, include a child—</P>
                <P>(i) Experiencing developmental delays, as defined by the State and as measured by appropriate diagnostic instruments and procedures, in 1 or more of the following areas: physical development; cognitive development; communication development; social or emotional development; or adaptive development; and</P>
                <P>(ii) Who, by reason thereof, needs special education and related services.</P>
                <P>
                    <E T="03">Demonstrates a rationale</E>
                     means a key project component included in the project's logic model is informed by research or evaluation findings that suggest the project component is likely to improve relevant outcomes.
                    <PRTPAGE P="25425"/>
                </P>
                <P>
                    <E T="03">English learner,</E>
                     when used with respect to an individual, means an individual—
                </P>
                <P>(A) Who is aged 3 through 21;</P>
                <P>(B) Who is enrolled or preparing to enroll in an elementary school or secondary school;</P>
                <P>(C)(i) Who was not born in the United States or whose native language is a language other than English;</P>
                <P>(ii)(I) Who is a Native American or Alaska Native, or a native resident of the outlying areas; and</P>
                <P>(II) Who comes from an environment where a language other than English has had a significant impact on the individual's level of English language proficiency; or</P>
                <P>(iii) Who is migratory, whose native language is a language other than English, and who comes from an environment where a language other than English is dominant; and</P>
                <P>(D) Whose difficulties in speaking, reading, writing, or understanding the English language may be sufficient to deny the individual—</P>
                <P>(i) The ability to meet the challenging State academic standards;</P>
                <P>(ii) The ability to successfully achieve in classrooms where the language of instruction is English; or</P>
                <P>(iii) The opportunity to participate fully in society.</P>
                <P>
                    <E T="03">Logic model</E>
                     (also referred to as a theory of action) means a framework that identifies key project components of the proposed project (
                    <E T="03">i.e.,</E>
                     the active “ingredients” that are hypothesized to be critical to achieving the relevant outcomes) and describes the theoretical and operational relationships among the key project components and relevant outcomes.
                </P>
                <P>
                    <E T="03">Project component</E>
                     means an activity, strategy, intervention, process, product, practice, or policy included in a project. Evidence may pertain to an individual project component or to a combination of project components (
                    <E T="03">e.g.,</E>
                     training teachers on instructional practices for English learners and follow-on coaching for these teachers).
                </P>
                <P>
                    <E T="03">Relevant outcome</E>
                     means the student outcome(s) or other outcome(s) the key project component is designed to improve, consistent with the specific goals of the program.
                </P>
                <P>
                    <E T="03">Universal design for learning,</E>
                     as defined under section 103 of the Higher Education Act of 1965, as amended, means a scientifically valid framework for guiding educational practice that—
                </P>
                <P>(a) Provides flexibility in the ways information is presented, in the ways students respond or demonstrate knowledge and skills, and in the ways students are engaged; and</P>
                <P>
                    (b) Reduces barriers in instruction, provides appropriate accommodations, supports, and challenges, and maintains high achievement expectations for all students, including students with disabilities and students who are limited English proficient.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         For purposes of this notice, English learner and limited English proficient have the same meaning.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Applicable Regulations:</E>
                     (a) The Education Department General Administrative Regulations in 34 CFR parts 75, 77, 79, 81, 82, 84, 86, 97, 98, and 99. (b) The Office of Management and Budget Guidelines to Agencies on Governmentwide Debarment and Suspension (Nonprocurement) in 2 CFR part 180, as adopted and amended as regulations of the Department in 2 CFR part 3485. (c) The Uniform Administrative Requirements, Cost Principles, and Audit Requirements for Federal Awards in 2 CFR part 200, as adopted and amended as regulations of the Department in 2 CFR part 3474. (d) The 2016 NFP. (e) The notice of final priorities published elsewhere in this issue of the 
                    <E T="04">Federal Register</E>
                    . (f) The IADA regulations in 34 CFR 200.104-200.108.
                </P>
                <P>
                    <E T="03">Program Authority:</E>
                     Section 1203(b)(1) of the ESEA (20 U.S.C. 6363(b)(1)).
                </P>
                <HD SOURCE="HD1">II. Award Information</HD>
                <P>
                    <E T="03">Type of Award:</E>
                     Discretionary grants.
                </P>
                <P>
                    <E T="03">Estimated Available Funds:</E>
                     $12,327,000.
                </P>
                <P>Contingent upon the availability of funds and the quality of applications, we may make additional awards in FY 2021 (or later) from the list of unfunded applications from this competition.</P>
                <P>
                    <E T="03">Estimated Range of Awards for the Project Period:</E>
                </P>
                <P>(a) Absolute Priority 1: Implementing the IADA: $1,000,000 to $3,000,000.</P>
                <P>(b) Absolute Priority 2: Planning to Apply for the IADA: $100,000 to $500,000.</P>
                <P>(c) Absolute Priority 3: Developing Innovative Item Types and Design Approaches: $1,000,000 to $3,000,000.</P>
                <P>
                    <E T="03">Estimated Average Size of Awards for the Project Period:</E>
                </P>
                <P>(a) Absolute Priority 1: Implementing the IADA: $2,500,000.</P>
                <P>(b) Absolute Priority 2: Planning to Apply for the IADA: $300,000.</P>
                <P>(c) Absolute Priority 3: Developing Innovative Item Types and Design Approaches: $2,500,000.</P>
                <P>
                    <E T="03">Maximum Size of Awards for the Project Period:</E>
                     We will not make an award exceeding these amounts:
                </P>
                <P>(a) Absolute Priority 1: Implementing the IADA: $3,000,000.</P>
                <P>(b) Absolute Priority 2: Planning to Apply for the IADA: $500,000 or the State statutory minimum award amount as specified in section 1203(b)(1)(C) of the ESEA if greater than $500,000.</P>
                <P>(c) Absolute Priority 3: Developing Innovative Item Types and Design Approaches: $3,000,000.</P>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>The Department will not make an award under any of the absolute priorities for less than the amount specified in section 1203(b)(1)(C) of the ESEA.</P>
                </NOTE>
                <P>
                    <E T="03">Estimated Number of Awards:</E>
                </P>
                <P>(a) Absolute Priority 1: Implementing the IADA: 1-3.</P>
                <P>(b) Absolute Priority 2: Planning to Apply for the IADA: 1-3.</P>
                <P>(c) Absolute Priority 3: Developing Innovative Item Types and Design Approaches: 1-3.</P>
                <NOTE>
                    <HD SOURCE="HED">Note:</HD>
                    <P>The Department is not bound by any estimates in this notice.</P>
                </NOTE>
                <P>
                    <E T="03">Project Period:</E>
                </P>
                <P>(a) Absolute Priority 1: Implementing the IADA: up to 48 months.</P>
                <P>(b) Absolute Priority 2: Planning to Apply for the IADA: up to 18 months.</P>
                <P>(c) Absolute Priority 3: Developing Innovative Item Types and Design Approaches: up to 48 months.</P>
                <HD SOURCE="HD1">III. Eligibility Information</HD>
                <P>
                    1. 
                    <E T="03">Eligible Applicants:</E>
                     SEAs, as defined in section 8101(49) of the ESEA, of the 50 States, the District of Columbia, and the Commonwealth of Puerto Rico, and consortia of such SEAs.
                </P>
                <P>
                    2. 
                    <E T="03">Cost Sharing or Matching:</E>
                     This competition does not require cost sharing or matching.
                </P>
                <P>
                    3. 
                    <E T="03">Subgrantees:</E>
                     A grantee under this competition may not award subgrants to entities to directly carry out project activities described in its application.
                </P>
                <P>
                    4. 
                    <E T="03">Other:</E>
                     An application from a consortium of SEAs must designate one SEA as the fiscal agent.
                </P>
                <HD SOURCE="HD1">IV. Application and Submission Information</HD>
                <P>
                    1. 
                    <E T="03">Application Submission Instructions:</E>
                     Applicants are required to follow the Common Instructions for Applicants to Department of Education Discretionary Grant Programs, published in the 
                    <E T="04">Federal Register</E>
                     on February 13, 2019 (84 FR 3768) and available at 
                    <E T="03">www.govinfo.gov/content/pkg/FR-2019-02-13/pdf/2019-02206.pdf,</E>
                     which contain requirements and information on how to submit an application.
                </P>
                <P>
                    <E T="03">Grants.gov</E>
                     has relaxed the requirement for applicants to have an active registration in the System for Award Management (SAM) in order to apply for funding during the COVID-19 pandemic. An applicant that does not have an active SAM registration can still register with 
                    <E T="03">Grants.gov</E>
                    , but must contact the 
                    <E T="03">Grants.gov</E>
                     Support Desk, toll-free, at 1-800-518-4726, in order to take advantage of this flexibility.
                    <PRTPAGE P="25426"/>
                </P>
                <P>
                    2. 
                    <E T="03">Submission of Proprietary Information:</E>
                     Given the types of projects that may be proposed in applications for the CGSA, your application may include business information that you consider proprietary. In 34 CFR 5.11, we define “business information” and describe the process we use in determining whether any of that information is proprietary and, thus, protected from disclosure under Exemption 4 of the Freedom of Information Act (5 U.S.C. 552, as amended). Because we plan to make all application materials public, you may wish to request confidentiality of business information.
                </P>
                <P>Consistent with Executive Order 12600, please designate in your application any information that you believe is exempt from disclosure under Exemption 4. In the appropriate Appendix section of your application, under “Other Attachments Form,” please list the page number or numbers on which we can find this information. For additional information please see 34 CFR 5.11(c).</P>
                <P>
                    3. 
                    <E T="03">Intergovernmental Review:</E>
                     This competition is subject to Executive Order 12372 and the regulations in 34 CFR part 79. However, under 34 CFR 79.8(a), we waive intergovernmental review in order to make awards by the end of FY 2020.
                </P>
                <P>
                    4. 
                    <E T="03">Funding Restrictions:</E>
                     We reference regulations outlining funding restrictions in the 
                    <E T="03">Applicable Regulations</E>
                     section of this notice.
                </P>
                <P>
                    5. 
                    <E T="03">Recommended Page Limit:</E>
                     The project narrative is where you, the applicant, address the selection criteria that reviewers use to evaluate your application. We recommend that you (1) limit the application narrative to the equivalent of no more than 65 pages and (2) use the following standards:
                </P>
                <P>• A “page” is 8.5” x 11”, on one side only, with 1” margins at the top, bottom, and both sides.</P>
                <P>• Double space (no more than three lines per vertical inch) all text in the application narrative, including titles, headings, footnotes, quotations, references, and captions, as well as all text in charts, tables, figures, and graphs.</P>
                <P>• Use a font that is either 12 point or larger or no smaller than 10 pitch (characters per inch).</P>
                <P>• Use one of the following fonts: Times New Roman, Courier, Courier New, or Arial.</P>
                <P>The recommended page limit applies to the project narrative, including the table of contents, which must include a discussion of how the application meets one of the absolute priorities; and how well the application addresses each of the selection criteria. The recommended page limit also applies to any attachments to the project narrative other than the items mentioned in Part 6 of the application package, including the references/bibliography. In other words, we recommend that the entirety of the project narrative, including the aforementioned discussion and any attachments to the project narrative, be limited to the equivalent of no more than 65 pages. The only allowable attachments other than those included in the project narrative are outlined in Part 6, “Other Attachments Forms,” in the application package.</P>
                <P>The recommended 65-page limit, or its equivalent, does not apply to the following sections of an application: Part 1 (including the response regarding research activities involving human subjects); Part 2 (budget information); Part 3 (two-page project abstract); Part 5 (the budget narrative); Part 6 (memoranda of understanding or other binding agreement, if applicable; copy of applicant's indirect cost rate agreement; letters of commitment and support from collaborating SEAs and organizations; other attachments forms, including, if applicable, references/bibliography for the project narrative and individual résumés for project director(s) and key personnel); and Part 7 (standard assurances and certifications). Applicants are encouraged to limit each résumé to no more than five pages.</P>
                <P>Please note, hyperlinks should not be used in an application. Reviewers will be instructed not to follow hyperlinks if included. Applicants are encouraged to submit applications that meet the page limit following the standards outlined in this section rather than submitting applications that are the equivalent of the page limit applying other standards.</P>
                <P>
                    6. 
                    <E T="03">Notice of Intent to Apply:</E>
                </P>
                <P>
                    We are better able to develop a more efficient process for reviewing grant applications if we have a better understanding of the number of applicants that intend to apply for funding under this competition. Therefore, we strongly encourage each potential applicant to notify us of the applicant's intent to submit an application for funding and which absolute priority the applicant intends to address. This notification should be brief and identify the SEA applicant and, in the case of consortia applicants, the SEA that it will designate as the fiscal agent for an award. Submit this notification by email to 
                    <E T="03">ESEA.Assessment@ed.gov</E>
                     with “Intent to Apply” in the email subject line or mail to Donald Peasley, U.S. Department of Education, 400 Maryland Avenue SW, room 3W106, Washington, DC 20202-6132. Applicants that do not provide this notification may still apply for funding.
                </P>
                <HD SOURCE="HD1">V. Application Review Information</HD>
                <P>
                    1. 
                    <E T="03">Selection Criteria:</E>
                     The selection criteria for this competition are from 34 CFR 75.210. We will award up to 100 points to an application under the selection criteria; the total possible points for each selection criterion are noted in parentheses.
                </P>
                <P>
                    (a) 
                    <E T="03">Need for project</E>
                     (up to 10 points).
                </P>
                <P>The Secretary considers the need for the proposed project. In determining the need for the proposed project, the Secretary considers the extent to which specific gaps or weaknesses in services, infrastructure, or opportunities have been identified and will be addressed by the proposed project, including the nature and magnitude of those gaps or weaknesses.</P>
                <P>
                    (b) 
                    <E T="03">Significance</E>
                     (up to 10 points).
                </P>
                <P>The Secretary considers the significance of the proposed project. In determining the significance of the proposed project, the Secretary considers the extent to which the proposed project is likely to build local capacity to provide, improve, or expand services that address the needs of the target population.</P>
                <P>
                    (c) 
                    <E T="03">Quality of the project design</E>
                     (up to 20 points).
                </P>
                <P>The Secretary considers the quality of the design of the proposed project. In determining the quality of the design of the proposed project, the Secretary considers the following factors:</P>
                <P>(1) The extent to which the goals, objectives, and outcomes to be achieved by the proposed project are clearly specified and measurable. (5 points)</P>
                <P>(2) The extent to which the proposed project will establish linkages with other appropriate agencies and organizations providing services to the target population. (5 points)</P>
                <P>(3) The extent to which the proposed project is part of a comprehensive effort to improve teaching and learning and support rigorous academic standards for students. (5 points)</P>
                <P>(4) The extent to which the proposed project demonstrates a rationale (as defined in this notice). (5 points)</P>
                <P>
                    (d) 
                    <E T="03">Quality of project services</E>
                     (up to 25 points).
                </P>
                <P>The Secretary considers the quality of the services to be provided by the proposed project. In determining the quality of the services to be provided by the proposed project, the Secretary considers:</P>
                <P>
                    (1) The quality and sufficiency of strategies for ensuring equal access and treatment for eligible project participants who are members of groups 
                    <PRTPAGE P="25427"/>
                    that have traditionally been underrepresented based on race, color, national origin, gender, age, or disability. (10 points)
                </P>
                <P>(2) The extent to which the services to be provided by the proposed project are appropriate to the needs of the intended recipients or beneficiaries of those services. (10 points)</P>
                <P>(3) The extent to which the training or professional development services to be provided by the proposed project are of sufficient quality, intensity, and duration to lead to improvements in practice among the recipients of those services. (5 points)</P>
                <P>
                    (e) 
                    <E T="03">Adequacy of resources</E>
                     (up to 10 points).
                </P>
                <P>The Secretary considers the adequacy of resources for the proposed project. In determining the adequacy of resources for the proposed project, the Secretary considers the extent to which the costs are reasonable in relation to the number of persons to be served and to the anticipated results and benefits.</P>
                <P>
                    (f) 
                    <E T="03">Quality of the management plan</E>
                     (up to 20 points).
                </P>
                <P>The Secretary considers the quality of the management plan for the proposed project. In determining the quality of the management plan for the proposed project, the Secretary considers:</P>
                <P>(1) The adequacy of the management plan to achieve the objectives of the proposed project on time and within budget, including clearly defined responsibilities, timelines, and milestones for accomplishing project tasks. (10 points)</P>
                <P>(2) The extent to which the time commitments of the project director and principal investigator and other key project personnel are appropriate and adequate to meet the objectives of the proposed project. (10 points)</P>
                <P>
                    (g) 
                    <E T="03">Quality of the project evaluation</E>
                     (up to 5 points).
                </P>
                <P>The Secretary considers the quality of the evaluation to be conducted of the proposed project. In determining the quality of the evaluation, the Secretary considers the extent to which the methods of evaluation are thorough, feasible, and appropriate to the goals, objectives, and outcomes of the proposed project.</P>
                <P>
                    2. 
                    <E T="03">Review and Selection Process:</E>
                     We remind potential applicants that in reviewing applications in any discretionary grant competition, the Secretary may consider, under 34 CFR 75.217(d)(3), the past performance of the applicant in carrying out a previous award, such as the applicant's use of funds, achievement of project objectives, and compliance with grant conditions. The Secretary may also consider whether the applicant failed to submit a timely performance report or submitted a report of unacceptable quality.
                </P>
                <P>In addition, in making a competitive grant award, the Secretary requires various assurances, including those applicable to Federal civil rights laws that prohibit discrimination in programs or activities receiving Federal financial assistance from the Department (34 CFR 100.4, 104.5, 106.4, 108.8, and 110.23).</P>
                <P>
                    3. 
                    <E T="03">Risk Assessment and Specific Conditions:</E>
                     Consistent with 2 CFR 200.205, before awarding grants under this competition the Department conducts a review of the risks posed by applicants. Under 2 CFR 3474.10, the Secretary may impose specific conditions and, in appropriate circumstances, high-risk conditions on a grant if the applicant or grantee is not financially stable; has a history of unsatisfactory performance; has a financial or other management system that does not meet the standards in 2 CFR part 200, subpart D; has not fulfilled the conditions of a prior grant; or is otherwise not responsible.
                </P>
                <P>
                    4. 
                    <E T="03">Integrity and Performance System:</E>
                     If you are selected under this competition to receive an award that over the course of the project period may exceed the simplified acquisition threshold (currently $150,000), under 2 CFR 200.205(a)(2), we must make a judgment about your integrity, business ethics, and record of performance under Federal awards—that is, the risk posed by you as an applicant—before we make an award. In doing so, we must consider any information about you that is in the integrity and performance system (currently referred to as the Federal Awardee Performance and Integrity Information System (FAPIIS)), accessible through SAM. You may review and comment on any information about yourself that a Federal agency previously entered and that is currently in FAPIIS.
                </P>
                <P>Please note that, if the total value of your currently active grants, cooperative agreements, and procurement contracts from the Federal Government exceeds $10,000,000, the reporting requirements in 2 CFR part 200, Appendix XII, require you to report certain integrity information to FAPIIS semiannually. Please review the requirements in 2 CFR part 200, Appendix XII, if this grant plus all the other Federal funds you receive exceed $10,000,000.</P>
                <HD SOURCE="HD1">VI. Award Administration Information</HD>
                <P>
                    1. 
                    <E T="03">Award Notices:</E>
                     If your application is successful, we notify your U.S. Representative and U.S. Senators and send you a Grant Award Notification (GAN); or we may send you an email containing a link to access an electronic version of your GAN. We may notify you informally, also.
                </P>
                <P>If your application is not evaluated or not selected for funding, we notify you.</P>
                <P>
                    2. 
                    <E T="03">Administrative and National Policy Requirements:</E>
                     We identify administrative and national policy requirements in the application package and reference these and other requirements in the 
                    <E T="03">Applicable Regulations</E>
                     section of this notice.
                </P>
                <P>
                    We reference the regulations outlining the terms and conditions of an award in the 
                    <E T="03">Applicable Regulations</E>
                     section of this notice and include these and other specific conditions in the GAN. The GAN also incorporates your approved application as part of your binding commitments under the grant.
                </P>
                <P>
                    3. 
                    <E T="03">Open Licensing Requirements:</E>
                     Unless an exception applies, if you are awarded a grant under this competition, you will be required to openly license to the public grant deliverables created in whole, or in part, with Department grant funds. When the deliverable consists of modifications to pre-existing works, the license extends only to those modifications that can be separately identified and only to the extent that open licensing is permitted under the terms of any licenses or other legal restrictions on the use of pre-existing works. Additionally, a grantee or subgrantee that is awarded competitive grant funds must have a plan to disseminate these public grant deliverables. This dissemination plan can be developed and submitted after your application has been reviewed and selected for funding. For additional information on the open licensing requirements please refer to 2 CFR 3474.20.
                </P>
                <P>
                    4. 
                    <E T="03">Reporting:</E>
                     (a) If you apply for a grant under this competition, you must ensure that you have in place the necessary processes and systems to comply with the reporting requirements in 2 CFR part 170 should you receive funding under the competition. This does not apply if you have an exception under 2 CFR 170.110(b).
                </P>
                <P>
                    (b) At the end of your project period, you must submit a final performance report, including financial information, as directed by the Secretary. If you receive a multiyear award, you must submit an annual performance report that provides the most current performance and financial expenditure information as directed by the Secretary under 34 CFR 75.118. The Secretary may also require more frequent performance reports under 34 CFR 75.720(c). For specific requirements on reporting, please go to 
                    <E T="03">
                        www.ed.gov/
                        <PRTPAGE P="25428"/>
                        fund/grant/apply/appforms/appforms.html.
                    </E>
                </P>
                <P>(c) Under 34 CFR 75.250(b), the Secretary may provide a grantee with additional funding for data collection analysis and reporting. In this case the Secretary establishes a data collection period.</P>
                <P>
                    5. 
                    <E T="03">Performance Measures:</E>
                     Under the Government Performance and Results Act of 1993, the Department has developed three measures to evaluate the overall effectiveness of the CGSA program:
                </P>
                <P>(1) The percentage of grantees, for each grant cycle, that demonstrate significant progress towards improving, developing, or implementing a new model for measuring the achievement of students.</P>
                <P>(2) The percentage of grantees, for each grant cycle, that demonstrate collaboration with institutions of higher education, other research institutions, or other organizations to develop or improve State assessments.</P>
                <P>(3) The percentage of grantees that, at least three times during the period of their grants, make available to SEA staff in non-participating States and to assessment researchers information on findings resulting from the CGSA program through presentations at national conferences, publications in refereed journals, or other products disseminated to the assessment community.</P>
                <P>Grantees will be expected to include in their interim and final performance reports information about the accomplishments of their projects.</P>
                <HD SOURCE="HD1">VII. Other Information</HD>
                <P>
                    <E T="03">Accessible Format:</E>
                     Individuals with disabilities can obtain this document and a copy of the application package in an accessible format (
                    <E T="03">e.g.,</E>
                     braille, large print, audiotape, or compact disc) on request to the program contact person listed under 
                    <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                    .
                </P>
                <P>
                    <E T="03">Electronic Access to This Document:</E>
                     The official version of this document is the document published in the 
                    <E T="04">Federal Register</E>
                    . You may access the official edition of the 
                    <E T="04">Federal Register</E>
                     and the Code of Federal Regulations at 
                    <E T="03">www.govinfo.gov.</E>
                     At this site you can view this document, as well as all other documents of this Department published in the 
                    <E T="04">Federal Register,</E>
                     in text or Portable Document Format (PDF). To use PDF you must have Adobe Acrobat Reader, which is available free at the site.
                </P>
                <P>
                    You may also access documents of the Department published in the 
                    <E T="04">Federal Register</E>
                     by using the article search feature at: 
                    <E T="03">www.federalregister.gov.</E>
                     Specifically, through the advanced search feature at this site, you can limit your search to documents published by the Department.
                </P>
                <SIG>
                    <NAME>Frank Brogan,</NAME>
                    <TITLE>Assistant Secretary for Elementary and Secondary Education.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09336 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4000-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF ENERGY</AGENCY>
                <SUBJECT>Notice of Orders Issued Under Section 3 of the Natural Gas Act During March 2020</SUBJECT>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s200,xs90">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1">FE Docket Nos.</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">OVINTIV MARKETING INC. </ENT>
                        <ENT>20-08-NG; 19-47-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">IRVING OIL COMMERCIAL GP</ENT>
                        <ENT>20-18-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">NORTHWEST NATURAL GAS COMPANY</ENT>
                        <ENT>20-19-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SHELL NA LNG LLC</ENT>
                        <ENT>20-15-LNG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">POWEREX CORP</ENT>
                        <ENT>20-16-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">CENTRAL LOMAS DE REAL, S.A. DE C.V</ENT>
                        <ENT>20-17-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">GOLDEN PASS LNG TERMINAL LLC) (Formerly GOLDEN PASS PRODUCTS LLC</ENT>
                        <ENT>12-88-LNG; 12-156-LNG; 18-06-LNG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PEMCORP, S.A.P.I. DE C.V</ENT>
                        <ENT>20-21-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ENGELHART CTP (US) LLC</ENT>
                        <ENT>20-25-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SHELL ENERGY NORTH AMERICA (US) L.P</ENT>
                        <ENT>20-24-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">MERRILL LYNCH COMMODITIES CANADA, ULC</ENT>
                        <ENT>20-26-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">TUSCAROWA TRADING, LLC</ENT>
                        <ENT>19-72-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">ALTAGAS LTD</ENT>
                        <ENT>19-83-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">PROMETHEUS ENERGY GROUP INC</ENT>
                        <ENT>20-27-LNG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">IRVING OIL COMMERCIAL GP</ENT>
                        <ENT>20-18-NG</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">SANTA FE GAS</ENT>
                        <ENT>20-29-NG</ENT>
                    </ROW>
                </GPOTABLE>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Fossil Energy, Department of Energy.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of orders.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The Office of Fossil Energy (FE) of the Department of Energy gives notice that during March 2020, it issued orders granting authority to import and export natural gas, to import and export liquefied natural gas (LNG), to vacate authorization, to transfer authorization, request for extension of export commencement deadlines, and errata. These orders are summarized in the attached appendix and may be found on the FE website at 
                        <E T="03">https://www.energy.gov/fe/listing-doefe-authorizationsorders-issued-2020.</E>
                    </P>
                    <P>They are also available for inspection and copying in the U.S. Department of Energy (FE-34), Division of Natural Gas Regulation, Office of Regulation, Analysis, and Engagement, Office of Fossil Energy, Docket Room 3E-033, Forrestal Building, 1000 Independence Avenue SW, Washington, DC 20585, (202) 586-9387. The Docket Room is open between the hours of 8:00 a.m. and 4:30 p.m., Monday through Friday, except Federal holidays.</P>
                </SUM>
                <SIG>
                    <DATED>Signed in Washington, DC, on April 27, 2020.</DATED>
                    <NAME>Amy Sweeney,</NAME>
                    <TITLE>Director, Office of Regulation, Analysis, and Engagement, Office of Oil and Natural Gas.</TITLE>
                </SIG>
                <HD SOURCE="HD1">Appendix</HD>
                <GPOTABLE COLS="5" OPTS="L2,p1,8/9,i1" CDEF="xs54,12,xs54,r75,r100">
                    <TTITLE>DOE/FE Orders Granting Import/Export Authorizations</TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">4507; 4382-A</ENT>
                        <ENT>03/02/20</ENT>
                        <ENT>20-08-NG; 19-47-NG</ENT>
                        <ENT>Ovintiv Marketing Inc.</ENT>
                        <ENT>Order 4507 granting blanket authority to import natural gas from Canada, and vacating prior authorization (Order 4382-A)</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25429"/>
                        <ENT I="01">4509</ENT>
                        <ENT>03/02/20</ENT>
                        <ENT>20-18-NG</ENT>
                        <ENT>Irving Oil Commercial GP</ENT>
                        <ENT>Order 4509 granting blanket authority to export natural gas to Canada.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4510</ENT>
                        <ENT>03/02/20</ENT>
                        <ENT>20-19-NG</ENT>
                        <ENT>Northwest Natural Gas Company</ENT>
                        <ENT>Order 4510 granting blanket authority to import/export natural gas from/to Canada.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4511</ENT>
                        <ENT>03/02/20</ENT>
                        <ENT>20-15-LNG</ENT>
                        <ENT>Shell NA LNG LLC</ENT>
                        <ENT>Order 4511 granting blanket authority to import LNG from various international sources by vessel.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4512</ENT>
                        <ENT>03/02/20</ENT>
                        <ENT>20-16-NG</ENT>
                        <ENT>Powerex Corp</ENT>
                        <ENT>Order 4512 granting blanket authority to import/export natural gas from/to Canada/Mexico.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4513</ENT>
                        <ENT>03/02/20</ENT>
                        <ENT>20-17-NG</ENT>
                        <ENT>Central Lomas de Real, S.A. de C.V</ENT>
                        <ENT>Order 4513 granting blanket authority to import/export natural gas from/to Mexico.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3147-A; 3978-B; 4146-A</ENT>
                        <ENT>03/04/20</ENT>
                        <ENT>12-88-LNG; 12-156-LNG; 18-06-LNG</ENT>
                        <ENT>Golden Pass LNG Terminal LLC (Formerly Golden Pass Products LLC)</ENT>
                        <ENT>Order 3147-A granting request to transfer authorizations and responding to change in control (Orders 3978-B and 4146-A).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4514</ENT>
                        <ENT>03/13/20</ENT>
                        <ENT>20-21-NG</ENT>
                        <ENT>Pemcorp, S.A.P.I. de C.V</ENT>
                        <ENT>Order 4514 granting blanket authority to export natural gas to Mexico.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4515</ENT>
                        <ENT>03/13/20</ENT>
                        <ENT>20-25-NG</ENT>
                        <ENT>Engelhart CTP (US) LLC</ENT>
                        <ENT>Order 4515 granting blanket authority to import/export natural gas from/to Canada/Mexico.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4516</ENT>
                        <ENT>03/13/20</ENT>
                        <ENT>20-24-NG</ENT>
                        <ENT>Shell Energy North America (US), L.P</ENT>
                        <ENT>Order 4516 granting blanket authority to import/export natural gas from/to Canada/Mexico, to import LNG from various international sources by vessel, and to import/export LNG from/to Canada/Mexico by vessel.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4517</ENT>
                        <ENT>03/13/20</ENT>
                        <ENT>20-26-NG</ENT>
                        <ENT>Merrill Lynch Commodities Canada, ULC</ENT>
                        <ENT>Order 4517 granting blanket authority to export natural gas to Canada.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4404-A</ENT>
                        <ENT>03/13/20</ENT>
                        <ENT>19-72-NG</ENT>
                        <ENT>Tuscarowa Trading, LLC</ENT>
                        <ENT>Order 4501 granting blanket authority to import natural gas from Canada.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4437-A</ENT>
                        <ENT>03/13/20</ENT>
                        <ENT>19-83-NG</ENT>
                        <ENT>Altagas Ltd.</ENT>
                        <ENT>Order 4437-A vacating blanket authority to import/export natural gas from/to Canada.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">3147-B; 3978-C</ENT>
                        <ENT>03/24/20</ENT>
                        <ENT>12-88-LNG; 12-156-LNG</ENT>
                        <ENT>Golden Pass LNG Terminal LLC</ENT>
                        <ENT>Orders 3147-B and 3978-C granting request for extension of export commencement deadlines.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4518</ENT>
                        <ENT>03/25/20</ENT>
                        <ENT>20-27-LNG</ENT>
                        <ENT>Prometheus Energy Group Inc</ENT>
                        <ENT>Order 4518 granting blanket authority to import/export LNG from/to Canada/Mexico by truck, to export LNG to Canada/Mexico by vessel, and to import LNG from various international sources by vessel.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Errata 4509-A</ENT>
                        <ENT>03/25/20</ENT>
                        <ENT>20-18-NG</ENT>
                        <ENT>Irving Oil Commercial GP</ENT>
                        <ENT>Order 4509 Errata Notice.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">4522</ENT>
                        <ENT>03/31/20</ENT>
                        <ENT>20-29-NG</ENT>
                        <ENT>Santa Fe Gas</ENT>
                        <ENT>Order 4522 granting blanket authority to import/export natural gas from/to Mexico.</ENT>
                    </ROW>
                </GPOTABLE>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09271 Filed 4-30-20; 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</SUBJECT>
                <P>Take notice that the Commission has received the following Natural Gas Pipeline Rate and Refund Report filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     RP20-726-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     East Tennessee Natural Gas, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     2018-2019 Cashout Report of East Tennessee Natural Gas, LLC under RP20-726.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     3/30/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200330-5447.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/1/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     RP18-1126-004.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Transcontinental Gas Pipe Line Company, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing RP18-1126 Stipulation and Agreement Tariff Record Filing to be effective 3/1/2019.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/23/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200423-5163.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/5/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     RP20-800-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Southern Natural Gas Company, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing Abandon Transco X-Rate Schedules Compliance Filing to be effective 6/1/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/23/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200423-5023.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/5/20.
                </P>
                <P>The filings are accessible in the Commission's eLibrary system by clicking on the links or querying the docket number.</P>
                <P>Any person desiring to intervene or protest in any of the above proceedings must file in accordance with Rules 211 and 214 of the Commission's Regulations (18 CFR 385.211 and 385.214) on or before 5:00 p.m. Eastern time on the specified date(s). 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>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Nathaniel J. Davis, Sr.,</NAME>
                    <TITLE>Deputy Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09318 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="25430"/>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <SUBJECT>Combined Notice of Filings #1</SUBJECT>
                <P>Take notice that the Commission received the following electric corporate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EC20-57-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Little Bear Solar 1, LLC, Little Bear Solar 3, LLC, Little Bear Solar 4, LLC, Little Bear Solar 5, LLC, Little Bear Master Tenant, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application for Authorization Under Section 203 of the Federal Power Act, et al. of Little Bear Solar 1, LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200424-5313.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/15/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     EC20-58-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Bishop Hill Energy LLC, Blue Sky East, LLC, California Ridge Wind Energy LLC, Canandaigua Power Partners, LLC, Canandaigua Power Partners II, LLC, Erie Wind, LLC, Evergreen Gen Lead, LLC, Evergreen Wind Power, LLC, Evergreen Wind Power III, LLC, Imperial Valley Solar 1, LLC, Niagara Wind Power, LLC, Prairie Breeze Wind Energy LLC, Regulus Solar, LLC, Stetson Holdings, LLC, Stetson Wind II, LLC, Vermont Wind, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application for Authorization Under Section 203 of the Federal Power Act, et al. of Bishop Hill Energy LLC, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200424-5318.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/15/20.
                </P>
                <P>Take notice that the Commission received the following electric rate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER10-2718-035; ER10-2719-035; ER17-424-006.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     East Coast Power Linden Holding, L.L.C., Cogen Technologies Linden Venture, L.P., Footprint Power Salem Harbor Development.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of Cogen Technologies Linden Venture, L.P., et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200424-5307.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/15/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER11-3417-013; ER19-1073-003; ER10-2895-020; ER14-1964-011; ER16-287-006; ER12-161-020; ER13-2143-013; ER10-3167-012; ER13-203-012; ER12-2068-016; ER17-482-005; ER19-1074-003; ER11-3942-021; ER20-1447-001; ER10-2917-020; ER19-1075-003; ER19-529-003; ER19-2429-002; ER13-1613-013; ER12-645-021; ER10-2460-016; ER10-2461-017; ER10-2918-021; ER10-2920-020; ER12-682-017; ER10-2463-016; ER11-2201-020; ER11-3941-018; ER10-2921-020; ER10-2922-020; ER13-1139-020; ER13-1346-012; ER13-17-014; ER14-25-016; ER14-2630-013; ER10-2966-020; ER11-2383-015; ER12-1311-016; ER10-2466-017; ER11-4029-016; ER19-1076-003.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Brookfield Asset Management, Inc., Alta Wind VIII, LLC, Bear Swamp Power Company LLC, BIF II Safe Harbor Holdings LLC, BIF III Holtwood LLC, Black Bear Development Holdings, LLC, Black Bear Hydro Partners, LLC, Black Bear SO, LLC, BREG Aggregator LLC, Brookfield Energy Marketing Inc., Brookfield Energy Marketing LP, Brookfield Energy Marketing US LLC, Brookfield Power Piney &amp; Deep Creek LLC, Brookfield Renewable Energy Marketing US LLC, Brookfield Renewable Trading and Marketing LP, Brookfield Smoky Mountain Hydropower LLC, Brookfield White Pine Hydro LLC, Carr Street Generating Station, L.P., Erie Boulevard Hydropower, L.P., Granite Reliable Power, LLC, Great Lakes Hydro America, LLC, Hawks Nest Hydro LLC, Mesa Wind Power Corporation, Rumford Falls Hydro LLC, Safe Harbor Water Power Corporation, Windstar Energy, LLC, Bishop Hill Energy LLC, Blue Sky East, LLC, California Ridge Wind Energy LLC, Canandaigua Power Partners, LLC, Canandaigua Power Partners II, LLC, Erie Wind, LLC, Evergreen Wind Power, LLC, Evergreen Wind Power III, LLC, Imperial Valley Solar 1, LLC, Niagara Wind Power, LLC, Prairie Breeze Wind Energy LLC, Regulus Solar, LLC, Stetson Holdings, LLC, Stetson Wind II, LLC, Vermont Wind, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notice of Non-Material Change in Status of the Brookfield Asset Management, Inc. Sellers, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     2020.0424-5320
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/15/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER19-391-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Panda Hummel Station LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Compliance filing: Compliance 2020 information updated to be effective N/A.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200424-5268.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/15/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1241-002.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Pixelle Androscoggin LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Amended Tariff to be effective 4/25/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5006.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1242-002.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Pixelle Energy Services LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Amended Tariff to be effective 4/27/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5016.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1654-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Public Service Company of Colorado.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Cancellation: 2020-04-24_PSCo-MEAN-NITS-246-NOC-0.1.0 to be effective 6/23/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200424-5282.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/15/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1655-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Talen Energy Marketing, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: Market-Based Rate Tariff Revisions to be effective 4/28/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5117.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1656-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     MidAmerican Energy Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: Joint Pricing Zone Revenue Allocation Agreement-3rd Revised to be effective 6/1/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5133.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1657-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mechanicsville Solar, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Baseline eTariff Filing: baseline new to be effective 6/1/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5141.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1658-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Midcontinent Independent System Operator, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: 2020-04-27_MRES as agent for Atlantic and Pella Revisions to Sch 7,8,9 to be effective 6/1/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5148.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1659-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Tampa Electric Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: Updated Real Power Loss Factor to be effective 5/1/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5151.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1660-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Mississippi Power Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: MRA 29 Rate Case Filing to be effective 6/1/2020.
                    <PRTPAGE P="25431"/>
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5167.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1661-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Midcontinent Independent System Operator, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: 2020-04-27_SA 3481 A TC-Richland County Solar GIA (J864) to be effective 4/13/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5183.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1662-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Crystal Lake Wind Energy I, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Baseline eTariff Filing: Reactive Power Compensation Filing to be effective 6/27/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5185.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1663-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Public Service Electric and Gas Company, PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: PSEG submits Interconnection Agreement, SA No. 5590 with Silver Run to be effective 5/27/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5186.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1664-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     RE Mustang Two Whirlaway LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     § 205(d) Rate Filing: RE Mustang Two Whirlaway LLC LGIA Co-Tenancy Agreement to be effective 4/28/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5187.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>Take notice that the Commission received the following electric securities filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ES20-26-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application Under Section 204 of the Federal Power Act for Authorization to Issue Securities, et al. of PJM Interconnection, L.L.C.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200424-5304.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/4/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ES20-27-000.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     PJM Settlement, Inc.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Application Under Section 204 of the Federal Power Act for Authorization to Issue Securities, et al. of PJM Settlement, Inc.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/24/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200424-5305.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/4/20.
                </P>
                <P>The filings are accessible in the Commission's eLibrary system by clicking on the links or querying the docket number.</P>
                <P>Any person desiring to intervene or protest in any of the above proceedings must file in accordance with Rules 211 and 214 of the Commission's Regulations (18 CFR 385.211 and 385.214) on or before 5:00 p.m. Eastern time on the specified comment date. Protests may be considered, but intervention is necessary to become a party to the proceeding.</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>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Nathaniel J. Davis, Sr.,</NAME>
                    <TITLE>Deputy Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09313 Filed 4-30-20; 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. ER20-1616-000]</DEPDOC>
                <SUBJECT>Western Spirit Transmission LLC; Supplemental Notice that Initial Market-Based Rate Filing Includes Request for Blanket Section 204 Authorization</SUBJECT>
                <P>This is a supplemental notice in the above-referenced proceeding of Western Spirit Transmission LLC's application for market-based rate authority, with an accompanying rate tariff, noting that such application includes a request for blanket authorization, under 18 CFR part 34, of future issuances of securities and assumptions of liability.</P>
                <P>Any person desiring to intervene or to protest should file with the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426, in accordance with Rules 211 and 214 of the Commission's Rules of Practice and Procedure (18 CFR 385.211 and 385.214). Anyone filing a motion to intervene or protest must serve a copy of that document on the Applicant.</P>
                <P>Notice is hereby given that the deadline for filing protests with regard to the applicant's request for blanket authorization, under 18 CFR part 34, of future issuances of securities and assumptions of liability, is May 18, 2020.</P>
                <P>
                    The Commission encourages electronic submission of protests and interventions in lieu of paper, using the FERC Online links at 
                    <E T="03">http://www.ferc.gov.</E>
                     To facilitate electronic service, persons with internet access who will eFile a document and/or be listed as a contact for an intervenor must create and validate an eRegistration account using the eRegistration link. Select the eFiling link to log on and submit the intervention or protests.
                </P>
                <P>Persons unable to file electronically may mail similar pleadings to the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426. Hand delivered submissions in docketed proceedings should be delivered to Health and Human Services, 12225 Wilkins Avenue, Rockville, Maryland 20852.</P>
                <P>
                    In addition to publishing the full text of this document in the 
                    <E T="04">Federal Register</E>
                    , the Commission provides all interested persons an opportunity to view and/or print the contents of this document via the internet through the Commission's Home Page (
                    <E T="03">http://ferc.gov</E>
                    ) using the “eLibrary” link. Enter the docket number excluding the last three digits in the docket number field to access the document. At this time, the Commission has suspended access to the Commission's Public Reference Room, due to the proclamation declaring a National Emergency concerning the Novel Coronavirus Disease (COVID-19), issued by the President on March 13, 2020. For assistance, contact the Federal Energy Regulatory Commission at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or call toll-free, (886) 208-3676 or TYY, (202) 502-8659.
                </P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Nathaniel J. Davis, Sr.,</NAME>
                    <TITLE>Deputy Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09317 Filed 4-30-20; 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. 2513-090]</DEPDOC>
                <SUBJECT>Green Mountain Power Corporation; Notice of Intent To File License Application, Filing of Pre-Application Document (PAD), Commencement of Pre-Filing Process, and Scoping; Waiving Parts of the Pre-Filing Process; Request for Comments on the Pad and Scoping Document, and Identification of Issues and Associated Study Requests</SUBJECT>
                <P>
                    a. 
                    <E T="03">Type of Filing:</E>
                     Notice of Intent to File License Application for a New 
                    <PRTPAGE P="25432"/>
                    License and Commencing Pre-filing Process.
                </P>
                <P>
                    b. 
                    <E T="03">Project No.:</E>
                     2513-090.
                </P>
                <P>
                    c. 
                    <E T="03">Dated Filed:</E>
                     February 27, 2020.
                </P>
                <P>
                    d. 
                    <E T="03">Submitted By:</E>
                     Green Mountain Power Corporation.
                </P>
                <P>
                    e. 
                    <E T="03">Name of Project:</E>
                     Essex No. 19 Hydroelectric Project.
                </P>
                <P>
                    f. 
                    <E T="03">Location:</E>
                     On the Winooski River, in Chittenden County, Vermont. The project does not occupy federal lands.
                </P>
                <P>
                    g. 
                    <E T="03">Filed Pursuant to:</E>
                     18 CFR part 5 of the Commission's Regulations.
                </P>
                <P>
                    h. 
                    <E T="03">Licensee Contact:</E>
                     Mr. John Greenan, Green Mountain Power Corporation, 1252 Post Road, Rutland, Vermont 05701; phone: (802) 770-2195 or email at 
                    <E T="03">John.Greenan@greenmountainpower.com;</E>
                    .
                </P>
                <P>
                    i. 
                    <E T="03">FERC Contact:</E>
                     Michael Tust at (202) 502-6522 or email at 
                    <E T="03">michael.tust@ferc.gov.</E>
                </P>
                <P>
                    j. 
                    <E T="03">Cooperating agencies:</E>
                     Federal, state, local, and tribal agencies with jurisdiction and/or special expertise with respect to environmental issues that wish to cooperate in the preparation of the environmental document should follow the instructions for filing such requests described in item o below. Cooperating agencies should note the Commission's policy that agencies that cooperate in the preparation of the environmental document cannot also intervene. 
                    <E T="03">See</E>
                     94 FERC ¶ 61,076 (2001).
                </P>
                <P>k. With this notice, we are initiating informal consultation with: (a) the U.S. Fish and Wildlife Service and/or NOAA Fisheries under section 7 of the Endangered Species Act and the joint agency regulations thereunder at 50 CFR, Part 402 and (b) the State Historic Preservation Officer, as required by section 106, National Historic Preservation Act, and the implementing regulations of the Advisory Council on Historic Preservation at 36 CFR 800.2.</P>
                <P>l. With this notice, we are designating Green Mountain Power Corporation (Green Mountain Power) as the Commission's non-federal representatives for carrying out informal consultation, pursuant to section 7 of the Endangered Species Act and section 106 of the National Historic Preservation Act.</P>
                <P>m. Green Mountain Power filed a Pre-Application Document (PAD; including a proposed process plan and schedule) with the Commission, pursuant to 18 CFR 5.6 of the Commission's regulations.</P>
                <P>
                    n. In addition to publishing the full text of this document in the 
                    <E T="04">Federal Register</E>
                    , the Commission provides all interested persons an opportunity to view and/or print the contents via the internet through the Commission's Home Page (
                    <E T="03">http://www.ferc.gov</E>
                    ) using the “eLibrary” link. Enter the docket number excluding the last three digits in the docket number field to access the document. At this time, the Commission has suspended access to the Commission's Public Reference Room, due to the proclamation declaring a National Emergency concerning the Novel Coronavirus Disease (COVID-19), issued by the President on March 13, 2020. For assistance, contact FERC at 
                    <E T="03">FERCONlineSupport@ferc.gov</E>
                     or call toll-free, (866) 208-3676 or TYY, (202) 502-8659.
                </P>
                <P>
                    Register online at 
                    <E T="03">http://www.ferc.gov/docs-filing/esubscription.asp</E>
                     to be notified via email of new filing and issuances related to this or other pending projects. For assistance, contact FERC Online Support.
                </P>
                <P>o. With this notice, we are soliciting comments on the PAD and Commission's staff Scoping Document 1 (SD1), as well as study requests. All comments on the PAD and SD1, and study requests should be sent to the address above in paragraph h. In addition, all comments on the PAD and SD1, study requests, requests for cooperating agency status, and all communications to and from Commission staff related to the merits of the potential application must be filed with the Commission.</P>
                <P>
                    The Commission strongly encourages electronic filing. Please file all documents 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>
                     You must include your name and contact information at the end of your comments. For assistance, please contact FERC Online Support at 
                    <E T="03">FERCOnlineSupport@ferc.gov.</E>
                </P>
                <P>All filings with the Commission must bear the appropriate heading: “Comments on Pre-Application Document,” “Study Requests,” “Comments on Scoping Document 1,” “Request for Cooperating Agency Status,” or “Communications to and from Commission Staff.” Any individual or entity interested in submitting study requests, commenting on the PAD or SD1, and any agency requesting cooperating status must do so by June 26, 2020.</P>
                <P>p. Although our current intent is to prepare an environmental assessment (EA), there is the possibility that an Environmental Impact Statement (EIS) will be required. Nevertheless, this scoping document will satisfy the NEPA scoping requirements, irrespective of whether an EA or EIS is issued by the Commission.</P>
                <HD SOURCE="HD1">Scoping Meetings and Environmental Site Review</HD>
                <P>
                    Due to the proclamation declaring a National Emergency concerning the Novel Coronavirus Disease (COVID-19), issued by the President on March 13, 2020, we are waiving section 5.8(b)(viii) of the Commission's regulations and do not intend to conduct a public scoping meeting or site visit in this case. Instead, we are soliciting written comments, recommendations, and information, on the SD1. Any individual or entity interested in submitting scoping comments must do so by the date specified in item o. SD1, which outlines the subject areas to be addressed in the environmental document, was mailed to the individuals and entities on the Commission's mailing list. Copies of SD1 may be viewed on the web at 
                    <E T="03">http://www.ferc.gov,</E>
                     using the “eLibrary” link. Follow the directions for accessing information in paragraph n. Based on all written comments, a Scoping Document 2 (SD2) may be issued. SD2 may include a revised process plan and schedule, as well as a list of issues, identified through the scoping process.
                </P>
                <P>We may conduct the site visit, if needed, later in the process, such as in conjunction with the study plan meeting required by section 5.11(e) of the Commission's regulations which is required to occur by September 9. 2020. Further revisions to the schedule may be made as appropriate.</P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Kimberly D. Bose,</NAME>
                    <TITLE>Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09319 Filed 4-30-20; 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. ER20-1650-000]</DEPDOC>
                <SUBJECT>Little Bear Master Tenant, LLC; Supplemental Notice That Initial Market-Based Rate Filing Includes Request for Blanket Section 204 Authorization</SUBJECT>
                <P>
                    This is a supplemental notice in the above-referenced proceeding of Little Bear Master Tenant, LLC's application for market-based rate authority, with an accompanying rate tariff, noting that such application includes a request for blanket authorization, under 18 CFR 
                    <PRTPAGE P="25433"/>
                    part 34, of future issuances of securities and assumptions of liability.
                </P>
                <P>Any person desiring to intervene or to protest should file with the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426, in accordance with Rules 211 and 214 of the Commission's Rules of Practice and Procedure</P>
                <P>(18 CFR 385.211 and 385.214). Anyone filing a motion to intervene or protest must serve a copy of that document on the Applicant.</P>
                <P>Notice is hereby given that the deadline for filing protests with regard to the applicant's request for blanket authorization, under 18 CFR part 34, of future issuances of securities and assumptions of liability, is May 18, 2020.</P>
                <P>
                    The Commission encourages electronic submission of protests and interventions in lieu of paper, using the FERC Online links at 
                    <E T="03">http://www.ferc.gov.</E>
                     To facilitate electronic service, persons with internet access who will eFile a document and/or be listed as a contact for an intervenor must create and validate an eRegistration account using the eRegistration link. Select the eFiling link to log on and submit the intervention or protests.
                </P>
                <P>Persons unable to file electronically may mail similar pleadings to the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426. Hand delivered submissions in docketed proceedings should be delivered to Health and Human Services, 12225 Wilkins Avenue, Rockville, Maryland 20852.</P>
                <P>
                    In addition to publishing the full text of this document in the 
                    <E T="04">Federal Register</E>
                    , the Commission provides all interested persons an opportunity to view and/or print the contents of this document via the internet through the Commission's Home Page (
                    <E T="03">http://ferc.gov</E>
                    ) using the “eLibrary” link. Enter the docket number excluding the last three digits in the docket number field to access the document. At this time, the Commission has suspended access to the Commission's Public Reference Room, due to the proclamation declaring a National Emergency concerning the Novel Coronavirus Disease (COVID-19), issued by the President on March 13, 2020. For assistance, contact the Federal Energy Regulatory Commission at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or call toll-free, (886) 208-3676 or TYY, (202) 502-8659.
                </P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Nathaniel J. Davis, Sr.,</NAME>
                    <TITLE>Deputy Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09315 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF ENERGY</AGENCY>
                <SUBAGY>Federal Energy Regulatory Commission</SUBAGY>
                <SUBJECT>Combined Notice of Filings #2</SUBJECT>
                <P>Take notice that the Commission received the following electric rate filings:</P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER15-2013-010; ER12-2510-009; ER15-2014-005; ER10-2435-016; ER10-2440-012; ER10-2442-014; ER12-2512-009; ER19-481-002; ER15-2018-005; ER18-2252-001; ER10-3286-013; ER15-2022-005; ER10-3299-012; ER10-2444-016; ER10-2446-012; ER15-2026-005; ER15-2020-008; ER10-2449-014; ER19-2250-002.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Talen Energy Marketing, LLC, Brandon Shores LLC, Brunner Island, LLC, Camden Plant Holding, L.L.C., Dartmouth Power Associates Limited Partnership, Elmwood Park Power, LLC, H.A. Wagner LLC, LMBE Project Company LLC, Martins Creek, LLC, MC Project Company LLC, Millennium Power Partners, LP, Montour, LLC, New Athens Generating Company, LLC, Newark Bay Cogeneration Partnership, L.P, Pedricktown Cogeneration Company LP, Susquehanna Nuclear, LLC, Talen Montana, LLC, York Generation Company LLC, TrailStone Energy Marketing, LLC.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Notification of Change in Status of the Indicated MBR Sellers, et al.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5181.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>
                    <E T="03">Docket Numbers:</E>
                     ER20-1136-001.
                </P>
                <P>
                    <E T="03">Applicants:</E>
                     Idaho Power Company.
                </P>
                <P>
                    <E T="03">Description:</E>
                     Tariff Amendment: Amendment re Add Omitted Cancelled Service Agreement to be effective 6/30/2020.
                </P>
                <P>
                    <E T="03">Filed Date:</E>
                     4/27/20.
                </P>
                <P>
                    <E T="03">Accession Number:</E>
                     20200427-5120.
                </P>
                <P>
                    <E T="03">Comments Due:</E>
                     5 p.m. ET 5/18/20.
                </P>
                <P>The filings are accessible in the Commission's eLibrary system by clicking on the links or querying the docket number.</P>
                <P>Any person desiring to intervene or protest in any of the above proceedings must file in accordance with Rules 211 and 214 of the Commission's Regulations (18 CFR 385.211 and 385.214) on or before 5:00 p.m. Eastern time on the specified comment date. Protests may be considered, but intervention is necessary to become a party to the proceeding.</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>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Nathaniel J. Davis, Sr.,</NAME>
                    <TITLE>Deputy Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09312 Filed 4-30-20; 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. 2077-119]</DEPDOC>
                <SUBJECT>Great River Hydro, LLC; Notice of Application Accepted for Filing and Soliciting Comments, Motions To Intervene, and Protests</SUBJECT>
                <P>Take notice that the following hydroelectric application has been filed with the Commission and is available for public inspection:</P>
                <P>
                    a. 
                    <E T="03">Application Type:</E>
                     Amendment of License.
                </P>
                <P>
                    b. 
                    <E T="03">Project No:</E>
                     2077-119.
                </P>
                <P>
                    c. 
                    <E T="03">Date Filed:</E>
                     January 21, 2020.
                </P>
                <P>
                    d. 
                    <E T="03">Applicant:</E>
                     Great River Hydro, LLC (licensee).
                </P>
                <P>
                    e. 
                    <E T="03">Name of Project:</E>
                     Fifteen Mile Falls Hydroelectric Project.
                </P>
                <P>
                    f. 
                    <E T="03">Location:</E>
                     The project is located on the Connecticut River, near the Town of Littleton in Grafton County, New Hampshire, and Caledonia County, Vermont.
                </P>
                <P>
                    g. 
                    <E T="03">Filed Pursuant to:</E>
                     Federal Power Act, 16 U.S.C. 791a-825r.
                </P>
                <P>
                    h. 
                    <E T="03">Applicant Contact:</E>
                     John Ragonese, FERC License Manager, Great River Hydro, LLC, 40 Pleasant Street, Suite 102, Portsmouth, NH 03801; telephone: (603) 498-2851;  email: 
                    <E T="03">jragonese@greatriverhydro.com.</E>
                </P>
                <P>
                    i. 
                    <E T="03">FERC Contact:</E>
                     Marybeth Gay, (202) 502-6125, 
                    <E T="03">Marybeth.Gay@ferc.gov.</E>
                </P>
                <P>
                    j. 
                    <E T="03">Deadline for filing comments, motions to intervene, and protests:</E>
                     May 27, 2020.
                </P>
                <P>
                    The Commission strongly encourages electronic filing. Please file comments, motions to intervene, and protests 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 
                    <PRTPAGE P="25434"/>
                    eComment system at 
                    <E T="03">http://www.ferc.gov/docs-filing/ecomment.asp.</E>
                     You must include your name and contact information at the end of your comments. For assistance, please contact FERC Online Support at 
                    <E T="03">FERCOnlineSupport@ferc.gov,</E>
                     (866) 208-3676 (toll free), or (202) 502-8659 (TTY).
                </P>
                <P>The Commission's Rules of Practice and Procedure require all intervenors filing documents with the Commission to serve a copy of that document on each person whose name appears on the official service list for the project. Further, if an intervenor files comments or documents with the Commission relating to the merits of an issue that may affect the responsibilities of a particular resource agency, they must also serve a copy of the document on that resource agency.</P>
                <P>
                    k. 
                    <E T="03">Description of Request:</E>
                     The licensee proposes to amend the license to allow for the construction and operation of an additional 4.7 MW unit at the Moore Development for the primary purpose of providing the required minimum flow of 320 cubic feet per second (cfs), or inflow if less, more efficiently than current operation. The licensee proposes structural modifications to the Moore Development, including: (1) a new modified intake with an accompanying trashrack and headgate providing flow to a new penstock that would be installed on the upstream face of the dam in the original additional intake location adjacent to the existing Unit 1 intake; (2) a 7-foot-diameter steel pipe would exit the downstream face of the dam on the Vermont side of the existing transmission substation (owned by New England Power Co., d.b.a. National Grid); (3) a new 42 foot by 30 foot reinforced concrete powerhouse constructed on the Vermont side of the existing powerhouse; (4) a dissolved oxygen enhancement system consisting of a pipe with aeration devices that discharge water into the new powerhouse tailrace, and;  (5) a new tailrace channel would extend into the existing tailrace bound by concrete or sheet pile retaining walls on either side. With the proposed modifications to the Moore Development, the maximum hydraulic capacity would be increased by a maximum of 430 cfs, while the installed capacity would be increased from the current 154.8 MW to 159.5 MW. The licensee does not propose any changes to the project's existing operating regime, with exception of operating the Moore Unit 5 as the priority unit to provide the minimum flow below the Moore Development.
                </P>
                <P>
                    l. In addition to publishing the full text of this document in the 
                    <E T="04">Federal Register</E>
                    , the Commission provides all interested persons an opportunity to view and/or print the contents of this document via the internet through the Commission's Home Page (
                    <E T="03">http://ferc.gov</E>
                    ) using the “eLibrary” link. Enter the docket number excluding the last three digits in the docket number field to access the document. At this time, the Commission has suspended access to the Commission's Public Reference Room, due to the proclamation declaring a National Emergency concerning the Novel Coronavirus Disease (COVID-19), issued by the President on March 13, 2020. For assistance, contact FERC at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or call toll-free, (886) 208-3676 or TYY, (202) 502-8659.
                </P>
                <P>
                    m. The Commission strongly encourages electronic filings of comments, protests and interventions in lieu of paper using the “eFiling” link at 
                    <E T="03">http://www.ferc.gov.</E>
                     Persons unable to file electronically may mail similar pleadings to the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426. Hand delivered submissions in docketed proceedings should be delivered to Health and Human Services, 12225 Wilkins Avenue, Rockville, Maryland 20852.
                </P>
                <P>
                    n. 
                    <E T="03">Comments, Protests, or Motions to Intervene:</E>
                     Anyone may submit comments, a protest, or a motion to intervene in accordance with the requirements of Rules of Practice and Procedure, 18 CFR 385.210, .211, .214, respectively. In determining the appropriate action to take, the Commission will consider all protests or other comments filed, but only those who file a motion to intervene in accordance with the Commission's Rules may become a party to the proceeding. Any comments, protests, or motions to intervene must be received on or before the specified comment date for the particular application.
                </P>
                <P>o. Filing and Service of Documents: Any filing must (1) bear in all capital letters the title “COMMENTS”, “PROTEST”, or “MOTION TO INTERVENE” as applicable; (2) set forth in the heading the name of the applicant and the project number of the application to which the filing responds; (3) furnish the name, address, and telephone number of the person commenting, protesting or intervening; and (4) otherwise comply with the requirements of 18 CFR 385.2001 through 385.2005. All comments, motions to intervene, or protests must set forth their evidentiary basis. Any filing made by an intervenor must be accompanied by proof of service on all persons listed in the service list prepared by the Commission in this proceeding, in accordance with 18 CFR 385.2010.</P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Kimberly D. Bose,</NAME>
                    <TITLE>Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09320 Filed 4-30-20; 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. ER20-1648-000]</DEPDOC>
                <SUBJECT>Inter-Power/AhlCon Partners, L.P.; Supplemental Notice That Initial Market-Based Rate Filing Includes Request for Blanket Section 204 Authorization</SUBJECT>
                <P>This is a supplemental notice in the above-referenced proceeding of Inter-Power/AhlCon Partners, L.P.'s application for market-based rate authority, with an accompanying rate tariff, noting that such application includes a request for blanket authorization, under 18 CFR part 34, of future issuances of securities and assumptions of liability.</P>
                <P>Any person desiring to intervene or to protest should file with the Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426, in accordance with Rules 211 and 214 of the Commission's Rules of Practice and Procedure (18 CFR 385.211 and 385.214). Anyone filing a motion to intervene or protest must serve a copy of that document on the Applicant.</P>
                <P>Notice is hereby given that the deadline for filing protests with regard to the applicant's request for blanket authorization, under 18 CFR part 34, of future issuances of securities and assumptions of liability, is May 18, 2020.</P>
                <P>
                    The Commission encourages electronic submission of protests and interventions in lieu of paper, using the FERC Online links at 
                    <E T="03">http://www.ferc.gov.</E>
                     To facilitate electronic service, persons with internet access who will eFile a document and/or be listed as a contact for an intervenor must create and validate an eRegistration account using the eRegistration link. Select the eFiling link to log on and submit the intervention or protests.
                </P>
                <P>
                    Persons unable to file electronically may mail similar pleadings to the Federal Energy Regulatory Commission, 
                    <PRTPAGE P="25435"/>
                    888 First Street NE, Washington, DC 20426. Hand delivered submissions in docketed proceedings should be delivered to Health and Human Services, 12225 Wilkins Avenue, Rockville, Maryland 20852.
                </P>
                <P>
                    In addition to publishing the full text of this document in the 
                    <E T="04">Federal Register</E>
                    , the Commission provides all interested persons an opportunity to view and/or print the contents of this document via the internet through the Commission's Home Page (
                    <E T="03">http://ferc.gov</E>
                    ) using the “eLibrary” link. Enter the docket number excluding the last three digits in the docket number field to access the document. At this time, the Commission has suspended access to the Commission's Public Reference Room, due to the proclamation declaring a National Emergency concerning the Novel Coronavirus Disease (COVID-19), issued by the President on March 13, 2020. For assistance, contact the Federal Energy Regulatory Commission at 
                    <E T="03">FERCOnlineSupport@ferc.gov</E>
                     or call toll-free, (886) 208-3676 or TYY, (202) 502-8659.
                </P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Nathaniel J. Davis, Sr.,</NAME>
                    <TITLE>Deputy Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09316 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6717-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <DEPDOC>[FRL—10008-97-OA]</DEPDOC>
                <SUBJECT>Notification of Public Meetings of the Science Advisory Board Economic Guidelines Review Panel</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Environmental Protection Agency (EPA).</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Environmental Protection Agency (EPA) Science Advisory Board (SAB) Staff Office announces four public meetings of the Science Advisory Board Economic Guidelines Review Panel. The purpose of the meetings is to conduct a peer review of the EPA's revised document titled “Guidelines for Preparing Economic Analyses” and to develop a report responsive to charge questions on the revised document.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Meetings will be held on May 18, 2020, May 21, 2020, May 26, 2020 and June 9, 2020. All meetings will occur from 11:00 a.m. to 3:00 p.m. (Eastern Time).</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The public meetings will be conducted remotely as an audio conference via webcast and telephone. Please refer to the SAB website at 
                        <E T="03">http://www.epa.gov/sab</E>
                         for information on how to access the meeting.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Any member of the public who wants further information concerning the meetings announced in this notice may contact Dr. Shaunta Hill-Hammond, Designated Federal Officer (DFO) via telephone (202) 564-3343, or email at 
                        <E T="03">hill-hammond.shaunta@epa.gov.</E>
                         Any technical questions concerning EPA's document titled
                        <E T="03"> “</E>
                        Guidelines for Preparing Economic Analyses” should be directed to Nathalie Simon (
                        <E T="03">simon.nathalie@epa.gov</E>
                        ). General information about the SAB, as well as any updates concerning the meetings announced in this notice can be found on the SAB website at 
                        <E T="03">http://www.epa.gov/sab.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    <E T="03">Background:</E>
                     The SAB was established pursuant to the Environmental Research, Development, and Demonstration Authorization Act (ERDDAA), codified at 42 U.S.C. 4365, to provide independent scientific and technical advice to the EPA Administrator on the scientific and technical basis for agency positions and regulations. The SAB is a Federal Advisory Committee chartered under the Federal Advisory Committee Act (FACA), 5 U.S.C., App. 2. The SAB will comply with the provisions of FACA and all appropriate SAB Staff Office procedural policies. Pursuant to FACA and EPA policy, notice is hereby given that the Science Advisory Board Economic Guidelines Review Panel will hold four public meetings to peer review EPA's revised document titled “Guidelines for Preparing Economic Analyses.” The first three meetings (May 18, 21, and 26, 2020) will be dedicated to the review of the document and the development of Panel's responses to charge questions. The fourth meeting (June 9, 2020) will be dedicated to the review of the Panel's responses. The purpose of the “Guidelines for Preparing Economic Analyses” document is to define and describe best practices for economic analysis grounded in the economics literature. It also describes Executive Orders and other documents that impose analytic requirements and provides detailed information on selected important topics for economic analyses.
                </P>
                <P>
                    <E T="03">Availability of Meeting Materials:</E>
                     All meeting materials, including the agendas will be available prior to the meetings on the SAB web page at 
                    <E T="03">http://epa.gov/sab.</E>
                </P>
                <P>
                    <E T="03">Procedures for Providing Public Input:</E>
                     Public comment for consideration by EPA's federal advisory committees and panels has a different purpose from public comment provided to EPA program offices. Therefore, the process for submitting comments to a federal advisory committee is different from the process used to submit comments to an EPA program office. Federal advisory committees and panels, including scientific advisory committees, provide independent advice to the EPA. Members of the public can submit relevant comments pertaining to the committee's charge or meeting materials. Input from the public to the SAB will have the most impact if it provides specific scientific or technical information or analysis for the SAB to consider or if it relates to the clarity or accuracy of the technical information. Members of the public wishing to provide comment should follow the instructions below to submit comments.
                </P>
                <P>
                    <E T="03">Oral Statements:</E>
                     In general, individuals or groups requesting an oral statement will be limited to three minutes. Each person making an oral statement should consider providing written comments as well as their oral statement so that the points presented orally can be expanded upon in writing. Oral statements will be heard on two meeting dates, May 18, 2020 and June 9, 2020. Persons interested in providing oral statements for the meetings occuring on May 18, 2020 should contact the DFO via email at the contact information noted above by May 12, 2020, to be placed on the list of registered speakers. Persons interested in providing oral statements for the meetings occuring on June 9, 2020 should contact the DFO by email at the contact information noted above by June 3, 2020, to be placed on the list of registered speakers.
                </P>
                <P>
                    <E T="03">Written Statements:</E>
                     Written statements will be accepted throughout the advisory process; however, for timely consideration by SAB members, statements should be received by May 12, 2020 for the meetings occuring on May 18, 21, and 26, 2020 and by June 3, 2020 for the meeting occuring on June 9, 2020. Written statements should be supplied to the DFO at the contact information above via email. Submitters are requested to provide a signed and unsigned version of each document because the SAB Staff Office does not publish documents with signatures on its websites. Members of the public should be aware that their personal contact information, if included in any written comments, may be posted to the SAB website. Copyrighted material will 
                    <PRTPAGE P="25436"/>
                    not be posted without explicit permission of the copyright holder.
                </P>
                <P>
                    <E T="03">Accessibility:</E>
                     For information on access or services for individuals with disabilities, please contact the DFO, at the contact information noted above, preferably at least ten days prior to the meeting, to give the EPA as much time as possible to process your request.
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020. </DATED>
                    <NAME>V. Khanna Johnston,</NAME>
                    <TITLE>Deputy Director, EPA Science Advisory Board Staff Office.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09286 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 6560-50-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">ENVIRONMENTAL PROTECTION AGENCY</AGENCY>
                <DEPDOC>[ER-FRL-9050-6]</DEPDOC>
                <SUBJECT>Environmental Impact Statements; Notice of Availability</SUBJECT>
                <P>
                    Responsible Agency: Office of Federal Activities, General Information 202-564-5632 or 
                    <E T="03">https://www.epa.gov/nepa.</E>
                </P>
                <FP SOURCE="FP-1">Weekly receipt of Environmental Impact Statements (EIS)</FP>
                <FP SOURCE="FP-1">Filed April 20, 2020, 10 a.m. EST Through April 27, 2020, 10 a.m. EST</FP>
                <FP SOURCE="FP-1">Pursuant to 40 CFR 1506.9.</FP>
                <P>
                    Section 309(a) of the Clean Air Act requires that EPA make public its comments on EISs issued by other Federal agencies. EPA's comment letters on EISs are available at: 
                    <E T="03">https://cdxnodengn.epa.gov/cdx-enepa-public/action/eis/search</E>
                    .
                </P>
                <HD SOURCE="HD1">Amended Notice:</HD>
                <FP SOURCE="FP-1">EIS No. 20200077, Draft, NNSA, SC, Plutonium Pit Production at the Savannah River Site in South Carolina, Comment Period Ends: 06/02/2020, Contact: Jennifer Nelson 803-208-1426. Revision to FR Notice Published 4/3/2020; Extending the Review Period from 5/18/2020 to 6/2/2020.</FP>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Cindy S. Barger,</NAME>
                    <TITLE>Director, NEPA Compliance Division, Office of Federal Activities.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09275 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6560-50-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">FEDERAL RESERVE SYSTEM</AGENCY>
                <SUBJECT>Change in Bank Control Notices; Acquisitions of Shares of a Bank or Bank Holding Company</SUBJECT>
                <P>The notificants listed below have applied under the Change in Bank Control Act (Act) (12 U.S.C. 1817(j)) and § 225.41 of the Board's Regulation Y (12 CFR 225.41) to acquire shares of a bank or bank holding company. The factors that are considered in acting on the applications are set forth in paragraph 7 of the Act (12 U.S.C. 1817(j)(7)).</P>
                <P>The applications listed below, as well as other related filings required by the Board, if any, are available for immediate inspection at the Federal Reserve Bank indicated. The applications will also be available for inspection at the offices of the Board of Governors. Interested persons may express their views in writing on the standards enumerated in paragraph 7 of the Act.</P>
                <P>Comments regarding each of these applications must be received at the Reserve Bank indicated or the offices of the Board of Governors, Ann E. Misback, Secretary of the Board, 20th Street and Constitution Avenue NW, Washington DC 20551-0001, not later than May 18, 2020.</P>
                <P>
                    <E T="03">A. Federal Reserve Bank of Minneapolis</E>
                     (Chris P. Wangen, Assistant Vice President), 90 Hennepin Avenue, Minneapolis, Minnesota 55480-0291:
                </P>
                <P>
                    1. 
                    <E T="03">The Western National Bank and Affiliates Employee Stock Ownership Plan, Duluth, Minnesota, Stephen H. Lewis, Duluth, Minnesota, and William S. Lewis, Hermantown, Minnesota, as co-trustees;</E>
                     as members of a group acting in concert to retain voting shares of Western Bancorporation, Inc., and thereby indirectly retain voting shares of Western National Bank, both of Duluth, Minnesota; and Cass Lake Company and Western National Bank of Cass Lake, both of Cass Lake, Minnesota.
                </P>
                <SIG>
                    <DATED>Board of Governors of the Federal Reserve System, April 28, 2020.</DATED>
                    <NAME>Yao-Chin Chao,</NAME>
                    <TITLE>Assistant Secretary of the Board.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09347 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">FEDERAL RESERVE SYSTEM</AGENCY>
                <SUBJECT>Agency Information Collection Activities: Announcement of Temporary Approval by the Board Under Delegated Authority and Submission to OMB</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Board of Governors of the Federal Reserve System.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Temporary approval of information collection activities.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Board of Governors of the Federal Reserve System (Board) has temporarily revised the Reports of Deposits (FR 2900 series; OMB Control Number 7100-0087), the Financial Statements for Holding Companies (FR Y-9 reports; OMB Control Number 7100-0128), and the Consolidated Report of Condition and Income for Edge and Agreement Corporations (FR 2886b; OMB Control Number 7100-0086) pursuant to the authority delegated to the Board by the Office of Management and Budget (OMB). The revisions are applicable only to the reports' instructions.</P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P/>
                    <P SOURCE="NPAR">Federal Reserve Board Clearance Officer—Nuha Elmaghrabi—Office of the Chief Data Officer, Board of Governors of the Federal Reserve System, Washington, DC 20551, (202) 452-3829.</P>
                    <P>OMB Desk Officer—Shagufta Ahmed—Office of Information and Regulatory Affairs, Office of Management and Budget, New Executive Office Building, Room 10235, 725 17th Street NW, Washington, DC 20503, or by fax to (202) 395-6974.</P>
                    <P>
                        A copy of the Paperwork Reduction Act (PRA) OMB submission, including the reporting form and instructions, supporting statement, and other documentation will be placed into OMB's public docket files. These documents also are available on the Federal Reserve Board's public website at 
                        <E T="03">https://www.federalreserve.gov/apps/reportforms/review.aspx</E>
                         or may be requested from the agency clearance officer, whose name appears above.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>On June 15, 1984, OMB delegated to the Board authority under the PRA to approve and assign OMB control numbers to collections of information conducted or sponsored by the Board. Board-approved collections of information are incorporated into the official OMB inventory of currently approved collections of information. Copies of the PRA submission, supporting statements, and approved collection of information instruments are placed into OMB's public docket files.</P>
                <P>Pursuant to its delegated authority, the Board may temporarily approve a revision to a collection of information, without providing opportunity for public comment, if the Board determines that a change in an existing collection must be instituted quickly and that public participation in the approval process would defeat the purpose of the collection or substantially interfere with the Board's ability to perform its statutory obligation.</P>
                <P>
                    As discussed below, the Board has made certain temporary revisions to the instructions of the FR 2900 series, the FR Y-9 reports, and the FR 2886b in accordance with amendments to 
                    <PRTPAGE P="25437"/>
                    Regulation D in an interim final rule published on April 28, 2020 (85 FR 23445). The Board's delegated authority requires that the Board, after temporarily approving a collection, publish a notice soliciting public comment. Therefore, the Board will publish a separate notice in the 
                    <E T="04">Federal Register</E>
                     to invite comment on a proposal to extend the FR 2900 series, the FR Y-9 reports, and the FR 2886b for three years.
                </P>
                <P>The Board has determined that the temporary revisions to the FR 2900 series, the FR Y-9 reports, and the FR 2886b must be instituted quickly and that public participation in the approval process would defeat the purpose of the collections of information, as delaying the revisions would cause public harm by interfering with financial institutions' ability to take advantage of the emergency relief provided by the interim final rule in response to significant financial industry disruptions from the containment measures adopted in response to the public health concerns.</P>
                <P>
                    The interim final rule also affects the following Federal Financial Institutions Examination Council (“FFIEC”) reports, which are shared by the Board, the Federal Deposit Insurance Corporation (“FDIC”), and the Office of the Comptroller of the Currency (“OCC”) (together, “the agencies”): The Consolidated Reports of Condition and Income (“Call Reports”) (Board OMB Control Number: 7100-0036; FDIC OMB Control Number 3064-0052; and OCC OMB Control Number 1557-0081) and the Report of Assets and Liabilities of U.S. Branches and Agencies of Foreign Banks (FFIEC 002; OMB Control Number: 7100-0032). Any corresponding revisions that should be made to the affected FFIEC reports as a result of the interim final rule will be addressed in a separate 
                    <E T="04">Federal Register</E>
                     notice.
                </P>
                <HD SOURCE="HD1">Approval Under OMB Delegated Authority of the Temporary Revision of the Following Information Collections</HD>
                <P>
                    (1) 
                    <E T="03">Report title:</E>
                     Reports of Deposits.
                </P>
                <P>
                    <E T="03">Agency form number:</E>
                     FR 2900; FR 2910a; FR 2915; and FR 2930.
                </P>
                <P>
                    <E T="03">OMB control number:</E>
                     7100-0087.
                </P>
                <P>
                    <E T="03">Applicable date:</E>
                     May 1, 2020.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Weekly, quarterly, annually, and on occasion.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Depository institutions.
                </P>
                <P>
                    <E T="03">Estimated number of respondents:</E>
                     FR 2900 (Weekly): 949; FR 2900 (Quarterly): 5,453; FR 2910a: 2,941; FR 2915: 122; and FR 2930: 93.
                </P>
                <P>
                    <E T="03">Estimated average hours per response:</E>
                     FR 2900 (Weekly): 1.25 hours; FR 2900 (Quarterly): 3; FR 2910a: 0.75; FR 2915: 0.5; and FR 2930: 0.25.
                </P>
                <P>
                    <E T="03">Estimated annual burden hours:</E>
                     FR 2900 (Weekly): 130,455; FR 2900 (Quarterly): 52,740; FR 2910a: 2,206; FR 2915: 244; FR 2930: 23.
                </P>
                <P>
                    <E T="03">General description of report:</E>
                     Data from these mandatory reports are used by the Board for administering Regulation D and for constructing, analyzing, and monitoring the monetary and reserve aggregates. The FR 2900 is the primary source of data for the construction and analysis of the monetary aggregates and was used for the calculation of required reserves and applied vault cash. Data are also used for (1) indexing the exemption amount and low reserve tranche amount each year, as required by statute, and (2) indexing the nonexempt deposit cutoff and reduced reporting limit each year, as determined by the Board. The amounts of the deposit cutoff and reporting limit determine whether depository institutions file the FR 2900 either weekly or quarterly. The FR 2910a is generally submitted by exempt institutions whose total deposits (as shown on their December Call Report) are greater than the exemption amount. All FR 2900 respondents, both weekly and quarterly, that offer deposits denominated in foreign currencies at their U.S. offices file the FR 2915 quarterly on the same reporting schedule as quarterly FR 2900 respondents. Foreign currency deposits are subject to reserve requirements and, therefore, are included in the FR 2900 data. However, because foreign currency deposits are not included in the monetary aggregates, the FR 2915 data are used to net foreign currency-denominated deposits from the FR 2900 data to exclude them from measures of the monetary aggregates. The FR 2930 data are collected when the low reserve tranche and reservable liabilities exemption thresholds are adjusted toward the end of each calendar year or upon the establishment of an office outside the home state or Federal Reserve District.
                </P>
                <P>
                    <E T="03">Legal authorization and confidentiality:</E>
                     The information collected on these reports is authorized under sections 11, 25(7), and 25A(17) of the Federal Reserve Act, and section 7 of the International Banking Act (IBA). Section 11 of the Federal Reserve Act (12 U.S.C. 248(a)) authorizes the Board to require reports from each member bank as it may deem necessary and authorizes the Board to prescribe reports of liabilities and assets from insured depository institutions to enable the Board to discharge its responsibility to monitor and control monetary and credit aggregates. Sections 25(7) and 25A(17) of the Federal Reserve Act (12 U.S.C. 604a and 625) authorize the Board to require Edge and agreement corporations to make reports to the Board. Section 7 of the IBA (12 U.S.C. 3105(c)(2)) authorizes the Board to require reports from U.S. branches and agencies of foreign banks. The FR 2900, FR 2910a, FR 2915, and FR 2930 are all mandatory. The release of data collected on these forms would likely cause substantial harm to the competitive position of the respondent if made publicly available. The data collected on these forms, therefore, may be kept confidential under exemption 4 of the Freedom of Information Act (FOIA), which protects from disclosure trade secrets and commercial or financial information (5 U.S.C. 552(b)(4)).
                </P>
                <P>
                    <E T="03">Current actions:</E>
                     The Board has temporarily revised the instructions to the FR 2900 and FR 2910a to update the definition of “savings deposits” in accordance with the amendments to Regulation D in the interim final rule published on April 28, 2020 (85 FR 23445). Specifically, the Board has temporarily revised the FR 2900 and FR 2910a instructions to exclude any reference to a numeric transfer or withdrawal limit from the definition of a savings deposit. Please note that this revision does not require any changes to the forms themselves. As a result of the revision, if a depository institution chooses to suspend enforcement of the six transfer limit on a “savings deposit,” the depository institution may continue to report that account as a “savings deposit” or may instead choose to report that account as a “transaction account.”
                </P>
                <P>
                    (2) 
                    <E T="03">Report title:</E>
                     Financial Statements for Holding Companies.
                </P>
                <P>
                    <E T="03">Agency form number:</E>
                     FR Y-9C, FR Y-9LP, FR Y-9SP, FR Y-9ES, and FR Y-9CS.
                </P>
                <P>
                    <E T="03">OMB control number:</E>
                     7100-0128.
                </P>
                <P>
                    <E T="03">Applicable date:</E>
                     May 1, 2020.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Quarterly, semiannually, and annually.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Bank holding companies, savings and loan holding companies,
                    <SU>1</SU>
                    <FTREF/>
                     securities holding companies, and U.S. intermediate holding companies (collectively, HCs).
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         An SLHC must file one or more of the FR Y-9 series of reports unless it is: (1) A grandfathered unitary SLHC with primarily commercial assets and thrifts that make up less than 5 percent of its consolidated assets; or (2) a SLHC that primarily holds insurance-related assets and does not otherwise submit financial reports with the SEC pursuant to section 13 or 15(d) of the Securities Exchange Act of 1934.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Estimated number of respondents:</E>
                     FR Y-9C (non-advanced approaches community bank leverage ratio (CBLR) 
                    <PRTPAGE P="25438"/>
                    HCs with less than $5 billion in total assets): 71; FR Y-9C (non-advanced approaches CBLR HCs with $5 billion or more in total assets): 35; FR Y-9C (non-advanced approaches, non-CBLR, HCs with less than $5 billion in total assets): 84; FR Y-9C (non-advanced approaches, non CBLR, HCs, with $5 billion or more in total assets): 154; FR Y-9C (advanced approaches HCs): 19; FR Y-9LP: 434; FR Y-9SP: 3,960; FR Y-9ES: 83; FR Y-9CS: 236.
                </P>
                <P>
                    <E T="03">Estimated average hours per response:</E>
                </P>
                <HD SOURCE="HD2">Reporting</HD>
                <P>FR Y-9C (non-advanced approaches CBLR HCs with less than $5 billion in total assets): 29.14 hours; FR Y-9C (non-advanced approaches CBLR HCs with $5 billion or more in total assets): 35.11; FR Y-9C (non-advanced approaches, non CBLR HCs, with less than $5 billion in total assets): 40.98; FR Y-9C (non-advanced approaches, non CBLR, HCs with $5 billion or more in total assets): 46.95; FR Y-9C (advanced approaches HCs): 48.59; FR Y-9LP: 5.27; FR Y-9SP: 5.40; FR Y-9ES: 0.50; FR Y-9CS: 0.50.</P>
                <HD SOURCE="HD2">Recordkeeping</HD>
                <P>FR Y-9C (non-advanced approaches HCs with less than $5 billion in total assets), FR Y-9C (non-advanced approaches HCs with $5 billion or more in total assets), FR Y-9C (advanced approaches HCs), and FR Y-9LP: 1.00 hour; FR Y-9SP, FR Y-9ES, and FR Y-9CS: 0.50.</P>
                <P>
                    <E T="03">Estimated annual burden hours:</E>
                </P>
                <HD SOURCE="HD2">Reporting</HD>
                <P>FR Y-9C (non-advanced approaches CBLR HCs with less than $5 billion in total assets): 8,276 hours; FR Y-9C (non-advanced approaches CBLR HCs with $5 billion or more in total assets): 4,915 hours; FR Y-9C (non-advanced approaches non CBLR HCs with less than $5 billion in total assets): 13,769 hours; FR Y-9C (non-advanced approaches non CBLR HCs with $5 billion or more in total assets): 28,921 hours; FR Y-9C (advanced approaches HCs): 3,693 hours; FR Y-9LP: 9,149 hours; FR Y-9SP: 42,768 hours; FR Y-9ES: 42 hours; FR Y-9CS: 472 hours.</P>
                <HD SOURCE="HD2">Recordkeeping</HD>
                <P>FR Y-9C (non-advanced approaches HCs with less than $5 billion in total assets): 620 hours; FR Y-9C (non-advanced approaches HCs with $5 billion or more in total assets): 756 hours; FR Y-9C (advanced approaches HCs): 76 hours; FR Y-9LP: 1,736 hours; FR Y-9SP: 3,960 hours; FR Y-9ES: 42 hours; FR Y-9CS: 472 hours.</P>
                <P>
                    <E T="03">General description of report:</E>
                     The FR Y-9 reports continue to be the primary source of financial data on HCs that examiners rely on in the intervals between on-site inspections. Financial data from these reporting forms are used to detect emerging financial problems, to review performance and conduct pre-inspection analysis, to monitor and evaluate capital adequacy, to evaluate holding company mergers and acquisitions, and to analyze a holding company's overall financial condition to ensure the safety and soundness of its operations. The FR Y-9C, FR Y-9LP, and FR Y-9SP serve as standardized financial statements for the consolidated holding company. The Board requires HCs to provide standardized financial statements to fulfill the Board's statutory obligation to supervise these organizations. The FR Y-9ES is a financial statement for HCs that are Employee Stock Ownership Plans. The Board uses the voluntary FR Y-9CS (a free-form supplement) to collect additional information deemed to be critical and needed in an expedited manner. HCs file the FR Y-9C on a quarterly basis, the FR Y-9LP quarterly, the FR Y-9SP semiannually, the FR Y-9ES annually, and the FR Y-9CS on a schedule that is determined when this supplement is used.
                </P>
                <P>
                    <E T="03">Legal authorization and confidentiality:</E>
                     The Board has the authority to impose the reporting and recordkeeping requirements associated with the FR Y-9 reports on bank holding companies pursuant to section 5 of the Bank Holding Company Act (BHC Act), (12 U.S.C. 1844); on savings and loan holding companies pursuant to section 10(b)(2) and (3) of the Home Owners' Loan Act, (12 U.S.C. 1467a(b)(2) and (3)); on U.S. intermediate holding companies pursuant to section 5 of the BHC Act, (12 U.S.C 1844), as well as pursuant to sections 102(a)(1) and 165 of the Dodd-Frank Wall Street Reform and Consumer Protection Act (Dodd-Frank Act), (12 U.S.C. 511(a)(1) and 5365); and on securities holding companies pursuant to section 618 of the Dodd-Frank Act, (12 U.S.C. 1850a(c)(1)(A)). The FR Y-9 series of reports, and the recordkeeping requirements set forth in the respective instructions to each report, are mandatory, except for the FR Y-9CS, which is voluntary.
                </P>
                <P>With respect to the FR Y-9C, Schedule HI's memoranda item 7(g), Schedule HC-P's item 7(a), and Schedule HC-P's item 7(b) are considered confidential commercial and financial information under exemption 4 of the FOIA, (5 U.S.C. 552(b)(4)), as is Schedule HC's memorandum item 2.b. for both the FR Y-9C and FR Y-9SP reports.</P>
                <P>Such treatment is appropriate under exemption 4 of the FOIA (5 U.S.C. 552(b)(4)) because these data items reflect commercial and financial information that is both customarily and actually treated as private by the submitter, and which the Board has previously assured submitters will be treated as confidential. It also appears that disclosing these data items may reveal confidential examination and supervisory information, and in such instances, this information would also be withheld pursuant to exemption 8 of the FOIA (5 U.S.C. 552(b)(8)), which protects information related to the supervision or examination of a regulated financial institution.</P>
                <P>In addition, for both the FR Y-9C report and the FR Y-9SP report, Schedule HC's memorandum item 2.b., the name and email address of the external auditing firm's engagement partner, is considered confidential commercial information and protected by exemption 4 of the FOIA (5 U.S.C. 552(b)(4)) if the identity of the engagement partner is treated as private information by HCs. The Board has assured respondents that this information will be treated as confidential since the collection of this data item was proposed in 2004.</P>
                <P>Aside from the data items described above, the remaining data items on the FR Y-9C report and the FR Y-9SP report are generally not accorded confidential treatment. The data items collected on FR Y-9LP, FR Y-9ES, and FR Y-9CS reports, are also generally not accorded confidential treatment. As provided in the Board's Rules Regarding Availability of Information (12 CFR part 261), however, a respondent may request confidential treatment for any data items the respondent believes should be withheld pursuant to a FOIA exemption. The Board will review any such request to determine if confidential treatment is appropriate, and will inform the respondent if the request for confidential treatment has been denied.</P>
                <P>
                    To the extent that the instructions to the FR Y-9C, FR Y-9LP, FR Y-9SP, and FR Y-9ES reports each respectively direct a financial institution to retain the workpapers and related materials used in preparation of each report, such material would only be obtained by the Board as part of the examination or supervision of the financial institution. Accordingly, such information may be considered confidential pursuant to exemption 8 of the FOIA (5 U.S.C. 552(b)(8)). In addition, the financial institution's workpapers and related materials may also be protected by exemption 4 of the FOIA, to the extent such financial information is treated as 
                    <PRTPAGE P="25439"/>
                    confidential by the respondent (5 U.S.C. 552(b)(4)).
                </P>
                <P>
                    <E T="03">Current actions:</E>
                     The Board has temporarily revised the instructions to the FR Y-9C report to accurately reflect the revised definition of “savings deposits” in accordance with the amendments to Regulation D in the interim final rule published on April 28, 2020 (85 FR 23445). Specifically, the Board has temporarily revised the instructions on the FR Y-9C, Schedule HC-E, items 1(b), 1(c), 2(c) and glossary content to remove the transfer or withdrawal limit. As a result of the revision, if a depository institution chooses to suspend enforcement of the six transfer limit on a “savings deposit,” the depository institution may continue to report that account as a “savings deposit” or may instead choose to report that account as a “transaction account.”
                </P>
                <P>
                    (3) 
                    <E T="03">Report title:</E>
                     Consolidated Report of Condition and Income for Edge and Agreement Corporations.
                </P>
                <P>
                    <E T="03">Agency form number:</E>
                     FR 2886b.
                </P>
                <P>
                    <E T="03">OMB control number:</E>
                     7100-0086.
                </P>
                <P>
                    <E T="03">Applicable date:</E>
                     May 1, 2020.
                </P>
                <P>
                    <E T="03">Frequency:</E>
                     Quarterly and annually.
                </P>
                <P>
                    <E T="03">Respondents:</E>
                     Banking Edge and agreement corporations and investment (nonbanking) Edge and agreement corporations.
                </P>
                <P>
                    <E T="03">Estimated number of respondents:</E>
                     Banking Edge and agreement corporations (quarterly): 9; banking Edge and agreement corporations (annually): 1; investment Edge and agreement corporations (quarterly): 21; investment Edge and agreement corporations (annually): 7.
                </P>
                <P>
                    <E T="03">Estimated average hours per response:</E>
                     Banking Edge and agreement corporations (quarterly): 15.77 hours; banking Edge and agreement corporations (annually): 15.87; investment Edge and agreement corporations (quarterly): 11.81; investment Edge and agreement corporations (annually): 10.82.
                </P>
                <P>
                    <E T="03">Estimated annual burden hours:</E>
                     Banking Edge and agreement corporations (quarterly): 568; banking Edge and agreement corporations (annually): 16; investment Edge and agreement corporations (quarterly): 992; investment Edge and agreement corporations (annually): 76.
                </P>
                <P>
                    <E T="03">General description of report:</E>
                     The FR 2886b reporting form is filed quarterly and annually by banking Edge and agreement corporations and investment (nonbanking) Edge and agreement corporations (collectively, Edges or Edge corporations). The mandatory FR 2886b comprises an income statement with two schedules reconciling changes in capital and reserve accounts and a balance sheet with 11 supporting schedules. Other than examination reports, it provides the only financial data available for these corporations. The Federal Reserve is solely responsible for authorizing, supervising, and assigning ratings to Edges. The Federal Reserve uses the data collected on the FR 2886b to identify present and potential problems and monitor and develop a better understanding of activities within the industry.
                </P>
                <P>
                    <E T="03">Legal authorization and confidentiality:</E>
                     Sections 25 and 25A of the Federal Reserve Act authorize the Federal Reserve to collect the FR 2886b (12 U.S.C. 602, 625). The obligation to report this information is mandatory. The information collected on the FR 2886b is generally not considered confidential, but certain data may be exempt from disclosure pursuant to exemptions (b)(4) and (b)(7)(C) of FOIA, (5 U.S.C. 552(b)(4) and (b)(7)(C)). The information exempt from disclosure pursuant to (b)(4) consists of information provided on Schedule RC-M (with the exception for item 3) and on Schedule RC-V, both of which pertain to claims on and liabilities to related organizations. The information exempt from disclosure pursuant to exemption (b)(7)(C) is information provided in the Patriot Act Contact Information section of the reporting form.
                </P>
                <P>
                    <E T="03">Current actions:</E>
                     The Board has temporarily revised the instructions to the FR 2886b to update the definition of “savings deposits” in accordance with the amendments to Regulation D in the interim final rule published on April 28, 2020 (85 FR 23445). Specifically, the Board has temporarily revised the instructions on Schedule RC-E to remove the transfer and withdrawal limit from the definition of a savings deposit. Please note that this revision does not require any changes to the form itself. As a result of the revision, if a depository institution chooses to suspend enforcement of the six transfer limit on a “savings deposit,” the depository institution may continue to report that account as a “savings deposit” or may instead choose to report that account as a “transaction account.”
                </P>
                <SIG>
                    <DATED>Board of Governors of the Federal Reserve System, April 28, 2020.</DATED>
                    <NAME>Michele Taylor Fennell,</NAME>
                    <TITLE>Assistant Secretary of the Board.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09342 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 6210-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Centers for Disease Control and Prevention</SUBAGY>
                <DEPDOC>[CDC-2020-0046; NIOSH-233-C]</DEPDOC>
                <SUBJECT>Hazardous Drugs: Draft NIOSH List of Hazardous Drugs in Healthcare Settings, 2020; Procedures; and Risk Management Information</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Centers for Disease Control and Prevention, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice and request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The National Institute for Occupational Safety and Health (NIOSH) of the Centers for Disease Control and Prevention (CDC), in the Department of Health and Human Services announces that the following draft documents are available for public comment: (1) 
                        <E T="03">NIOSH Procedures for Developing the NIOSH List of Hazardous Drugs in Healthcare Settings (Procedures);</E>
                         (2) 
                        <E T="03">NIOSH List of Hazardous Drugs in Healthcare Settings, 2020</E>
                         (
                        <E T="03">List</E>
                        ), including those drugs proposed for placement on the 2020 
                        <E T="03">List,</E>
                         and (3) 
                        <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings.</E>
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments must be received by June 30, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Comments may be submitted, identified by docket numbers CDC-2020-0046 and NIOSH-233-C, by either of the following two methods:</P>
                    <P>
                        • 
                        <E T="03">Federal eRulemaking Portal:</E>
                          
                        <E T="03">www.regulations.gov</E>
                         Follow the instructions for submitting comments.
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         NIOSH Docket Office, Robert A. Taft Laboratories, MS-C34, 1090 Tusculum Avenue, Cincinnati, OH 45226-1998.
                    </P>
                    <P>
                        <E T="03">Instructions:</E>
                         All information received in response to this notice must include the agency name and the docket numbers (CDC-2020-0046; NIOSH-233-C). All relevant comments received will be posted without change to 
                        <E T="03">www.regulations.gov,</E>
                         including any personal information provided.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Barbara MacKenzie, NIOSH, Robert A. Taft Laboratories, 1090 Tusculum Avenue, MS-C26, Cincinnati, OH 45226, telephone (513) 533-8132 (not a toll free number), email:
                        <E T="03">bmackenzie@cdc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">I. Public Participation</HD>
                <HD SOURCE="HD2">A. Request for Comments</HD>
                <P>
                    Interested parties are invited to participate in this activity by submitting 
                    <PRTPAGE P="25440"/>
                    written views, opinions, recommendations, and/or data. Comments are invited on any topic related to the procedures and drugs identified in this notice, including three draft documents: (1) 
                    <E T="03">NIOSH Procedures for Developing the NIOSH List of Hazardous Drugs in Healthcare Settings (Procedures);</E>
                     (2) 
                    <E T="03">NIOSH List of Hazardous Drugs in Healthcare Settings, 2020</E>
                     (
                    <E T="03">List</E>
                    ), including those drugs identified in this notice as being proposed for placement on the 
                    <E T="03">List;</E>
                     and (3) 
                    <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings.</E>
                     All three draft documents are available in the docket for this activity. NIOSH also invites comments specifically on the following questions related to this activity:
                </P>
                <P>
                    1. Which unique ingredient identifier is the most useful for users of the 
                    <E T="03">List</E>
                    ?
                </P>
                <P>
                    2. Because there is conflicting evidence about the hazard posed by botulinum toxins to the workers who handle these drugs, NIOSH is not proposing the placement of botulinum toxins on the 
                    <E T="03">List</E>
                     at this time and invites additional studies, data, and expert opinions pertinent to this issue in order to evaluate the botulinum toxins more fully.
                </P>
                <HD SOURCE="HD2">
                    B. February 2018 
                    <E T="04">Federal Register</E>
                     Notice
                </HD>
                <P>
                    In a 
                    <E T="04">Federal Register</E>
                     notice (FRN) published on February 14, 2018 (83 FR 6563), NIOSH invited the public to participate in the development of the 
                    <E T="03">List</E>
                     and the procedures used to develop the 
                    <E T="03">List</E>
                     by submitting written views, opinions, recommendations, and/or data. Comments were invited on any topic related to the drugs reviewed by NIOSH for possible placement on the planned 2018 version of the 
                    <E T="03">List.</E>
                     NIOSH also sought comment on a draft 
                    <E T="03">Policy and Procedures for Developing the NIOSH List of Antineoplastic and Other Hazardous Drugs in Healthcare Settings (Policy and Procedures).</E>
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         As discussed later in this notice, NIOSH has revised the draft 
                        <E T="03">Policy and Procedures</E>
                         based on peer reviews and public comments. The new iteration is now referred to as “draft 
                        <E T="03">Procedures”</E>
                         throughout this notice.
                    </P>
                </FTNT>
                <P>
                    Fifty-seven submissions were received in docket CDC-2018-0004 (NIOSH-233-B) from 55 commenters (one commenter sent three separate submissions to the docket). Commenters included pharmacists, professional organizations and associations, pharmaceutical manufacturers, medical centers and/or health systems, individuals who provided their names but not their affiliations, a company that provides risk assessments, a drug database, an insurance company, a medical school professor, a neurologist, and an anonymous commenter. NIOSH also conducted a peer review, with four independent reviewers, of the draft 
                    <E T="03">Policy and Procedures.</E>
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See https://www.cdc.gov/niosh/topics/hazdrug/peer-review-plan.html</E>
                         for the peer review plan for the draft 
                        <E T="03">Policy and Procedures.</E>
                    </P>
                </FTNT>
                <P>
                    Significant peer review and public comments on the draft 
                    <E T="03">Policy and Procedures</E>
                     are summarized and answered below in Section II; public comments on specific drugs are summarized and answered below in Section III.
                </P>
                <P>
                    NIOSH carefully considered all of the peer reviews and public comments and determined that significant, substantial changes should be made to the draft 
                    <E T="03">Policy and Procedures,</E>
                     the list of drugs proposed for placement on the 
                    <E T="03">List,</E>
                     and also to the organization of the 
                    <E T="03">List</E>
                     itself. The new drafts, entitled the 
                    <E T="03">Procedures for Developing the NIOSH List of Hazardous Drugs in Healthcare Settings (Procedures)</E>
                     and the 
                    <E T="03">NIOSH List of Hazardous Drugs in Healthcare Settings, 2020</E>
                     (
                    <E T="03">List</E>
                    ) are found in the Supplemental Materials tab of the docket and are available for public comment, as discussed above.
                </P>
                <P>
                    Public comments on the draft 
                    <E T="03">Policy and Procedures</E>
                     and the drugs proposed for placement on the 
                    <E T="03">List</E>
                     and peer review summaries on specific drugs proposed for placement on the 
                    <E T="03">List</E>
                     are available in dockets CDC-2018-0004 and NIOSH-233-B.
                </P>
                <HD SOURCE="HD1">II. Procedures for Developing the NIOSH List of Hazardous Drugs in Healthcare Settings</HD>
                <P>
                    NIOSH created and periodically updates the 
                    <E T="03">List</E>
                     to assist employers in providing safe and healthful workplaces by offering a list of drugs that meet the NIOSH definition of a hazardous drug. In the February 2018 Request for Comment, NIOSH requested comment on a draft 
                    <E T="03">Policy and Procedures</E>
                     for developing the 
                    <E T="03">List.</E>
                     The draft 
                    <E T="03">Policy and Procedures</E>
                     document was developed to formalize the methodology NIOSH uses to guide the addition of hazardous drugs to the 
                    <E T="03">List</E>
                     and create a process for requesting the removal from or placement of drugs on the 
                    <E T="03">List.</E>
                     Four independent peer reviewers and 55 public commenters offered input on the draft 
                    <E T="03">Policy and Procedures;</E>
                     their substantive comments are summarized below, followed by NIOSH responses.
                </P>
                <HD SOURCE="HD2">A. Peer Review Summaries and NIOSH Responses</HD>
                <P>NIOSH consulted four independent peer reviewers, who were asked to consider the following questions:</P>
                <P>• Does the draft policy and procedures clearly describe the process used by NIOSH to screen and evaluate drugs?</P>
                <P>• Are the screening and evaluation categorization processes described by the draft policy and procedures scientifically sound?</P>
                <P>• Is the set of information sources used for classifying drugs sufficient to identify relevant hazards? Are there other information sources that should be included?</P>
                <P>• Is the threshold of information required to move from the screening process to the full evaluation process clearly described? Is the information threshold scientifically sound?</P>
                <P>• Is the reconsideration process for addition or deletion of a drug to/from the hazardous drug list adequately described?</P>
                <P>• Are there any issues not considered by the charge questions that should be addressed?</P>
                <P>
                    Overall, the independent peer reviewers found the draft 
                    <E T="03">Policy and Procedures</E>
                     to be clearly written and supported by the available science and the reconsideration process (now referred to as “reevaluation”) to be adequate. Two reviewers had questions about the information thresholds required to evaluate drugs, and all reviewers had editorial suggestions for improving the clarity of the draft. Peer reviews on the draft 
                    <E T="03">Policy and Procedures,</E>
                     as well as NIOSH's responses, are discussed below.
                </P>
                <HD SOURCE="HD3">Scientific Approach</HD>
                <P>
                    <E T="03">Peer review comment:</E>
                     Some paragraphs in the section entitled, “Evidence of Health Effects in Workers from Handling Hazardous Drugs” do not belong in the scientific approach section and should be moved to be part of section B “Systematic and Sequential Methodology” section.
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     The frequency of review of the FDA database should be specified earlier in the draft.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     Although NIOSH typically reviews the FDA database on a monthly basis, the draft 
                    <E T="03">Procedures</E>
                     no longer specifies or indicates a frequency of database review to allow for flexibility in the event of unforeseen circumstances.
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH's discussion of an employer-performed site-based risk assessment to control the risk of exposure is confusing when placed in a document describing NIOSH's hazard identification procedures. The 
                    <E T="03">Procedures</E>
                     should state “that this list is [a] hazard identification and not a risk assessment exercise. The subsequent description of a site risk 
                    <PRTPAGE P="25441"/>
                    assessment does not seem appropriate here. The last paragraph of this section is particularly confusing to the reader. . .”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH is reorganizing and streamlining the document to make it more easily understood and to move information on site risk assessment to a separate draft document, 
                    <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings.</E>
                     The draft 
                    <E T="03">Procedures</E>
                     document is now focused on NIOSH's procedure for identifying hazardous drugs and no longer discusses managing the risk of exposure.
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should add “administrative controls” when discussing engineering controls, personal protective equipment, and other steps to manage the risk of exposure, because of their significance “in the well-accepted hierarchy of controls for minimizing exposure to workplace hazards.”
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should list further tools to aid employers to protect workers.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     In streamlining the document to make it more focused on NIOSH's procedures for identifying hazardous drugs, information on controlling the risk of hazardous drug exposure in the workplace was moved to the draft NIOSH document 
                    <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings.</E>
                </P>
                <HD SOURCE="HD3">Application</HD>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should mention “some other common healthcare job categories that are likely to be exposed . . . From my perspective, as a minimum, this should include porters, ward aides and unit clerks.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     Because the draft 
                    <E T="03">Procedures</E>
                     document only addresses NIOSH's procedure for identifying hazardous drugs, the “Application” section is removed. Information about the application of the 
                    <E T="03">List</E>
                     can be found in the introduction of the draft 
                    <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings.</E>
                     However, rather than identifying job-specific titles, the document focuses on workplace activities.
                </P>
                <HD SOURCE="HD3">Definitions</HD>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH did not include a mechanism to place investigational drugs on the 
                    <E T="03">List.</E>
                     There seems to be no “mechanism in place for labeling investigational (
                    <E T="03">i.e.,</E>
                     non-FDA approved drugs used in preclinical and clinical research prior to submission of an NDA [new drug approval]) drugs as potential human health hazards. Although such drugs are not in widespread clinical use, personnel in academic and research-oriented facilities are potentially at risk from exposure to these drugs. . . . the document speaks to the need for individual healthcare workplaces to create their own lists of hazardous drugs, but this places the burden of regulation on these institutions themselves, or more likely individuals within these institutions. I wonder whether the current regulatory climate permits NIOSH any level of control over the handling of drugs in this category.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     Drugs still under investigation are not included on the 
                    <E T="03">List</E>
                     because no scientific information, including information normally provided in package inserts, is available for NIOSH review. Accordingly, the 
                    <E T="03">List</E>
                     is derived only from drugs approved by FDA's Center for Drug Evaluation and Research. For this reason, NIOSH encourages individual healthcare settings to develop their own formulary-specific lists of hazardous drugs, which could include investigational drugs that have not yet been approved by FDA.
                </P>
                <HD SOURCE="HD3">
                    Identifying, Screening, Evaluating, and Reviewing a Drug for Placement on the 
                    <E T="03">List:</E>
                     Screening Potentially Hazardous Drugs
                </HD>
                <P>
                    <E T="03">Peer review comment:</E>
                     It may be inappropriate for NIOSH not to place drugs on the 
                    <E T="03">List</E>
                     when NIOSH has determined there is insufficient information to support the placement. According to the reviewer, “[t]his approach may not be appropriate if indeed the purpose of the screening is to protect the health and well-being of workers who may be exposed to hazardous drugs. From an occupational hygiene perspective, if there is no existing occupational exposure limit or threshold limit value for a chemical hazard, the best practice is to ensure that worker exposure to the chemical remains As Low As Reasonably Achievable (ALARA). This is because there is insufficient information to establish an exposure limit and, therefore, one should err on the side of caution and apply the ALARA principle. Employing this same train of thought to the draft policy and procedures, it would, in my opinion, be a best practice to add the drug that has insufficient information to the 
                    <E T="03">List</E>
                     until suitable scientific evidence demonstrates that it should not be included.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     FDA-approved drugs generally have a reasonable body of toxicity information because the manufacturers are required by FDA to provide this information to ensure patient safety when seeking approval for their drugs. The FDA requirements for tested and reported endpoints generally overlap with the NIOSH definition of a hazardous drug. The fact that FDA has requirements for reporting of relevant safety related data supports the NIOSH presumption that a lack of information on an endpoint indicates a lack of concern for a specific type of hazard.
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     A statement about the evaluation procedures in the draft 
                    <E T="03">Policy and Procedures</E>
                     indicates that NIOSH would only consider human studies. “'When available, published, peer-reviewed scientific literature about the hazard potential of a particular drug, including any studies cited in the package insert that are relevant to workers in a health care setting.' This clearly infers human studies only. However, the remaining parts of the draft policy and procedures mentions that animal studies should be reviewed . . . . It is unclear why animal studies were not included as a source of evaluating potentially hazardous drugs. In my opinion, a review of any animal studies should be conducted as they may offer insight regarding the potential risk posed by a drug. As such, the use of animal studies to evaluate the hazardous nature of a drug should be explicitly stated.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The reviewer has interpreted the NIOSH statement differently than what the agency intended. Animal studies, where available, are also used in our evaluations. The draft 
                    <E T="03">Procedures</E>
                     document is being reorganized to clarify the information NIOSH considers in its evaluations, including relevant animal studies.
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should consider a more detailed process when evaluating study quality because “[t]he issue related to the quality of a study and, in turn, the strength of data 
                    <E T="03">i.e.</E>
                     relative risk, odds ratios, 
                    <E T="03">etc.</E>
                     is not clearly outlined with respect to the evaluation process. Drawing conclusions from a methodologically flawed paper can lead to misclassification of a drug. In addition, having an algorithm to determine the strength of a paper will also aid in minimizing any potential inter- and intra-reviewer differences. Although there is currently some guidance in the footnotes, it may be worthwhile to consider a more detailed evaluation process of relevant studies and place it in a more prominent location in the document or possibly as an Appendix.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The majority of drug evaluations are based on information provided in the drug package insert; NIOSH relies on the quality of science 
                    <PRTPAGE P="25442"/>
                    generated by a drug manufacturer, subsequently reviewed by FDA during the drug approval process, and then published in the drug package insert. Peer-reviewed, published studies are usually not available and therefore evaluating the quality of studies is not typically possible. When studies are available for review of a drug being considered for placement on the 
                    <E T="03">List</E>
                     or for the reevaluation of a drug already on the 
                    <E T="03">List,</E>
                     quality may be evaluated by NIOSH scientists and independent peer reviewers on a case-by-case basis. In the case of a drug being reevaluated, conclusions about study quality would be discussed in a notice published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should provide “a more robust description of the evaluation criteria to include that these are shared across a number of other professional organizations and panels which also endorsed these same criteria.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The NIOSH 
                    <E T="03">List</E>
                     is adopted, endorsed, and/or referenced by a number of non-governmental organizations, including the American Society of Health-System Pharmacists (ASHP), The Joint Commission, and the Oncology Nursing Society.
                </P>
                <P>
                    Because the organizations that may endorse the evaluation criteria may change, NIOSH declines to identify them in the 
                    <E T="03">Procedures</E>
                     document.
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should offer an example of why a drug identified as a hazardous drug because it poses as carcinogenic hazard might not be a classified as a carcinogen pursuant to the NIOSH 
                    <E T="03">Chemical Carcinogen Policy.</E>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     A drug may be considered a hazardous drug but not a chemical carcinogen if, for example, a drug manufacturer includes a carcinogenicity warning in the drug's package insert but the evidence for carcinogenicity has not been reviewed by the International Agency for Research on Cancer (IARC); the National Toxicology Program (NTP), within the U.S. Department of Health and Human Services; the U.S. Environmental Protection Agency (EPA); or independently by NIOSH. In that case, NIOSH may consider it to be appropriately grouped with carcinogenic drugs, although it would not necessarily meet the criteria for an occupational carcinogen according to the NIOSH 
                    <E T="03">Chemical Carcinogen Policy.</E>
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should clarify “how the threshold dosages (10 mg/day or 1 mg/kg/day) for defining organ toxicity at 'low doses' . . . were derived. . . . Are these standard or commonly accepted definitions of 'low dose' exposure? Is there a scientific justification for them? If so, perhaps this could be referenced with a footnote.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The daily therapeutic dose at which serious organ toxicity, developmental toxicity, or reproductive toxicity occurs (10 mg/day in human adults and 1 mg/kg per day in laboratory animals) has long been used by the pharmaceutical industry to develop occupational exposure limits (OELs) of less than 10 μg/m
                    <SU>3</SU>
                     after applying appropriate uncertainty factors.
                    <SU>3</SU>
                    <FTREF/>
                     OELs in this range are typically established for potent or toxic drugs in the pharmaceutical industry. NIOSH is adding text in footnote 16 of the draft 
                    <E T="03">Procedures</E>
                     to clarify and emphasize the derivation.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         Sargent EV and Kirk GD [1988], 
                        <E T="03">Establishing Airborne Exposure Control Limits in the Pharmaceutical Industry,</E>
                         Am Ind Hyg Assoc J 49(6):309-13; Naumann BD and Sargent EV [1997], 
                        <E T="03">Setting Occupational Exposure Limits for Pharmaceuticals,</E>
                         Occup Med 12(1):67-80; Sargent EV, Naumann BD, Dolan DG, Faria EC, Schulman L [2002], 
                        <E T="03">The Importance of Human Data in the Establishment of Occupational Exposure Limits,</E>
                         Hum Ecol Risk Assess 8(4):805-822.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should clarify a sentence concerning NIOSH's preference for human genotoxicity data which states: “If available, NIOSH gives preference to those studies. . .”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     This refers to human genotoxicity studies, which are rarely available. If available, NIOSH would give preference to them over animal and in vitro studies. NIOSH is adding text to clarify the agency's intent.
                </P>
                <P>
                    <E T="03">Peer review comment:</E>
                     “Following the 60-day period to allow for public and stakeholder consultations, it is unclear if NIOSH will be responding to any parties that have provided comments. On the contrary, if a party submits a written request for reconsideration, NIOSH will be responding in these instances. One would assume that, in both instances, a great deal of time and thought is expected to provide feedback to NIOSH. It would presumably be courteous to respond to any party that has provided comments for consideration.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     It is NIOSH practice to respond to all stakeholder and public comments and peer reviews in a 
                    <E T="04">Federal Register</E>
                     notice or in a document posted in the relevant NIOSH docket, to maintain a transparent and thorough administrative record.
                </P>
                <HD SOURCE="HD3">Reconsideration (Reevaluation) of NIOSH Decisions to Place and Remove Drugs</HD>
                <P>
                    <E T="03">Peer review comment:</E>
                     NIOSH should clarify whether a drug may be removed from the 
                    <E T="03">List</E>
                     based on changes to the package insert, “or if written requests from interested parties to the NIOSH Director are the only mechanism for consideration of a drug for deletion from the 
                    <E T="03">List</E>
                     (the reconsideration process as described). If the latter is the case, could a sentence be added to clarify that?”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     A drug may be removed from the 
                    <E T="03">List</E>
                     based on either a written request from an interested party or a change to the package insert. Although rare, NIOSH notes any labeling changes that could affect the status of a drug that has been previously classified as hazardous. No labeling change has ever resulted in the removal of a drug from the 
                    <E T="03">List,</E>
                     but labeling changes that demonstrate a lack of evidence of toxicity would be dealt with in the regular 
                    <E T="03">List</E>
                     updates.
                </P>
                <P>
                    Only when a labeling change results in the addition of MSHI to a package insert will NIOSH automatically consider the drug to be a hazardous drug and add it to the 
                    <E T="03">List.</E>
                </P>
                <HD SOURCE="HD2">B. Public Comment Summaries and NIOSH Responses</HD>
                <P>
                    The public comments have been organized into the following topic areas: organization of the 
                    <E T="03">List</E>
                     and impact of 
                    <E T="03">United States Pharmacopeia (USP) Compounding Compendium</E>
                    chapter &lt;800&gt; Hazardous Drugs—Handling in Healthcare Settings; the nature of the 
                    <E T="03">List</E>
                    —exposure/hazard characterization; monoclonal antibodies; periodicity; methodology/process; criteria clarification; and editorial suggestions.
                </P>
                <HD SOURCE="HD3">
                    Organization of the 
                    <E T="03">List</E>
                    and Impact of USP &lt;800&gt; Hazardous Drugs—Handling in Healthcare Settings
                </HD>
                <P>
                    Seven commenters expressed concern about the impact of USP &lt;800&gt; on the NIOSH 
                    <E T="03">List,</E>
                    and, in turn, the effect on small pharmacies that compound pharmaceutical drugs. USP &lt;800&gt; incorporates by reference the NIOSH 
                    <E T="03">List</E>
                     and imposes certain requirements on its users when handling certain drugs on the 
                    <E T="03">List.</E>
                     The individuals and organizations who commented on this issue felt that USP's use of the NIOSH 
                    <E T="03">List</E>
                     raises the 
                    <E T="03">List</E>
                     to the level of a regulatory action, and should include only antineoplastic drugs on Table 1.
                </P>
                <P>
                    <E T="03">Comment:</E>
                    Prior to USP &lt;800&gt;, the NIOSH 
                    <E T="03">List</E>
                    was considered a “precautionary recommendation.” But the USP &lt;800&gt; standards are too restrictive and overreaching, and the chapter's incorporation into state law places facilities at legal risk if they fail to comply. The ordering of the tables in the 
                    <E T="03">List</E>
                    implies risk stratification; USP &lt;800&gt; supports this impression by requiring heightened handling requirements for Table 1 drugs. Because 
                    <PRTPAGE P="25443"/>
                    Table 1 includes drugs identified as antineoplastic, NIOSH should clarify the rationale and intent of Table 1, since drugs used as antineoplastics, but which are not cytotoxic or genotoxic, as traditional antineoplastics are, have been included. Moreover, USP &lt;800&gt;requires the use of personal protective equipment for Table 1 drugs, which may delay care or undermine patient safety. NIOSH should collaborate with healthcare to better understand the implications of identifying certain drugs as hazardous and the cost to implement USP &lt;800&gt;.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The NIOSH 
                    <E T="03">List</E>
                    creates no legal obligation for its users; it is informational, not regulatory, in content. USP added clarification about the application of chapter &lt;800&gt; to hazardous drugs, which can be found on its FAQ page.
                    <SU>4</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         USP, 
                        <E T="03">FAQs: &lt;800&gt; Hazardous Drugs—Handling in Healthcare Settings, https://www.usp.org/frequently-asked-questions/hazardous-drugs-handling-healthcare-settings.</E>
                    </P>
                </FTNT>
                <P>
                    In response to peer reviews and public comments, NIOSH proposes a reorganization of the tables in the draft 2020 
                    <E T="03">List</E>
                     in a manner that may address at least some of the concerns expressed. Because the way cancer is treated therapeutically has changed, and the classes of drugs used to fight cancer have changed, antineoplastic drugs are no longer all cytotoxic or genotoxic. Furthermore, some drugs carry multiple American Hospital Formulary Service (AHFS) code classifications and are not solely used as antineoplastic drugs. Therefore, when antineoplastic drugs are grouped as they were in earlier versions of Table 1 of the 
                    <E T="03">List,</E>
                     an appearance that these drugs pose the same hazard was inadvertently created (
                    <E T="03">i.e.,</E>
                     non-cytotoxic drugs with cytotoxic drugs). NIOSH determined that grouping all antineoplastic drugs together in one table is no longer the most useful or informative for the user. In light of these changes, NIOSH proposes a new 
                    <E T="03">List</E>
                     structure, described in the preamble to the draft 
                    <E T="03">List,</E>
                     which is available for review in the docket for this activity. Changes to the 
                    <E T="03">List</E>
                     structure would place all drugs that meet the NIOSH definition of a hazardous drug and contain MSHI in the package insert and/or are classified by the National Toxicology Program (NTP) as “known to be a human carcinogen,” or classified by the International Agency for Research on Cancer (IARC) as “carcinogenic” or “probably carcinogenic” on Table 1. Table 2 would now contain drugs that meet one or more of the NIOSH hazardous drug criteria and may be developmental and/or reproductive developmental toxins but are not drugs which have MSHI or are classified as carcinogens or probable carcinogens by NTP or IARC. Table 3 would be removed and the drugs formerly placed in that table placed into Table 1 or 2, accordingly.
                </P>
                <HD SOURCE="HD3">Realistic Risk of Occupational Exposure</HD>
                <P>
                    Nine commenters expressed the sentiment that the 
                    <E T="03">List</E>
                     would be more useful if it identified drugs that pose a realistic risk to healthcare workers.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     NIOSH should identify those drugs that pose a realistic risk to healthcare workers by considering such occupation exposure factors as drug type (
                    <E T="03">e.g.,</E>
                     small molecule, biologic), stability, dosage form, and route of exposure, and then evaluating them against the toxicity criteria. Not refining the 
                    <E T="03">List</E>
                     to identify real risks of occupational exposure could lead to “overwarning” for drugs that present little or no workplace risk.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     Compilation of the 
                    <E T="03">List</E>
                     is a hazard identification and hazard characterization process, as described in the draft 
                    <E T="03">Procedures.</E>
                     The draft 
                    <E T="03">Procedures</E>
                     considers the toxicity criteria in the definition of a hazardous drug to identify the hazard and some intrinsic molecular properties to characterize the hazard 
                    <SU>5</SU>
                    <FTREF/>
                     when determining the potential for adverse health effects of hazardous drugs in healthcare workers. Risks associated with how and how often a hazardous drug is used in a particular setting, and evaluation of exposure factors for all occupational exposures is beyond the scope of the 
                    <E T="03">List.</E>
                     The draft 
                    <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings,</E>
                     which is in the docket for this activity, is intended to assist employers in establishing their own hazardous drugs management procedures specific to their workplace.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         draft 
                        <E T="03">Procedures</E>
                         footnote 18, “Properties of a drug molecule that may limit adverse effects in healthcare workers are typically chemical, physical and structural properties that affect its absorption (ability to enter the cells of the body), distribution, metabolism, and/or elimination 
                        <E T="03">e.g.,</E>
                         chemical structure, molecular weight or mass.”
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Monoclonal Antibodies</HD>
                <P>
                    Seven commenters opposed the inclusion of biological drug products (monoclonal antibodies) on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     The language in the section titled “Application” indicates that the draft 
                    <E T="03">Policy and Procedures</E>
                     do not apply to healthcare workers who handle recombinant therapeutic proteins. Therefore, all recombinant therapeutic proteins should be excluded from the 
                    <E T="03">List</E>
                     unless “science-based or product-specific circumstances dictate otherwise.”
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Monoclonal antibodies (
                    <E T="03">i.e.,</E>
                     therapeutic proteins) are of such a large molecular weight that they do not pose a realistic risk to healthcare workers. For example, monoclonal antibodies “are too large to be absorbed through skin contact, and if ingested, they would be destroyed by digestion; if inhaled, the pulmonary system would prevent absorption. Consequently, these drugs are all administered by injection. The only potential risk to healthcare workers is of an accidental needle stick, which would not inject a pharmacologically active dose.” Accordingly, the monoclonal antibodies bevacizumab, blintumomab, and trastuzumab should not be placed on the 
                    <E T="03">List,</E>
                     and pertuzumab should be removed from Table 1.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     The draft 
                    <E T="03">Policy and Procedures</E>
                     should include a methodology describing how NIOSH evaluates monoclonal antibodies.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH applies the same methodology for evaluating each drug approved by the FDA Center for Drug Evaluation and Research, regardless of class. The definition of a hazardous drug in the draft 
                    <E T="03">Procedures</E>
                     recognizes that the molecular properties of a drug, such as the molecular weight, may substantially limit the potential for adverse health effects. NIOSH may consider molecular weight along with the other intrinsic molecular properties of a drug that affect the hazard a drug poses. While some large molecular weight drugs may have low bioavailability by relevant routes of exposure, other factors in the characterization of the hazard are considered as well. Therefore, in accordance with the draft 
                    <E T="03">Procedures</E>
                     some monoclonal antibodies may not meet the NIOSH definition of the term “hazardous drug.” Because the list of drugs proposed for placement on the 
                    <E T="03">List</E>
                     has been updated based on the draft 
                    <E T="03">Procedures,</E>
                     the monoclonal antibodies bevacizumab and trastuzumab are no longer proposed for placement on the 
                    <E T="03">List.</E>
                     Blinatumomab continues to be proposed for placement and other monoclonal antibodies that have properties meeting the NIOSH definition of a hazardous drug will remain on the 
                    <E T="03">List.</E>
                </P>
                <HD SOURCE="HD3">Periodicity</HD>
                <P>
                    Three commenters offered opinions on the timeliness of the 
                    <E T="03">List,</E>
                     which NIOSH has attempted to publish every 2 years since 2010.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     The 
                    <E T="03">List</E>
                     seems to be heavily weighted toward older drugs.
                    <PRTPAGE P="25444"/>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The 
                    <E T="03">List</E>
                     is about 4 years behind the introduction of new drugs when it is periodically updated because there are several steps in the review process. NIOSH appreciates that a timelier 
                    <E T="03">List</E>
                     might be helpful and is working toward that end. The current 
                    <E T="03">List</E>
                     created by NIOSH requires an extensive review process that does not readily allow more frequent publication. That said, when NIOSH becomes aware of new drugs with MSHI, NIOSH identifies such drugs on the web page for the current 
                    <E T="03">List</E>
                     to immediately alert stakeholders. The inclusion of MSHI makes such drugs automatically hazardous under the NIOSH definition and thus, the extensive review process is not required.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     FDA-approved drugs should be reviewed in real time or NIOSH should provide “off-cycle” updates to the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The 
                    <E T="03">List</E>
                     is updated any time NIOSH is aware that a drug manufacturer has added special handling information to the patient information for a specific drug. For example, three drugs were added to the 2016 
                    <E T="03">List</E>
                     after it was initially published; they are identified on the 
                    <E T="03">NIOSH List of Antineoplastic and Other Hazardous Drugs in Healthcare Settings, 2016</E>
                     web page, 
                    <E T="03">https://www.cdc.gov/niosh/docs/2016-161/default.html.</E>
                     NIOSH's extensive review process only allows for periodic updates of hazardous drugs that do not have MSHI.
                </P>
                <HD SOURCE="HD3">Methodology/Process</HD>
                <P>Seven commenters asked questions and offered suggestions about the procedures themselves.</P>
                <P>
                    <E T="03">Comment:</E>
                     The methodology used to develop the list of drugs proposed for placement on the 
                    <E T="03">List</E>
                     was not the same as the methodology used in previous years.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     In 2004, NIOSH used lists from several organizations as examples of hazardous drugs. In 2010, NIOSH first updated the 
                    <E T="03">List</E>
                     based on the NIOSH definition of a hazardous drug. The draft 
                    <E T="03">Policy and Procedures</E>
                     used to develop the drugs proposed for placement on the 
                    <E T="03">List</E>
                     in the February 2018 FRN described the methodology used by NIOSH since 2010. The draft 
                    <E T="03">Procedures</E>
                     reflects peer review and public comment; the list of drugs proposed for placement on the 
                    <E T="03">List</E>
                     has been updated based on the revised draft 
                    <E T="03">Procedures.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     NIOSH should conduct or commission a meta-analysis or systematic review, “[i]n the absence of published literature synthesizing the body of clinical knowledge” about a specific drug.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     A systematic review is a significant undertaking requiring the prior publication or dissemination of multiple studies relating to a specific drug. In very few cases, if any, would sufficient studies be available to conduct a formal meta-analysis relating to a specific drug. NIOSH will consider conducting a systematic review if such studies become available relating to the hazard that a specific drug may pose in healthcare settings.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     What is the mechanism for evaluating investigational new drugs (
                    <E T="03">i.e.,</E>
                     drugs used in preclinical and clinical research but not yet FDA-approved)?
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     Drugs still under investigation are not included on the 
                    <E T="03">List</E>
                     because no scientific information, including information normally provided in package inserts, is available for NIOSH review. Accordingly, the 
                    <E T="03">List</E>
                     is derived only from drugs approved by FDA's Center for Drug Evaluation and Research. NIOSH does not review drugs that are not yet approved for use in humans. NIOSH does not review biologics reviewed by the FDA Center for Biologics Evaluation and Research.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Peer reviews should be conducted before the close of the public comment period to allow public commenters time to review them. Not allowing public commenters to review peer reviews before submitting their own comments to the docket is “in conflict with the principle of transparency” established in the OMB 
                    <E T="03">Final Information Quality Bulletin for Peer Review</E>
                     (70 FR 2664, Jan. 14, 2005).
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH views peer review and public comment as two distinct, often complementary, tools in ensuring both quality and transparency in influential scientific information products. As stated in the OMB 
                    <E T="03">Final Information Quality Bulletin for Peer Review</E>
                     (Bulletin), “[p]eer reviewers shall be charged with reviewing scientific and technical matters. . .” whereas public comment, including stakeholder review, often provides NIOSH with crucial feedback on how a project or publication may impact the interests of employees, stakeholder organizations, or other parties. While the Bulletin recognizes the benefit of both forms of input to agencies, it provides agencies with broad discretion in determining how to implement peer review, including timing as it relates to public comment, if applicable. NIOSH does not offer peer reviews for public comment for any scientific publications because the technical and scientific review conducted by independent peer reviewers are not NIOSH products.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     The draft 
                    <E T="03">Policy and Procedures</E>
                     should provide the drug manufacturer with “transparent documentation as to the basis of adding a drug to the 
                    <E T="03">List.”</E>
                     Without a thorough understanding of the basis for adding a drug, the drug manufacturer may not be able to formulate a request for reconsideration of the drug.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The rationale for proposing the placement of each drug to the 
                    <E T="03">List</E>
                     is provided in the 
                    <E T="04">Federal Register</E>
                     notice preceding the final 
                    <E T="03">List</E>
                     publication. The manufacturer or any other stakeholder is invited to comment on the sufficiency of the explanation of the basis for adding a drug to the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Providing sufficient information to rebut a NIOSH determination to add or not add a drug to the 
                    <E T="03">List</E>
                     is difficult for healthcare organizations.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     For reevaluation of a listed drug, NIOSH does not require requestors to provide a complete analysis of the available evidence. The requestor need only provide some new information that is relevant to the issue of whether the drug does or does not meet the NIOSH definition of a hazardous drug or the decision to place a drug on a particular table in the 
                    <E T="03">List.</E>
                     NIOSH will begin the reevaluation process for any request to add or remove a drug that provides some new supporting evidence by searching for additional hazard identification (toxicity) and hazard characterization information about the drug that is relevant to the criteria set out in the NIOSH definition of a hazardous drug.
                </P>
                <HD SOURCE="HD3">Criteria Clarification</HD>
                <P>
                    Six commenters were critical of the methodology NIOSH described for adding drugs to the 
                    <E T="03">List</E>
                     and asked that NIOSH clarify the language in certain sections of the draft 
                    <E T="03">Policy and Procedures.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     NIOSH should include the professional qualifications of the NIOSH staff who perform these evaluations.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH relies on a range of knowledge, experience, and skills to evaluate drugs for placement on the 
                    <E T="03">List,</E>
                     including but not limited to pharmacology, toxicology, medicine, and risk evaluation. The specific backgrounds of the professional staff engaged in the evaluation process may change over time, but NIOSH is committed to a high-quality process conducted by a team of professionals with the needed knowledge and experience. Additionally, peer reviews provide the Agency with a review of its science; peer reviewers and their credentials are identified in the NIOSH Peer Review Agenda.
                    <PRTPAGE P="25445"/>
                </P>
                <P>
                    <E T="03">Commenters:</E>
                     NIOSH should identify the criteria used to evaluate study quality and strength, and describe how they are used to critically appraise the quality and risk of bias and other limitations of individual studies; arbitrate conflicting information; and synthesize the totality of animal and human studies data in support of, or opposition to, the listing of a drug as “hazardous.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The majority of these evaluations are based on the information provided in the drug package insert; thus, NIOSH relies on the quality of science generated by a drug manufacturer, subsequently reviewed by FDA during the drug approval process, and then published in the drug package insert. When studies are available for review of a drug being considered for placement on the 
                    <E T="03">List</E>
                     or for the reevaluation of a drug already on the 
                    <E T="03">List,</E>
                     quality may be evaluated by NIOSH scientists and independent peer reviewers on a case-by-case basis. In the case of a drug being reevaluated, conclusions about study quality would be discussed in a 
                    <E T="04">Federal Register</E>
                     notice.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     While NIOSH describes several Bradford Hill criteria 
                    <SU>6</SU>
                    <FTREF/>
                     used to evaluate information from human studies in footnote 44 of the draft 
                    <E T="03">Policy and Procedures,</E>
                     no rationale is offered to explain why many of the original nine Bradford Hill criteria are not used. Moreover, caution should be taken when making determinations about potentially hazardous drugs because causality is not necessarily demonstrated by a strong association just as absence of causality is not necessarily demonstrated by weak associations; associations that demonstrate a monotonic trend in health outcome frequency (steadily increasing or decreasing without ever changing direction) are not necessarily causal if a confounding factor demonstrates a dose-response relationship with the health outcome; and prior beliefs should not be allowed to cloud judgment with regard to plausibility. NIOSH should clarify the criteria described in the footnote and explain how evidence against these various criteria is evaluated, how each independent line of evidence is systematically and critically appraised, how the quality and risk of bias of individual studies is evaluated, how conflicting information is arbitrated, and how the totality of the data is synthesized.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         Aschengrau A, Seage GR [2018], 
                        <E T="03">Essentials of Epidemiology in Public Health. 4th Edition,</E>
                         (Burlington, MA: Jones &amp; Bartlett).
                    </P>
                </FTNT>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH uses the subset of Bradford Hill criteria which are most useful for evaluating human study results on hazardous drugs. The most important criteria for the review of human studies are strength of association, temporality, plausibility, and biological gradient.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     In the draft 
                    <E T="03">Policy and Procedures</E>
                     footnote 45, NIOSH lists criteria used to evaluate information from animal studies. It is unclear if NIOSH will conduct meta-analyses to test for consistency of results; how NIOSH will interpret evidence for, or absence of, concordance across species or between structural analogs of the drug; whether NIOSH will conduct categorical regression analyses to evaluate dose-response data; and how NIOSH evaluates routes of exposures. Furthermore, animal studies must be evaluated for the recovery/reversibility of effects and the pharmacological relevance of the species studied. NIOSH must add criteria for animal studies to include the recovery/reversibility of adverse effects and the pharmacological relevance of the test species.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH has not conducted a formal meta-analysis or systematic review for any drug currently on the 
                    <E T="03">List.</E>
                     In very few cases, if any, would sufficient studies be available to conduct a formal meta-analysis relating to a specific drug. Accordingly, NIOSH primarily uses information available in the package inserts to make determinations about whether to place a drug on the 
                    <E T="03">List.</E>
                     NIOSH may conduct a meta-analysis or systematic review when reevaluating the placement of a drug already on the 
                    <E T="03">List,</E>
                     if the available evidence warrants such a review. In that case, important criteria for animal studies include strength of association; consistency between studies; relevance of the model system and routes of exposure; the duration, reversibility, and recoverability of the observed effects; and concordance of those effects with effects in humans. If a meta-analysis or systematic review is warranted for a reevaluation, NIOSH would consider these criteria on a case-by-case basis. Under the draft 
                    <E T="03">Procedures,</E>
                     NIOSH's rationale, including a description of any meta-analysis or systematic review if performed, and final determination would be described in a notice published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <P>
                    <E T="03">Comment:</E>
                     It is unclear how NIOSH interprets evidence of increasing progression or severity with increased dose, and how the value for “low dose” was derived. Specifically, whether NIOSH conducts categorical regression analyses to evaluate dose-response data for severity. The value for “low dose” should be drug-specific and a function of several factors such as normal therapeutic doses, body weight, and length of exposure.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The daily therapeutic dose at which serious organ toxicity, developmental toxicity, or reproductive toxicity occurs (10 mg/day in human adults and 1 mg/kg per day in laboratory animals) has long been used by the pharmaceutical industry to develop occupational exposure limits (OELs) of less than 10 μg/m
                    <SU>3</SU>
                     after applying appropriate uncertainty factors.
                    <SU>7</SU>
                    <FTREF/>
                     OELs in this range are typically established for potent or toxic drugs in the pharmaceutical industry. NIOSH is adding text in footnote 16 of the draft 
                    <E T="03">Procedures</E>
                     to clarify and emphasize the derivation.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See supra</E>
                         note 3.
                    </P>
                </FTNT>
                <P>
                    <E T="03">Comment:</E>
                     NIOSH should clarify how close chemical analogs are identified, and whether NIOSH establishes site concordance across analogs and how evidence for and against the absence of concordance is interpreted. Similar questions were raised about animal studies.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH examines chemical analogs based on similarities in a drug's structure and toxicity profile compared with other drugs on the 
                    <E T="03">List.</E>
                     Often the mechanism of action for the drug being assessed is known and can be compared to other drugs of a similar structure/activity. This criterion is typically only used when toxicity information specific to the drug under evaluation is insufficient or unavailable but is available for the chemical analog.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Hazardous drugs should also be identified by UNII code (the unique ingredient identifier used by FDA and USP) on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     There are several methods for identifying active pharmaceutical ingredient compounds, including Chemical Abstract Service Registry number (CAS) and UNII. At this time, NIOSH has chosen not to list any of the identification numbers but is considering doing so in the future. NIOSH encourages public input on the question of which ingredient identifier may be the most useful for the 
                    <E T="03">List.</E>
                </P>
                <HD SOURCE="HD3">Editorial Suggestions</HD>
                <P>
                    Two commenters offered editorial suggestions for clarifying language in the draft; although the comments are not summarized here, changes were made to the revised draft 
                    <E T="03">Procedures</E>
                     as appropriate.
                    <PRTPAGE P="25446"/>
                </P>
                <HD SOURCE="HD2">
                    C. Draft 
                    <E T="03">Procedures:</E>
                     Summary of Changes
                </HD>
                <P>
                    NIOSH considered peer review and public comment received in response to the February 2018 FRN, and significantly revised the draft 
                    <E T="03">Policy and Procedures;</E>
                     that document is now called 
                    <E T="03">Procedures.</E>
                     These changes now reflected in the draft 
                    <E T="03">Procedures for Developing the NIOSH List of Hazardous Drugs in Healthcare Settings</E>
                     (draft 
                    <E T="03">Procedures</E>
                    ) include the clarification of some language and streamlining the procedures NIOSH uses to determine the hazard potential of a specific drug. Most importantly, the definition of the term “hazardous drug” would now acknowledge that “hazard characterization” is an important factor for drugs under consideration. Section C of the draft 
                    <E T="03">Procedures,</E>
                     which includes the evaluation criteria, would be expanded to include new clauses 4 and 5 to allow NIOSH to consider additional factors beyond the intrinsic toxicity of the drug molecule in determining whether to place the drug on the 
                    <E T="03">List.</E>
                     The draft 
                    <E T="03">Procedures</E>
                     is in the docket for this activity.
                </P>
                <HD SOURCE="HD1">III. The NIOSH List of Hazardous Drugs in Healthcare Settings, 2020</HD>
                <HD SOURCE="HD2">A. Public Comment Summaries and NIOSH Responses</HD>
                <P>
                    As discussed extensively in the notice published February 14, 2018, NIOSH identified 275 potentially hazardous drugs between January 2014 and December 2015 (83 FR 6563). Of the 275 drugs identified during that timeframe, two had special handling information specified by the manufacturer (MSHI) and were automatically placed on the 
                    <E T="03">List.</E>
                     The other 273 were screened and the information available for 44 drugs suggested one or more toxic effects; those drugs were evaluated by NIOSH and shared with peer reviewers and stakeholders. After considering the peer and stakeholder reviews, NIOSH determined that 20 drugs and one class of drugs exhibit toxicity that meets the NIOSH definition of a hazardous drug and proposed them for placement on the 
                    <E T="03">List.</E>
                     The two drugs with MSHI that were placed on the 
                    <E T="03">List</E>
                     and the 20 drugs and one drug class proposed for placement on the 
                    <E T="03">List</E>
                     were identified in the February 14, 2018 notice, along with NIOSH's rationale for each proposed addition. A new peer review was not conducted. Public comments on the drugs and drug class proposed for placement on the 
                    <E T="03">List</E>
                     in 2018 are summarized and answered below.
                </P>
                <HD SOURCE="HD3">
                    Do Not Place Drug on the 
                    <E T="03">List</E>
                </HD>
                <P>
                    <E T="03">Comment:</E>
                     Botulinum toxins, including abobotulinumtoxinA and onabotulinumtoxinA, should not be placed on the 
                    <E T="03">List.</E>
                     Botulinum toxins do not meet the criteria for placement on the 
                    <E T="03">List;</E>
                     abotulinumtoxinA and rimabotulinumtoxinB did not have labeling changes during the search period January 2014 through December 2015, and changes to the labels for onabotulinumtoxinA and incobotulinumtoxinA do not meet the criteria for organ toxicity at low doses or teratogenicity or other developmental toxicity. Moreover, NIOSH is not properly weighing the low therapeutic index of the drug against the relatively low risk of handling the drug by healthcare workers who are knowledgeable about safe handling. According to the safety data sheets for botulinum toxins, no engineering controls or respiratory protective devices are required for safe handling.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH reviews the relevant data on a drug when a label change is made, not just the data relating to the label change. However, after consideration of input from the public and stakeholders, NIOSH has decided to review the toxicity and the hazards related to occupational exposure to botulinum toxins. Therefore, at this time NIOSH is no longer proposing to place the class of botulinum toxins on the 2020 
                    <E T="03">List.</E>
                     Any additional information from any interested party that will assist with further reviews of the botulinum toxins will be reviewed for potential placement on the 
                    <E T="03">List</E>
                     in the future.
                </P>
                <P>
                    <E T="03">Comment.</E>
                     Darbepoetin alfa should not be placed on the 
                    <E T="03">List.</E>
                     This drug poses no risk to healthcare workers; the evidence supporting its addition is not based on occupational exposure. The large molecular size limits dermal absorption and aerosolization. The drug's mechanism of action does not indicate DNA damage.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH concurs with commenters that the evidence of carcinogenicity for darbepoetin alfa in patients who did not already have cancer was insufficient to support a NIOSH finding of carcinogenicity. In addition, darbepoetin alfa did not meet the NIOSH criteria for a hazardous drug based on any other toxicity endpoint. Accordingly, darbepoetin alfa is no longer proposed for placement on the 2020 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Dihydroergotamine should not be placed on the 
                    <E T="03">List.</E>
                     The safety data sheet for this drug indicates that it does not pose a heightened risk to healthcare workers.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH has determined that dihydroergotamine has demonstrated reproductive toxicity in experimental animals. In embryo-fetal development studies of dihydroergotamine mesylate nasal spray, intranasal administration to pregnant rats throughout the period of organogenesis resulted in decreased fetal body weights and/or skeletal ossification at doses approximately 0.4-1.2 times the exposures in humans receiving the maximum recommended daily dose of 4 mg or greater. Accordingly, NIOSH proposes to place dihydroergotamine on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Exenatide should not be placed on the 
                    <E T="03">List.</E>
                     NIOSH did not take into account the real risk of occupational exposure or the mechanism of action of this relatively large molecule. The size of the molecule limits dermal absorption and aerosolization.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     While some drugs may have low bioavailability by relevant routes of exposure due to molecular weight, other factors in the characterization of the hazard are considered as well. NIOSH has determined that exenatide extended-release caused a dose-related and treatment-duration-dependent increase in the incidence of thyroid C-cell tumors (adenomas and/or carcinomas) at clinically relevant exposures in both genders of rats. In mice, doses near the maximum recommended human dose lead to increased neonatal death. In rats, exenatide administered during the period of organogenesis reduced fetal growth and produced skeletal ossification deficits at doses that approximate the maximum recommended human dose. Accordingly, NIOSH proposes to place exenatide on the 
                    <E T="03">List.</E>
                     Polypeptides of this size and larger have been shown to have bioavailability through relevant routes of exposure. Because dosage forms can change and new dosage forms may be approved, dosage form is not considered in making 
                    <E T="03">List</E>
                     placement determinations.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Interferon beta-1b should not be placed on the 
                    <E T="03">List,</E>
                     or, in the alternative, it should only be placed on Table 3. The rationale for placing interferon beta-1b on the 
                    <E T="03">List</E>
                     is that information from the package insert indicated reproductive toxicity: spontaneous abortion in human clinical trials. Data evaluation submitted to the docket by the manufacturer demonstrates that interferon beta-1b is not causally associated with spontaneous abortion or with any “patterns or signals suggesting pregnancy outcomes.” Research on 
                    <PRTPAGE P="25447"/>
                    populations who have received interferon beta-1b throughout pregnancy have demonstrated no difference in spontaneous abortions or birth weight compared to population comparators.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     The manufacturer provided information indicating that multiple evaluations of pregnancy registries did not provide any signals suggesting negative pregnancy outcomes associated with interferon beta-1b. Accordingly, NIOSH has determined that interferon beta-1b does not meet the criteria for a hazardous drug and is no longer proposing to place it on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Ivabradine should not be placed on the 
                    <E T="03">List.</E>
                     This drug is administered as a coated tablet, self-administered by the patient at home; as such, ivabradine poses no risk to healthcare workers.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH has determined that reproductive effects were observed in pregnant rats at doses near the equivalent maximum recommended human dose. Drugs are placed on the 
                    <E T="03">List</E>
                     based on their intrinsic properties. Because dosage forms can change and new dosage forms may be approved, dosage form is not considered in making 
                    <E T="03">List</E>
                     placement determinations. Accordingly, NIOSH continues to propose placing ivabradine on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Olaparib should not be placed on the 
                    <E T="03">List</E>
                     because the risk to direct occupational healthcare worker exposure is anticipated to be minimal when handling intact olaparib capsules.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH has determined that teratogenicity occurred in rats at doses approximately 0.3 percent of therapeutic doses in humans. Accordingly, NIOSH proposes to place olaparib on the 
                    <E T="03">List.</E>
                     Because dosage forms can change and new dosage forms may be approved, dosage form is not considered in making 
                    <E T="03">List</E>
                     placement determinations.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Osimertinib should not be placed on the 
                    <E T="03">List.</E>
                     Embryo-fetal toxicity is shown to happen at dose exposure 1.5 times the recommended ingested human dose of 80 mg; it is unlikely that a healthcare worker would accidentally be exposed to osimertinib during handling at levels found to cause embryo-fetal harm. In addition, there are no reports of teratogenicity, developmental toxicity, embryo-fetal toxicity, lethality, or reduced growth in clinical trials conducted in humans, or in real world use since FDA approval in 2015.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH has determined that teratogenicity or other developmental toxicity after exposure to osimertinib were observed at doses higher than the maximum recommended human dose and reproductive effects at doses lower than the maximum recommended human doses were equivocal. Therefore, NIOSH no longer proposes to place osimertinib on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Triazolam should not be placed on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH's rationale for proposing the placement of triazolam on the 
                    <E T="03">List</E>
                     was that it mimics the benzodiazepines which are included on the 
                    <E T="03">List</E>
                     because they are teratogenic or cause other developmental effects. However, NIOSH did not independently evaluate triazolam. After review, NIOSH now finds that the information in the package insert for this drug does not support a determination that it presents a hazard to healthcare workers and is no longer proposing to place it on the 
                    <E T="03">List.</E>
                </P>
                <HD SOURCE="HD3">
                    Place Drug on the 
                    <E T="03">List</E>
                </HD>
                <P>
                    <E T="03">Comment:</E>
                     NIOSH indicated that two drugs—daratumumab and dinutuximab—demonstrated insufficient toxicity information available to meet the NIOSH definition of a hazardous drug. Both drugs should be placed on the 
                    <E T="03">List</E>
                     because information available in the respective package inserts indicates that both drugs may cause teratogenic effects. NIOSH should provide the rationale for not proposing their placement on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     As presented in the 2018 FRN, daratumumab and dinutuximab were reviewed and did not meet the NIOSH criteria for a hazardous drug because the available information about each drug's toxicity was insufficient to support placement on the 
                    <E T="03">List.</E>
                     There are no human studies relating to the developmental effects of daratumumab or dinutuximab. No animal studies have been performed regarding developmental effects of daratumumab or dinutuximab. Accordingly, NIOSH is not proposing to place these two drugs on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     NIOSH indicated that 10 drugs—cetuximab, ibrutinib, ipilmumab, necitumumab, nintedanib, nivolumab, palbociclib, panitumumab, ramucirumab, and ruxolitinib—demonstrated available information that shows a toxic effect that does not meet the NIOSH definition of a hazardous drug. These drugs should be placed on the 
                    <E T="03">List</E>
                     because of their teratogenic and/or reproductive effects or the rationale for not proposing their placement on the 
                    <E T="03">List</E>
                     should be further explained.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     As presented in the 2018 FRN, NIOSH reviewed cetuximab, ibrutinib, ipilimumab, necitumumab, nintedanib, nivolumab, palbociclib, panitumumab, ramucirumab, and ruxolitinib for placement on the 
                    <E T="03">List</E>
                     and, for each, the available information showed a toxic effect that does not meet the NIOSH definition of a hazardous drug. For some of these drugs, no drug-specific data were available in the package inserts to support warnings in the inserts regarding developmental or reproductive effects; for other drugs, the toxic effects occurred at doses higher than human recommended doses. For example, NIOSH found that ibrutinib had developmental effects in animals but only at doses twice the maximum recommended human dose of 560 mg/day. If new information becomes available about any of these drugs, NIOSH will reevaluate them in a future update to the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Eight drugs were approved by FDA prior to December 2015, but do not appear on the 2016 
                    <E T="03">List</E>
                     and were not proposed for placement on the 
                    <E T="03">List</E>
                     in the February 2018 FRN. The drugs and rationales for each of them include the following:
                </P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,p1,8/9,i1" CDEF="s50,r150">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Fosamprenavir</ENT>
                        <ENT>Carcinogenicity: Cited studies demonstrated an increased incidence of various oncologic presentations (hepatocellular adenoma/carcinoma, interstitial cell hyperplasia, and uterine endometrial adenocarcinoma), in multiple animal species (rat and mice) at exposure lower than human doses (0.7-1.4 fold in rats and 0.3-0.7 fold in mice compared to a human dosing).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Gefitinib</ENT>
                        <ENT>Carcinogenicity/teratogenicity: Cited studies demonstrated an increased incidence of hepatocellular adenomas in mice. The package insert also cites gefitinib as exhibiting teratogenicity.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Idelalisib</ENT>
                        <ENT>Genotoxicity: Cited studies demonstrated genotoxicity in male rats at high doses (2 grams/kilogram).</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Lapatinib</ENT>
                        <ENT>Reproductive toxicity/teratogenicity: The FDA classifies lapatinib as pregnancy category D indicating positive evidence of human fetal risk. Cited studies in the package insert also demonstrate impaired fertility in rats.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Midostaurin</ENT>
                        <ENT>Reproductive toxicity: Cited studies in the package insert demonstrated reproductive toxicity in male and female rates.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Nicotine</ENT>
                        <ENT>Carcinogenicity/genotoxicity: Cited studies in the package insert demonstrated an increased incidence of tumors in hamsters and rats. Genotoxicity has been noted in Chinese hamster ovary cells.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25448"/>
                        <ENT I="01">Pembrolizumab</ENT>
                        <ENT>Teratogenicity: The package insert contains a warning of embryofetal toxicity when administered to pregnant women. Manufacturer recommendation: that females of reproduction potential use effective contraception during and for four months after completing therapy.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Talimogene laherparepvec</ENT>
                        <ENT>Reproductive toxicity: The package insert contains MSHI stating, “Healthcare providers who are immunocompromised or pregnant should not prepare or administer IMLYGIC and should not come into direct contact with the IMLYGIC injection sites, dressings, or body fluids of treated patients” due to the risk of transmission of talimogene laherparepvec and herpetic infection.</ENT>
                    </ROW>
                </GPOTABLE>
                <P>
                    <E T="03">NIOSH response:</E>
                     Each of these drugs has either been previously reviewed and found not to meet the NIOSH definition of a hazardous drug, falls outside the scope of the 
                    <E T="03">List,</E>
                     or is slated for review in the future. NIOSH's findings about each drug are as follows:
                </P>
                <GPOTABLE COLS="2" OPTS="L2,tp0,p1,8/9,i1" CDEF="s50,r150">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1"> </CHED>
                        <CHED H="1"> </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Fosamprenavir</ENT>
                        <ENT>
                            This drug was reviewed by NIOSH for a previous update to the 
                            <E T="03">List</E>
                             and it did not meet the criteria for a hazardous drug. The available information showed this drug has a toxic effect that does not meet the NIOSH definition of hazardous drug. No new information has been reported that would meet the NIOSH criteria for a hazardous drug. If new information becomes available, NIOSH will reevaluate it in a future update to the 
                            <E T="03">List.</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Gefitinib</ENT>
                        <ENT>
                            This drug was reviewed by NIOSH for a previous update to the 
                            <E T="03">List</E>
                             and it did not meet the criteria for a hazardous drug. However, because new safety information was recently added to the package insert, this drug is scheduled to be reviewed for the update after the 2020 
                            <E T="03">List</E>
                             update.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Idelalisib</ENT>
                        <ENT>
                            This drug was reviewed by NIOSH and presented in the 2018 FRN; it did not meet the criteria for a hazardous drug. The available information does not demonstrate or support a determination that the drug meets the NIOSH definition of hazardous drug. No new information has been reported that would meet the NIOSH criteria for a hazardous drug. If new information becomes available, NIOSH will reevaluate it in a future update to the 
                            <E T="03">List.</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Lapatinib</ENT>
                        <ENT>
                            This drug was reviewed by NIOSH for a previous update to the 
                            <E T="03">List.</E>
                             The available information showed this drug has a toxic effect that does not meet the NIOSH definition of hazardous drug. No new information has been reported that would meet the NIOSH criteria for a hazardous drug. If new information becomes available, NIOSH will reevaluate it in a future update to the 
                            <E T="03">List.</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Midostaurin</ENT>
                        <ENT>
                            This drug was approved by FDA in 2017. This drug is scheduled to be reviewed for the next 
                            <E T="03">List</E>
                             update.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Nicotine</ENT>
                        <ENT>
                            Because drugs sold over the counter are not contemplated in this activity, this drug has not been and will not be reviewed for placement on the 
                            <E T="03">List.</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Pembrolizumab</ENT>
                        <ENT>
                            This drug was reviewed by NIOSH and presented in the 2018 FRN; the available information shows a toxic effect that does not meet the NIOSH definition of hazardous drug. It is scheduled to be re-reviewed for the next update to the 
                            <E T="03">List,</E>
                             because new information has been added to the package insert.
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Talimogene laherparepvec</ENT>
                        <ENT>
                            This oncolytic viral therapy product is outside the scope of NIOSH's definition of a hazardous drug because it is approved by FDA's Center for Biologics Evaluation and Research. NIOSH's definition of a hazardous drug only covers drugs approved by FDA's Center for Drug Evaluation and Research and is not considered for inclusion on the 
                            <E T="03">List.</E>
                        </ENT>
                    </ROW>
                </GPOTABLE>
                <HD SOURCE="HD3">
                    Move From One Table on the 
                    <E T="03">List</E>
                     to Another
                </HD>
                <P>
                    <E T="03">Comment:</E>
                     The hormonal agents in Table 1 of the 2016 
                    <E T="03">List</E>
                     that are exclusively reproductive risks, including estrogens (estrogen agonist-antagonists such as tamoxifen and antiestrogens such as anastrozole, exemestane, and letrozole), gonadotropins (leuprolide and triptorelin), antigonadotrophins (degarelix), and progestins (megestrol) should be moved to Table 2 or 3.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Monoclonal antibodies do not have a cytotoxic mechanism of action and, as such, do not pose the same level of occupational risk or toxicity as conventional antineoplastic drugs. Those monoclonal antibodies that are not directly cytotoxic or conjugated with a cytotoxic agent should be moved from Table 1 to another place on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    Similarly, small-molecule kinase inhibitors, such as afatinib, crizotinib, dabrafenib, and imatinib, act through a targeted mechanism of action and are not directly cytotoxic; they primarily pose a reproductive and teratogenic risk. As such, they should be moved from Table 1 to another place on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     After scientific review and consideration of input from peer reviewers and public commenters, NIOSH is proposing a reorganization of the 
                    <E T="03">List.</E>
                     As cancer therapy has changed from primarily cytotoxic drugs to non-cytotoxic and targeted therapies, there is sometimes a mismatch in general recommendations for safe handling and the hazardous nature of the drugs. In light of these changes, NIOSH proposes a new 
                    <E T="03">List</E>
                     structure, described in the preamble to the 
                    <E T="03">List,</E>
                     which is available for review in the docket for this activity. In accordance with the new structure, many of the hormonal agents on the 2016 
                    <E T="03">List</E>
                     have been moved to Table 2. Hormonal agents that are classified by NTP as “known to be a human carcinogen” or by IARC as “carcinogenic” or “probably carcinogenic” will be identified in Table 1.
                </P>
                <HD SOURCE="HD3">
                    Remove Drug From 
                    <E T="03">List</E>
                </HD>
                <P>
                    <E T="03">Comment:</E>
                     Bacillus Calmette-Guerin (BCG) should be removed from the 
                    <E T="03">List.</E>
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     BCG, a vaccine approved by the FDA Center for Biologics Evaluation and Research, was included in the original 2004 Alert and `grandfathered' into the 
                    <E T="03">List.</E>
                     However, because NIOSH has reaffirmed in the draft 
                    <E T="03">Procedures</E>
                     that only those drugs approved by the FDA Center for Drug Evaluation and Research are included in the 
                    <E T="03">List,</E>
                     BCG is no longer included in the 
                    <E T="03">List.</E>
                </P>
                <HD SOURCE="HD3">Drugs Handled Inconsistently</HD>
                <P>
                    <E T="03">Comment:</E>
                     The drugs ibrutinib and blinatumomab, both antineoplastic monoclonal antibodies, are treated inconsistently in the February 2018 FRN. Ibrutinib was identified as a drug for which the available information shows a toxic effect that does not meet the NIOSH definition of a hazardous drug; blinatumomab was proposed for placement on the 
                    <E T="03">List</E>
                     on the basis of evidence which shows the drug is a neurotoxin at low doses. NIOSH should consider whether reliance on the AHFS Class 10:00 (antineoplastic agents) alone “is enough to necessitate Table 1 
                    <PRTPAGE P="25449"/>
                    inclusion even if a drug does need to be on the NIOSH list.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     In response to input from peer reviewers and external comments and following scientific review, NIOSH proposes a reorganization of the tables in the draft 2020 
                    <E T="03">List</E>
                     in a manner that may address at least some of the concerns expressed. Because the way cancer is treated therapeutically has changed, and the types of drugs used to fight cancer have changed, antineoplastic drugs are no longer all cytotoxic, genotoxic, and highly hazardous chemicals. Furthermore, some drugs carry multiple AHFS code classifications and are not just antineoplastic drugs. Therefore, when antineoplastic drugs are grouped, as they were in earlier versions of Table 1, drugs that required different levels of protection were grouped together (non-cytotoxic drugs with cytotoxic drugs). NIOSH determined that grouping all antineoplastic drugs together in one table is no longer the most useful or informative for the user. In light of these changes, NIOSH proposes a new 
                    <E T="03">List</E>
                     structure, described in the preamble to the draft 
                    <E T="03">List,</E>
                     which is available for review in the docket for this activity.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     Azole antifungal drugs are being treated inconsistently. Fluconazole is included in the 
                    <E T="03">List</E>
                     on Table 3, but for two newer azole antifungals, the available information showed a toxic effect that does not meet the NIOSH definition of a hazardous drug (ketoconazole) and information does not demonstrate or support that the drug meets the NIOSH definition (itraconazole) in the FRN. Thus, neither was proposed for placement on the 
                    <E T="03">List</E>
                     in the February 2018 FRN.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     NIOSH has evaluated each drug individually and not by class of drug. Two very similar drugs may have substantially different toxicities and at different doses. Fluconazole meets the NIOSH criteria for a hazardous drug while the other two, ketoconazol and itraconazole, do not. Animal data on the developmental effects of fluconazole suggest developmental changes in rats at doses less than the equivalent maximum human recommended dose of 400 mg/day. In humans receiving 400 mg/day or higher developmental effects consistent with animal data have been observed and epidemiological data suggest a risk of spontaneous abortions and congenital abnormalities in infants whose mothers were treated with 150 mg/day fluconazole. Data on the developmental effects of itraconazole and ketoconazole suggest developmental toxicity has only been observed in doses greater than the maximum human recommended dose.
                </P>
                <HD SOURCE="HD3">Add New Category of Drugs</HD>
                <P>
                    <E T="03">Comment:</E>
                     Add a new category for drugs that sublime and offer information about proper handling, including the conditions under which sublimation (transition of a solid substance to a gas) happens as well as the need to filter and exhaust the work area where such drugs are used. The 
                    <E T="03">List</E>
                     should also indicate that hazardous drugs that do not sublime may be exhausted through a HEPA filter back into the work area.
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     Sublimation depends on the drug form and is not an inherent toxicity property of the drug. Accordingly, drugs that sublime should be handled using risk management strategies relevant to the conditions of use. Although assessing specific controls for specific exposure situations is beyond the scope of the 
                    <E T="03">List,</E>
                     information about the use of respiratory protection in the handling of hazardous drugs is found in the draft risk management document, 
                    <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings,</E>
                     which is available in the docket for this activity.
                </P>
                <P>
                    <E T="03">Comment:</E>
                     The 
                    <E T="03">List</E>
                     should identify those hazardous drugs that are both cytotoxic and cytostatic as well as volatile. The drugs pose the greatest risk to healthcare workers, “based on a combination of volatility and dose-related toxic potential of those vapors.”
                </P>
                <P>
                    <E T="03">NIOSH response:</E>
                     Only a few of the drugs on the 
                    <E T="03">List</E>
                     are known to have an appreciable vapor pressure; reliable information concerning the vapor pressure of most drugs can be difficult to identify. Because this issue is a matter of delivery form, rather than inherent toxicity, it is currently beyond the scope of the 
                    <E T="03">List.</E>
                     NIOSH will consider identifying hazardous drugs that are known to be volatile in future updates to the 
                    <E T="03">List.</E>
                </P>
                <HD SOURCE="HD2">B. Draft NIOSH List of Hazardous Drugs in Healthcare Settings, 2020: Summary of Changes</HD>
                <P>
                    In February 2018, NIOSH proposed adding 21 drugs (including one class of drugs) to the 
                    <E T="03">List.</E>
                     After evaluating public comments, NIOSH made the following determination:
                </P>
                <P>
                     13 drugs are proposed for placement on the 
                    <E T="03">List</E>
                </P>
                <P>
                     3 drugs are automatically added to the 
                    <E T="03">List</E>
                     because they have MSHI in the package insert (2 drugs identified in the 2018 FRN and another recently-approved by FDA)
                </P>
                <P>
                     7 drugs proposed for placement on the 
                    <E T="03">List</E>
                     in the 2018 FRN are no longer considered in this action
                </P>
                <P>
                    The 13 drugs proposed for placement on the 
                    <E T="03">List</E>
                     are presented for public comment in the table below, along with the rationale for their placement on the 
                    <E T="03">List.</E>
                </P>
                <P>
                    Two drugs included in the 2018 FRN, inotuzumab ozogamicin and trabectedin, have MSHI and are automatically added to the 2016 
                    <E T="03">List.</E>
                     One additional drug, polatuzumab vedotin, was approved by FDA's Center for Drug Evaluation and Research in July/August 2019 and its package insert includes MSHI provided by the drug's manufacturer. Because drugs with MSHI are automatically placed on the 
                    <E T="03">List</E>
                     and are not subject to public or peer review, polatuzumab vedotin was added to the 2016 
                    <E T="03">List</E>
                     in September 2019 and will appear in the 2020 
                    <E T="03">List.</E>
                    <SU>8</SU>
                    <FTREF/>
                     These three drugs do not appear below because they are not subject to public comment.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See https://www.cdc.gov/niosh/docs/2016-161/default.html</E>
                         for all drugs with special handling information added to the 2016 
                        <E T="03">List.</E>
                    </P>
                </FTNT>
                <P>
                    The following seven drugs that were proposed for placement on the 
                    <E T="03">List</E>
                     in the February 2018 FRN are no longer proposed for placement on the 
                    <E T="03">List,</E>
                     for the reasons discussed above in Sections II.B. and III.B: bevacizumab, botulinum toxins, darbepoetin alfa, interferon beta-1b, osimertinib, trastuzumab, and triazolam.
                </P>
                <GPOTABLE COLS="02" OPTS="L2,i1" CDEF="s75,r200">
                    <TTITLE>Drugs Proposed for Placement on the NIOSH List of Hazardous Drugs in Healthcare Settings, 2020</TTITLE>
                    <BOXHD>
                        <CHED H="1">
                            Generic drug name 
                            <E T="0731">a</E>
                             and AHFS class 
                            <E T="0731">b</E>
                        </CHED>
                        <CHED H="1">
                            Rationale 
                            <E T="0731">c</E>
                             and proposed location 
                            <E T="0731">d</E>
                             on the 
                            <E T="7462">List</E>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">
                            Blinatumomab
                            <LI>AHFS Class: Antineoplastic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Organ toxicity at low doses:</E>
                                 neurotoxicity at low doses in patients in clinical studies.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25450"/>
                        <ENT I="01">
                            Ceritinib
                            <LI>AHFS Class: Antineoplastic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Developmental toxicity:</E>
                                 embryo-fetal toxicity at low doses in rats and rabbits.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Clobazam
                            <LI>AHFS Class: Antiepileptic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Reproductive toxicity and Developmental toxicity:</E>
                                 embryo-fetal mortality and other harm at low doses in rats and rabbits, present in human breast milk.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Cobimetinib
                            <LI>AHFS Class: Antineoplastic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Reproductive toxicity and Developmental toxicity:</E>
                                 increased post-implantation loss, including total litter loss in rats at low doses; post-implantation loss and fetal malformations in humans.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Dihydroergotamine
                            <LI>AHFS Class: 5-hydroxytryptamine (HT) receptor binder</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Reproductive toxicity:</E>
                                 oxytocic properties at low doses in humans.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Exenatide
                            <LI>AHFS Class: Antidiabetic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Carcinogenicity and Developmental toxicity:</E>
                                 thyroid C-cell tumors in rat studies; adverse fetal effects in rats and mice.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Isotretinoin
                            <LI>AHFS Class: Retinoid</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Developmental toxicity:</E>
                                 severe fetal malformations at any dose in humans.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Ivabradine
                            <LI>AHFS Class: Hyperpolarization-activated cyclic nucleotide-gated (HCN) blocker</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Developmental toxicity:</E>
                                 embryo-fetal toxicity and teratogenicity at low doses in rats.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Lenvatinib
                            <LI>AHFS Class: Antineoplastic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Developmental toxicity:</E>
                                 embryo-fetal toxicity at low doses in rats and rabbits; abortifacient in rabbits at low doses.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>
                                <E T="03">Table 2:</E>
                                 No MSHI, not classified as known or probable carcinogen by NTP or IARC.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Miltefosine
                            <LI>AHFS Class: Antibiotic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Developmental toxicity:</E>
                                 fetal death and teratogenicity at low doses in rats and rabbits.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>Table 2: No MSHI, not classified as known or probable carcinogen by NTP or IARC.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Olaparib
                            <LI>AHFS Class: Antineoplastic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Carcinogenicity and Developmental toxicity:</E>
                                 myelodysplastic syndrome/acute myeloid leukemia in patients in clinical studies; embryo-fetal toxicity, post implantation loss, malformations at low doses in rats.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>Table 2: No MSHI, not classified as known or probable carcinogen by NTP or IARC.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Sonidegib
                            <LI>AHFS Class: Antineoplastic</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Reproductive toxicity and Developmental toxicity:</E>
                                 embryo-fetal toxicity, teratogenesis, and spontaneous abortions at low doses in rabbits.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>Table 2: No MSHI, not classified as known or probable carcinogen by NTP or IARC.</LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">
                            Urofollitropin
                            <LI>AHFS Class: Ovulation stimulator</LI>
                        </ENT>
                        <ENT>
                            Rationale
                            <LI>
                                <E T="03">Developmental toxicity:</E>
                                 drug is known to cause fetal harm in patients.
                            </LI>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="22"> </ENT>
                        <ENT>
                            Proposed Location
                            <LI>Table 2: No MSHI, not classified as known or probable carcinogen by NTP or IARC.</LI>
                        </ENT>
                    </ROW>
                    <TNOTE>
                        <SU>a</SU>
                         FDA-approved drug (January 2014-December 2015).
                    </TNOTE>
                    <TNOTE>
                        <SU>b</SU>
                         AHFS (American Hospital Formulary Service) Pharmacologic-Therapeutic Classification system.
                    </TNOTE>
                    <TNOTE>
                        <SU>c</SU>
                         
                        <E T="03">See Procedures</E>
                         section IV.
                    </TNOTE>
                    <TNOTE>
                        <SU>d</SU>
                         NIOSH proposes that the 
                        <E T="03">List</E>
                         include only two tables. Table 1 includes only those drugs that contain MSHI in the package insert; and/or meet the NIOSH definition of a hazardous drug and are classified by the NTP as “known to be a human carcinogen,” or classified by the IARC as “carcinogenic” or “probably carcinogenic.” Table 2 includes those drugs that meet the NIOSH definition of a hazardous drug but are not drugs that have MSHI or are classified by the NTP as “known to be a human carcinogen,” or classified by the IARC as “carcinogenic” or “probably carcinogenic.”
                    </TNOTE>
                </GPOTABLE>
                <PRTPAGE P="25451"/>
                <HD SOURCE="HD2">C. NIOSH List of Hazardous Drugs in Healthcare Settings, 2020—Title, Reorganization, and Removals</HD>
                <P>
                    NIOSH has retitled and reorganized the 
                    <E T="03">List</E>
                     in response to comments received. Many of the drugs currently used to fight cancer function differently than those previously used. Antineoplastic drugs are no longer all cytotoxic, genotoxic, and highly hazardous chemicals. Therefore, when drugs are grouped by their function (
                    <E T="03">i.e.,</E>
                     antineoplastic), as they were in earlier versions of Table 1, drugs that required different protective measures were grouped together (non-cytotoxic drugs with cytotoxic drugs). NIOSH has determined that grouping all antineoplastic drugs together in one table is no longer the most useful or informative for users. Therefore, NIOSH has regrouped the tables by hazard. The 
                    <E T="03">List</E>
                     now comprises only two tables: 
                </P>
                <EXTRACT>
                    <P>Table 1: Drugs that contain MSHI in the package insert and/or meet the NIOSH definition of a hazardous drug and are classified by NTP as “known to be a human carcinogen,” or classified by IARC as “carcinogenic” or “probably carcinogenic.”</P>
                    <P>Table 2: Drugs that meet the NIOSH definition of a hazardous drug, but do not have MSHI and are not classified by NTP as “known to be a human carcinogen,” or classified by IARC as “carcinogenic” or “probably carcinogenic.”</P>
                </EXTRACT>
                <P>
                    Additional changes to the 
                    <E T="03">List,</E>
                     including those drugs proposed for removal from the 
                    <E T="03">List,</E>
                     are described in detail in the draft 
                    <E T="03">NIOSH List of Hazardous Drugs in Healthcare Settings, 2020,</E>
                     which is available for review in the docket for this activity.
                </P>
                <HD SOURCE="HD1">IV. Risk Management for Hazardous Drugs in Healthcare Settings</HD>
                <P>
                    In the 2016 
                    <E T="03">List,</E>
                     Table 5 provided information on recommended exposure controls for hazardous drugs based on formulations. In order to clarify that the 
                    <E T="03">List</E>
                     is a hazard identification tool, NIOSH has removed this table from the document. In its place, NIOSH has developed a new, comprehensive document on risk management strategies entitled, 
                    <E T="03">Managing Hazardous Drug Exposures: Information for Healthcare Settings,</E>
                     which includes a revision of this table on control approaches to safe handling of hazardous drugs. The new risk management document is available for review in the docket for this activity.
                </P>
                <P>
                    NIOSH is seeking input from the public on the draft risk management strategies document and table to ensure that they contain accurate and helpful information. Independent peer reviewers are being consulted as well; their charge is available on the NIOSH website 
                    <SU>9</SU>
                    <FTREF/>
                     and includes the following questions. NIOSH encourages public comment on these questions.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         NIOSH Peer Review Agenda, 
                        <E T="03">https://www.cdc.gov/niosh/review/peer/isi/healthsafetyrisks.html</E>
                        .
                    </P>
                </FTNT>
                <P>1. Please provide feedback on the overall document:</P>
                <P>a. What additional information would improve its usefulness and why?</P>
                <P>b. What changes could be made to improve the utility of the information?</P>
                <P>c. What information is redundant, incorrect, missing, or not needed? Please explain.</P>
                <P>2. Please provide any additional studies or scientific information that evaluate or validate engineering, work practice or administrative controls to reduce exposures to hazardous drugs in healthcare settings.</P>
                <P>3. Please provide any additional studies or scientific information that support or validate the use of the NIOSH recommended control strategies or alternative strategies to control exposures to hazardous drugs.</P>
                <P>4. Please provide any additional studies or scientific information that support or validate evidence-based strategies or approaches for controlling exposures to hazardous drugs that are different from those that NIOSH has proposed.</P>
                <P>5. NIOSH has provided its proposed recommendations and related information about controlling hazardous drugs in the Table of Control Approaches in Chapter 8.</P>
                <P>a. What additional information would improve the usefulness of this table and why?</P>
                <P>b. What structural or format changes could be made to improve the utility of this table?</P>
                <P>c. What information is redundant, incorrect, missing, or not needed? Please explain.</P>
                <P>6. What improvements could be made to this risk management information to make it more useful to employers and healthcare workers? Please provide specific examples.</P>
                <P>7. Please provide information about your professional experience, if any, of implementing control strategies for exposures to hazardous drugs in healthcare or similar settings. Please describe what you found to be most or least effective and why. Include relevant publications if available.</P>
                <P>8. Please provide any additional studies or scientific information related to the use of a medical surveillance program as an additional approach to protect workers in healthcare settings. Information of particular interest includes considerations for design and implementation of a medical surveillance program, data analysis, and communication of results to participants.</P>
                <SIG>
                    <NAME>John J. Howard,</NAME>
                    <TITLE>Director,National Institute for Occupational Safety and Health, Centers for Disease Control and Prevention.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09332 Filed 4-30-20; 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>Mine Safety and Health Research Advisory Committee (MSHRAC)</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 CDC announces the following meeting for the Mine Safety and Health Research Advisory Committee (MSHRAC). This is a virtual meeting. It is open to the public, limited only by web conference lines (500 web conference lines are available). If you wish to attend, please contact Marie Chovanec by email at 
                        <E T="03">MChovanec@cdc.gov</E>
                         or by telephone at 412-386-5302 at least 5 business days in advance of the meeting. She will provide you the Zoom web conference access.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The meeting will be held on June 2, 2020, 10:00 a.m.-2:30 p.m., EDT.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The Zoom web conference access can be obtained via email at 
                        <E T="03">MChovanec@cdc.gov</E>
                         or by telephone at 412-386-5302.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jeffrey H. Welsh, Designated Federal Officer, MSHRAC, NIOSH, CDC, 626 Cochrans Mill Road, Pittsburgh, PA 15236, telephone 412-386-4040; email 
                        <E T="03">jwelsh@cdc.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Purpose:</E>
                     This committee is charged with providing advice to the Secretary, Department of Health and Human Services; the Director, CDC; and the Director, NIOSH, on priorities in mine safety and health research, including grants and contracts for such research, 30 U.S.C. 812(b)(2), Section 102(b)(2).
                </P>
                <P>
                    <E T="03">Matters to be Considered:</E>
                     The agenda will include discussions on mining safety and health research projects and outcomes, including updates from one MSHRAC Workgroup, the Health Advisory in the Mining Program 
                    <PRTPAGE P="25452"/>
                    (HAMP) Workgroup, NIOSH Miner Health Program strategic plan, NIOSH Mining respirable crystalline silica research, Understanding elongate mineral particle exposure in mining, Research roadmap for haul truck health and safety issues, and Future of the coal industry presentation. The meeting will also include an update from the NIOSH Associate Director for Mining. Agenda items are subject to change as priorities dictate.
                </P>
                <P>
                    The Director, Strategic Business Initiatives Unit, Office of the Chief Operating Officer, Centers for Disease Control and Prevention, has been delegated the authority to sign 
                    <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, Strategic Business Initiatives Unit, Office of the Chief Operating Officer, Centers for Disease Control and Prevention.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09306 Filed 4-30-20; 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>Advisory Committee on Breast Cancer in Young Women (ACBCYW); Cancellation of Meeting</SUBJECT>
                <P>Notice is hereby given of a change in the meeting of the Advisory Committee on Breast Cancer in Young Women (ACBCYW); May 13, 2020, 8:00 a.m. to 1:00 p.m., EDT.</P>
                <P>
                    The teleconference and web conference, which was published in the 
                    <E T="04">Federal Register</E>
                     on March 16, 2020, Volume 85, Number 51, page 14945, is being canceled in its entirety.
                </P>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Jeremy McCallister, Designated Federal Officer, National Center for Chronic Disease Prevention and Health Promotion, CDC, 4770 Buford Hwy. NE, Mailstop S107-4, Atlanta, Georgia 30341, Telephone (404) 639-7989, Fax (770) 488-4760; Email: 
                        <E T="03">acbcyw@cdc.gov.</E>
                    </P>
                    <P>
                        The Director, Strategic Business Initiatives Unit, Office of the Chief Operating Officer, Centers for Disease Control and Prevention, has been delegated the authority to sign 
                        <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, Strategic Business Initiatives Unit, Office of the Chief Operating Officer, Centers for Disease Control and Prevention.</TITLE>
                    </SIG>
                </FURINF>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09305 Filed 4-30-20; 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>
                <DEPDOC>[Docket No. CDC-2019-0069]</DEPDOC>
                <SUBJECT>Proposed Update of the CDC's 2006 Revised Recommendations for HIV Testing of Adults, Adolescents, and Pregnant Women in Health-Care Settings; Re-opening of the Comment Period</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.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Centers for Disease Control and Prevention (CDC) in the Department of Health and Human Services (HHS) announces the re-opening of this docket to obtain additional public comment on the proposed update of the 2006 Revised Recommendations for HIV Testing. CDC is re-opening this docket at the request of the public.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Electronic or written comments must be received by June 30, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>You may submit comments, identified by Docket No. CDC-2019-0069, by any of the following methods below. CDC does not accept public comment by email.</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>
                         DHAP Guideline Team, Centers for Disease Control and Prevention, 1600 Clifton Road, NE, MS US8-4, Atlanta, Georgia 30329.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Priya Jakhmola, Health Scientist, Centers for Disease Control and Prevention, 1600 Clifton Road NE, MS US8-4, Atlanta, Georgia 30329. Telephone: 404-639-2495, Email: 
                        <E T="03">dhapguideline@cdc.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <HD SOURCE="HD1">Public Participation</HD>
                <P>Interested persons or organizations are invited to participate by submitting written views, recommendations, and data related to HIV screening approaches. In addition, CDC invites comments specifically on opt-out routine HIV testing, including, but not limited to:</P>
                <FP SOURCE="FP-1">• Suggestions for revisions, edits, and new additions</FP>
                <FP SOURCE="FP-1">• Contemporary issues and new evidence</FP>
                <FP SOURCE="FP-1">• Implementation barriers, challenges, and lessons learned</FP>
                <FP SOURCE="FP-1">• Examples of innovative models, partnerships, and collaborations</FP>
                <P>
                    Please note that comments received, including attachments and other supporting materials, are part of the public record and are subject to public disclosure. Comments will be posted on 
                    <E T="03">https://www.regulations.gov</E>
                    . Therefore, do not include any information in your comments or supporting materials that you consider confidential or inappropriate for public disclosure. If you include your name, contact information, or other information that identifies you in the body of your comments, that information will be on public display. CDC will review all submissions and may choose to redact, or withhold, submissions containing private or proprietary information, inappropriate language, or examples of a mass-mail campaign. CDC will carefully consider all comments submitted in preparation of the final document and may revise the final document as appropriate.
                </P>
                <HD SOURCE="HD1">Background</HD>
                <P>On August 30, 2019, CDC published a notice (84 FR 45495) announcing the availability of a Proposed Update of the CDC's 2006 Revised Recommendations for HIV Testing of Adults, Adolescents, and Pregnant Women in Health-Care Settings. The comment period ended October 28, 2019. CDC received a request from the public to re-open the comment period.</P>
                <P>
                    The CDC guideline “Revised Recommendations for HIV Testing of Adults, Adolescents, and Pregnant Women in Health-Care Settings” was published on September 22, 2006 in CDC's 
                    <E T="03">Morbidity and Mortality Weekly Report</E>
                     (MMWR). Since then, there have been changes in evidence related to HIV testing technologies and interventions, disease epidemiology, outcomes, implementation resources, and related guidelines. This evidence will be identified, assessed, and analyzed to inform the update of the guideline.
                </P>
                <P>
                    CDC will update the 2006 guideline based on input from subject matter experts, public health agencies, the public, and other stakeholders. The guideline development process will draw on up-to-date nationally and internationally accepted guideline 
                    <PRTPAGE P="25453"/>
                    development criteria, tools, and resources, including CDC guideline development standards. The process will include a rigorous systematic review of key questions formulated through the PICO (Patient-Intervention-Comparator-Outcome) method. PICO is the foundation of an evidence-based process and facilitates the search for relevant evidence by identifying key concepts and formulating a search strategy. Graded recommendations will be developed using quality and strength of underlying evidence.
                </P>
                <P>Throughout the process of updating the guideline, there will be multiple opportunities for the public to comment on the drafts. We welcome input from a diverse range of perspectives, which will inform the development of the guideline, improve its credibility, and increase the transparency of the process.</P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Sandra Cashman,</NAME>
                    <TITLE>Executive Secretary, Centers for Disease Control and Prevention.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09348 Filed 4-30-20; 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>Health Resources and Services Administration</SUBAGY>
                <SUBJECT>Agency Information Collection Activities: Submission to OMB for Review and Approval; Public Comment Request; Information Collection Request Title: Bureau of Health Workforce Substance Use Disorder Evaluation, OMB No. 0906-xxxx-NEW</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Health Resources and Services Administration (HRSA), Department of Health and Human Services.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In compliance with the Paperwork Reduction Act of 1995, HRSA has submitted an Information Collection Request (ICR) to the Office of Management and Budget (OMB) for review and approval. Comments submitted during the first public review of this ICR will be provided to OMB. OMB will accept further comments from the public during the review and approval period. OMB may act on HRSA's ICR only after the 30 day comment period for this Notice has closed.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments on this ICR should be received no later than June 1, 2020.</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 a copy of the clearance requests submitted to OMB for review, email Lisa Wright-Solomon, the HRSA Information Collection Clearance Officer at 
                        <E T="03">paperwork@hrsa.gov</E>
                         or call (301) 443-1984.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P SOURCE="NPAR">
                    <E T="03">Information Collection Request Title:</E>
                     Bureau of Health Workforce Substance Use Disorder (SUD) Evaluation, OMB No. 0906-xxxx-New.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     In September 2017, HRSA's Bureau of Health Workforce launched a multi-part effort to increase the workforce capacity of the U.S. health care system to prevent and treat the opioid crisis. As a part of this effort, HRSA developed or expanded activities under five programs to help combat the crisis: (1) The National Health Service Corps (NHSC) Loan Repayment Program offers loan repayment to providers focused on Substance Use Disorder treatment (NHSC SUD Workforce Loan Repayment Program (LRP)); (2) the National Health Service Corps Rural Communities Loan Repayment Program (NHSC Rural Communities LRP); (3) the Opioid Workforce Expansion Program (OWEP); (4) the Behavioral Health Workforce Education and Training Program (BHWET); and (5) the Graduate Psychology Education (GPE) Program. These programs provide either loan repayment to providers (NHSC SUD Workforce LRP, NHSC Rural Communities LRP), or funding for training programs for behavioral health professionals and paraprofessionals to increase integrated behavioral health into primary care treatment and interprofessional team-based care to high-need areas (OWEP, BHWET, GPE).
                </P>
                <P>The purpose of the planned evaluation is to assess these programs with respect to their stated goals of increasing access to the number of clinicians delivering evidence-based SUD treatment, enhancing education and training in substance use prevention and treatment for current and future health care professionals and paraprofessionals in rural and underserved communities, and integrating behavioral health into primary care to improve the capacity of the health care delivery system to provide SUD prevention and treatment services.</P>
                <P>
                    The evaluation will include data collection through web-based surveys to trainees, recipients of loan repayments, grantee organizations, and training sites participating in HRSA's SUD prevention and treatment programs. At the trainee/participant level, questions will focus on educational and professional background; motivation and incentives to join or leave the program; training experiences; perceived readiness to deliver SUD treatment services (where applicable); capacity to engage in prevention strategies; and post-graduation employment (where applicable). At the recipient grantee organization level 
                    <E T="03">(note: This level is not relevant to the NHSC programs),</E>
                     questions will focus on recruitment and retention of students, how their SUD prevention and treatment training program curriculum was developed, as applicable, collaboration with SUD prevention and treatment training sites, plans for sustainability of SUD prevention and treatment activities, as well as any other benefits that resulted from the program. At the site level, questions will focus on SUD prevention and treatment training such as addressing motivation for the site to participate, whether and what type of integrated care delivery is available, and other organizational factors of the site. At all three levels, and for all programs, we will collect survey SUD prevention and treatment training data on satisfaction with the program and recommendations for improving it.
                </P>
                <P>
                    In total, six survey instruments will be used in this evaluation: (1) NHSC SUD Workforce Loan Repayment Program/NHSC Rural Communities Loan Repayment Program/NHSC Loan Repayment Program—Participant Survey; (2) NHSC Loan Repayment Program— Site Survey; (3) Grantee Training and Educational Programs—Trainee Survey; (4) Grantee Training and Educational Programs—Alumni Survey; (5) Grantee Training and Educational Programs—Site Survey; and (6) Grantee Training and Educational Programs—Grantee Organization Survey. As part of a comprehensive questionnaire design process, questions will be limited and refined to collect information not available through secondary sources. Any data collected will not be duplicative of that collected under progress reports or other HRSA grant monitoring. NHSC site and participant survey questions will be drawn from prior NHSC Satisfaction Surveys, which were fielded in 2017 and 2018 but were discontinued. Skip patterns will allow respondents to answer only relevant questions for each of their programs. Participation in all surveys is voluntary, and all surveys 
                    <PRTPAGE P="25454"/>
                    will be fielded annually for three years beginning in 2020 and concluding at the end of 2022 to include each annual cohort of trainees and participants. Each trainee, participant, or site will complete their respective surveys one time.
                </P>
                <P>
                    A 60-day notice published in the 
                    <E T="04">Federal Register</E>
                     on January 24, 2020, vol. 85, No. 16; pp. 4327-29. There were no public comments.
                </P>
                <P>
                    <E T="03">Need and Proposed Use of the Information:</E>
                     The purpose of this effort is to evaluate HRSA's SUD prevention and treatment expansion program investments with respect to the following objectives:
                </P>
                <P>
                    • 
                    <E T="03">Objective 1:</E>
                     What is the impact of the NHSC SUD Workforce LRP and the NHSC Rural Communities LRP on the provision of SUD services in underserved areas compared to those who participate in the non-SUD NHSC LRP?
                </P>
                <P>
                    • 
                    <E T="03">Objective 2:</E>
                     How are the activities in the BHWET, GPE, and OWEP programs contributing to the expansion of service delivery for SUD prevention and treatment, at the individual, educational, and service-delivery system levels?
                </P>
                <P>
                    • 
                    <E T="03">Objective 3:</E>
                     To what extent are HRSA's programs successful at increasing access to treatment for SUD, including opioid treatment services?
                </P>
                <P>The survey data will be critical to understanding the factors related to the success of current HRSA programs, and assist in the development of future programs and ongoing SUD prevention and treatment workforce policy development.</P>
                <P>
                    <E T="03">Likely Respondents:</E>
                     Data will be collected from trainees, grantee organizations, and sites participating in HRSA's SUD prevention and treatment expansion programs as described below.
                </P>
                <P>
                    <E T="03">NHSC SUD Workforce Loan Repayment Program/NHSC Rural Communities LRP/NHSC LRP—Participants Survey:</E>
                     All NHSC SUD Workforce LRP participants, NHSC Rural Communities LRP participants, and NHSC traditional LRP participants who have served at an NHSC site for at least nine months will be invited to respond. Respondents will also include those whom have exited a program early to understand reasons for termination.
                </P>
                <P>
                    <E T="03">NHSC Loan Repayment Program—Site Survey:</E>
                     All sites that were approved to receive NHSC resources, regardless if they currently have a participant on staff will be invited to respond.
                </P>
                <P>
                    <E T="03">Grantee Training and Educational Programs—Trainee Survey:</E>
                     All individuals identified by a grantee as currently receiving training as part of one of the grantee training and educational programs will be invited to respond. Respondents will also include those who have exited a program early, to understand reasons for termination.
                </P>
                <P>
                    <E T="03">Grantee Training and Educational Programs—Alumni Survey:</E>
                     All individuals who completed the Grantee Training and Educational Program Trainee Survey but had not completed their training at the time of the trainee survey, will be invited to respond to this short survey which will ask about employment since graduation.
                </P>
                <P>
                    <E T="03">Grantee Training and Educational Programs—Site Survey:</E>
                     All sites that were approved to receive BHWET, OWEP, or GPE trainees, regardless of whether they currently have trainees, will be invited to respond.
                </P>
                <P>
                    <E T="03">Grantee Training and Educational Programs—Grantee Organization Survey:</E>
                     All grantee organizations that received awards in fiscal year (FY) 2018 for the BHWET program, and received FY 2019 awards for the GPE and OWEP programs will be invited to respond.
                </P>
                <P>
                    <E T="03">Burden Statement:</E>
                     Burden in this context means the time expended by persons to generate, maintain, retain, disclose or provide the information requested. This includes the time needed to review instructions; to develop, acquire, install, and utilize technology and systems for the purpose of collecting, validating, and verifying information, processing and maintaining information, and disclosing and providing information; to train personnel and to be able to respond to a collection of information; to search data sources; to complete and review the collection of information; and to transmit or otherwise disclose the information. The total annual burden hours estimated for this ICR are summarized in the table below.
                </P>
                <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s100,12,12,12,12,12">
                    <TTITLE>Total Estimated Annualized Burden—Hours</TTITLE>
                    <BOXHD>
                        <CHED H="1">Form name</CHED>
                        <CHED H="1">
                            Number of
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Number of
                            <LI>responses per</LI>
                            <LI>respondent</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>responses</LI>
                        </CHED>
                        <CHED H="1">
                            Average
                            <LI>burden per</LI>
                            <LI>response</LI>
                            <LI>(in hours)</LI>
                        </CHED>
                        <CHED H="1">
                            Total
                            <LI>burden hours</LI>
                        </CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">NHSC Loan Repayment Programs- Participant Survey</ENT>
                        <ENT>8,000</ENT>
                        <ENT>1</ENT>
                        <ENT>8,000</ENT>
                        <ENT>0.33</ENT>
                        <ENT>2,640</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">NHSC Loan Repayment Programs- Site Survey</ENT>
                        <ENT>18,000</ENT>
                        <ENT>1</ENT>
                        <ENT>18,000</ENT>
                        <ENT>0.33</ENT>
                        <ENT>5,940</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Grantee Programs- Trainee Survey</ENT>
                        <ENT>8,000</ENT>
                        <ENT>1</ENT>
                        <ENT>8,000</ENT>
                        <ENT>0.33</ENT>
                        <ENT>2,640</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Grantee Programs- Alumni Survey</ENT>
                        <ENT>2,000</ENT>
                        <ENT>1</ENT>
                        <ENT>2,000</ENT>
                        <ENT>0.16</ENT>
                        <ENT>320</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Grantee Programs- Site Survey</ENT>
                        <ENT>5,000</ENT>
                        <ENT>1</ENT>
                        <ENT>5,000</ENT>
                        <ENT>0.33</ENT>
                        <ENT>1,650</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Grantee Programs- Grantee Organization Survey</ENT>
                        <ENT>300</ENT>
                        <ENT>1</ENT>
                        <ENT>300</ENT>
                        <ENT>0.33</ENT>
                        <ENT>99</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total</ENT>
                        <ENT>41,300</ENT>
                        <ENT/>
                        <ENT>41,300</ENT>
                        <ENT/>
                        <ENT>13,289</ENT>
                    </ROW>
                </GPOTABLE>
                <SIG>
                    <NAME>Maria G. Button,</NAME>
                    <TITLE>Director, Executive Secretariat.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09254 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4165-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>Health Resources and Services Administration</SUBAGY>
                <SUBJECT>Meeting of the National Advisory Council on the National Health Service Corps</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Health Resources and Services Administration (HRSA), Department of Health and Human Services.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; correction.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        The National Advisory Council on the National Health Service Corps (NACNHSC) meeting scheduled for Tuesday, June 16, 2020, and Wednesday, June 17, 2020, has changed its format, date, and time. The decision to change the NACNHSC meeting has been made after carefully examining the Centers for Disease Control and Prevention's recommendations to restrict all non-essential travel, and the 
                        <PRTPAGE P="25455"/>
                        widespread health risks posed by COVID-19 to the American public. The public meeting will now be a one-day webinar and conference call held only on Tuesday, June 16, 2020, from 9:30 a.m.-1:30 p.m. Eastern Time. The webinar link, conference dial-in number, meeting materials, and updates will be available on the NACNHSC website: 
                        <E T="03">https://nhsc.hrsa.gov/about/national-advisory-council-nhsc/index.html.</E>
                    </P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Diane Fabiyi-King, Designated Federal Official, Division of the National Health Service Corps, HRSA. Address: 5600 Fishers Lane, Room 14N110, Rockville, Maryland 20857; phone (301) 443-3609; or 
                        <E T="03">DFabiyi-King@hrsa.gov.</E>
                    </P>
                    <P>
                        <E T="03">Correction: This meeting will be a one-day webinar and conference call only, rather than an in-person, two-day meeting as previously announced in the</E>
                          
                        <E T="7462">Federal Register</E>
                        <E T="03">, Vol. 84, No. 244 on Thursday, December 19, 2019 (FR Doc. 2019-27357 Filed 12-18-19).</E>
                    </P>
                    <SIG>
                        <NAME>Maria G. Button,</NAME>
                        <TITLE>Director, Executive Secretariat.</TITLE>
                    </SIG>
                </FURINF>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09264 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4165-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Human Genome Research Institute; Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to section 10(d) of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.</P>
                <P>The meeting will be closed to the public in accordance with the provisions set forth in sections 552b(c)(4) and 552b(c)(6), Title 5 U.S.C., as amended. The grant applications and the discussions could disclose confidential trade secrets or commercial property such as patentable material, and personal information concerning individuals associated with the grant applications, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Human Genome Research Institute Special Emphasis Panel Genomic Resource SEP.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         June 9, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         11:00 a.m. to 4:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Human Genome Research Institute, National Institutes of Health, 6700 B Rockledge Drive, Room 3189 Bethesda, MD 20892 (Telephone Conference Call).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Keith McKenney, Ph.D. Scientific Review Officer National Human Genome Research Institute  National Institutes of Health 6700 B Rockledge Drive, Room 3189 Bethesda, MD 20892 301-594-4280 
                        <E T="03">mckenneyk@mail.nih.gov.</E>
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.172, Human Genome Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: April 27, 2020. </DATED>
                    <NAME>Melanie Pantoja,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09309 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Human Genome Research Institute; Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to section 10(d) of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.</P>
                <P>The meeting will be closed to the public in accordance with the provisions set forth in sections 552b(c)(4) and 552b(c)(6), Title 5 U.S.C., as amended. The grant applications and the discussions could disclose confidential trade secrets or commercial property such as patentable material, and personal information concerning individuals associated with the grant applications, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Human Genome Research Institute Initial Review Group; Genome Research Review Committee.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         June 4, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         11:00 a.m. to 4:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Human Genome Research Institute, National Institutes of Health, 6700B Rockledge Drive, Room 3189, Bethesda, MD 20892 (Telephone Conference Call).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Keith McKenney, Ph.D., Scientific Review Officer, National Human Genome Research Institute, National Institutes of Health,  6700B Rockledge Drive, Room 3189, Bethesda, MD 20892, 301-594-4280, 
                        <E T="03">mckenneyk@mail.nih.gov</E>
                        .
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.172, Human Genome Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: April 27, 2020. </DATED>
                    <NAME>Melanie J. Pantoja,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09308 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>Center for Scientific Review; Notice of Closed Meetings</SUBJECT>
                <P>Pursuant to section 10(d) of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meetings.</P>
                <P>The meetings will be closed to the public in accordance with the provisions set forth in sections 552b(c)(4) and 552b(c)(6), Title 5 U.S.C., as amended. The grant applications and the discussions could disclose confidential trade secrets or commercial property such as patentable material, and personal information concerning individuals associated with the grant applications, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Cardiovascular and Respiratory Sciences Integrated Review Group; Lung Cellular, Molecular, and Immunobiology Study Section.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         June 2-3, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:00 a.m. to 3:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Dr., Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         George M Barnas, Ph.D., Scientific Review Officer Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Room 2180, MSC 7818, Bethesda, MD 20892, 301-435-0696, 
                        <E T="03">barnasg@csr.nih.gov</E>
                        .
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Digestive, Kidney and Urological Systems Integrated Review Group; Kidney Molecular Biology and Genitourinary Organ Development.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         June 4, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         8:00 a.m. to 6:30 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Dr., Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Ganesan Ramesh, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Room 2182, MSC 7818 Bethesda, MD 20892, 301-827-5467, 
                        <E T="03">ganesan.ramesh@nih.gov</E>
                        .
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Oncology 1-Basic Translational Integrated Review Group; Tumor Cell Biology Study Section.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         June 4-5, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         8:00 a.m. to 5:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II 6701, Rockledge Dr., Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Charles Morrow, MD, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Room 6202, 
                        <PRTPAGE P="25456"/>
                        MSC 7804, Bethesda, MD 20892, 301-408-9850, 
                        <E T="03">morrowcs@csr.nih.gov</E>
                        .
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Infectious Diseases and Microbiology Integrated Review Group; Bacterial Pathogenesis Study Section.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         June 4-5, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:00 a.m. to 6:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Dr., Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Marci Scidmore, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Room 3192, MSC 7808, Bethesda, MD 20892 301-435-1149 
                        <E T="03">marci.scidmore@nih.gov</E>
                        ,
                    </P>
                    <P>
                        <E T="03">Name of Committee:</E>
                         Cell Biology Integrated Review Group; Development—1 Study Section.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         June 4, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:30 a.m. to 6:00 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate grant applications.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institutes of Health, Rockledge II, 6701 Rockledge Drive, Bethesda, MD 20892 (Virtual Meeting).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Thomas Beres, Ph.D., Scientific Review Officer, Center for Scientific Review, National Institutes of Health, 6701 Rockledge Drive, Room 5148, MSC 7840 Bethesda, MD 20892, 301-435-1175, 
                        <E T="03">berestm@mail.nih.gov</E>
                        .
                    </P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.306, Comparative Medicine; 93.333, Clinical Research, 93.306, 93.333, 93.337, 93.393-93.396, 93.837-93.844, 93.846-93.878, 93.892, 93.893, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Tyeshia M. Roberson,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09307 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4140-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                <SUBAGY>National Institutes of Health</SUBAGY>
                <SUBJECT>National Institute of Allergy and Infectious Diseases; Notice of Closed Meeting</SUBJECT>
                <P>Pursuant to section 10(d) of the Federal Advisory Committee Act, as amended, notice is hereby given of the following meeting.</P>
                <P>The meeting will be closed to the public in accordance with the provisions set forth in sections 552b(c)(4) and 552b(c)(6), Title 5 U.S.C., as amended. The contract proposals and the discussions could disclose confidential trade secrets or commercial property such as patentable material, and personal information concerning individuals associated with the contract proposals, the disclosure of which would constitute a clearly unwarranted invasion of personal privacy.</P>
                <EXTRACT>
                    <P>
                        <E T="03">Name of Committee:</E>
                         National Institute of Allergy and Infectious Diseases Special Emphasis Panel NIAID Omnibus BAA 2020-1: Research Area 003—Advanced Development of Vaccine Candidates for Biodefense and Emerging Infectious Diseases.
                    </P>
                    <P>
                        <E T="03">Date:</E>
                         May 11, 2020.
                    </P>
                    <P>
                        <E T="03">Time:</E>
                         9:30 a.m. to 3:30 p.m.
                    </P>
                    <P>
                        <E T="03">Agenda:</E>
                         To review and evaluate contract proposals.
                    </P>
                    <P>
                        <E T="03">Place:</E>
                         National Institute of Allergy and Infectious Diseases, National Institutes of Health, 5601 Fishers Lane, Room 3G41B, Rockville, MD 20892 (Telephone Conference Call).
                    </P>
                    <P>
                        <E T="03">Contact Person:</E>
                         Zhuqing (Charlie) Li, Ph.D., Scientific Review Officer, Scientific Review Program, Division of Extramural Activities, National Institute of Allergy and Infectious Diseases, National Institutes of Health, 5601 Fishers Lane, Room 3G41B, Bethesda, MD 20892-9823, (240) 669-5068, 
                        <E T="03">zhuqing.li@nih.gov.</E>
                    </P>
                    <P>This notice is being published less than 15 days prior to the meeting due to the timing limitations imposed by the review and funding cycle.</P>
                    <FP>(Catalogue of Federal Domestic Assistance Program Nos. 93.855, Allergy, Immunology, and Transplantation Research; 93.856, Microbiology and Infectious Diseases Research, National Institutes of Health, HHS)</FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Tyeshia M. Roberson,</NAME>
                    <TITLE>Program Analyst, Office of Federal Advisory Committee Policy.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09310 Filed 4-30-20; 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>Current List of HHS-Certified Laboratories and Instrumented Initial Testing Facilities Which Meet Minimum Standards To Engage in Urine and Oral Fluid Drug Testing for Federal Agencies</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Substance Abuse and Mental Health Services Administration, HHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Health and Human Services (HHS) notifies federal agencies of the laboratories and Instrumented Initial Testing Facilities (IITFs) currently certified to meet the standards of the Mandatory Guidelines for Federal Workplace Drug Testing Programs using Urine or Oral Fluid (Mandatory Guidelines).</P>
                    <P>
                        A notice listing all currently HHS-certified laboratories and IITFs is published in the 
                        <E T="04">Federal Register</E>
                         during the first week of each month. If any laboratory or IITF certification is suspended or revoked, the laboratory or IITF will be omitted from subsequent lists until such time as it is restored to full certification under the Mandatory Guidelines.
                    </P>
                    <P>If any laboratory or IITF has withdrawn from the HHS National Laboratory Certification Program (NLCP) during the past month, it will be listed at the end and will be omitted from the monthly listing thereafter.</P>
                    <P>
                        This notice is also available on the internet at 
                        <E T="03">https://www.samhsa.gov/workplace/resources/drug-testing/certified-lab-list.</E>
                    </P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Anastasia Donovan, Division of Workplace Programs, SAMHSA/CSAP, 5600 Fishers Lane, Room 16N06B, Rockville, Maryland 20857; 240-276-2600 (voice); 
                        <E T="03">Anastasia.Donovan@samhsa.hhs.gov</E>
                         (email).
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Department of Health and Human Services (HHS) notifies federal agencies of the laboratories and Instrumented Initial Testing Facilities (IITFs) currently certified to meet the standards of the Mandatory Guidelines for Federal Workplace Drug Testing Programs (Mandatory Guidelines) using Urine and of the laboratories currently certified to meet the standards of the Mandatory Guidelines using Oral Fluid.</P>
                <P>
                    The Mandatory Guidelines using Urine were first published in the 
                    <E T="04">Federal Register</E>
                     on April 11, 1988 (53 FR 11970), and subsequently revised in the 
                    <E T="04">Federal Register</E>
                     on June 9, 1994 (59 FR 29908); September 30, 1997 (62 FR 51118); April 13, 2004 (69 FR 19644); November 25, 2008 (73 FR 71858); December 10, 2008 (73 FR 75122); April 30, 2010 (75 FR 22809); and on January 23, 2017 (82 FR 7920).
                </P>
                <P>
                    The Mandatory Guidelines using Oral Fluid were first published in the 
                    <E T="04">Federal Register</E>
                     on October 25, 2019 (84 FR 57554) with an effective date of January 1, 2020.
                </P>
                <P>The Mandatory Guidelines were initially developed in accordance with Executive Order 12564 and section 503 of Public Law 100-71 and allowed urine drug testing only. The Mandatory Guidelines using Urine have since been revised, and new Mandatory Guidelines allowing for oral fluid drug testing have been published. The Mandatory Guidelines require strict standards that laboratories and IITFs must meet in order to conduct drug and specimen validity tests on specimens for federal agencies. HHS does not allow IITFs for oral fluid testing.</P>
                <P>
                    To become certified, an applicant laboratory or IITF must undergo three 
                    <PRTPAGE P="25457"/>
                    rounds of performance testing plus an on-site inspection. To maintain that certification, a laboratory or IITF must participate in a quarterly performance testing program plus undergo periodic, on-site inspections.
                </P>
                <P>Laboratories and IITFs in the applicant stage of certification are not to be considered as meeting the minimum requirements described in the HHS Mandatory Guidelines using Urine and/or Oral Fluid. An HHS-certified laboratory or IITF must have its letter of certification from HHS/SAMHSA (formerly: HHS/NIDA), which attests that the test facility has met minimum standards. HHS does not allow IITFs for oral fluid testing.</P>
                <HD SOURCE="HD1">HHS-Certified Laboratories Certified To Conduct Oral Fluid Drug Testing</HD>
                <P>In accordance with the Mandatory Guidelines using Oral Fluid dated October 25, 2019 (84 FR 57554), the following HHS-certified laboratories meet the minimum standards to conduct drug and specimen validity tests on oral fluid specimens:</P>
                <P>At this time, there are no laboratories certified to conduct drug and specimen validity tests on oral fluid specimens.</P>
                <HD SOURCE="HD1">HHS-Certified Instrumented Initial Testing Facilities Certified To Conduct Urine Drug Testing</HD>
                <P>In accordance with the Mandatory Guidelines using Urine dated January 23, 2017 (82 FR 7920), the following HHS-certified IITFs meet the minimum standards to conduct drug and specimen validity tests on urine specimens:</P>
                <FP SOURCE="FP-1">Dynacare, 6628 50th Street NW, Edmonton, AB Canada T6B 2N7, 780-784-1190 (Formerly: Gamma-Dynacare Medical Laboratories).</FP>
                <HD SOURCE="HD1">HHS-Certified Laboratories Certified To Conduct Urine Drug Testing</HD>
                <P>In accordance with the Mandatory Guidelines using Urine dated January 23, 2017 (82 FR 7920), the following HHS-certified laboratories meet the minimum standards to conduct drug and specimen validity tests on urine specimens:</P>
                <FP SOURCE="FP-1">Alere Toxicology Services, 1111 Newton St., Gretna, LA 70053, 504-361-8989/800-433-3823 (Formerly: Kroll Laboratory Specialists, Inc., Laboratory Specialists, Inc.).</FP>
                <FP SOURCE="FP-1">Alere Toxicology Services, 450 Southlake Blvd., Richmond, VA 23236, 804-378-9130 (Formerly: Kroll Laboratory Specialists, Inc., Scientific Testing Laboratories, Inc.; Kroll Scientific Testing Laboratories, Inc.).</FP>
                <FP SOURCE="FP-1">Clinical Reference Laboratory, Inc., 8433 Quivira Road, Lenexa, KS 66215-2802, 800-445-6917.</FP>
                <FP SOURCE="FP-1">Cordant Health Solutions, 2617 East L Street, Tacoma, WA 98421, 800-442-0438 (Formerly: STERLING Reference Laboratories).</FP>
                <FP SOURCE="FP-1">Desert Tox, LLC, 10221 North 32nd Street, Suite J, Phoenix, AZ 85028, 602-457-5411.</FP>
                <FP SOURCE="FP-1">DrugScan, Inc., 200 Precision Road, Suite 200, Horsham, PA 19044, 800-235-4890. </FP>
                <FP SOURCE="FP-1">Dynacare *, 245 Pall Mall Street, London, ONT, Canada N6A 1P4, 519-679-1630 (Formerly: Gamma-Dynacare Medical Laboratories).</FP>
                <FP SOURCE="FP-1">ElSohly Laboratories, Inc., 5 Industrial Park Drive, Oxford, MS 38655, 662-236-2609.</FP>
                <FP SOURCE="FP-1">Laboratory Corporation of America Holdings, 7207 N. Gessner Road, Houston, TX 77040, 713-856-8288/800-800-2387.</FP>
                <FP SOURCE="FP-1">Laboratory Corporation of America Holdings, 69 First Ave., Raritan, NJ 08869, 908-526-2400/800-437-4986 (Formerly: Roche Biomedical Laboratories, Inc.).</FP>
                <FP SOURCE="FP-1">Laboratory Corporation of America Holdings, 1904 TW Alexander Drive, Research Triangle Park, NC 27709, 919-572-6900/800-833-3984 (Formerly: LabCorp Occupational Testing Services, Inc., CompuChem Laboratories, Inc.; CompuChem Laboratories, Inc., A Subsidiary of Roche Biomedical Laboratory; Roche CompuChem Laboratories, Inc., A Member of the Roche Group).</FP>
                <FP SOURCE="FP-1">Laboratory Corporation of America Holdings, 1120 Main Street, Southaven, MS 38671, 866-827-8042/800-233-6339 (Formerly: LabCorp Occupational Testing Services, Inc.; MedExpress/National Laboratory Center).</FP>
                <FP SOURCE="FP-1">LabOne, Inc. d/b/a Quest Diagnostics, 10101 Renner Blvd., Lenexa, KS 66219, 913-888-3927/800-873-8845 (Formerly: Quest Diagnostics Incorporated; LabOne, Inc.; Center for Laboratory Services, a Division of LabOne, Inc.).</FP>
                <FP SOURCE="FP-1">Legacy Laboratory Services Toxicology, 1225 NE 2nd Ave., Portland, OR 97232, 503-413-5295/800-950-5295. </FP>
                <FP SOURCE="FP-1">MedTox Laboratories, Inc., 402 W. County Road D, St. Paul, MN 55112, 651-636-7466/800-832-3244.</FP>
                <FP SOURCE="FP-1">Minneapolis Veterans Affairs Medical Center, Forensic Toxicology Laboratory, 1 Veterans Drive, Minneapolis, MN 55417, 612-725-2088, Testing for Veterans Affairs (VA) Employees Only.</FP>
                <FP SOURCE="FP-1">Pacific Toxicology Laboratories, 9348 DeSoto Ave., Chatsworth, CA 91311, 800-328-6942 (Formerly: Centinela Hospital Airport Toxicology Laboratory).</FP>
                <FP SOURCE="FP-1">Pathology Associates Medical Laboratories, 110 West Cliff Dr., Spokane, WA 99204, 509-755-8991/800-541-7891x7.</FP>
                <FP SOURCE="FP-1">Phamatech, Inc., 15175 Innovation Drive, San Diego, CA 92128, 888-635-5840.</FP>
                <FP SOURCE="FP-1">Quest Diagnostics Incorporated, 1777 Montreal Circle, Tucker, GA 30084, 800-729-6432 (Formerly: SmithKline Beecham Clinical Laboratories; SmithKline Bio-Science Laboratories).</FP>
                <FP SOURCE="FP-1">Quest Diagnostics Incorporated, 400 Egypt Road, Norristown, PA 19403, 610-631-4600/877-642-2216 (Formerly: SmithKline Beecham Clinical Laboratories; SmithKline Bio-Science Laboratories).</FP>
                <FP SOURCE="FP-1">Redwood Toxicology Laboratory, 3700 Westwind Blvd., Santa Rosa, CA 95403, 800-255-2159.</FP>
                <FP SOURCE="FP-1">
                    U.S. Army Forensic Toxicology Drug Testing Laboratory, 2490 Wilson St., Fort George G. Meade, MD 20755-5235, 301-677-7085, Testing for Department of Defense (DoD) Employees Only.
                    <FTREF/>
                </FP>
                <FTNT>
                    <P>* The Standards Council of Canada (SCC) voted to end its Laboratory Accreditation Program for Substance Abuse (LAPSA) effective May 12, 1998. Laboratories certified through that program were accredited to conduct forensic urine drug testing as required by U.S. Department of Transportation (DOT) regulations. As of that date, the certification of those accredited Canadian laboratories will continue under DOT authority. The responsibility for conducting quarterly performance testing plus periodic on-site inspections of those LAPSA-accredited laboratories was transferred to the U.S. HHS, with the HHS' NLCP contractor continuing to have an active role in the performance testing and laboratory inspection processes. Other Canadian laboratories wishing to be considered for the NLCP may apply directly to the NLCP contractor just as U.S. laboratories do.</P>
                    <P>
                        Upon finding a Canadian laboratory to be qualified, HHS will recommend that DOT certify the laboratory (
                        <E T="04">Federal Register</E>
                        , July 16, 1996) as meeting the minimum standards of the Mandatory Guidelines published in the 
                        <E T="04">Federal Register</E>
                         on January 23, 2017 (82 FR 7920). After receiving DOT certification, the laboratory will be included in the monthly list of HHS-certified laboratories and participate in the NLCP certification maintenance program.
                    </P>
                </FTNT>
                <SIG>
                    <NAME>Anastasia Marie Donovan.</NAME>
                    <TITLE>Policy Analyst.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09296 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4160-20-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="25458"/>
                <AGENCY TYPE="N">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Docket ID FEMA-2020-0002]</DEPDOC>
                <SUBJECT>Final Flood Hazard Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Flood hazard determinations, which may include additions or modifications of Base Flood Elevations (BFEs), base flood depths, Special Flood Hazard Area (SFHA) boundaries or zone designations, or regulatory floodways on the Flood Insurance Rate Maps (FIRMs) and where applicable, in the supporting Flood Insurance Study (FIS) reports have been made final for the communities listed in the table below. The FIRM and FIS report are the basis of the floodplain management measures that a community is required either to adopt or to show evidence of having in effect in order to qualify or remain qualified for participation in the Federal Emergency Management Agency's (FEMA's) National Flood Insurance Program (NFIP). In addition, the FIRM and FIS report are used by insurance agents and others to calculate appropriate flood insurance premium rates for buildings and the contents of those buildings.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The date of September 18, 2020 has been established for the FIRM and, where applicable, the supporting FIS report showing the new or modified flood hazard information for each community.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The FIRM, and if applicable, the FIS report containing the final flood hazard information for each community is available for inspection at the respective Community Map Repository address listed in the tables below and will be available online through the FEMA Map Service Center at 
                        <E T="03">https://msc.fema.gov</E>
                         by the date indicated above.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Rick Sacbibit, Chief, Engineering Services Branch, Federal Insurance and Mitigation Administration, FEMA, 400 C Street SW, Washington, DC 20472, (202) 646-7659, or (email) 
                        <E T="03">patrick.sacbibit@fema.dhs.gov;</E>
                         or visit the FEMA Mapping and Insurance eXchange (FMIX) online at 
                        <E T="03">https://www.floodmaps.fema.gov/fhm/fmx_main.html.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>The Federal Emergency Management Agency (FEMA) makes the final determinations listed below for the new or modified flood hazard information for each community listed. Notification of these changes has been published in newspapers of local circulation and 90 days have elapsed since that publication. The Deputy Associate Administrator for Insurance and Mitigation has resolved any appeals resulting from this notification.</P>
                <P>This final notice is issued in accordance with section 110 of the Flood Disaster Protection Act of 1973, 42 U.S.C. 4104, and 44 CFR part 67. FEMA has developed criteria for floodplain management in floodprone areas in accordance with 44 CFR part 60.</P>
                <P>
                    Interested lessees and owners of real property are encouraged to review the new or revised FIRM and FIS report available at the address cited below for each community or online through the FEMA Map Service Center at 
                    <E T="03">https://msc.fema.gov.</E>
                </P>
                <P>The flood hazard determinations are made final in the watersheds and/or communities listed in the table below.</P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance No. 97.022, “Flood Insurance.”)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Michael M. Grimm,</NAME>
                    <TITLE>Assistant Administrator for Risk Management, Department of Homeland Security, Federal Emergency Management Agency.</TITLE>
                </SIG>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s100,r100">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Community</CHED>
                        <CHED H="1">Community map repository address</CHED>
                    </BOXHD>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">City and Borough of Juneau, Alaska</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket No.: FEMA-B-1811</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s" EXPSTB="00">
                        <ENT I="01">City and Borough of Juneau</ENT>
                        <ENT>Marine View Building, 230 South Franklin Street, Juneau, AK 99801.</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">Fairbanks North Star Borough, Alaska</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket No.: FEMA-B-1940</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s" EXPSTB="00">
                        <ENT I="01">Fairbanks North Star Borough</ENT>
                        <ENT>Department of Community Planning, Juanita Helms Administrative Center, 907 Terminal Street, Fairbanks, AK 99701.</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">Maricopa County, Arizona and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket Nos.: FEMA-B-1557 and FEMA-B-1630</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">City of Avondale</ENT>
                        <ENT>Development and Engineering Services Department, 11465 West Civic Center Drive, Avondale, AZ 85323.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of El Mirage</ENT>
                        <ENT>City Hall, 10000 North El Mirage Road, El Mirage, AZ 85335.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Glendale</ENT>
                        <ENT>City Hall, 5850 West Glendale Avenue, Glendale, AZ 85301.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Goodyear</ENT>
                        <ENT>Engineering Department, 14455 West Van Buren Street, Suite D-101, Goodyear, AZ 85338.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Peoria</ENT>
                        <ENT>City Hall, 8401 West Monroe Street, Peoria, AZ 85345.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Phoenix</ENT>
                        <ENT>Street Transportation Department, 200 West Washington Street, 5th Floor, Phoenix, AZ 85003.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Tempe</ENT>
                        <ENT>Engineering Department, City Hall, 31 East 5th Street, Tempe, AZ 85281.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Town of Wickenburg</ENT>
                        <ENT>Town Hall, 155 North Tegner Street, Wickenburg, AZ 85390.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Unincorporated Areas of Maricopa County</ENT>
                        <ENT>Flood Control District of Maricopa County, 2801 West Durango Street, Phoenix, AZ 85009.</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">Allamakee County, Iowa and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket No.: FEMA-B-1911</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">City of Harpers Ferry</ENT>
                        <ENT>City Hall, 238 North 4th Street, Harpers Ferry, IA 52146.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Lansing</ENT>
                        <ENT>City Hall, 201 John Street, Lansing, IA 52151.</ENT>
                    </ROW>
                    <ROW>
                        <PRTPAGE P="25459"/>
                        <ENT I="01">City of New Albin</ENT>
                        <ENT>Municipal Building, 164 Elm Street Northeast, New Albin, IA 52160.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Postville</ENT>
                        <ENT>City Hall, 147 North Lawler Street, Postville, IA 52162.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Waterville</ENT>
                        <ENT>City Hall, 82 Main Street, Waterville, IA 52170.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Waukon</ENT>
                        <ENT>City Hall, 101 Allamakee Street, Waukon, IA 52172.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Unincorporated Areas of Allamakee County</ENT>
                        <ENT>Allamakee County Courthouse, 110 Allamakee Street, Waukon, IA 52172.</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">Spencer County, Kentucky and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket No.: FEMA-B-1918</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">City of Taylorsville</ENT>
                        <ENT>Spencer County Planning and Zoning, 220 Main Cross, Taylorsville, KY 40071.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Unincorporated Areas of Spencer County</ENT>
                        <ENT>Spencer County Planning and Zoning, 220 Main Cross, Taylorsville, KY 40071.</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">Dent County, Missouri and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket No.: FEMA-B-1945</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">City of Salem</ENT>
                        <ENT>City Administration Building, 400 North Iron Street, Salem, MO 65560.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Unincorporated Areas of Dent County</ENT>
                        <ENT>Dent County Courthouse, 400 North Main Street, Salem MO 65560.</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">Madison County, Virginia and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket No.: FEMA-B-1921</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s" EXPSTB="00">
                        <ENT I="01">Unincorporated Areas of Madison County</ENT>
                        <ENT>Madison County Administrative Center, 414 North Main Street, Madison, VA 22727.</ENT>
                    </ROW>
                    <ROW EXPSTB="01">
                        <ENT I="21">
                            <E T="02">Grays Harbor County, Washington and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="21">
                            <E T="02">Docket No.: FEMA-B-1920</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">City of Elma</ENT>
                        <ENT>Elma City Hall, 202 West Main Street, Elma, WA 98541.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Montesano</ENT>
                        <ENT>City Hall, 112 North Main Street, Montesano, WA 98563.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">City of Oakville</ENT>
                        <ENT>City Hall, 204 East Main Street, Oakville, WA 98568.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Confederated Tribes of Chehalis Reservation</ENT>
                        <ENT>Chehalis Tribal Center, 420 Howanut Road, Oakville, WA 98568.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Unincorporated Areas of Grays Harbor County</ENT>
                        <ENT>Grays Harbor Administration Building, 100 West Broadway, Suite 31, Montesano, WA 98563.</ENT>
                    </ROW>
                </GPOTABLE>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09279 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Docket ID FEMA-2020-0002; Internal Agency Docket No. FEMA-B-1859]</DEPDOC>
                <SUBJECT>Proposed Flood Hazard Determinations for Fremont County, Iowa and Incorporated Areas</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice; withdrawal.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Federal Emergency Management Agency (FEMA) is withdrawing its proposed notice concerning proposed flood hazard determinations, which may include the addition or modification of any Base Flood Elevation, base flood depth, Special Flood Hazard Area boundary or zone designation, or regulatory floodway (herein after referred to as proposed flood hazard determinations) on the Flood Insurance Rate Maps and, where applicable, in the supporting Flood Insurance Study reports for Fremont County, Iowa and Incorporated Areas.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>This withdrawal is effective May 1, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        You may submit comments, identified by Docket No. FEMA-B-1859, to Rick Sacbibit, Chief, Engineering Services Branch, Federal Insurance and Mitigation Administration, FEMA, 400 C Street SW, Washington, DC 20472, (202) 646-7659, or (email) 
                        <E T="03">patrick.sacbibit@fema.dhs.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Rick Sacbibit, Chief, Engineering Services Branch, Federal Insurance and Mitigation Administration, FEMA, 400 C Street SW, Washington, DC 20472, (202) 646-7659, or (email) 
                        <E T="03">patrick.sacbibit@fema.dhs.gov;</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>On November 5, 2018, FEMA published a proposed notice at: 83 FR 55380, proposing flood hazard determinations for Fremont County, Iowa and Incorporated Areas. FEMA is withdrawing the proposed notice.</P>
                <EXTRACT>
                    <FP>(Authority: 42 U.S.C. 4104; 44 CFR 67.4)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Michael M. Grimm,</NAME>
                    <TITLE>Assistant Administrator for Risk Management, Department of Homeland Security, Federal Emergency Management Agency.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09276 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Docket ID FEMA-2020-0002; Internal Agency Docket No. FEMA-B-2027]</DEPDOC>
                <SUBJECT>Proposed Flood Hazard Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        Comments are requested on proposed flood hazard determinations, which may include additions or modifications of any Base Flood Elevation (BFE), base flood depth, Special Flood Hazard Area (SFHA) boundary or zone designation, or 
                        <PRTPAGE P="25460"/>
                        regulatory floodway on the Flood Insurance Rate Maps (FIRMs), and where applicable, in the supporting Flood Insurance Study (FIS) reports for the communities listed in the table below. The purpose of this notice is to seek general information and comment regarding the preliminary FIRM, and where applicable, the FIS report that the Federal Emergency Management Agency (FEMA) has provided to the affected communities. The FIRM and FIS report are the basis of the floodplain management measures that the community is required either to adopt or to show evidence of having in effect in order to qualify or remain qualified for participation in the National Flood Insurance Program (NFIP). In addition, the FIRM and FIS report, once effective, will be used by insurance agents and others to calculate appropriate flood insurance premium rates for new buildings and the contents of those buildings.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments are to be submitted on or before July 30, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The Preliminary FIRM, and where applicable, the FIS report for each community are available for inspection at both the online location 
                        <E T="03">https://www.fema.gov/preliminaryfloodhazarddata</E>
                         and the respective Community Map Repository address listed in the tables below. Additionally, the current effective FIRM and FIS report for each community are accessible online through the FEMA Map Service Center at 
                        <E T="03">https://msc.fema.gov</E>
                         for comparison.
                    </P>
                    <P>
                        You may submit comments, identified by Docket No. FEMA-B-2027, to Rick Sacbibit, Chief, Engineering Services Branch, Federal Insurance and Mitigation Administration, FEMA, 400 C Street SW, Washington, DC 20472, (202) 646-7659, or (email) 
                        <E T="03">patrick.sacbibit@fema.dhs.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Rick Sacbibit, Chief, Engineering Services Branch, Federal Insurance and Mitigation Administration, FEMA, 400 C Street SW, Washington, DC 20472, (202) 646-7659, or (email) 
                        <E T="03">patrick.sacbibit@fema.dhs.gov;</E>
                         or visit the FEMA Mapping and Insurance eXchange (FMIX) online at 
                        <E T="03">https://www.floodmaps.fema.gov/fhm/fmx_main.html.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>FEMA proposes to make flood hazard determinations for each community listed below, in accordance with section 110 of the Flood Disaster Protection Act of 1973, 42 U.S.C. 4104, and 44 CFR 67.4(a).</P>
                <P>These proposed flood hazard determinations, together with the floodplain management criteria required by 44 CFR 60.3, are the minimum that are required. They should not be construed to mean that the community must change any existing ordinances that are more stringent in their floodplain management requirements. The community may at any time enact stricter requirements of its own or pursuant to policies established by other Federal, State, or regional entities. These flood hazard determinations are used to meet the floodplain management requirements of the NFIP and are used to calculate the appropriate flood insurance premium rates for new buildings built after the FIRM and FIS report become effective.</P>
                <P>The communities affected by the flood hazard determinations are provided in the tables below. Any request for reconsideration of the revised flood hazard information shown on the Preliminary FIRM and FIS report that satisfies the data requirements outlined in 44 CFR 67.6(b) is considered an appeal. Comments unrelated to the flood hazard determinations also will be considered before the FIRM and FIS report become effective.</P>
                <P>
                    Use of a Scientific Resolution Panel (SRP) is available to communities in support of the appeal resolution process. SRPs are independent panels of experts in hydrology, hydraulics, and other pertinent sciences established to review conflicting scientific and technical data and provide recommendations for resolution. Use of the SRP only may be exercised after FEMA and local communities have been engaged in a collaborative consultation process for at least 60 days without a mutually acceptable resolution of an appeal. Additional information regarding the SRP process can be found online at 
                    <E T="03">https://www.floodsrp.org/pdfs/srp_overview.pdf.</E>
                </P>
                <P>
                    The watersheds and/or communities affected are listed in the tables below. The Preliminary FIRM, and where applicable, FIS report for each community are available for inspection at both the online location 
                    <E T="03">https://www.fema.gov/preliminaryfloodhazarddata</E>
                     and the respective Community Map Repository address listed in the tables. For communities with multiple ongoing Preliminary studies, the studies can be identified by the unique project number and Preliminary FIRM date listed in the tables. Additionally, the current effective FIRM and FIS report for each community are accessible online through the FEMA Map Service Center at 
                    <E T="03">https://msc.fema.gov</E>
                     for comparison.
                </P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance No. 97.022, “Flood Insurance.”)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Michael M. Grimm,</NAME>
                    <TITLE>Assistant Administrator for Risk Management, Department of Homeland Security, Federal Emergency Management Agency.</TITLE>
                </SIG>
                <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s75,r150">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Community</CHED>
                        <CHED H="1">Community map repository address</CHED>
                    </BOXHD>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Shelby County, Alabama and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Project: 12-04-1070S Preliminary Date: December 6, 2019</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s" EXPSTB="00">
                        <ENT I="01">City of Birmingham</ENT>
                        <ENT>Department of Planning, Engineering, and Permits, 710 North 20th Street, 5th Floor, Birmingham, AL 35203.</ENT>
                    </ROW>
                    <ROW RUL="s">
                        <ENT I="01">Unincorporated Areas of New Shelby County</ENT>
                        <ENT>Shelby County Engineer's Office, 506 Highway 70, 2nd Floor, Columbiana, AL 35051.</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">Gloucester County, Virginia (All Jurisdictions)</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Project: 19-03-0007S Preliminary Date: October 15, 2019</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s" EXPSTB="00">
                        <ENT I="01">Unincorporated Areas of Gloucester County</ENT>
                        <ENT>Gloucester County Office Building 2, 6489 Main Street, Suite 247, Gloucester, VA 23061</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <PRTPAGE P="25461"/>
                        <ENT I="21">
                            <E T="02">King and Queen County, Virginia (All Jurisdictions)</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Project: 19-03-0008S Preliminary Date: October 15, 2019</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s" EXPSTB="00">
                        <ENT I="01">Unincorporated Areas of King and Queen County</ENT>
                        <ENT>King and Queen County Administrator's Office, 242 Allens Circle, Suite L, King and Queen Court House, VA 23085.</ENT>
                    </ROW>
                    <ROW EXPSTB="01" RUL="s">
                        <ENT I="21">
                            <E T="02">New Kent County, Virginia (All Jurisdictions)</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Project: 19-03-0012S Preliminary Date: November 29, 2019</E>
                        </ENT>
                    </ROW>
                    <ROW EXPSTB="00">
                        <ENT I="01">Unincorporated Areas of New Kent County</ENT>
                        <ENT>New Kent County Administration Building, 12007 Courthouse Circle, New Kent, VA 23124.</ENT>
                    </ROW>
                </GPOTABLE>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09280 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Federal Emergency Management Agency</SUBAGY>
                <DEPDOC>[Docket ID FEMA-2020-0002; Internal Agency Docket No. FEMA-B-2028]</DEPDOC>
                <SUBJECT>Proposed Flood Hazard Determinations</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Federal Emergency Management Agency, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>Comments are requested on proposed flood hazard determinations, which may include additions or modifications of any Base Flood Elevation (BFE), base flood depth, Special Flood Hazard Area (SFHA) boundary or zone designation, or regulatory floodway on the Flood Insurance Rate Maps (FIRMs), and where applicable, in the supporting Flood Insurance Study (FIS) reports for the communities listed in the table below. The purpose of this notice is to seek general information and comment regarding the preliminary FIRM, and where applicable, the FIS report that the Federal Emergency Management Agency (FEMA) has provided to the affected communities. The FIRM and FIS report are the basis of the floodplain management measures that the community is required either to adopt or to show evidence of having in effect in order to qualify or remain qualified for participation in the National Flood Insurance Program (NFIP). In addition, the FIRM and FIS report, once effective, will be used by insurance agents and others to calculate appropriate flood insurance premium rates for new buildings and the contents of those buildings.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments are to be submitted on or before July 30, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The Preliminary FIRM, and where applicable, the FIS report for each community are available for inspection at both the online location 
                        <E T="03">https://www.fema.gov/preliminaryfloodhazarddata</E>
                         and the respective Community Map Repository address listed in the tables below. Additionally, the current effective FIRM and FIS report for each community are accessible online through the FEMA Map Service Center at 
                        <E T="03">https://msc.fema.gov</E>
                         for comparison.
                    </P>
                    <P>
                        You may submit comments, identified by Docket No. FEMA-B-2028, to Rick Sacbibit, Chief, Engineering Services Branch, Federal Insurance and Mitigation Administration, FEMA, 400 C Street SW, Washington, DC 20472, (202) 646-7659, or (email) 
                        <E T="03">patrick.sacbibit@fema.dhs.gov.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Rick Sacbibit, Chief, Engineering Services Branch, Federal Insurance and Mitigation Administration, FEMA, 400 C Street SW, Washington, DC 20472, (202) 646-7659, or (email) 
                        <E T="03">patrick.sacbibit@fema.dhs.gov;</E>
                         or visit the FEMA Mapping and Insurance eXchange (FMIX) online at 
                        <E T="03">https://www.floodmaps.fema.gov/fhm/fmx_main.html.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>FEMA proposes to make flood hazard determinations for each community listed below, in accordance with section 110 of the Flood Disaster Protection Act of 1973, 42 U.S.C. 4104, and 44 CFR 67.4(a).</P>
                <P>These proposed flood hazard determinations, together with the floodplain management criteria required by 44 CFR 60.3, are the minimum that are required. They should not be construed to mean that the community must change any existing ordinances that are more stringent in their floodplain management requirements. The community may at any time enact stricter requirements of its own or pursuant to policies established by other Federal, State, or regional entities. These flood hazard determinations are used to meet the floodplain management requirements of the NFIP and are used to calculate the appropriate flood insurance premium rates for new buildings built after the FIRM and FIS report become effective.</P>
                <P>The communities affected by the flood hazard determinations are provided in the tables below. Any request for reconsideration of the revised flood hazard information shown on the Preliminary FIRM and FIS report that satisfies the data requirements outlined in 44 CFR 67.6(b) is considered an appeal. Comments unrelated to the flood hazard determinations also will be considered before the FIRM and FIS report become effective.</P>
                <P>
                    Use of a Scientific Resolution Panel (SRP) is available to communities in support of the appeal resolution process. SRPs are independent panels of experts in hydrology, hydraulics, and other pertinent sciences established to review conflicting scientific and technical data and provide recommendations for resolution. Use of the SRP only may be exercised after FEMA and local communities have been engaged in a collaborative consultation process for at least 60 days without a mutually acceptable resolution of an appeal. Additional information regarding the SRP process can be found online at 
                    <E T="03">https://www.floodsrp.org/pdfs/srp_overview.pdf.</E>
                </P>
                <P>
                    The watersheds and/or communities affected are listed in the tables below. The Preliminary FIRM, and where applicable, FIS report for each community are available for inspection at both the online location 
                    <E T="03">https://www.fema.gov/preliminaryfloodhazarddata</E>
                     and the respective Community Map Repository address listed in the tables. For communities with multiple ongoing Preliminary studies, the studies can be identified by the unique project number and Preliminary FIRM date listed in the tables. Additionally, the current effective FIRM and FIS report for each community are accessible online 
                    <PRTPAGE P="25462"/>
                    through the FEMA Map Service Center at 
                    <E T="03">https://msc.fema.gov</E>
                     for comparison.
                </P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance No. 97.022, “Flood Insurance.”)</FP>
                </EXTRACT>
                <SIG>
                    <NAME>Michael M. Grimm,</NAME>
                    <TITLE>Assistant Administrator for Risk Management, Department of Homeland Security, Federal Emergency Management Agency.</TITLE>
                </SIG>
                <GPOTABLE COLS="2" OPTS="L2,tp0,i1" CDEF="s100,r100">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Community</CHED>
                        <CHED H="1">Community map repository address</CHED>
                    </BOXHD>
                    <ROW EXPSTB="00" RUL="s">
                        <ENT I="21">
                            <E T="02">Warren County, Illinois and Incorporated Areas</E>
                        </ENT>
                    </ROW>
                    <ROW>
                        <ENT I="21">
                            <E T="02">Project: 17-05-1692S Preliminary Date: October 30, 2019</E>
                        </ENT>
                    </ROW>
                    <ROW RUL="s" EXPSTB="00">
                        <ENT I="01">City of Monmouth</ENT>
                        <ENT>City Hall, 100 East Broadway, Monmouth, IL 61462.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Unincorporated Areas of Warren County</ENT>
                        <ENT>Warren County Courthouse, 100 West Broadway, Monmouth, IL 61462.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Village of Alexis</ENT>
                        <ENT>Village Hall, 204 South Main Street, Alexis, IL 61412.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Village of Kirkwood</ENT>
                        <ENT>Village Hall, 120 West Cedar Street, Kirkwood, IL 61447.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Village of Little York</ENT>
                        <ENT>Village Hall, 401 West Main Street, Little York, IL 61453.</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Village of Roseville</ENT>
                        <ENT>Village Hall, 185 West Penn Avenue, Roseville, IL 61473.</ENT>
                    </ROW>
                </GPOTABLE>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09277 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBJECT>Agreement Between the Government of the United States of America and the Government of the Republic of Honduras for Cooperation in the Examination of Protection Claims</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of Strategy, Policy, and Plans, Department of Homeland Security.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of agreement.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Department of Homeland Security is publishing the Agreement Between the Government of the United States of America and the Government of the Republic of Honduras for Cooperation in the Examination of Protection Claims. The text of the Agreement is set out below.</P>
                </SUM>
                <SIG>
                    <NAME>Valerie Boyd,</NAME>
                    <TITLE>Assistant Secretary for International Affairs, Office of Strategy, Policy, and Plans, U.S. Department of Homeland Security.</TITLE>
                </SIG>
                <BILCOD>BILLING CODE 9110-9-P</BILCOD>
                <GPH SPAN="3" DEEP="491">
                    <PRTPAGE P="25463"/>
                    <GID>EN01MY20.217</GID>
                </GPH>
                <GPH SPAN="3" DEEP="582">
                    <PRTPAGE P="25464"/>
                    <GID>EN01MY20.218</GID>
                </GPH>
                <GPH SPAN="3" DEEP="633">
                    <PRTPAGE P="25465"/>
                    <GID>EN01MY20.219</GID>
                </GPH>
                <GPH SPAN="3" DEEP="633">
                    <PRTPAGE P="25466"/>
                    <GID>EN01MY20.220</GID>
                </GPH>
                <GPH SPAN="3" DEEP="615">
                    <PRTPAGE P="25467"/>
                    <GID>EN01MY20.221</GID>
                </GPH>
                <GPH SPAN="3" DEEP="348">
                    <PRTPAGE P="25468"/>
                    <GID>EN01MY20.222</GID>
                </GPH>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09322 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 9110-9M-C</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Transportation Security Administration</SUBAGY>
                <DEPDOC>[Docket No. TSA-2011-0008]</DEPDOC>
                <SUBJECT>Request for Applicants for Appointment to the Aviation Security Advisory Committee</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Transportation Security Administration, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Committee management; request for applicants.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Transportation Security Administration (TSA) is requesting individuals who are interested in serving on the Aviation Security Advisory Committee (ASAC) for the constituencies specified below to apply for appointment. ASAC's mission is to provide advice and recommendations to the Administrator of TSA on improving aviation security matters, including developing, refining, and implementing policies, programs, rulemaking, and security directives pertaining to aviation security, while adhering to sensitive security guidelines.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        Applications for membership must be submitted to TSA using one of the methods in the 
                        <E T="02">ADDRESSES</E>
                         section below on or before May 22, 2020.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Applications must be submitted by one of the following means:</P>
                    <P>
                        • 
                        <E T="03">Email: ASAC@tsa.dhs.gov.</E>
                    </P>
                    <P>
                        • 
                        <E T="03">Mail:</E>
                         Tamika McCree Elhilali, ASAC Designated Federal Officer, Transportation Security Administration (TSA-28), 601 12th St. South, Arlington, VA 20598-4028.
                    </P>
                    <P>
                        See 
                        <E T="02">SUPPLEMENTARY INFORMATION</E>
                         for application requirements.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Tamika McCree Elhilali, ASAC Designated Federal Officer, Transportation Security Administration (TSA-28), 601 12th St. South, Arlington, VA 20598-4028, 
                        <E T="03">ASAC@tsa.dhs.gov,</E>
                         571-227-2632.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>ASAC is an advisory committee established pursuant to 49 U.S.C 44946. The committee is composed of individual members representing key constituencies affected by aviation security requirements.</P>
                <HD SOURCE="HD1">Balanced Membership Plans</HD>
                <P>The ASAC will be composed of individuals representing not more than 34 member organizations. Each organization shall be represented by one individual (or the individual's designee). TSA is seeking applications for the membership categories scheduled to expire in May 2020, which are marked with an asterisk in this section below. Individuals are appointed by the Administrator of TSA to represent the following 19 key constituencies affected by aviation security requirements, as defined at 49 U.S.C. 44946(c)(1)(C):</P>
                <P>1. Air carriers.*</P>
                <P>2. All-cargo air transportation.*</P>
                <P>3. Labor organizations representing air carrier employees.*</P>
                <P>4. Aircraft manufacturers.</P>
                <P>5. Airport operators.*</P>
                <P>6. General aviation.*</P>
                <P>7. Travel industry.</P>
                <P>8. Victims of terrorist acts against aviation.*</P>
                <P>9. Law enforcement and security experts.*</P>
                <P>10. Indirect air carriers.</P>
                <P>
                    11. Aviation security technology industry (including screening technology and biometrics).*
                    <PRTPAGE P="25469"/>
                </P>
                <P>12. Airport-based businesses (including minority-owned small businesses).</P>
                <P>13. Passenger advocacy groups.</P>
                <P>14. Businesses that conduct security operations at airports (Screening Partnership Program contractors).</P>
                <P>15. Labor organizations representing transportation security officers.</P>
                <P>16. Airport construction and maintenance contractors.</P>
                <P>17. Labor organizations representing employees of airport construction and maintenance contractors.*</P>
                <P>18. Privacy organizations.*</P>
                <P>19. Aeronautical repair stations.*</P>
                <P>ASAC does not have a specific number of members allocated to any membership category and the number of members in a category may change to fit the needs of the Committee, but each organization shall be represented by one individual. Members will serve as representatives and speak on behalf of their respective constituency group, and will not be appointed as Special Government Employees as defined in 18 U.S.C. 202(a). Membership on the Committee is personal to the appointee and a member may not send an alternate to a Committee meeting. Pursuant to 49 U.S.C 44946(c)(3), members shall not receive pay, allowances, or benefits from the Government by reason of their service on the Committee.</P>
                <HD SOURCE="HD1">Committee Meetings</HD>
                <P>The Committee typically convenes four times per year; however, additional meetings may be held with the approval of the Designated Federal Official. Due to the sensitive nature of the material discussed, meetings are typically closed to the public. At least one meeting will be open to the public each year. In addition, members are expected to participate on ASAC subcommittees that typically meet more frequently to deliberate and discuss specific aviation matters.</P>
                <HD SOURCE="HD1">Committee Membership</HD>
                <P>Committee members are appointed by and serve at the pleasure of the Administrator of TSA for a 2-year term or until a successor is appointed. Members who are currently serving on the Committee are eligible to reapply for membership. A new application is required.</P>
                <HD SOURCE="HD1">Application for Advisory Committee Appointment</HD>
                <P>TSA is seeking applications for the membership categories scheduled to expire in May 2020, which are marked with an asterisk in the Balanced Membership Plans section above. Any person wishing to be considered for appointment to ASAC must provide the following:</P>
                <P>• Complete professional resume.</P>
                <P>• Statement of interest and reasons for application, including the membership category and how you represent a significant portion of that constituency.</P>
                <P>• Home and work addresses, telephone number, and email address.</P>
                <P>
                    Please submit your application to the Responsible TSA Official in 
                    <E T="02">ADDRESSES</E>
                     noted above by May 22, 2020.
                </P>
                <SIG>
                    <DATED>Dated: April 27, 2020.</DATED>
                    <NAME>Eddie D. Mayenschein,</NAME>
                    <TITLE>Assistant Administrator, Policy, Plans, and Engagement.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09304 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-05-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF HOMELAND SECURITY</AGENCY>
                <SUBAGY>Transportation Security Administration</SUBAGY>
                <SUBJECT>Revision of an Agency Information Collection Activity Under OMB Review: Security Appointment Center (SAC) Visitor Request Form and Foreign National Vetting Request</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Transportation Security Administration, DHS.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>30-Day notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice announces that the Transportation Security Administration (TSA) has forwarded the Information Collection Request (ICR), Office of Management and Budget (OMB) control number 1652-0068, abstracted below to OMB for review and approval of a revision of the currently approved collection under the Paperwork Reduction Act (PRA). The collection involves gathering information from individuals who plan to visit all TSA facilities in the National Capital Region (NCR). In addition, TSA is revising the collection to transition TSA Forms 2802, 2816A, and 2816B into Common Forms to streamline the information collection process.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Send your comments by June 1, 2020. A comment to OMB is most effective if OMB receives it within 30 days of publication.</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, OMB. Comments should be identified by Docket ID: TSA-2013-0001 and sent to the Federal eRulemaking Portal, 
                        <E T="03">http://www.regulations.gov</E>
                        . Please follow the portal instructions for submitting comments. This process is conducted in accordance with 5 CFR 1320.1.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Christina A. Walsh, TSA PRA Officer, Information Technology (IT), TSA-11, Transportation Security Administration, 601 South 12th Street, Arlington, VA 20598-6011; telephone (571) 227-2062; email 
                        <E T="03">TSAPRA@tsa.dhs.gov</E>
                        .
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    TSA published a 
                    <E T="04">Federal Register</E>
                     notice, with a 60-day comment period soliciting comments, of the following collection of information on March 4, 2020, 85 FR 12800.
                </P>
                <HD SOURCE="HD1">Comments Invited</HD>
                <P>
                    In accordance with the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), an agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a valid OMB control number. The ICR documentation will be available at 
                    <E T="03">http://www.reginfo.gov</E>
                     upon its submission to OMB. Therefore, in preparation for OMB review and approval of the following information collection, TSA is soliciting comments to—
                </P>
                <P>(1) Evaluate whether the proposed information requirement is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility;</P>
                <P>(2) Evaluate the accuracy of the agency's estimate of the burden;</P>
                <P>(3) Enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>(4) Minimize the burden of the collection of information on those who are to respond, including using appropriate automated, electronic, mechanical, or other technological collection techniques or other forms of information technology.</P>
                <P>Consistent with the requirements of Executive Order (E.O.) 13771, Reducing Regulation and Controlling Regulatory Costs, and E.O. 13777, Enforcing the Regulatory Reform Agenda, TSA is also requesting comments on the extent to which this request for information could be modified to reduce the burden on respondents.</P>
                <HD SOURCE="HD1">Information Collection Requirement</HD>
                <P>
                    <E T="03">Title:</E>
                     Security Appointment Center (SAC) Visitor Request Form and Foreign National Vetting Request.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     Revision of a currently approved collection.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     1652-0068.
                </P>
                <P>
                    <E T="03">Form(s):</E>
                     TSA Forms 2802, 2816A, and 2816B.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Visitors to TSA facilities in the National Capital Region.
                    <PRTPAGE P="25470"/>
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     The Secretary of the Department of Homeland Security (DHS) is authorized to protect property owned, occupied, or secured by the Federal Government. 
                    <E T="03">See</E>
                     40 U.S.C. 1315. 
                    <E T="03">See also</E>
                     41 CFR 102-81.15 (requires Federal agencies to be responsible for maintaining security at their own or leased facilities). To implement this requirement, DHS policy requires all visitors to DHS facilities in the NCR 
                    <SU>1</SU>
                    <FTREF/>
                     to have a criminal history records check through the National Crime Information Center (NCIC) system before accessing the facility. In reviewing the NCIC results, TSA will consider whether an individual could potentially pose a threat to the safety of TSA employees, contractors, visitors, or the facility. TSA is revising the collection to transition the applicable forms, TSA Forms 2802, 2816A, and 2816B, into Common Forms. Common Forms permit Federal agency users beyond the agency that created the form (
                    <E T="03">e.g.,</E>
                     Department of Homeland Security or U.S. Office of Personnel Management) to streamline the information collection process in coordination with OMB.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         TSA facilities in the NCR include TSA Headquarters, the Freedom Center, the Transportation Security Integration Facility (TSIF), the Metro Park office complex (Metro Park), and the Annapolis Junction facility (AJ).
                    </P>
                </FTNT>
                <P>
                    <E T="03">Number of Respondents:</E>
                     29,595.
                </P>
                <P>
                    <E T="03">Estimated Annual Burden Hours:</E>
                     An estimated 226 hours annually.
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020 .</DATED>
                    <NAME>Christina A. Walsh,</NAME>
                    <TITLE>TSA Paperwork Reduction Act Officer, Information Technology.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09349 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 9110-05-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT</AGENCY>
                <DEPDOC>[Docket No. FR-7024-N-19]</DEPDOC>
                <SUBJECT>30-Day Notice of Proposed Information Collection: Family Unification Program/Family Self-Sufficiency Demonstration Evaluation OMB Control No.: 2528-NEW</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Chief Information Officer, HUD.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>HUD is seeking approval from the Office of Management and Budget (OMB) for the information collection described below. In accordance with the Paperwork Reduction Act, HUD is requesting comment from all interested parties on the proposed collection of information. The purpose of this notice is to allow for 30 days of public comment.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        <E T="03">Comments Due Date:</E>
                         June 1, 2020.
                    </P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        Interested persons are invited to submit comments regarding this proposal. 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/StartPrintedPage15501PRAMain.</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>
                        Anna P. Guido, Reports Management Officer, QMAC, Department of Housing and Urban Development, 451 7th Street SW, Washington, DC 20410; email her at 
                        <E T="03">Anna.P.Guido@hud.gov</E>
                         or telephone 202-402-5535. This is not a toll-free number. Person with hearing or speech impairments may access this number through TTY by calling the toll-free Federal Relay Service at (800) 877-8339. Copies of available documents submitted to OMB may be obtained from Ms. Guido.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>This notice informs the public that HUD is seeking approval from OMB for the information collection described in Section A.</P>
                <P>
                    The 
                    <E T="04">Federal Register</E>
                     notice that solicited public comment on the information collection for a period of 60 days was published on January 13, 2020 at 85 FR 1822.
                </P>
                <HD SOURCE="HD1">A. Overview of Information Collection</HD>
                <P>
                    <E T="03">Title of Information Collection:</E>
                     Family Unification Program/Family Self-Sufficiency Demonstration Evaluation.
                </P>
                <P>
                    <E T="03">OMB Approval Number:</E>
                     2528-New.
                </P>
                <P>
                    <E T="03">Type of Request:</E>
                     New Collection.
                </P>
                <P>
                    <E T="03">Form Number:</E>
                     Pending.
                </P>
                <P>
                    <E T="03">Description of the need for the information and proposed use:</E>
                     The Family Unification Program/Family Self-Sufficiency (FUP/FSS) Demonstration, authorized in HUD's FY 2015 appropriations, was designed to test whether combining FUP and FSS for eligible youth would result in beneficial outcomes. The demonstration program was first announced in January 2016, and a total of 51 PHAs are participating in the demonstration as of 2019. As a part of the demonstration, the time limit on rental assistance was extended to match the maximum allowable five-year FSS contract (at the start of the demonstration, this was an increase from 18 months, although FUP-Youth vouchers were extended to 36 months shortly after the time the demonstration was announced). No funds or additional FUP vouchers were allocated for the demonstration, although certain regulatory requirements were relaxed for participating Public Housing Agencies (PHAs), with the aim of better aligning the existing programs into the new approach. As a result, all participating PHAs already had FUP allocations. Participating PHAs can choose to modify their FSS programs to better meet the needs of youth participants. The most recent FUP awards (FY17 and FY18) require partnership with a local Continuum of Care (CoC), which can increase referrals of eligible youth through coordinated entry.
                </P>
                <P>The main goal of the FUP/FSS Demonstration Evaluation is to assess whether the combination of FUP and FSS, along with the extension of time limits, has been an effective approach to improving housing stability and self-sufficiency outcomes for youth aging out of foster care. Related to this is whether participation in the demonstration has provided an avenue for closer and more productive partnerships between PHAs, Public Child Welfare Agencies (PCWAs), and other youth-focused organizations involved. This includes capturing information about how PHAs and their PCWA partners have worked together to implement the demonstration program and the challenges and lessons learned from their experience to date.</P>
                <P>Initial take-up rates for the demonstration, as well as non-demonstration FUP-Youth voucher issuances, have both generally been low. Given these low take-up rates, an additional baseline goal will be to assess the extent to which the FUP/FSS Demonstration is being actively implemented across the 51 participating PHAs and why some sites that applied to the demonstration do not appear to be implementing the program or issuing many FUP-Youth vouchers. To this end, while many of the core evaluation questions are focused on implementation questions and challenges, the study will also necessarily explore why some demonstration sites do not appear to be fully engaged with the program. Finally, a goal of the evaluation is to measure short-term outcomes for participating youth and determine any emerging common attributes among them.</P>
                <P>
                    This notice announces HUD's intent to collect information through the following methods: (1) Study investigators (from Urban Institute) will administer an agency-level web-based survey to all PHAs and PCWAs 
                    <PRTPAGE P="25471"/>
                    participating in the demonstration. (2) Investigators will conduct one-time telephone interviews with a sample of staff from 10 PHAs in the demonstration to gather more nuanced information than can be collected in the web-based surveys. (3) Investigators will also visit three FUP/FSS demonstration sites to conduct interviews with PHA and PCWA administrators, front-line workers, community service providers, as well as interviews with youth participants. (4) To describe the characteristics of the participating PHAs and FUP/FSS participants and measure short-term outcomes, the study investigators will analyze HUD Public and Indian Housing Information Center (PIC) and Voucher Management System (VMS) administrative data.
                </P>
                <GPOTABLE COLS="8" OPTS="L2,tp0,i1" CDEF="s50,12,12,12,12,12,12,12">
                    <TTITLE> </TTITLE>
                    <BOXHD>
                        <CHED H="1">Instrument</CHED>
                        <CHED H="1">
                            Number of 
                            <LI>respondents</LI>
                        </CHED>
                        <CHED H="1">
                            Frequency of 
                            <LI>response</LI>
                        </CHED>
                        <CHED H="1">
                            Responses per 
                            <LI>annum</LI>
                        </CHED>
                        <CHED H="1">
                            Burden hour 
                            <LI>per response</LI>
                        </CHED>
                        <CHED H="1">
                            Total burden 
                            <LI>hours</LI>
                        </CHED>
                        <CHED H="1">
                            Hourly cost 
                            <LI>per response</LI>
                        </CHED>
                        <CHED H="1">Cost</CHED>
                    </BOXHD>
                    <ROW>
                        <ENT I="01">Public Housing Authority (PHA) Survey</ENT>
                        <ENT>51.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>51.00</ENT>
                        <ENT>0.50</ENT>
                        <ENT>25.50</ENT>
                        <ENT>
                            <SU>1</SU>
                             $34.46
                        </ENT>
                        <ENT>$878.73</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Public Child Welfare Agency (PCWA) Survey</ENT>
                        <ENT>51.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>51.00</ENT>
                        <ENT>0.50</ENT>
                        <ENT>25.50</ENT>
                        <ENT>
                            <SU>6</SU>
                             34.46
                        </ENT>
                        <ENT>878.73</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Interview Guide for PHA Staff</ENT>
                        <ENT>41.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>41.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>41.00</ENT>
                        <ENT>
                            <SU>6</SU>
                             34.46
                        </ENT>
                        <ENT>1,412.86</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Interview Guide for Public Child Welfare Agency (PCWA) Staff</ENT>
                        <ENT>16.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>16.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>16.00</ENT>
                        <ENT>
                            <SU>6</SU>
                             34.46
                        </ENT>
                        <ENT>551.36</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Interview Guide for Community Service Provider Staff</ENT>
                        <ENT>3.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>3.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>3.00</ENT>
                        <ENT>
                            <SU>2</SU>
                             23.92
                        </ENT>
                        <ENT>71.76</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="01">Interview Guide for Continuum of Care (COC) Lead Organization Staff</ENT>
                        <ENT>3.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>3.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>3.00</ENT>
                        <ENT>
                            <SU>7</SU>
                             23.92
                        </ENT>
                        <ENT>71.76</ENT>
                    </ROW>
                    <ROW RUL="n,s">
                        <ENT I="01">Interview Guide for Youth</ENT>
                        <ENT>18.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>18.00</ENT>
                        <ENT>1.00</ENT>
                        <ENT>18.00</ENT>
                        <ENT>
                            <SU>3</SU>
                             7.25
                        </ENT>
                        <ENT>130.50</ENT>
                    </ROW>
                    <ROW>
                        <ENT I="03">Total</ENT>
                        <ENT/>
                        <ENT/>
                        <ENT>183.00</ENT>
                        <ENT/>
                        <ENT>132.00</ENT>
                        <ENT/>
                        <ENT>3,995.70</ENT>
                    </ROW>
                    <TNOTE>
                        <SU>1</SU>
                         “Occupational Employment Statistics: Occupational Employment and Wages, May 2018—Social and Community Service Managers,” Bureau of Labor Statistics, accessed December 6th, 2019, 
                        <E T="03">https://www.bls.gov/oes/current/oes119151.htm.</E>
                    </TNOTE>
                    <TNOTE>
                        <SU>2</SU>
                         “Occupational Employment Statistics: Occupational Employment and Wages, May 2018—Child, Family and Social Workers,” Bureau of Labor Statistics, accessed December 6th, 2019, 
                        <E T="03">https://www.bls.gov/oes/current/oes211021.htm.</E>
                    </TNOTE>
                    <TNOTE>
                        <SU>3</SU>
                         For youth interviews, we assume an hourly wage of $7.25, the federal minimum wage.
                    </TNOTE>
                </GPOTABLE>
                <HD SOURCE="HD1">B. Solicitation of Public Comment</HD>
                <P>This notice is soliciting comments from members of the public and affected parties concerning the collection of information described in Section A on the following:</P>
                <P>(1) Whether the proposed collection of information is necessary for the proper performance of the functions of the agency, including whether the information will have practical utility;</P>
                <P>(2) The accuracy of the agency's estimate of the burden of the proposed collection of information;</P>
                <P>(3) Ways to enhance the quality, utility, and clarity of the information to be collected; and</P>
                <P>
                    (4) Ways to minimize the burden of the collection of information on those who are to respond; including through the use of appropriate automated collection techniques or other forms of information technology, 
                    <E T="03">e.g.,</E>
                     permitting electronic submission of responses.
                </P>
                <P>(5) Ways to minimize the burden of the collection of information on those who are to respond, including the use of automated collection techniques or other forms of information technology.</P>
                <P>HUD encourages interested parties to submit comment in response to these questions.</P>
                <HD SOURCE="HD1">C. Authority</HD>
                <P>Section 3507 of the Paperwork Reduction Act of 1995, 44 U.S.C. Chapter 35.</P>
                <SIG>
                    <DATED>Dated: April 20, 2020.</DATED>
                    <NAME>Anna P. Guido,</NAME>
                    <TITLE>Department Reports Management Officer, Office of the Chief Information Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09321 Filed 4-30-20; 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-R2-ES-2020-N062; FXES11140200000-201-FF02ENEH00]</DEPDOC>
                <SUBJECT>Application for an Incidental Take Permit; Low-Effect Habitat Conservation Plan for the Four Corners Water Development Project, Pueblo of Santa Clara, Rio Arriba County, New Mexico; Reopening of Public Comment Period</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Fish and Wildlife Service, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of availability; reopening of public comment period.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>We, the U.S. Fish and Wildlife Service, are reopening the public comment period for the incidental take permit (ITP) application received from the Pueblo of Santa Clara supported by a low-effect habitat conservation plan (LEHCP).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The comment period for the ITP application and associated documents, which opened via a notice that published on March 2, 2020 (85 FR 12324), is reopened. We will accept comments received or postmarked on or before May 15, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        <E T="03">Obtaining documents:</E>
                         You may obtain copies of the ITP application, the LEHCP, or other related documents on the internet at 
                        <E T="03">https://www.fws.gov/southwest/es/NewMexico/.</E>
                    </P>
                    <P>
                        <E T="03">Submitting comments:</E>
                         You may submit written comments by email to 
                        <E T="03">nmesfo@fws.gov.</E>
                         Please note that your comment is in reference to the Pueblo of Santa Clara HCP. For more information, see Public Availability of Comments.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Seth Willey, Acting Project Leader, 505-761-4781. Individuals who are hearing or speech impaired may call the Federal 
                        <PRTPAGE P="25472"/>
                        Relay Service at 1-800-877-8339 for TTY assistance.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    We, the U.S. Fish and Wildlife Service (Service), received an incidental take permit (ITP) application from the Pueblo of Santa Clara in accordance with the requirements of the Endangered Species Act, as amended (ESA; 16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ). We announced the availability of the ITP application and associated low-effect habitat conservation plan (LEHCP) in a March 2, 2020 (85 FR 12324), 
                    <E T="04">Federal Register</E>
                     notice. For more information, see that notice.
                </P>
                <P>
                    We are reopening the public comment period on the ITP application and associated documents (see 
                    <E T="02">DATES</E>
                     and 
                    <E T="02">ADDRESSES</E>
                    ). Based on comments submitted during the original public comment period, we identified an incomplete statement in the LEHCP regarding the land status of the well field. This statement has been corrected and clarified in the LEHCP on the following pages: Page i (Summary), page 2 (Section 1.1), page 4 (Section 1.5), page 9 (introduction paragraph to Section 3), page 19 (Section 4.1), and page 32 (Section I of Appendix A). No other changes were made to the document other than this clarification. If you have previously submitted comments, please do not resubmit them, we have already incorporated them in the public record and will fully consider them in our final decision.
                </P>
                <HD SOURCE="HD1">Public Availability of Comments</HD>
                <P>All comments we receive become part of the public record associated with this action. Requests for copies of comments will be handled in accordance with the Freedom of Information Act, National Environmental Policy Act, and Service and Department of the Interior policies and procedures. 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 to withhold your personal identifying information from public review, we cannot guarantee that we will be able to do so. All submissions from organizations or businesses, and from individuals identifying themselves as representatives or officials of organizations or businesses, will be made available for public disclosure in their entirety.</P>
                <HD SOURCE="HD1">Authority</HD>
                <P>
                    We issue this notice pursuant to section 10(c) of the ESA (16 U.S.C. 1531 
                    <E T="03">et seq.</E>
                    ) and its implementing regulations in the Code of Federal Regulations (50 CFR 17.22 and 17.32), and the National Environmental Policy Act (42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    ) and its implementing regulations (40 CFR 1506.6 and 43 CFR 46.305).
                </P>
                <SIG>
                    <NAME>Amy Lueders,</NAME>
                    <TITLE>Regional Director, Southwest Region, U.S. Fish and Wildlife Service.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09262 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4333-15-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF THE INTERIOR</AGENCY>
                <SUBAGY>Office of the Secretary</SUBAGY>
                <DEPDOC>[LLWO210000.L1610000]</DEPDOC>
                <SUBJECT>National Environmental Policy Act Implementing Procedures for the Bureau of Land Management (516 DM 11)</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Office of the Secretary, Interior.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of revisions.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>This notice announces the establishment of a categorical exclusion (CX) for the Bureau of Land Management (BLM) as directed by the amendment of the Healthy Forests Restoration Act (HFRA) of 2003 by the Agriculture Improvement Act of 2018. This establishment revises BLM policies and procedures for compliance with the National Environmental Policy Act (NEPA), as amended; other statutes; Executive Order 11514, as amended; Executive Order 12114; and the Council on Environmental Quality's regulations. These CXs, as well as others established by Congress, as described below, will be incorporated into the Departmental Manual (DM) and will be added to the Department of the Interior's (Department) Electronic Library of Interior Policies (ELIPS).</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>The CXs will be incorporated into 516 DM 11 June 1, 2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The public will be able to review the revised DM on the Department's website at 
                        <E T="03">http://www.doi.gov/nepa.</E>
                         ELIPS is located at: 
                        <E T="03">https://www.doi.gov/elips.</E>
                         The BLM's current procedures can be found at: 
                        <E T="03">https://elips.doi.gov/ELIPS/DocView.aspx?id=1721.</E>
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Heather Bernier, Acting Division Chief, Planning and Decision Support, Bureau of Land Management at (202) 912-7282, [insert address], or 
                        <E T="03">hbernier@blm.gov.</E>
                         Persons who use a telecommunications device for the deaf (TDD) may call the Federal Relay Service (FRS) at 1-800-877-8339 to contact Heather Bernier. The FRS is available 24 hours a day, 7 days a week, to leave a message or question with the above individual. You will receive a reply during normal business hours.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The BLM's NEPA procedures, located at Chapter 11 of Part 516 of the Departmental Manual (516 DM 11), were last updated August 14, 2007. The Agriculture Improvement Act of 2018 amended Title VI of the HFRA of 2003 (16 U.S.C. 6591 
                    <E T="03">et seq.</E>
                    ) to add Section 606. Section 606 directed development of a CX for specified covered vegetation management activities carried out to protect, restore, or improve habitat for greater sage-grouse or mule deer (HFRA, Section 606(b)(1)). Section 606 further provides the specific terms, actions, limitations, exclusions, and definitions of activities to be included in the CX established. As directed by this section, the BLM is to establish the CX that meets these same specific terms, actions, limitations, exclusions, and definitions; and to establish the CX within one year of the enactment of the legislation (by December 20, 2019). In addition, the BLM is taking the opportunity to incorporate into 516 DM 11 several other CXs established by Congress in recent years.
                </P>
                <P>Because the CXs are established or directed by Congress, the BLM does not have the discretion to change their terms.</P>
                <P>Below is the new text of Chapter 11, reflecting the statutorily established or directed CXs:</P>
                <HD SOURCE="HD3">11.10 Categorical Exclusions Established or Directed by Statute</HD>
                <P>A. The Energy Policy Act of 2005 (Pub. L. 109-58) (42 U.S.C. 15942) established actions for categorical exclusion from NEPA analysis. Use of Energy Policy Act categorical exclusions does not require review for extraordinary circumstances. This is because these CXs are established by statute, and their application is governed by that statute. Section 390 of the Energy Policy Act of 2005 provides:</P>
                <P>(a) NEPA Review.—Action by the Secretary of the Interior in managing the public lands, with respect to any of the activities described in subsection (b), shall be subject to a rebuttable presumption that the use of a categorical exclusion under the National Environmental Policy Act (NEPA) of 1969 would apply if the activity is conducted pursuant to the Mineral Leasing Act for the purpose of exploration or development of oil or gas.</P>
                <P>
                    (b) Activities Described.—The activities referred to in subsection (a) are the following:
                    <PRTPAGE P="25473"/>
                </P>
                <P>(1) Individual surface disturbances of less than 5 acres so long as the total surface disturbance on the lease is not greater than 150 acres and site-specific analysis in a document prepared pursuant to NEPA has been previously completed.</P>
                <P>(2) Drilling an oil or gas well at a location or well pad site at which drilling has occurred previously within 5 years prior to the date of spudding the well.</P>
                <P>(3) Drilling an oil or gas well within a developed field for which an approved land use plan or any environmental document prepared pursuant to NEPA analyzed such drilling as a reasonably foreseeable activity, so long as such plan or document was approved within 5 years prior to the date of spudding the well.</P>
                <P>(4) Placement of a pipeline in an approved right-of-way corridor, so long as the corridor was approved within 5 years prior to the date of placement of the pipeline.</P>
                <P>(5) Maintenance of a minor activity, other than any construction or major renovation of a building or facility.</P>
                <P>B. Section 3023 “Grazing Permits and Leases” of Public Law 113-291, The Carl Levin and Howard P. `Buck' McKeon National Defense Authorization Act for Fiscal Year 2015, amended Section 402 of FLPMA. The amended text is now included in FLPMA, as amended, as Section 402(h). Therefore, the BLM may use the grazing permit categorical exclusion (1) or the trailing and crossing categorical exclusion (2). Application of either categorical exclusion requires extraordinary circumstances review. Section 402(h) of FLPMA provides:</P>
                <P>
                    (1) 
                    <E T="03">In general</E>
                    .—The issuance of a grazing permit or lease by the Secretary concerned may be categorically excluded from the requirement to prepare an environmental assessment or an environmental impact statement under the National Environmental Policy Act of 1969 (42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    ) if—
                </P>
                <P>(A) the issued permit or lease continues the current grazing management of the allotment; and</P>
                <P>(B) the Secretary concerned—</P>
                <P>(i) has assessed and evaluated the grazing allotment associated with the lease or permit; and</P>
                <P>(ii) based on the assessment and evaluation under clause (i), has determined that the allotment—</P>
                <P>(I) with respect to public land administered by the Secretary of the Interior— (aa) is meeting land health standards; or</P>
                <P>(bb) is not meeting land health standards due to factors other than existing livestock grazing; or</P>
                <P>
                    (2) 
                    <E T="03">Trailing and crossing.</E>
                    —The trailing and crossing of livestock across public land and the implementation of trailing and crossing practices by the Secretary concerned may be categorically excluded from the requirement to prepare an environmental assessment or an environmental impact statement under the National Environmental Policy Act of 1969 (42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    )
                </P>
                <P>
                    C. The Agriculture Improvement Act of 2018 (P.L. 115-334) amended Title VI of the Healthy Forests Restoration Act of 2003 (HFRA) (16 U.S.C. 6591 
                    <E T="03">et seq.</E>
                    ) to add Section 606. Section 606 directed development of a categorical exclusion for covered vegetation management activities carried out to protect, restore, or improve habitat for greater sage-grouse or mule deer (HFRA, Section 606(b)(1)). This categorical exclusion may be used to carry out a “covered vegetation management activity” (defined at HFRA, Section 606(a)(1)(B)) whose purpose is for the management of greater sage-grouse and mule deer habitat on public lands that was designated under HFRA section 602(b), on December 20, 2018 (HFRA, Section 606(g)(2)). Application of this categorical exclusion requires extraordinary circumstances review. Section 606 of HFRA provides:
                </P>
                <P>(a) Definitions.—In this section:</P>
                <P>(1) COVERED VEGETATION MANAGEMENT ACTIVITY.—</P>
                <P>(A) IN GENERAL.—The term `covered vegetation management activity' means any activity described in subparagraph (B) that—</P>
                <P>(i) is carried out on public land administered by the Bureau of Land Management;</P>
                <P>(ii) with respect to public land, meets the objectives of the order of the Secretary of the Interior numbered 3336 and dated January 5, 2015;</P>
                <P>(iii) conforms to an applicable land use plan;</P>
                <P>(iv) protects, restores, or improves greater sage-grouse or mule deer habitat in a sagebrush steppe ecosystem as described in—</P>
                <P>(I) Circular 1416 of the United States Geological Survey entitled `Restoration Handbook for Sagebrush Steppe Ecosystems with Emphasis on Greater Sage-Grouse Habitat—Part 1. Concepts for Understanding and Applying Restoration' (2015); or</P>
                <P>(II) the habitat guidelines for mule deer published by the Mule Deer Working Group of the Western Association of Fish and Wildlife Agencies;</P>
                <P>(v) will not permanently impair—</P>
                <P>(I) the natural state of the treated area;</P>
                <P>(II) outstanding opportunities for solitude;</P>
                <P>(III) outstanding opportunities for primitive, unconfined recreation;</P>
                <P>(IV) economic opportunities consistent with multiple-use management; or</P>
                <P>(V) the identified values of a unit of the National Landscape Conservation System;</P>
                <P>(vi) (I) restores native vegetation following a natural disturbance;</P>
                <P>(II) prevents the expansion into greater sage-grouse or mule deer habitat of—</P>
                <P>(aa) juniper, pinyon pine, or other associated conifers; or</P>
                <P>(bb) nonnative or invasive vegetation;</P>
                <P>(III) reduces the risk of loss of greater sage-grouse or mule deer habitat from wildfire or any other natural disturbance; or</P>
                <P>(IV) provides emergency stabilization of soil resources after a natural disturbance; and</P>
                <P>(vii) provides for the conduct of restoration treatments that—</P>
                <P>(I) maximize the retention of old-growth and large trees, as appropriate for the forest type;</P>
                <P>(II) consider the best available scientific information to maintain or restore the ecological integrity, including maintaining or restoring structure, function, composition, and connectivity;</P>
                <P>(III) are developed and implemented through a collaborative process that—</P>
                <P>(aa) includes multiple interested persons representing diverse interests; and</P>
                <P>(bb) (AA) is transparent and nonexclusive; or</P>
                <P>(BB) meets the requirements for a resource advisory committee under subsections (c) through (f) of section 205 of the Secure Rural Schools and Community Self-Determination Act of 2000 (16 U.S.C. 7125); and</P>
                <P>(IV) may include the implementation of a proposal that complies with the eligibility requirements of the Collaborative Forest Landscape Restoration Program under section 4003(b) of the Omnibus Public Land Management Act of 2009 (16 U.S.C. 7303(b)).</P>
                <P>(B) DESCRIPTION OF ACTIVITIES.—An activity referred to in subparagraph (A) is—</P>
                <P>(i) manual cutting and removal of juniper trees, pinyon pine trees, other associated conifers, or other nonnative or invasive vegetation;</P>
                <P>
                    (ii) mechanical mastication, cutting, or mowing, mechanical piling and burning, chaining, broadcast burning, or yarding;
                    <PRTPAGE P="25474"/>
                </P>
                <P>(iii) removal of cheat grass, medusa head rye, or other nonnative, invasive vegetation;</P>
                <P>(iv) collection and seeding or planting of native vegetation using a manual, mechanical, or aerial method;</P>
                <P>(v) seeding of nonnative, noninvasive, ruderal vegetation only for the purpose of emergency stabilization;</P>
                <P>(vi) targeted use of an herbicide, subject to the condition that the use shall be in accordance with applicable legal requirements, Federal agency procedures, and land use plans;</P>
                <P>(vii) targeted livestock grazing to mitigate hazardous fuels and control noxious and invasive weeds;</P>
                <P>(viii) temporary removal of wild horses or burros in the area in which the activity is being carried out to ensure treatment objectives are met;</P>
                <P>(ix) in coordination with the affected permit holder, modification or adjustment of permissible usage under an annual plan of use of a grazing permit issued by the Secretary concerned to achieve restoration treatment objectives;</P>
                <P>(x) installation of new, or modification of existing, fencing or water sources intended to control use or improve wildlife habitat; or</P>
                <P>(xi) necessary maintenance of, repairs to, rehabilitation of, or reconstruction of an existing permanent road or construction of temporary roads to accomplish the activities described in this subparagraph.</P>
                <P>(C) EXCLUSIONS.—The term `covered vegetation management activity' does not include—</P>
                <P>(i) any activity conducted in a wilderness area or wilderness study area;</P>
                <P>(ii) any activity for the construction of a permanent road or permanent trail;</P>
                <P>(iii) any activity conducted on Federal land on which, by Act of Congress or Presidential proclamation, the removal of vegetation is restricted or prohibited;</P>
                <P>(iv) any activity conducted in an area in which activities under subparagraph (B) would be inconsistent with the applicable resource management plan; or</P>
                <P>(2) SECRETARY CONCERNED.—The term `Secretary concerned' means—</P>
                <P>(B) the Secretary of the Interior, with respect to public land.</P>
                <P>(3) TEMPORARY ROAD.—The term `temporary road' means a road that is—</P>
                <P>(A) authorized—</P>
                <P>(i) by a contract, permit, lease, other written authorization; or</P>
                <P>(ii) pursuant to an emergency operation;</P>
                <P>(B) not intended to be part of the permanent transportation system of a Federal department or agency;</P>
                <P>(C) not necessary for long-term resource management;</P>
                <P>(D) designed in accordance with standards appropriate for the intended use of the road, taking into consideration—</P>
                <P>(i) safety;</P>
                <P>(ii) the cost of transportation; and</P>
                <P>(iii) impacts to land and resources; and</P>
                <P>(E) managed to minimize—</P>
                <P>(i) erosion; and</P>
                <P>(ii) the introduction or spread of invasive species.</P>
                <P>(b) Categorical Exclusion.—</P>
                <P>(1) IN GENERAL.—Not later than 1 year after the date of enactment of this section, the Secretary concerned shall develop a categorical exclusion (as defined in section 1508.4 of title 40, Code of Federal Regulations (or a successor regulation)) for covered vegetation management activities carried out to protect, restore, or improve habitat for greater sage-grouse or mule deer.</P>
                <P>(2) ADMINISTRATION.—In developing and administering the categorical exclusion under paragraph (1), the Secretary concerned shall—</P>
                <P>
                    (A) comply with the National Environmental Policy Act of 1969 (42 U.S.C. 4321 
                    <E T="03">et seq.</E>
                    );
                </P>
                <P>(C) with respect to public land, apply the extraordinary circumstances procedures under section 46.215 of title 43, Code of Federal Regulations (or successor regulations), in determining whether to use the categorical exclusion; and</P>
                <P>(D) consider—</P>
                <P>(i) the relative efficacy of landscape-scale habitat projects;</P>
                <P>(ii) the likelihood of continued declines in the populations of greater sage-grouse and mule deer in the absence of landscape-scale vegetation management; and</P>
                <P>(iii) the need for habitat restoration activities after wildfire or other natural disturbances.</P>
                <P>(c) Implementation Of Covered Vegetative Management Activities Within The Range Of Greater Sage-Grouse And Mule Deer.—If the categorical exclusion developed under subsection (b) is used to implement a covered vegetative management activity in an area within the range of both greater sage-grouse and mule deer, the covered vegetative management activity shall protect, restore, or improve habitat concurrently for both greater sage-grouse and mule deer.</P>
                <P>(d) Long-Term Monitoring And Maintenance.—Before commencing any covered vegetation management activity that is covered by the categorical exclusion under subsection (b), the Secretary concerned shall develop a long-term monitoring and maintenance plan, covering at least the 20-year period beginning on the date of commencement, to ensure that management of the treated area does not degrade the habitat gains secured by the covered vegetation management activity.</P>
                <P>(e) Disposal Of Vegetative Material.—Subject to applicable local restrictions, any vegetative material resulting from a covered vegetation management activity that is covered by the categorical exclusion under subsection (b) may be—</P>
                <P>(1) used for—</P>
                <P>(A) fuel wood; or</P>
                <P>(B) other products; or</P>
                <P>(2) piled or burned, or both.</P>
                <P>(f) Treatment For Temporary Roads.—</P>
                <P>(1) IN GENERAL.—Notwithstanding subsection (a)(1)(B)(xi), any temporary road constructed in carrying out a covered vegetation management activity that is covered by the categorical exclusion under subsection (b)—</P>
                <P>(A) shall be used by the Secretary concerned for the covered vegetation management activity for not more than 2 years; and</P>
                <P>(B) shall be decommissioned by the Secretary concerned not later than 3 years after the earlier of the date on which—</P>
                <P>(i) the temporary road is no longer needed; and</P>
                <P>(ii) the project is completed.</P>
                <P>(2) REQUIREMENT.—A treatment under paragraph (1) shall include reestablishing native vegetative cover—</P>
                <P>(A) as soon as practicable; but</P>
                <P>(B) not later than 10 years after the date of completion of the applicable covered vegetation management activity.</P>
                <P>(g) Limitations.—</P>
                <P>(1) PROJECT SIZE.—A covered vegetation management activity that is covered by the categorical exclusion under subsection (b) may not exceed 4,500 acres.</P>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                        NEPA, the National Environmental Quality Improvement Act of 1970, as amended (42 U.S.C. 4371 
                        <E T="03">et seq.</E>
                        ); E.O. 11514, March 5, 1970, as amended by E.O. 11991, May 24, 1977; and CEQ regulations (40 CFR 1507.3).
                    </P>
                </AUTH>
                <SIG>
                    <NAME>Michaela E. Noble,</NAME>
                    <TITLE>Director, Office of Environmental Policy and Compliance.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09301 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4331-84-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <PRTPAGE P="25475"/>
                <AGENCY TYPE="N">INTERNATIONAL TRADE COMMISSION</AGENCY>
                <DEPDOC>[Investigation Nos. 701-TA-456 and 731-TA-1151-1152 (Second Review)]</DEPDOC>
                <SUBJECT>Citric Acid and Certain Citrate Salts From Canada and China; Institution of Five-Year Reviews</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>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The Commission hereby gives notice that it has instituted reviews pursuant to the Tariff Act of 1930 (“the Act”), as amended, to determine whether revocation of the countervailing and antidumping duty orders on citric acid and certain citrate salts from China and the antidumping duty order on citric acid and certain citrate salts from Canada would be likely to lead to continuation or recurrence of material injury. Pursuant to the Act, interested parties are requested to respond to this notice by submitting the information specified below to the Commission.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Instituted May 1, 2020. To be assured of consideration, the deadline for responses is June 1, 2020. Comments on the adequacy of responses may be filed with the Commission by July 15, 2020.</P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mary Messer (202-205-3193), 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 proceeding 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>
                    <E T="03">Background.</E>
                    —On May 29, 2009, the Department of Commerce (“Commerce”) issued a countervailing duty order on imports of citric acid and certain citrate salts from China (74 FR 25705) and antidumping duty orders on imports of citric acid and certain citrate salts from China and Canada (74 FR 25703). Following the first five-year reviews by Commerce and the Commission, effective June 24, 2015, Commerce issued a continuation of the countervailing duty order on imports of citric acid and certain citrate salts from China and the antidumping duty orders on imports of citric acid and certain citrate salts from Canada and China (80 FR 36318). The Commission is now conducting its second reviews pursuant to section 751(c) of the Act, as amended (19 U.S.C. 1675(c)), to determine whether revocation of the orders would be likely to lead to continuation or recurrence of material injury to the domestic industry within a reasonably foreseeable time. Provisions concerning the conduct of this proceeding may be found in the Commission's Rules of Practice and Procedure at 19 CFR part 201, subparts A and B, and 19 CFR part 207, subparts A and F. The Commission will assess the adequacy of interested party responses to this notice of institution to determine whether to conduct full reviews or expedited reviews. The Commission's determinations in any expedited reviews will be based on the facts available, which may include information provided in response to this notice.
                </P>
                <P>
                    <E T="03">Definitions.</E>
                    —The following definitions apply to these reviews:
                </P>
                <P>
                    (1) 
                    <E T="03">Subject Merchandise</E>
                     is the class or kind of merchandise that is within the scope of the five-year reviews, as defined by Commerce.
                </P>
                <P>
                    (2) The 
                    <E T="03">Subject Countries</E>
                     in these reviews are Canada and China.
                </P>
                <P>
                    (3) The 
                    <E T="03">Domestic Like Product</E>
                     is the domestically produced product or products which are like, or in the absence of like, most similar in characteristics and uses with, the 
                    <E T="03">Subject Merchandise.</E>
                     In its original determinations, the Commission defined one 
                    <E T="03">Domestic Like Product</E>
                     consisting of citric acid (whether in crude form as calcium citrate or in finished form), sodium citrate, and potassium citrate in all chemical and physical forms and grades. In its full five-year review determinations, the Commission defined the 
                    <E T="03">Domestic Like Product</E>
                     as the same as in the original investigations.
                </P>
                <P>
                    (4) The 
                    <E T="03">Domestic Industry</E>
                     is the U.S. producers as a whole of the 
                    <E T="03">Domestic Like Product,</E>
                     or those producers whose collective output of the 
                    <E T="03">Domestic Like Product</E>
                     constitutes a major proportion of the total domestic production of the product. In its original determinations and its full first five-year review determinations, the Commission defined the 
                    <E T="03">Domestic Industry</E>
                     as consisting of all domestic producers of citric acid and citrate salts.
                </P>
                <P>
                    (5) An 
                    <E T="03">Importer</E>
                     is any person or firm engaged, either directly or through a parent company or subsidiary, in importing the 
                    <E T="03">Subject Merchandise</E>
                     into the United States from a foreign manufacturer or through its selling agent.
                </P>
                <P>
                    <E T="03">Participation in the proceeding and public service list.</E>
                    —Persons, including industrial users of the 
                    <E T="03">Subject Merchandise</E>
                     and, if the merchandise is sold at the retail level, representative consumer organizations, wishing to participate in the proceeding as parties must file an entry of appearance with the Secretary to the Commission, as provided in section 201.11(b)(4) of the Commission's rules, no later than 21 days after publication of this notice in the 
                    <E T="04">Federal Register</E>
                    <E T="03">.</E>
                     The Secretary will maintain a public service list containing the names and addresses of all persons, or their representatives, who are parties to the proceeding.
                </P>
                <P>Former Commission employees who are seeking to appear in Commission five-year reviews are advised that they may appear in a review even if they participated personally and substantially in the corresponding underlying original investigation or an earlier review of the same underlying investigation. The Commission's designated agency ethics official has advised that a five-year review is not the same particular matter as the underlying original investigation, and a five-year review is not the same particular matter as an earlier review of the same underlying investigation for purposes of 18 U.S.C. 207, the post employment statute for Federal employees, and Commission rule 201.15(b) (19 CFR 201.15(b)), 79 FR 3246 (Jan. 17, 2014), 73 FR 24609 (May 5, 2008). Consequently, former employees are not required to seek Commission approval to appear in a review under Commission rule 19 CFR 201.15, even if the corresponding underlying original investigation or an earlier review of the same underlying investigation was pending when they were Commission employees. For further ethics advice on this matter, contact Charles Smith, Office of the General Counsel, at 202-205-3408.</P>
                <P>
                    <E T="03">Limited disclosure of business proprietary information (BPI) under an administrative protective order (APO) and APO service list.</E>
                    —Pursuant to section 207.7(a) of the Commission's rules, the Secretary will make BPI submitted in this proceeding available to authorized applicants under the APO issued in the proceeding, provided that the application is made no later than 21 days after publication of this notice in the 
                    <E T="04">Federal Register</E>
                    . Authorized applicants must represent interested parties, as defined in 19 U.S.C. 1677(9), who are parties to the proceeding. A 
                    <PRTPAGE P="25476"/>
                    separate service list will be maintained by the Secretary for those parties authorized to receive BPI under the APO.
                </P>
                <P>
                    <E T="03">Certification.</E>
                    —Pursuant to section 207.3 of the Commission's rules, any person submitting information to the Commission in connection with this proceeding must certify that the information is accurate and complete to the best of the submitter's knowledge. In making the certification, the submitter will acknowledge that information submitted in response to this request for information and throughout this proceeding or other proceeding may be disclosed to and used: (i) By the Commission, its employees and Offices, and contract personnel (a) for developing or maintaining the records of this or a related proceeding, or (b) in internal investigations, audits, reviews, and evaluations relating to the programs, personnel, and operations of the Commission including under 5 U.S.C. Appendix 3; or (ii) by U.S. government employees and contract personnel, solely for cybersecurity purposes. All contract personnel will sign appropriate nondisclosure agreements.
                </P>
                <P>
                    <E T="03">Written submissions.</E>
                    —Pursuant to section 207.61 of the Commission's rules, each interested party response to this notice must provide the information specified below. The deadline for filing such responses is June 1, 2020. Pursuant to section 207.62(b) of the Commission's rules, eligible parties (as specified in Commission rule 207.62(b)(1)) may also file comments concerning the adequacy of responses to the notice of institution and whether the Commission should conduct expedited or full reviews. The deadline for filing such comments is July 15, 2020. All written submissions must conform with the provisions of section 201.8 of the Commission's rules; any submissions that contain BPI must also conform with the requirements of sections 201.6, 207.3, and 207.7 of the Commission's rules. The Commission's 
                    <E T="03">Handbook on Filing Procedures,</E>
                     available on the Commission's website at 
                    <E T="03">https://www.usitc.gov/documents/handbook_on_filing_procedures.pdf,</E>
                     elaborates upon the Commission's procedures with respect to filings. Also, in accordance with sections 201.16(c) and 207.3 of the Commission's rules, each document filed by a party to the proceeding must be served on all other parties to the proceeding (as identified by either the public or APO service list as appropriate), and a certificate of service must accompany the document (if you are not a party to the proceeding you do not need to serve your response).
                </P>
                <P>
                    Please note the Secretary's Office will accept only electronic filings at this time. Filings must be made through the Commission's Electronic Document Information System (EDIS, 
                    <E T="03">https://edis.usitc.gov</E>
                    ). No in-person paper-based filings or paper copies of any electronic filings will be accepted until further notice.
                </P>
                <P>No response to this request for information is required if a currently valid Office of Management and Budget (“OMB”) number is not displayed; the OMB number is 3117 0016/USITC No. 20-5-461, expiration date June 30, 2020. Public reporting burden for the request is estimated to average 15 hours per response. Please send comments regarding the accuracy of this burden estimate to the Office of Investigations, U.S. International Trade Commission, 500 E Street SW, Washington, DC 20436.</P>
                <P>
                    <E T="03">Inability to provide requested information.</E>
                    —Pursuant to section 207.61(c) of the Commission's rules, any interested party that cannot furnish the information requested by this notice in the requested form and manner shall notify the Commission at the earliest possible time, provide a full explanation of why it cannot provide the requested information, and indicate alternative forms in which it can provide equivalent information. If an interested party does not provide this notification (or the Commission finds the explanation provided in the notification inadequate) and fails to provide a complete response to this notice, the Commission may take an adverse inference against the party pursuant to section 776(b) of the Act (19 U.S.C. 1677e(b)) in making its determinations in the reviews.
                </P>
                <P>
                    <E T="03">Information To Be Provided in Response to This Notice of Institution:</E>
                     If you are a domestic producer, union/worker group, or trade/business association; import/export 
                    <E T="03">Subject Merchandise</E>
                     from more than one 
                    <E T="03">Subject Country;</E>
                     or produce 
                    <E T="03">Subject Merchandise</E>
                     in more than one 
                    <E T="03">Subject Country,</E>
                     you may file a single response. If you do so, please ensure that your response to each question includes the information requested for each pertinent 
                    <E T="03">Subject Country.</E>
                     As used below, the term “firm” includes any related firms.
                </P>
                <P>(1) The name and address of your firm or entity (including World Wide Web address) and name, telephone number, fax number, and Email address of the certifying official.</P>
                <P>
                    (2) A statement indicating whether your firm/entity is an interested party under 19 U.S.C. 1677(9) and if so, how, including whether your firm/entity is a U.S. producer of the 
                    <E T="03">Domestic Like Product,</E>
                     a U.S. union or worker group, a U.S. importer of the 
                    <E T="03">Subject Merchandi</E>
                    se, a foreign producer or exporter of the 
                    <E T="03">Subject Merchandise,</E>
                     a U.S. or foreign trade or business association (a majority of whose members are interested parties under the statute), or another interested party (including an explanation). If you are a union/worker group or trade/business association, identify the firms in which your workers are employed or which are members of your association.
                </P>
                <P>(3) A statement indicating whether your firm/entity is willing to participate in this proceeding by providing information requested by the Commission.</P>
                <P>
                    (4) A statement of the likely effects of the revocation of the countervailing duty order on imports of citric acid and certain citrate salts from China and revocation of the antidumping duty orders on imports of citric acid and certain citrate salts from Canada and China on the 
                    <E T="03">Domestic Industry</E>
                     in general and/or your firm/entity specifically. In your response, please discuss the various factors specified in section 752(a) of the Act (19 U.S.C. 1675a(a)) including the likely volume of subject imports, likely price effects of subject imports, and likely impact of imports of 
                    <E T="03">Subject Merchandise</E>
                     on the 
                    <E T="03">Domestic Industry.</E>
                </P>
                <P>
                    (5) A list of all known and currently operating U.S. producers of the 
                    <E T="03">Domestic Like Product.</E>
                     Identify any known related parties and the nature of the relationship as defined in section 771(4)(B) of the Act (19 U.S.C. 1677(4)(B)).
                </P>
                <P>
                    (6) A list of all known and currently operating U.S. importers of the 
                    <E T="03">Subject Merchandise</E>
                     and producers of the 
                    <E T="03">Subject Merchandise</E>
                     in each 
                    <E T="03">Subject Country</E>
                     that currently export or have exported 
                    <E T="03">Subject Merchandise</E>
                     to the United States or other countries after 2013.
                </P>
                <P>
                    (7) A list of 3-5 leading purchasers in the U.S. market for the 
                    <E T="03">Domestic Like Product</E>
                     and the 
                    <E T="03">Subject Merchandise</E>
                     (including street address, World Wide Web address, and the name, telephone number, fax number, and Email address of a responsible official at each firm).
                </P>
                <P>
                    (8) A list of known sources of information on national or regional prices for the 
                    <E T="03">Domestic Like Product</E>
                     or the 
                    <E T="03">Subject Merchandise</E>
                     in the U.S. or other markets.
                </P>
                <P>
                    (9) If you are a U.S. producer of the 
                    <E T="03">Domestic Like Product,</E>
                     provide the following information on your firm's operations on that product during calendar year 2019, except as noted (report quantity data in dry pounds and value data in U.S. dollars, f.o.b. plant). 
                    <PRTPAGE P="25477"/>
                    If you are a union/worker group or trade/business association, provide the information, on an aggregate basis, for the firms in which your workers are employed/which are members of your association.
                </P>
                <P>
                    (a) Production (quantity) and, if known, an estimate of the percentage of total U.S. production of the 
                    <E T="03">Domestic Like Product</E>
                     accounted for by your firm's(s') production;
                </P>
                <P>
                    (b) Capacity (quantity) of your firm to produce the 
                    <E T="03">Domestic Like Product</E>
                     (that is, the level of production that your establishment(s) could reasonably have expected to attain during the year, assuming normal operating conditions (using equipment and machinery in place and ready to operate), normal operating levels (hours per week/weeks per year), time for downtime, maintenance, repair, and cleanup, and a typical or representative product mix);
                </P>
                <P>
                    (c) the quantity and value of U.S. commercial shipments of the 
                    <E T="03">Domestic Like Product</E>
                     produced in your U.S. plant(s);
                </P>
                <P>
                    (d) the quantity and value of U.S. internal consumption/company transfers of the 
                    <E T="03">Domestic Like Product</E>
                     produced in your U.S. plant(s); and
                </P>
                <P>
                    (e) the value of (i) net sales, (ii) cost of goods sold (COGS), (iii) gross profit, (iv) selling, general and administrative (SG&amp;A) expenses, and (v) operating income of the 
                    <E T="03">Domestic Like Product</E>
                     produced in your U.S. plant(s) (include both U.S. and export commercial sales, internal consumption, and company transfers) for your most recently completed fiscal year (identify the date on which your fiscal year ends).
                </P>
                <P>
                    (10) If you are a U.S. importer or a trade/business association of U.S. importers of the 
                    <E T="03">Subject Merchandise</E>
                     from either 
                    <E T="03">Subject Country,</E>
                     provide the following information on your firm's(s') operations on that product during calendar year 2019 (report quantity data in dry pounds and value data in U.S. dollars). If you are a trade/business association, provide the information, on an aggregate basis, for the firms which are members of your association.
                </P>
                <P>
                    (a) The quantity and value (landed, duty-paid but not including antidumping or countervailing duties) of U.S. imports and, if known, an estimate of the percentage of total U.S. imports of 
                    <E T="03">Subject Merchandise</E>
                     from each 
                    <E T="03">Subject Country</E>
                     accounted for by your firm's(s') imports;
                </P>
                <P>
                    (b) the quantity and value (f.o.b. U.S. port, including antidumping and/or countervailing duties) of U.S. commercial shipments of 
                    <E T="03">Subject Merchandise</E>
                     imported from each 
                    <E T="03">Subject Country;</E>
                     and
                </P>
                <P>
                    (c) the quantity and value (f.o.b. U.S. port, including antidumping and/or countervailing duties) of U.S. internal consumption/company transfers of 
                    <E T="03">Subject Merchandise</E>
                     imported from each 
                    <E T="03">Subject Country.</E>
                </P>
                <P>
                    (11) If you are a producer, an exporter, or a trade/business association of producers or exporters of the 
                    <E T="03">Subject Merchandise</E>
                     in either 
                    <E T="03">Subject Country,</E>
                     provide the following information on your firm's(s') operations on that product during calendar year 2019 (report quantity data in dry pounds and value data in U.S. dollars, landed and duty-paid at the U.S. port but not including antidumping or countervailing duties). If you are a trade/business association, provide the information, on an aggregate basis, for the firms which are members of your association.
                </P>
                <P>
                    (a) Production (quantity) and, if known, an estimate of the percentage of total production of 
                    <E T="03">Subject Merchandise</E>
                     in each 
                    <E T="03">Subject Country</E>
                     accounted for by your firm's(s') production;
                </P>
                <P>
                    (b) Capacity (quantity) of your firm(s) to produce the 
                    <E T="03">Subject Merchandise</E>
                     in each 
                    <E T="03">Subject Country</E>
                     (that is, the level of production that your establishment(s) could reasonably have expected to attain during the year, assuming normal operating conditions (using equipment and machinery in place and ready to operate), normal operating levels (hours per week/weeks per year), time for downtime, maintenance, repair, and cleanup, and a typical or representative product mix); and
                </P>
                <P>
                    (c) the quantity and value of your firm's(s') exports to the United States of 
                    <E T="03">Subject Merchandise</E>
                     and, if known, an estimate of the percentage of total exports to the United States of 
                    <E T="03">Subject Merchandise</E>
                     from each 
                    <E T="03">Subject Country</E>
                     accounted for by your firm's(s') exports.
                </P>
                <P>
                    (12) Identify significant changes, if any, in the supply and demand conditions or business cycle for the 
                    <E T="03">Domestic Like Product</E>
                     that have occurred in the United States or in the market for the 
                    <E T="03">Subject Merchandise</E>
                     in each 
                    <E T="03">Subject Country</E>
                     after 2013, and significant changes, if any, that are likely to occur within a reasonably foreseeable time. Supply conditions to consider include technology; production methods; development efforts; ability to increase production (including the shift of production facilities used for other products and the use, cost, or availability of major inputs into production); and factors related to the ability to shift supply among different national markets (including barriers to importation in foreign markets or changes in market demand abroad). Demand conditions to consider include end uses and applications; the existence and availability of substitute products; and the level of competition among the 
                    <E T="03">Domestic Like Product</E>
                     produced in the United States, 
                    <E T="03">Subject Merchandise</E>
                     produced in each 
                    <E T="03">Subject Country,</E>
                     and such merchandise from other countries.
                </P>
                <P>
                    (13) (Optional) A statement of whether you agree with the above definitions of the 
                    <E T="03">Domestic Like Product</E>
                     and 
                    <E T="03">Domestic Industry;</E>
                     if you disagree with either or both of these definitions, please explain why and provide alternative definitions.
                </P>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P> This proceeding is being conducted under authority of title VII of the Tariff Act of 1930; this notice is published pursuant to section 207.61 of the Commission's rules.</P>
                </AUTH>
                <EXTRACT>
                    <P>By order of the Commission.</P>
                </EXTRACT>
                <SIG>
                    <DATED>Issued: April 28, 2020.</DATED>
                    <NAME>Lisa Barton,</NAME>
                    <TITLE>Secretary to the Commission.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09288 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7020-02-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NATIONAL SCIENCE FOUNDATION</AGENCY>
                <SUBJECT>Advisory Committee for Computer and Information Science and Engineering; Notice of Meeting</SUBJECT>
                <P>In accordance with the Federal Advisory Committee Act (Pub. L. 92-463, as amended), the National Science Foundation (NSF) announces the following meeting:</P>
                <P>
                    <E T="03">Name and Committee Code:</E>
                     Advisory Committee for Computer and Information Science and Engineering (CISE) (1115) (Virtual Meeting).
                </P>
                <P>
                    <E T="03">Date and Time:</E>
                     June 4, 2020; 11:00 a.m. to 5:00 p.m.
                </P>
                <P>
                    <E T="03">Place:</E>
                     NSF, 2415 Eisenhower Avenue, Alexandria, VA 22314 (Virtual attendance only). To attend the virtual meeting, please send your request for the virtual meeting link to the following email address: 
                    <E T="03">cmessam@nsf.gov.</E>
                </P>
                <P>
                    <E T="03">Type of Meeting:</E>
                     Open.
                </P>
                <P>
                    <E T="03">Contact Person:</E>
                     KaJuana Mayberry, National Science Foundation, 2415 Eisenhower Avenue, Alexandria, VA 22314; Telephone: 703-292-8900; Email: 
                    <E T="03">kmayberr@nsf.gov.</E>
                </P>
                <P>
                    <E T="03">Purpose of Meeting:</E>
                     To advise NSF on the impact of its policies, programs and activities in support of CISE research, education, and research infrastructure. To provide advice to the NSF Assistant Director for CISE on issues related to long-range planning, and to form ad hoc subcommittees and working groups to carry out needed studies and tasks.
                </P>
                <P>
                    <E T="03">Agenda:</E>
                </P>
                <FP SOURCE="FP-1">
                    • NSF and CISE updates
                    <PRTPAGE P="25478"/>
                </FP>
                <FP SOURCE="FP-1">• Discussion on the impacts of the novel coronavirus disease 2019 (COVID-19) on NSF and the broader research community</FP>
                <FP SOURCE="FP-1">• Discussion on a recent roundtable between the CISE and social, behavioral, and economic sciences</FP>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>Crystal Robinson,</NAME>
                    <TITLE>Committee Management Officer.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09333 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 7555-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[NRC-2019-0211]</DEPDOC>
                <SUBJECT>Information Collection: NRC Form 5, “Occupational Dose Record for a Monitoring Period”</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Renewal of existing information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) invites public comment on the renewal of Office of Management and Budget (OMB) approval for an existing collection of information. The information collection is entitled, NRC Form 5, “Occupational Dose Record for a Monitoring Period.”</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit comments by June 30, 2020. 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>You may submit comments 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-2019-0211. 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">Mail comments to:</E>
                         David Cullison, Office of the Chief Information Officer, Mail Stop: T-6 A10M, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001.
                    </P>
                    <P>
                        For additional direction 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>
                        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>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Obtaining Information and Submitting Comments</HD>
                <HD SOURCE="HD2">A. Obtaining Information</HD>
                <P>Please refer to Docket ID NRC-2019-0211 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-2019-0211. A copy of the collection of information and related instructions may be obtained without charge by accessing Docket ID NRC-2019-0211 on this website.
                </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, 301-415-4737, or by email to 
                    <E T="03">pdr.resource@nrc.gov.</E>
                     A copy of the collection of information and related instructions may be obtained without charge by accessing ADAMS Accession Nos. ML20023A311 and ML20023A312. The supporting statement is available in ADAMS under Accession No. ML20023A313.
                </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 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>Please include Docket ID NRC-2019-0211 in the subject line of your comment submission, in order to ensure that the NRC is able to make your comment submission available to the public in this docket.</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. 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, and 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. Background</HD>
                <P>In accordance with the Paperwork Reduction Act of 1995 (44 U.S.C. Chapter 35), the NRC is requesting public comment on its intention to request the OMB's approval for the information collection summarized below.</P>
                <P>
                    1. 
                    <E T="03">The title of the information collection:</E>
                     NRC Form 5, “Occupational Dose Record for a Monitoring Period.”
                </P>
                <P>
                    2. 
                    <E T="03">OMB approval number:</E>
                     3150-0006.
                </P>
                <P>
                    3. 
                    <E T="03">Type of submission:</E>
                     Extension.
                </P>
                <P>
                    4. 
                    <E T="03">The form number, if applicable:</E>
                     NRC Form 5.
                </P>
                <P>
                    5. 
                    <E T="03">How often the collection is required or requested:</E>
                     Annually.
                </P>
                <P>
                    6. 
                    <E T="03">Who will be required or asked to respond:</E>
                     NRC licensees who are required to comply with part 20 of title 10 of the 
                    <E T="03">Code of Federal Regulations</E>
                     (10 CFR).
                </P>
                <P>
                    7. 
                    <E T="03">The estimated number of annual responses:</E>
                     4,328 responses (182 reporting responses plus 4,146 recordkeepers).
                </P>
                <P>
                    8. 
                    <E T="03">The estimated number of annual respondents:</E>
                     4,146 respondents (98 reactors plus 4,048 materials licenses).
                </P>
                <P>
                    9. 
                    <E T="03">The estimated number of hours needed annually to comply with the information collection requirement or request:</E>
                     106,906 hours (5,460 hours reporting plus 101,446 hours recordkeeping).
                </P>
                <P>
                    10. 
                    <E T="03">Abstract:</E>
                     NRC Form 5 is used to record and report the results of individual monitoring for occupational radiation exposure during a monitoring period (one calendar year) to ensure regulatory compliance with annual radiation dose limits specified in 10 CFR 20.1201.
                </P>
                <HD SOURCE="HD1">III. Specific Requests for Comments</HD>
                <P>The NRC is seeking comments that address the following questions:</P>
                <P>1. Is the proposed collection of information necessary for the NRC to properly perform its functions? Does the information have practical utility?</P>
                <P>2. Is the estimate of the burden of the information collection accurate?</P>
                <P>3. Is there a way to enhance the quality, utility, and clarity of the information to be collected?</P>
                <P>
                    4. How can the burden of the information collection on respondents 
                    <PRTPAGE P="25479"/>
                    be minimized, including the use of automated collection techniques or other forms of information technology?
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>David C. Cullison,</NAME>
                    <TITLE>NRC Clearance Officer, Office of the Chief Information Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09323 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[NRC-2019-0183]</DEPDOC>
                <SUBJECT>Information Collection: NRC Form 749, “Manual License Verification Report”/License Verification System</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Renewal of existing information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) invites public comment on the renewal of Office of Management and Budget (OMB) approval for an existing collection of information. The information collection is entitled, “NRC Form 749, Manual License Verification Report/License Verfication System.”</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit comments by June 30, 2020. 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>You may submit comments 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-2019-0183. 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">Mail comments to:</E>
                         David Cullison, Office of the Chief Information Officer, Mail Stop: T-6 A10M, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001.
                    </P>
                    <P>
                        For additional direction 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>
                        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>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Obtaining Information and Submitting Comments</HD>
                <HD SOURCE="HD2">A. Obtaining Information</HD>
                <P>Please refer to Docket ID NRC-2019-0183 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">http://www.regulations.gov</E>
                     and search for Docket ID NRC-2019-0183. A copy of the collection of information and related instructions may be obtained without charge by accessing Docket ID NRC-2019-0183 on this website.
                </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, 301-415-4737, or by email to 
                    <E T="03">pdr.resource@nrc.gov.</E>
                     The supporting statement and NRC Form 749 “Manual License Verification Report” are available in ADAMS under Accession Nos. ML19329C623 and ML19329C625.
                </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 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>Please include Docket ID NRC-2019-0183 in the subject line of your comment submission, in order to ensure that the NRC is able to make your comment submission available to the public in this docket.</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. 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, and 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. Background</HD>
                <P>In accordance with the Paperwork Reduction Act of 1995 (44 U.S.C. Chapter 35), the NRC is requesting public comment on its intention to request the OMB's approval for the information collection summarized below.</P>
                <P>
                    1. 
                    <E T="03">The title of the information collection:</E>
                     NRC Form 749, Manual License Verification Report/License Verification System.
                </P>
                <P>
                    2. 
                    <E T="03">OMB approval number:</E>
                     3150-0223.
                </P>
                <P>
                    3. 
                    <E T="03">Type of submission:</E>
                     Extension.
                </P>
                <P>
                    4. 
                    <E T="03">The form number, if applicable:</E>
                     NRC 749.
                </P>
                <P>
                    5. 
                    <E T="03">How often the collection is required or requested:</E>
                     On occasion. Licensees subject to 10 CFR part 37, “Physical Protection of Byproduct Material” license verification requirements must verify the legitimacy of the license with the issuing agency prior to transferring radioactive materials in quantities of concern.
                </P>
                <P>
                    6. 
                    <E T="03">Who will be required or asked to respond:</E>
                     Licensees are required to complete a license verification under the circumstances noted in 5 above. A License Verification System (LVS) is available to provide an electronic method for fulfilling this requirement. In cases where a licensee is unable to use the LVS to perform a verification, they will provide NRC Form 749 for manual license verification.
                </P>
                <P>
                    7. 
                    <E T="03">The estimated number of annual responses:</E>
                     587 + 5,520 = 6,107.
                </P>
                <P>
                    8. 
                    <E T="03">The estimated number of annual respondents:</E>
                     587 + 5,520 = 6,107.
                </P>
                <P>
                    9. 
                    <E T="03">The estimated number of hours needed annually to comply with the information collection requirement or request:</E>
                     59 + 386 hours = 445 hours.
                </P>
                <P>
                    10. 
                    <E T="03">Abstract:</E>
                     When a licensee is unable to use the License Verification System to perform their license verification prior to transferring radioactive materials in quantities of concern, a manual process is available, in which licensees submit the NRC Form 749, “Manual License Verification Report.” The form provides the information necessary for the license issuing agencies to perform the verification on behalf of the licensee transferring the radioactive materials.
                </P>
                <HD SOURCE="HD1">III. Specific Requests for Comments</HD>
                <P>
                    The NRC is seeking comments that address the following questions:
                    <PRTPAGE P="25480"/>
                </P>
                <P>1. Is the proposed collection of information necessary for the NRC to properly perform its functions? Does the information have practical utility?</P>
                <P>2. Is the estimate of the burden of the information collection accurate?</P>
                <P>3. Is there a way to enhance the quality, utility, and clarity of the information to be collected?</P>
                <P>4. How can the burden of the information collection on respondents be minimized, including the use of automated collection techniques or other forms of information technology?</P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>David C. Cullison,</NAME>
                    <TITLE>NRC Clearance Officer, Office of the Chief Information Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09325 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">NUCLEAR REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[NRC-2019-0222]</DEPDOC>
                <SUBJECT>Information Collection: NRC Form 241, Report of Proposed Activities in Non-Agreement States, Areas of Exclusive Federal Jurisdiction, or Offshore Waters</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Nuclear Regulatory Commission.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Renewal of existing information collection; request for comment.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The U.S. Nuclear Regulatory Commission (NRC) invites public comment on the renewal of Office of Management and Budget (OMB) approval for an existing collection of information. The information collection is entitled, “Draft OMB Supporting Statement for NRC Form 241 Report of Proposed Activities in Non-Agreement States, Areas of Exclusive Federal Jurisdiction, or Offshore Waters.”</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Submit comments by June 30, 2020. 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>You may submit comments 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-2019-0222. 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">Mail comments to:</E>
                         David Cullison, Office of the Chief Information Officer, Mail Stop: T-6 A10M, U.S. Nuclear Regulatory Commission, Washington, DC 20555-0001.
                    </P>
                    <P>
                        For additional direction 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>
                        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>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">I. Obtaining Information and Submitting Comments</HD>
                <HD SOURCE="HD2">A. Obtaining Information</HD>
                <P>Please refer to Docket ID NRC-2019-0222 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-2019-0222. A copy of the collection of information and related instructions may be obtained without charge by accessing Docket ID NRC-2019-0222 on this website.
                </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, 301-415-4737, or by email to 
                    <E T="03">pdr.resource@nrc.gov.</E>
                     The supporting statement “Draft OMB Supporting Statement for NRC Form 241 Report of Proposed Activities in Non-Agreement States, Areas of Exclusive Federal Jurisdiction, or Offshore Waters” is available in ADAMS under Accession No. ML20015A486.
                </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 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>Please include Docket ID NRC-2019-0222 in the subject line of your comment submission, in order to ensure that the NRC is able to make your comment submission available to the public in this docket.</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. 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, and 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. Background</HD>
                <P>In accordance with the Paperwork Reduction Act of 1995 (44 U.S.C. Chapter 35), the NRC is requesting public comment on its intention to request the OMB's approval for the information collection summarized below.</P>
                <P>
                    1. 
                    <E T="03">The title of the information collection:</E>
                     “Draft OMB Supporting Statement for NRC Form 241 Report of Proposed Activities in Non-Agreement States, Areas of Exclusive Federal Jurisdiction, or Offshore Waters.”
                </P>
                <P>
                    2. 
                    <E T="03">OMB approval number:</E>
                     3150-0013.
                </P>
                <P>
                    3. 
                    <E T="03">Type of submission:</E>
                     Revision.
                </P>
                <P>
                    4. 
                    <E T="03">The form number, if applicable:</E>
                     Form 241.
                </P>
                <P>
                    5. 
                    <E T="03">How often the collection is required or requested:</E>
                     NRC Form 241 must be submitted each time an Agreement State licensee wants to engage in or revise its activities involving the use of radioactive byproduct material in a non-Agreement State, areas of exclusive Federal jurisdiction, or offshore waters. The NRC may waive the requirements for filing additional copies of NRC Form 241 during the remainder of the calendar year following receipt of the initial form.
                </P>
                <P>
                    6. 
                    <E T="03">Who will be required or asked to respond:</E>
                     Any licensee who holds a specific license from an Agreement State and want to conduct the same activity in non-Agreement States areas of exclusive Federal Jurisdiction, or offshore waters under the general license in section 150.20 of Title 10 of the 
                    <E T="03">Code of Federal Regulations</E>
                     (10 CFR).
                    <PRTPAGE P="25481"/>
                </P>
                <P>
                    7. 
                    <E T="03">The estimated number of annual responses: 1,645 responses.</E>
                </P>
                <P>
                    8. 
                    <E T="03">The estimated number of annual respondents: 233 respondents.</E>
                </P>
                <P>
                    9. 
                    <E T="03">The estimated number of hours needed annually to comply with the information collection requirement or request:</E>
                     467 hours (111.5 hours for initial submissions + 355.5 for changes + 0 hours for clarifications).
                </P>
                <P>
                    10. 
                    <E T="03">Abstract:</E>
                     Any Agreement State licensee who engages in the use of radioactive material in Non-Agreement States, areas of exclusive Federal jurisdiction, or offshore waters, under the general license in 10 CFR 150.20, is required to file, with the NRC Regional Administrator for the Region which the Agreement State that issues the license is located, a copy of NRC Form 241, Report of Proposed Activities in Non-Agreement State specific license, and the appropriate fee as prescribed in 10 CFR 170.31 at least 3 days before engaging in such activity. This mandatory notification permits the NRC to schedule inspections of the activities to determine whether the activities are being conducted in accordance with requirements for protection of the public health and safety.
                </P>
                <HD SOURCE="HD1">III. Specific Requests for Comments</HD>
                <P>The NRC is seeking comments that address the following questions:</P>
                <P>1. Is the proposed collection of information necessary for the NRC to properly perform its functions? Does the information have practical utility?</P>
                <P>2. Is the estimate of the burden of the information collection accurate?</P>
                <P>3. Is there a way to enhance the quality, utility, and clarity of the information to be collected?</P>
                <P>4. How can the burden of the information collection on respondents be minimized, including the use of automated collection techniques or other forms of information technology?</P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <P>For the Nuclear Regulatory Commission.</P>
                    <NAME>David C. Cullison,</NAME>
                    <TITLE>NRC Clearance Officer, Office of the Chief Information Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09324 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 7590-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">POSTAL REGULATORY COMMISSION</AGENCY>
                <DEPDOC>[Docket No. CP2019-176]</DEPDOC>
                <SUBJECT>New Postal Product</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>
                         May 5, 2020.
                    </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>
                <P/>
                <HD SOURCE="HD1">Table of Contents</HD>
                <EXTRACT>
                    <FP SOURCE="FP-2">I. Introduction</FP>
                    <FP SOURCE="FP-2">II. Docketed Proceeding(s)</FP>
                </EXTRACT>
                <HD SOURCE="HD1">I. Introduction</HD>
                <P>The Commission gives notice that the Postal Service filed request(s) for the Commission to consider matters related to negotiated service agreement(s). The request(s) may propose the addition or removal of a negotiated service agreement from the market dominant or the competitive product list, or the modification of an existing product currently appearing on the market dominant or the competitive product list.</P>
                <P>Section II identifies the docket number(s) associated with each Postal Service request, the title of each Postal Service request, the request's acceptance date, and the authority cited by the Postal Service for each request. For each request, the Commission appoints an officer of the Commission to represent the interests of the general public in the proceeding, pursuant to 39 U.S.C. 505 (Public Representative). Section II also establishes comment deadline(s) pertaining to each request.</P>
                <P>
                    The public portions of the Postal Service's request(s) can be accessed via the Commission's website (
                    <E T="03">http://www.prc.gov</E>
                    ). Non-public portions of the Postal Service's request(s), if any, can be accessed through compliance with the requirements of 39 CFR 3011.301.
                    <SU>1</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         Docket No. RM2018-3, Order Adopting Final Rules Relating to Non-Public Information, June 27, 2018, Attachment A at 19-22 (Order No. 4679).
                    </P>
                </FTNT>
                <P>The Commission invites comments on whether the Postal Service's request(s) in the captioned docket(s) are consistent with the policies of title 39. For request(s) that the Postal Service states concern market dominant product(s), applicable statutory and regulatory requirements include 39 U.S.C. 3622, 39 U.S.C. 3642, 39 CFR part 3030, and 39 CFR part 3040, subpart B. For request(s) that the Postal Service states concern competitive product(s), applicable statutory and regulatory requirements include 39 U.S.C. 3632, 39 U.S.C. 3633, 39 U.S.C. 3642, 39 CFR part 3035, and 39 CFR part 3040, subpart B. Comment deadline(s) for each request appear in section II.</P>
                <HD SOURCE="HD1">II. Docketed Proceeding(s)</HD>
                <P>
                    1. 
                    <E T="03">Docket No(s).:</E>
                     CP2019-176; 
                    <E T="03">Filing Title:</E>
                     Notice of the United States Postal Service of Filing Modification One to a Global Expedited Package Services 11 Negotiated Service Agreement; 
                    <E T="03">Filing Acceptance Date:</E>
                     April 27, 2020; 
                    <E T="03">Filing Authority:</E>
                     39 CFR 3035.105; 
                    <E T="03">Public Representative:</E>
                     Christopher C. Mohr; 
                    <E T="03">Comments Due:</E>
                     May 5, 2020.
                </P>
                <P>
                    This Notice will be published in the 
                    <E T="04">Federal Register</E>
                    .
                </P>
                <SIG>
                    <NAME>Erica A. Barker, </NAME>
                    <TITLE>Secretary.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09339 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 7710-FW-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">POSTAL SERVICE</AGENCY>
                <SUBJECT>Board of Governors; Sunshine Act Meeting</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">DATES AND TIMES:</HD>
                    <P>Thursday, May 7, 2020, at 11:00 a.m.; and Friday, May 8, 2020, at 9:00 a.m.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PLACE:</HD>
                    <P>Washington, DC, at U.S. Postal Service Headquarters, 475 L'Enfant Plaza SW, in the Benjamin Franklin Room.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">STATUS:</HD>
                    <P>Thursday, May 7, 2020, at 11:00 a.m.—Closed. Friday, May 8, 2020, at 9:00 a.m.—Open.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">MATTERS TO BE CONSIDERED:</HD>
                    <P/>
                </PREAMHD>
                <HD SOURCE="HD1">Thursday, May 7, 2020, at 11:00 a.m. (Closed)</HD>
                <P>1. Strategic Issues.</P>
                <P>2. Financial and Operational Matters.</P>
                <P>3. Administrative Items.</P>
                <HD SOURCE="HD1">Friday, May 8, 2020, at 9:00 a.m. (Open)</HD>
                <P>1. Remarks of the Chairman of the Board of Governors.</P>
                <P>2. Remarks of the Postmaster General and CEO.</P>
                <P>3. Approval of Minutes of Previous Meetings.</P>
                <P>4. Committee Reports.</P>
                <P>5. Quarterly Financial Report.</P>
                <P>6. Quarterly Service Performance Report.</P>
                <P>7. Approval of Tentative Agenda for August Meetings.</P>
                <PREAMHD>
                    <PRTPAGE P="25482"/>
                    <HD SOURCE="HED">CONTACT PERSON FOR MORE INFORMATION:</HD>
                    <P>Michael J. Elston, Secretary of the Board, U.S. Postal Service, 475 L'Enfant Plaza, SW, Washington, DC 20260-1000. Telephone: (202) 268-4800.</P>
                </PREAMHD>
                <SIG>
                    <NAME>Michael J. Elston,</NAME>
                    <TITLE>Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09402 Filed 4-29-20; 11:15 am]</FRDOC>
            <BILCOD>BILLING CODE 7710-12-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-88757; File No. SR-NYSEAMER-2020-33]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; NYSE American LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend Rule 928NY Relating to the Risk Limitation Mechanism</SUBJECT>
                <DATE>April 27, 2020.</DATE>
                <P>
                    Pursuant to Section 19(b)(1) 
                    <SU>1</SU>
                    <FTREF/>
                     of the Securities Exchange Act of 1934 (the “Act”) 
                    <SU>2</SU>
                    <FTREF/>
                     and Rule 19b-4 thereunder,
                    <SU>3</SU>
                    <FTREF/>
                     notice is hereby given that on April 17, 2020, NYSE American LLC (“NYSE American” or the “Exchange”) filed with the Securities and Exchange Commission (the “Commission”) the proposed rule change as described in Items I and II below, which Items have been prepared by the self-regulatory organization. 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>
                         15 U.S.C. 78a.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>
                    The Exchange proposes to amend Rule 928NY (Risk Limitation Mechanism) to reflect modifications to the operation of the trade and trigger counters as well as the applicable time periods for determining if a risk setting is triggered in the event of a trading halt or for transactions at the open in regards to the Risk Limitation Mechanism. The Exchange also proposes to relocate certain text from Rule 928NY to Rule 970NY (Firm Quotes). The proposed rule change is available on the Exchange's website at 
                    <E T="03">www.nyse.com,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the self-regulatory organization included statements concerning the purpose of, and basis for, the proposed rule change and discussed any comments it received on the proposed rule change. The text of those statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant parts of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and the Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>The Exchange proposes to amend Rule 928NY (Risk Limitation Mechanism) (the “Rule”) to reflect modifications to the operation of the trade and trigger counters as well as the applicable time periods for determining if a risk setting is triggered in the event of a trading halt or for transactions at the open in regards to the Risk Limitation Mechanism. The Exchange also proposes to relocate certain text from Rule 928NY to Rule 970NY (Firm Quotes).</P>
                <HD SOURCE="HD3">Risk Limitation Mechanism</HD>
                <P>
                    Rule 928NY sets forth the risk-limitation mechanism (the “Mechanism”), which is designed to help Market Makers and ATP Holders (collectively “ATP Holders” for the purpose of this filing) better manage risk related to quoting and submitting orders during periods of increased and significant trading activity.
                    <SU>4</SU>
                    <FTREF/>
                     Specifically, the Mechanism calculates for quotes and orders, respectively: The number of trades executed by the Market Maker or ATP Holder in a particular options class; the volume of contracts traded by the Market Maker or ATP Holder in a particular options class; or the aggregate percentage of the Market Maker's quoted size or ATP Holder's order size(s) executed in a particular options class.
                    <SU>5</SU>
                    <FTREF/>
                     To determine whether the Mechanism is triggered (
                    <E T="03">i.e.,</E>
                     the risk setting breached), the Exchange maintains separate trade counters that are incremented every time a trade is executed; that aggregate the number of contracts traded during each such execution; and that calculate applicable percentages depending on the risk setting at issue.
                    <SU>6</SU>
                    <FTREF/>
                     A breach of the Mechanism occurs if the number of increments to the trade counter, within a time period specified by the Exchange, exceeds the threshold set by the ATP Holder. Under the current Rule, the applicable time period will not be less than 100 milliseconds.
                    <SU>7</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         Market Makers are included in the definition of ATP Holders and therefore, unless the Exchange is discussing the quoting activity of Market Makers, the Exchange does not distinguish Market Makers from ATP Holders when discussing the risk limitation mechanisms. 
                        <E T="03">See</E>
                         Rule 900.2NY(5) (defining ATP Holder as “a natural person, sole proprietorship, partnership, corporation, limited liability company or other organization, in good standing, that has been issued an ATP,” and requires that “[a]n ATP Holder must be a registered broker or dealer pursuant to Section 15 of the Securities Exchange Act of 1934”). 
                        <E T="03">See also</E>
                         Rule 900.2NY(38) (providing that a Market Maker is “an ATP Holder that acts as a Market Maker pursuant to Rule 920NY”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Rule 928NY(b)-(d) (setting forth the three risk limitation mechanisms available).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See</E>
                         Rule 928NY(a).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         Commentary .03 to Rule 928NY.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Proposed Clarification to Time Period for Triggering of Risk Limitation Mechanism</HD>
                <P>Currently, the timer elapses at the conclusion of the time period specified by the Exchange, unless a breach occurs sooner than the timer expiration. The Exchange proposes to modify this functionality such that the time period is rolling (as opposed to static) and is activated each time a trade counter is incremented such that the Exchange “looks back” at other trades that occurred within the time period specified by the Exchange to see if a breach has occurred (See examples at the end of this section). The Exchange believes this modification will enhance the operation of the timer—and hence the risk protection. The Exchange proposes to modify the Rule to ensure that it is consistent with this proposed functionality change.</P>
                <P>
                    First, the Exchange proposes to modify the Rule regarding the applicable time period during which the increments of the trade counters are tallied, including, to account for the occurrence of trading halts or transactions occurring at the open of trading in a series. Specifically, the Exchange proposes to modify Commentary .03 to Rule 928NY to provide that the minimum time period determined by the Exchange would be “inclusive of the duration of any trading halt occurring within that time”; however, “[f]or transactions occurring at the open per Rule 952NY, the applicable time period is the lesser of (i) the time between the opening of a series and the initial transaction or (ii) the time period 
                    <PRTPAGE P="25483"/>
                    specified by the Exchange.” 
                    <SU>8</SU>
                    <FTREF/>
                     The Exchange believes this proposed change adds clarity and transparency to Exchange rules making them easier to comprehend and navigate.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .03 to Rule 928NY. 
                        <E T="03">See also</E>
                         Rule 953NY (Trading Halts and Suspensions) and Rule 952NY (Opening Process)
                    </P>
                </FTNT>
                <P>
                    The Exchange also proposes to modify Commentary .06 to the Rule, which relates to the operation of trade and trigger counters once the Mechanism is activated. Current Commentary .06 to Rule provides that “[t]he trade counters will automatically reset and commence a new count for the ATP Holder (1) when a time period specified by the Exchange elapses or, (2) if one of the Risk Limitation Mechanisms is triggered”, upon the ATP Holder submitting a message to the Exchange to be re-enabled.
                    <SU>9</SU>
                    <FTREF/>
                     The Exchange proposes to clarify that the trade counters do not reset, per se, when the time period specified by Exchange elapses as the trade counters only commence a new count after a breach of the risk settings upon the ATP Holder's re-entry to the market. As proposed, modified Commentary .06 to the Rule would provide in relevant part that “[f]ollowing a breach of any of the Risk Limitation Mechanisms set forth in paragraphs (b), (c) or (d), the trade counters will commence a new count for the ATP Holder” upon the ATP Holder submitting a message to the Exchange to be re-enabled.
                    <SU>10</SU>
                    <FTREF/>
                     Consistent with this change, the Exchange also proposes to modify the rule text regarding the operation of the timer as it relates to the trigger counter.
                    <SU>11</SU>
                    <FTREF/>
                     As proposed, the Exchange would remove language regarding instances resulting in the automatic reset of the trigger counter and instead state simply that “[f]ollowing any breach pursuant to Rule 928NY(f), the trigger counter will commence a new count” when the ATP Holder submits a request to be re-enabled.
                    <SU>12</SU>
                    <FTREF/>
                     The Exchange believes this proposed clarification adds specificity and transparency to Exchange rules.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See</E>
                         Commentary .06 to Rule 928NY.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .06 to Rule 928NY.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         
                        <E T="03">See</E>
                         Commentary .06 to Rule 928NY (providing that “[a]bsent a breach pursuant to Rule 928NY(f), the trigger counter will automatically reset and commence a new count for the ATP Holder (1) when a time period specified by the Exchange elapses; or (2) following any intraday update to configurable thresholds, as provided in Commentary .03 to this Rule 928NY” and that “[f]ollowing any breach pursuant to Rule 928NY(f), the trigger counter will be reset and commence a new count” when the ATP Holder makes non-automated contact requesting to be re-enabled).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .06 to Rule 928NY.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Examples Illustrating Current and Proposed Functionality</HD>
                <P>
                    <E T="03">Assumptions:</E>
                     The ATP Holder utilizes the transaction-based risk setting for orders with a maximum of three transactions before the setting is breached and the time period announced by the Exchange is 100ms.
                </P>
                <P>
                    <E T="03">Current Mechanism:</E>
                     Timer is asynchronous and covers fixed, non-overlapping periods.
                </P>
                <P>Timer starts at 10:10:00.101 (end of fixed period is 10:10:00.201).</P>
                <FP SOURCE="FP-1">
                    <E T="03">Event 1:</E>
                     At 10:10:00.150, the ATP Holder trades 10 contracts.
                </FP>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there was one transaction (Event 1) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.101—10:10:00.201) = no breach.
                </FP>
                <FP SOURCE="FP-1">
                    <E T="03">Event 2:</E>
                     At 10:10:00.190, the ATP Holder trades 15 contracts.
                </FP>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there were two transactions (Events 1 and 2) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.101-10:10:00.201) = no breach.
                </FP>
                <FP>Timer expires at 10:10:00.201.</FP>
                <FP>Timer re-starts at 10:10:00.202 (end of fixed period is 10:10:00.302).</FP>
                <FP SOURCE="FP-1">
                    <E T="03">Event 3:</E>
                     At 10:10:00.210, the ATP Holder trades 20 contracts.
                </FP>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there was one transaction (Event 3 since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.202—10:10:00.302) = no breach.
                </FP>
                <P>
                    <E T="03">Event 4:</E>
                     At 10:10:00.220, the ATP Holder trades 10 contracts.
                </P>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there were two transactions (Events 3 and 4) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.202—10:10:00.302) = no breach.
                </FP>
                <FP SOURCE="FP-1">
                    <E T="03">Event 5:</E>
                     At 10:10:00.240, the ATP Holder trades 15 contracts.
                </FP>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there were three transactions (Events 3, 4 and 5) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.202—10:10:00.302) = BREACH.
                </FP>
                <P>
                    <E T="03">Proposed Mechanism:</E>
                     Timer “looks back” prior 100ms each time a transaction occurs.
                </P>
                <FP SOURCE="FP-1">
                    <E T="03">Event 1:</E>
                     At 10:10:00.150, the ATP Holder trades 10 contracts.
                </FP>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there was one transaction (Event 1) that occurred in the prior 100ms (
                    <E T="03">i.e.,</E>
                     10:10:00.150-10:10:00.050) = no breach.
                </FP>
                <FP SOURCE="FP-1">
                    <E T="03">Event 2:</E>
                     At 10:10:00.190, the ATP Holder trades 15 contracts.
                </FP>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there were two transactions (Events 1 and 2) that occurred in the prior 100ms (
                    <E T="03">i.e.,</E>
                     10:10:00.190—10:10:00.090) = no breach.
                </FP>
                <FP SOURCE="FP-1">Event 3: At 10:10:00.210, the ATP Holder trades 20 contracts.</FP>
                <FP SOURCE="FP1-2">
                    —The Exchange determines there were three transactions (Events 1, 2 and 3) that occurred in the prior 100ms (
                    <E T="03">i.e.,</E>
                     10:10:00.210—10:10:00.110) = BREACH.
                </FP>
                <HD SOURCE="HD3">Technical Changes</HD>
                <P>
                    Finally, the Exchange also proposes to delete the text located in Commentary .05 to Rule and to hold this Commentary as “Reserved.” 
                    <SU>13</SU>
                    <FTREF/>
                     Current Commentary .05 to the Rule relates to the Exchange's dissemination of a best bid and offer when no Market Makers are quoting in a class, which information is irrelevant to the operation of the Mechanism.
                    <SU>14</SU>
                    <FTREF/>
                     At the time Rule 928NY was implemented, the Exchange noted that it would “no longer generate two-sided quotes on behalf of a Specialist in the event that there are no Market Makers quoting in an issue” but would instead disseminate as the BBO “the best bids and offers of those orders residing in the Consolidated Book in the issue”—if such orders existed—or would “disseminate a bid of zero and an offer of zero in that issue.” 
                    <SU>15</SU>
                    <FTREF/>
                     In retrospect, the Exchange believes that Rule 928NY—which is focused on managing risk not quote dissemination—was not the optimal placement for this information. Instead, the Exchange believes such information would be more appropriately included with information regarding quote dissemination requirements. The Exchange therefore proposes to relocate this text to Rule 970NY (Firm Quotes) as market participants would be more likely to consult this rule (as opposed to Rule 928NY) in regards to quoting information. The Exchange believes the proposed relocation of this text would add clarity and consistency to Exchange rules, making them easier to navigate.
                    <SU>16</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .05 to Rule 928NY.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         
                        <E T="03">See</E>
                         Commentary .05 to Rule 928NY (providing that “[i]n the event that there are no Market Makers quoting in a class, the best bids and offers of those orders residing in the Consolidated Book in the class will be disseminated as the BBO. If there are no Market Makers quoting in the class and there are no orders in the Consolidated Book in the class, the System shall disseminate a bid of zero and an offer of zero”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         
                        <E T="03">See</E>
                         Securities Exchange Act Release No. 59142 (December 22, 2008), 73 FR 80494, 80498 (December 31, 2008) (SR-NYSEALTR-2008-14) (adopting, among other Section 900NY rules, Rule 928NY).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         
                        <E T="03">See</E>
                         proposed Rule 970NY(b)(1)(A). The Exchange notes that it proposes the change “System” to “Exchange” regarding the source that disseminates the BBO for consistency with the rest of Rule 970NY.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that its proposal is consistent with Section 6(b) 
                    <PRTPAGE P="25484"/>
                    of the Act,
                    <SU>17</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Section 6(b)(5) of the Act,
                    <SU>18</SU>
                    <FTREF/>
                     in particular, in that it is designed to prevent fraudulent and manipulative acts and practices, to promote just and equitable principles of trade, to foster cooperation and coordination with persons engaged in regulating, clearing, settling, processing information with respect to, and facilitating transactions in securities, to remove impediments to and perfect the mechanism of a free and open market and a national market system and, in general, to protect investors and the public interest.
                </P>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         15 U.S.C. 78f(b)(5).
                    </P>
                </FTNT>
                <P>ATP Holders are vulnerable to the risk from a system or other error or a market event that may cause them to send a large number of orders or receive multiple, automatic executions before they can adjust their exposure in the market. Without adequate risk management tools, such as the available risk settings, ATP Holders may opt to reduce the amount of order flow and liquidity that they provide to the market, which could undermine the quality of the markets available to market participants. The Exchange believes that the proposed change would remove impediments to and perfect the mechanism of a free and open market by adding clarity, transparency and specificity regarding the operation of the Mechanism thereby making Exchange rules easier to comprehend and navigate to the benefit of all market participants.</P>
                <P>
                    The Exchange believes the proposal to modify the time period to a rolling basis (as opposed to static time segments) would remove impediments to and perfect the mechanism of a free and open market and a national market system because it would provide ATP Holders with greater ability to monitor their risk. The proposed change, which allows for a count after each transaction on a rolling “look back” basis, would provide a more finely tuned tracking method for ATP Holders related to each transaction within a specified time period. As such, ATP Holders that use the Mechanism to reduce their risk, particularly in the event of a system issue or due to the occurrence of unusual or unexpected market activity, would have greater certainty of how the Mechanism would function with respect to each transaction. Moreover, the proposed rule change would provide ATP Holders with transparency regarding the manner in which the Exchange counts quotes and orders, which would provide ATP Holders with an increased ability to monitor transactions. Finally, the Exchange believes the proposed change is consistent with risk timers utilized by other options markets that offer similar risk limitation mechanisms.
                    <SU>19</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         
                        <E T="03">See, e.g.,</E>
                         MIAX Rule 519A, Risk Protection Monitor (providing that, for orders, MIAX utilizes a counter that will “look back over the specified time period” to determine if a market participant has triggered its risk settings) and Rule 612, Aggregate Risk Manager (ARM) (providing that, for quotes, MIAX utilizes a counter that will “look back over the specified time period” to determine if a market maker has triggered its risk settings).
                    </P>
                </FTNT>
                <P>The Exchange believes that the non-substantive change to Rule 928NY, Commentary.05 (to delete and relocate text) related to quote dissemination requirements from the Rule, which relates to managing risk, to the Firm Quote rule would make Exchange rules easier to navigate, thus adding clarity and transparency to Exchange rules to the benefit of the investing public.</P>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>
                    The Exchange does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. Rather, the Exchange believes that the proposed rule change would enhance the Mechanism by providing ATP Holders with greater ability to monitor their risk by providing a more finely tuned tracking method for ATP Holders related to each transaction within a specified time period. In addition, the Exchange does not believe the proposal creates any significant impact on competition as the proposed “look back” time period is consistent with risk timers utilized by other options markets that offer similar risk limitation mechanisms.
                    <SU>20</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         
                        <E T="03">See id.</E>
                         (regarding MIAX risk mechanisms for orders and quotes, both of which utilize a counter that “looks back over the specified time period” to determine if risk settings have been triggered).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were solicited or received with respect to the proposed rule change.</P>
                <HD SOURCE="HD1">III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action</HD>
                <P>
                    Because the foregoing proposed rule change does not: (i) Significantly affect the protection of investors or the public interest; (ii) impose any significant burden on competition; and (iii) become operative for 30 days from the date on which it was filed, or such shorter time as the Commission may designate, it has become effective pursuant to Section 19(b)(3)(A) of the Act 
                    <SU>21</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(6) thereunder.
                    <SU>22</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         15 U.S.C. 78s(b)(3)(A).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         17 CFR 240.19b-4(f)(6). In addition, Rule 19b-4(f)(6)(iii) requires a self-regulatory organization to give the Commission written notice of its intent to file the proposed rule change, along with a brief description and text of the proposed rule change, at least five business days prior to the date of filing of the proposed rule change, or such shorter time as designated by the Commission. The Exchange has satisfied this requirement.
                    </P>
                </FTNT>
                <P>
                    A proposed rule change filed pursuant to Rule 19b-4(f)(6) under the Act 
                    <SU>23</SU>
                    <FTREF/>
                     normally does not become operative for 30 days after the date of its filing. However, Rule 19b-4(f)(6)(iii) 
                    <SU>24</SU>
                    <FTREF/>
                     permits the Commission to designate a shorter time if such action is consistent with the protection of investors and the public interest. The Exchange has requested that the Commission waive the 30-day operative delay so that the proposed rule change may become operative upon filing. Waiver of the operative delay would allow the Exchange to immediately amend its rules to provide ATP Holders with a more finely tuned tracking method for each transaction within a specified time period, which could provide greater certainty of how the Mechanism would function with respect to each transaction. The Commission believes that waiver of the 30-day operative delay is consistent with the protection of investors and the public interest. Accordingly, the Commission hereby waives the operative delay and designates the proposed rule change operative upon filing.
                    <SU>25</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         17 CFR 240.19b-4(f)(6).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         17 CFR 240.19b-4(f)(6)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>25</SU>
                         For purposes only of waiving the 30-day operative delay, the Commission also has considered the proposed rule's impact on efficiency, competition, and capital formation. 
                        <E T="03">See</E>
                         15 U.S.C. 78c(f).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule change should be approved or disapproved.</P>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>
                    Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. 
                    <PRTPAGE P="25485"/>
                    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">http://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-NYSEAMER-2020-33 on the subject line.
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to: Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.</P>
                <FP>
                    All submissions should refer to File Number SR-NYSEAMER-2020-33. 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">http://www.sec.gov/rules/sro.shtml</E>
                    ). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission's Public Reference Room, 100 F Street NE, Washington, DC 20549 on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. All comments received will be posted without change. Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR-NYSEAMER-2020-33 and should be submitted on or before May 22, 2020.
                </FP>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>26</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             17 CFR 200.30-3(a)(12).
                        </P>
                    </FTNT>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09253 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-505, OMB Control No. 3235-0562]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <FP SOURCE="FP-1">
                    <E T="03">Upon Written Request, Copies Available From:</E>
                     Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736.
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                         Rule 17d-1.
                    </FP>
                </EXTRACT>
                <P>
                    Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), the Securities and Exchange Commission (“Commission”) is soliciting comments on the collections of information summarized below. The Commission plans to submit these existing collections of information to the Office of Management and Budget for extension and approval.
                </P>
                <P>
                    Section 17(d) (15 U.S.C. 80a-17(d)) of the Investment Company Act of 1940 (15 U.S.C. 80a 
                    <E T="03">et seq.</E>
                    ) (the “Act”) prohibits first- and second-tier affiliates of a fund, the fund's principal underwriters, and affiliated persons of the fund's principal underwriters, acting as principal, to effect any transaction in which the fund or a company controlled by the fund is a joint or a joint and several participant in contravention of the Commission's rules. Rule 17d-1 (17 CFR 270.17d-1) prohibits an affiliated person of or principal underwriter for any fund (a “first-tier affiliate”), or any affiliated person of such person or underwriter (a “second-tier affiliate”), acting as principal, from participating in or effecting any transaction in connection with a joint enterprise or other joint arrangement in which the fund is a participant, unless prior to entering into the enterprise or arrangement “an application regarding [the transaction] has been filed with the Commission and has been granted by an order.” In reviewing the proposed affiliated transaction, the rule provides that the Commission will consider whether the proposal is (i) consistent with the provisions, policies, and purposes of the Act, and (ii) on a basis different from or less advantageous than that of other participants in determining whether to grant an exemptive application for a proposed joint enterprise, joint arrangement, or profit-sharing plan.
                </P>
                <P>
                    Rule 17d-1 also contains a number of exceptions to the requirement that a fund must obtain Commission approval prior to entering into joint transactions or arrangements with affiliates. For example, funds do not have to obtain Commission approval for certain employee compensation plans, certain tax-deferred employee benefit plans, certain transactions involving small business investment companies, the receipt of securities or cash by certain affiliates pursuant to a plan of reorganization, certain arrangements regarding liability insurance policies and transactions with “portfolio affiliates” (companies that are affiliated with the fund solely as a result of the fund (or an affiliated fund) controlling them or owning more than five percent of their voting securities) so long as certain other affiliated persons of the fund (
                    <E T="03">e.g.,</E>
                     the fund's adviser, persons controlling the fund, and persons under common control with the fund) are not parties to the transaction and do not have a “financial interest” in a party to the transaction. The rule excludes from the definition of “financial interest” any interest that the fund's board of directors (including a majority of the directors who are not interested persons of the fund) finds to be not material, as long as the board records the basis for its finding in their meeting minutes.
                </P>
                <P>Thus, the rule contains two filing and recordkeeping requirements that constitute collections of information. First, rule 17d-1 requires funds that wish to engage in a joint transaction or arrangement with affiliates to meet the procedural requirements for obtaining exemptive relief from the rule's prohibition on joint transactions or arrangements involving first- or second-tier affiliates. Second, rule 17d-1 permits a portfolio affiliate to enter into a joint transaction or arrangement with the fund if a prohibited participant has a financial interest that the fund's board determines is not material and records the basis for this finding in their meeting minutes. These requirements of rule 17d-1 are designed to prevent fund insiders from managing funds for their own benefit, rather than for the benefit of the funds' shareholders.</P>
                <P>
                    Based on an analysis of past filings, Commission staff estimates that 23 funds file applications under section 17(d) and rule 17d-1 per year. The staff understands that funds that file an application generally obtain assistance from outside counsel to prepare the application. The cost burden of using outside counsel is discussed below. The Commission staff estimates that each applicant will spend an average of 154 hours to comply with the Commission's applications process. The Commission staff therefore estimates the annual burden hours per year for all funds under rule 17d-1's application process to be 3,542 hours at a cost of 
                    <PRTPAGE P="25486"/>
                    $1,528,120.
                    <SU>1</SU>
                    <FTREF/>
                     The Commission, therefore, requests authorization to increase the inventory of total burden hours per year for all funds under rule 17d-1 from the current authorized burden of 2002 hours to 3,542 hours. The increase is due to an increase in the number of funds that filed applications for exemptions under rule 17d-1.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         The Commission staff estimates that a senior executive, such as the fund's chief compliance officer, will spend an average of 62 hours and a mid-level compliance attorney will spend an average of 92 hours to comply with this collection of information: 62 hours + 92 hours = 154 hours. 23 funds × 154 burden hours = 3,542 burden hours. The Commission staff estimate that the chief compliance officer is paid $530 per hour and the compliance attorney is paid $365 per hour. ($530 per hour × 62 hours) + ($365 per hour × 92 hours) = $66,440 per fund. $66,440 × 23 funds = $1,528,120. The $530 and $365 per hour figures are based on salary information compiled by SIFMA's Management &amp; Professional Earnings in the Securities Industry, 2019. The Commission staff has modified SIFMA's information to account for an 1800-hour work year and inflation, and multiplied by 5.35 to account for bonuses, firm size, employee benefits, and overhead.
                    </P>
                </FTNT>
                <P>
                    As noted above, the Commission staff understands that funds that file an application under rule 17d-1 generally use outside counsel to assist in preparing the application. The staff estimates that, on average, funds spend an additional $93,131 for outside legal services in connection with seeking Commission approval of affiliated joint transactions. Thus, the staff estimates that the total annual cost burden imposed by the exemptive application requirements of rule 17d-1 is $2,142,013.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         The estimate is based on the following calculation: $93,131 × 23 funds = $2,142,013.
                    </P>
                </FTNT>
                <P>We estimate that funds currently do not rely on the exemption from the term “financial interest” with respect to any interest that the fund's board of directors (including a majority of the directors who are not interested persons of the fund) finds to be not material. Accordingly, we estimate that annually there will be no transactions under rule 17d-1 that will result in this aspect of the collection of information.</P>
                <P>Based on these calculations, the total annual hour burden is estimated to be 3,542 hours and the total annual cost burden is estimated to be $2,142,013.</P>
                <P>The estimate of average burden hours is made solely for the purposes of the Paperwork Reduction Act. The estimate is not derived from a comprehensive or even a representative survey or study of the costs of Commission rules. Complying with these collections of information requirement is necessary to obtain the benefit of relying on rule 17d-1. Responses will not be kept confidential. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid control number.</P>
                <P>Written comments are invited on: (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 of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication.</P>
                <P>
                    Please direct your written comments to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, C/O Cynthia Roscoe, 100 F Street NE, Washington, DC 20549; or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09295 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-513, OMB Control No. 3235-0571]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <FP SOURCE="FP-1">
                    <E T="03">Upon Written Request, Copies Available From:</E>
                     Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                    </FP>
                    <FP SOURCE="FP1-2">Rule 206(4)-6</FP>
                </EXTRACT>
                <P>
                    Notice is hereby given that pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ) the Securities and Exchange Commission (the “Commission”) is soliciting comments on the collections of information summarized below. The Commission plans to submit these existing collections of information to the Office of Management and Budget (“OMB”) for extension and approval.
                </P>
                <P>
                    The title for the collection of information is “Rule 206(4)-6” under the Investment Advisers Act of 1940 (15 U.S.C. 80b-1 
                    <E T="03">et seq.</E>
                    ) (“Advisers Act”) and the collection has been approved under OMB Control No. 3235-0571. The Commission adopted rule 206(4)-6 (17 CFR 275.206(4)-6), the proxy voting rule, to address an investment adviser's fiduciary obligation to clients who have given the adviser authority to vote their securities. Under the rule, an investment adviser that exercises voting authority over client securities is required to: (i) Adopt and implement written policies and procedures that are reasonably designed to ensure that the adviser votes client securities in the best interest of clients, including procedures to address any material conflict that may arise between the interests of the adviser and the client; (ii) disclose to clients how they may obtain information from the adviser on how the adviser has voted with respect to their securities; and (iii) describe to clients the adviser's proxy voting policies and procedures and, on request, furnish a copy of the policies and procedures to the requesting client. The rule is designed to assure that advisers that vote proxies for their clients vote those proxies in their clients' best interest and provide clients with information about how their proxies were voted.
                </P>
                <P>Rule 206(4)-6 contains “collection of information” requirements within the meaning of the Paperwork Reduction Act. The respondents are investment advisers registered with the Commission that vote proxies with respect to clients' securities. Advisory clients of these investment advisers use the information required by the rule to assess investment advisers' proxy voting policies and procedures and to monitor the advisers' performance of their proxy voting activities. The information required by Adviser's Act rule 204-2, a recordkeeping rule, also is used by the Commission staff in its examination and oversight program. Without the information collected under the rules, advisory clients would not have information they need to assess the adviser's services and monitor the adviser's handling of their accounts, and the Commission would be less efficient and effective in its programs.</P>
                <P>
                    The estimated number of investment advisers subject to the collection of information requirements under the rule is 12,265. It is estimated that each of these advisers is required to spend on average 10 hours annually documenting its proxy voting procedures under the requirements of the rule, for a total burden of 122,650 hours. We further estimate that on average, approximately 279 clients of each adviser would request copies of the underlying policies and procedures. We estimate that it would take these advisers 0.1 hours per client to deliver copies of the policies and procedures, for a total burden of 
                    <PRTPAGE P="25487"/>
                    342,194 hours. Accordingly, we estimate that rule 206(4)-6 results in an annual aggregate burden of collection for SEC-registered investment advisers of a total of 464,844 hours.
                </P>
                <P>Written comments are invited on: (a) Whether the collections of information are necessary for the proper performance of the functions of the Commission, including whether the information has practical utility; (b) the accuracy of the Commission's estimate of the burdens of the collections of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burdens of the collections of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication. An agency may not conduct or sponsor a collection of information unless it displays a currently valid OMB control number. No person shall be subject to any penalty for failing to comply with a collection of information subject to the PRA that does not display a valid OMB control number.</P>
                <P>
                    Please direct your written comments to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, C/O Cynthia Roscoe, 100 F Street NE, Washington, DC 20549; or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09297 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-88754; File No. SR-NYSE-2020-34]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; New York Stock Exchange LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend Rule 1.1 To Modify the Definition of “UTP Exchange Traded Product” and Rule 5.1 To Incorporate the Modified Definition of “UTP Exchange Traded Product”</SUBJECT>
                <DATE>April 27, 2020.</DATE>
                <P>
                    Pursuant to Section 19(b)(1) 
                    <SU>1</SU>
                    <FTREF/>
                     of the Securities Exchange Act of 1934 (“Act”) 
                    <SU>2</SU>
                    <FTREF/>
                     and Rule 19b-4 thereunder,
                    <SU>3</SU>
                    <FTREF/>
                     notice is hereby given that on April 16, 2020, New York Stock Exchange LLC (“Exchange”) filed with the Securities and Exchange Commission (“Commission”) the proposed rule change as described in Items I and II below, which Items have been prepared by the self-regulatory organization. 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>
                         15 U.S.C. 78a.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>
                    The Exchange proposes to amend (1) Rule 1.1 to modify the definition of “UTP Exchange Traded Product” and (2) Rule 5.1 to incorporate the definition of UTP Exchange Traded Product as set forth in revised Rule 1.1. The proposed rule change is available on the Exchange's website at 
                    <E T="03">www.nyse.com,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the self-regulatory organization included statements concerning the purpose of, and basis for, the proposed rule change and discussed any comments it received on the proposed rule change. The text of those statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant parts of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and the Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>The Exchange proposes to amend (1) Rule 1.1 to modify the definition of “UTP Exchange Traded Product” and (2) Rule 5.1 to incorporate the definition of UTP Exchange Traded Product as set forth in revised Rule 1.1.</P>
                <HD SOURCE="HD3">Rule 1.1</HD>
                <P>Rule 1.1(l) currently provides that the term “Exchange Traded Product” means a security that meets the definition of “derivative securities product” in Rule 19b-4(e) under the Securities Exchange Act of 1934 and a “UTP Exchange Traded Product” means an Exchange Traded Product that trades on the Exchange pursuant to unlisted trading privileges. The Exchange proposes to amend the definition of “UTP Exchange Traded Product” to mean one of the following Exchange Traded Products that trades on the Exchange pursuant to unlisted trading privileges: Equity Linked Notes, Investment Company Units, Index-Linked Exchangeable Notes, Equity Gold Shares, Equity Index-Linked Securities, Commodity-Linked Securities, Currency-Linked Securities, Fixed-Income Index-Linked Securities, Futures-Linked Securities, Multifactor-Index-Linked Securities, Trust Certificates, Currency and Index Warrants, Portfolio Depository Receipts, Trust Issued Receipts, Commodity-Based Trust Shares, Currency Trust Shares, Commodity Index Trust Shares, Commodity Futures Trust Shares, Partnership Units, Paired Trust Shares, Trust Units, Managed Fund Shares, Managed Trust Securities, and Managed Portfolio Shares.</P>
                <P>
                    This proposed change is based on NYSE National, Inc. (“NYSE National”) Rule 1.1(m) and NYSE Chicago, Inc. (“NYSE Chicago”) Rule 1.1(k).
                    <SU>4</SU>
                    <FTREF/>
                     This list is designed to align the rules of the Exchange with the rules of NYSE National and NYSE Chicago and to enumerate the types of Exchange Traded Products to which the Exchange would extend unlisted trading privileges (“UTP”).
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         NYSE National and NYSE Chicago have filed proposed rule changes for immediate effectiveness to amend their respective rules to add Managed Portfolio Shares to their definitions of UTP Exchange Traded Products. 
                        <E T="03">See</E>
                         SR-NYSENAT-2020-16 (filed April 16, 2020) and SR-NYSECHX-2020-13 (filed April 16, 2020).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Rule 5.1</HD>
                <P>Rule 5.1(a)(1) provides that the Exchange may extend UTP to any security that is an NMS stock (as defined in Rule 600 of Regulation NMS under the Act) that is listed on another national securities exchange or with respect to which unlisted trading privileges may otherwise be extended in accordance with Section 12(f) of the Act. Rule 5.1(a)(2) further specifies that a UTP Exchange Traded Product, which is defined in that Rule as a “new derivative securities product” as defined in Rule 19b-4(e) under the Exchange Act and traded pursuant to Rule 19b-4(e) under the Act, would be subject to the additional rules enumerated in Rule 5.1(a)(2)(A)-(E).</P>
                <P>
                    Because the Exchange proposes to modify the definition of UTP Exchange Trading Product in Rule 1.1(l) to conform to the rules of NYSE National and NYSE Chicago, the Exchange proposes to amend Rule 5.1(a)(2) to eliminate redundant text and cross reference the term “UTP Exchange Traded Product” as it is defined in Rule 1.1. This proposed change would also 
                    <PRTPAGE P="25488"/>
                    conform Rule 5.1(a)(2) with the NYSE National rule of the same number.
                </P>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that the proposed rule change is consistent with Section 6(b) of the Act,
                    <SU>5</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Section 6(b)(5) of the Act,
                    <SU>6</SU>
                    <FTREF/>
                     in particular, because it is designed to remove impediments to and perfect the mechanism of a free and open market, to promote just and equitable principles of trade, and, in general, to protect investors and the public interest.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         15 U.S.C. 78f(b)(4) &amp; (5).
                    </P>
                </FTNT>
                <P>The Exchange believes its proposed rule change ensures that Rule 1.1 identifies and publicly states the complete list of Exchange Traded Products to which UTP may be extended for trading on the Exchange. The Exchange also believes that the proposed rule change removes impediments to and perfects the mechanism of a free and open market, promotes just and equitable principles of trade, and protects investors and the public interest by promoting consistency with the rules of the Exchange's affiliated markets and by providing additional specificity, clarity, and transparency in the Exchange's rules with respect to the Exchange Traded Products that may be traded on a UTP basis on the Exchange.</P>
                <P>
                    The Exchange believes that its proposal to amend Rule 5.1(a)(2) also removes impediments to and perfects the mechanism of a free and open market, promotes just and equitable principles of trade, and protects investors and the public interest because it proposes to conform this rule governing the trading of UTP Exchange Traded Products with the comparable rule of the Exchange's affiliated market, NYSE National, which has been approved by the Commission.
                    <SU>7</SU>
                    <FTREF/>
                     The proposed rule change would also remove impediments to and perfect the mechanism of a free and open market and a national market system and protect investors and the public interest by promoting continuity across affiliated exchanges.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         In its Order approving the NYSE National rule on which this proposed change is based, the Commission found that the NYSE National rules set forth an “appropriate framework for the trading of Exchange Traded Products on a UTP basis on the Exchange” and are consistent with Section 6(b)(5) of the Act. 
                        <E T="03">See</E>
                         Securities and Exchange Act Release No. 83289 (May 17, 2018), 83 FR 23968 (May 23, 2018), at 23975.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>The Exchange does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. The proposed change would conform Exchange rules, as described herein, with the comparable rules of its affiliated exchanges, NYSE National and NYSE Chicago, and permit UTP trading of Exchange Traded Products on the Exchange in a manner consistent with its affiliated exchange.</P>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were solicited or received with respect to the proposed rule change.</P>
                <HD SOURCE="HD1">III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action</HD>
                <P>
                    Because the foregoing proposed rule change does not: (i) Significantly affect the protection of investors or the public interest; (ii) impose any significant burden on competition; and (iii) become operative for 30 days from the date on which it was filed, or such shorter time as the Commission may designate, it has become effective pursuant to Section 19(b)(3)(A) of the Act 
                    <SU>8</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(6) thereunder.
                    <SU>9</SU>
                    <FTREF/>
                </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)(6). In addition, Rule 19b-4(f)(6)(iii) requires a self-regulatory organization to give the Commission written notice of its intent to file the proposed rule change, along with a brief description and text of the proposed rule change, at least five business days prior to the date of filing of the proposed rule change, or such shorter time as designated by the Commission. The Exchange has satisfied this requirement.
                    </P>
                </FTNT>
                <P>
                    A proposed rule change filed under Rule 19b-4(f)(6) 
                    <SU>10</SU>
                    <FTREF/>
                     normally does not become operative for 30 days after the date of the filing. However, pursuant to Rule 19b-4(f)(6)(iii),
                    <SU>11</SU>
                    <FTREF/>
                     the Commission may designate a shorter time if such action is consistent with the protection of investors and the public interest. The Exchange has asked the Commission to waive the 30-day operative delay so that the proposal may become operative immediately upon filing. The Commission notes that the Exchange's proposal would conform the Exchange's rules, as described herein, to the corresponding rules of its affiliated exchanges.
                    <SU>12</SU>
                    <FTREF/>
                     Accordingly, the Commission believes that the proposal raises no new or novel regulatory issues and waiver of the 30-day operative delay is consistent with the protection of investors and the public interest. The Commission therefore waives the 30-day operative delay and designates the proposed rule change to be operative upon filing.
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         17 CFR 240.19b-4(f)(6).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         17 CFR 240.19b-4(f)(6)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See</E>
                         NYSE National Rules 1.1 and 5.1 and NYSE Chicago Rule 1.1.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         For purposes only of waiving the 30-day operative delay, the Commission has also considered the proposed rule's impact on efficiency, competition, and capital formation. 
                        <E T="03">See</E>
                         15 U.S.C. 78c(f).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act.</P>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:</P>
                <HD SOURCE="HD2">Electronic Comments</HD>
                <P>
                    • Use the Commission's internet comment form (
                    <E T="03">http://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-NYSE-2020-34 on the subject line.
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.</P>
                <FP>
                    All submissions should refer to File Number SR-NYSE-2020-34. 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">http://www.sec.gov/rules/sro.shtml</E>
                    ). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission's Public Reference Room, 100 F Street NE, 
                    <PRTPAGE P="25489"/>
                    Washington, DC 20549 on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. All comments received will be posted without change. Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR-NYSE-2020-34 and should be submitted on or 
                    <FTREF/>
                    before May 22, 2020.
                </FP>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         17 CFR 200.30-3(a)(12).
                    </P>
                </FTNT>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>14</SU>
                    </P>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09250 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-259, OMB Control No. 3235-0269]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <EXTRACT>
                    <FP SOURCE="FP-1">
                        <E T="03">Upon Written Request, Copies Available From:</E>
                         Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736.
                    </FP>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                    </FP>
                    <FP SOURCE="FP1-2">Rule 17f-5. </FP>
                </EXTRACT>
                <P>Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 350l-3520), the Securities and Exchange Commission (“Commission”) is soliciting comments on the collection of information summarized below. The Commission plans to submit the existing collection of information to the Office of Management and Budget for extension and approval.</P>
                <P>Rule 17f-5 (17 CFR 270.17f-5) under the Investment Company Act of 1940 [15 U.S.C. 80a] (the “Act”) governs the custody of the assets of registered management investment companies (“funds”) with custodians outside the United States. Under rule 17f-5, a fund or its foreign custody manager (as delegated by the fund's board) may maintain the fund's foreign assets in the care of an eligible fund custodian under certain conditions. If the fund's board delegates to a foreign custody manager authority to place foreign assets, the fund's board must find that it is reasonable to rely on each delegate the board selects to act as the fund's foreign custody manager. The delegate must agree to provide written reports that notify the board when the fund's assets are placed with a foreign custodian and when any material change occurs in the fund's custody arrangements. The delegate must agree to exercise reasonable care, prudence, and diligence, or to adhere to a higher standard of care. When the foreign custody manager selects an eligible foreign custodian, it must determine that the fund's assets will be subject to reasonable care if maintained with that custodian, and that the written contract that governs each custody arrangement will provide reasonable care for fund assets. The contract must contain certain specified provisions or others that provide at least equivalent care. The foreign custody manager must establish a system to monitor the performance of the contract and the appropriateness of continuing to maintain assets with the eligible foreign custodian.</P>
                <P>
                    The collection of information requirements in rule 17f-5 are intended to provide protection for fund assets maintained with a foreign bank custodian whose use is not authorized by statutory provisions that govern fund custody arrangements,
                    <SU>1</SU>
                    <FTREF/>
                     and that is not subject to regulation and examination by U.S. regulators. The requirement that the fund board determine that it is reasonable to rely on each delegate is intended to ensure that the board carefully considers each delegate's qualifications to perform its responsibilities. The requirement that the delegate provide written reports to the board is intended to ensure that the delegate notifies the board of important developments concerning custody arrangements so that the board may exercise effective oversight. The requirement that the delegate agree to exercise reasonable care is intended to provide assurances to the fund that the delegate will properly perform its duties.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         
                        <E T="03">See</E>
                         section 17(f) of the Act. 15 U.S.C. 80a-17(f).
                    </P>
                </FTNT>
                <P>
                    The requirements that the foreign custody manager determine that fund assets will be subject to reasonable care with the eligible foreign custodian and under the custody contract, and that each contract contain specified provisions or equivalent provisions, are intended to ensure that the delegate has evaluated the level of care provided by the custodian, that it weighs the adequacy of contractual provisions, and that fund assets are protected by minimal contractual safeguards. The requirement that the foreign custody manager establish a monitoring system is intended to ensure that the manager periodically reviews each custody arrangement and takes appropriate action if developing custody risks may threaten fund assets.
                    <SU>2</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         The staff believes that subcustodian monitoring does not involve “collection of information” within the meaning of the Paperwork Reduction Act of 1995 (44 U.S.C. 3501-3520) (“Paperwork Reduction Act”).
                    </P>
                </FTNT>
                <P>
                    Commission staff estimates that each year, approximately 90 registrants 
                    <SU>3</SU>
                    <FTREF/>
                     could be required to make an average of one response per registrant under rule 17f-5, requiring approximately 2.5 hours of board of director time per response, to make the necessary findings concerning foreign custody managers. The total annual burden associated with these requirements of the rule is up to approximately 225 hours (90 registrants × 2.5 hours per registrant). The staff further estimates that during each year, approximately 15 global custodians 
                    <SU>4</SU>
                    <FTREF/>
                     are required to make an average of 4 responses per custodian concerning the use of foreign custodians other than depositories. The staff estimates that each response will take approximately 270 hours, requiring approximately 1080 total hours annually per custodian (270 hours × 4 responses per custodian). The total annual burden associated with these requirements of the rule is approximately 16,200 hours (15 global custodians × 1080 hours per custodian). Therefore, the total annual burden of all collection of information requirements of rule 17f-5 is estimated to be up to 16,425 hours (225 + 16,200). The total annual cost of burden hours is estimated to be $4,779,225 (225 hours × $4,465/hour for board of director's time + (16,200 hours x $233/hour for a trust administrator's time)).
                    <SU>5</SU>
                    <FTREF/>
                     Compliance with the collection of information requirements of the rule is necessary to obtain the benefit of relying on the rule's permission for funds to maintain their assets in foreign custodians.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         This figure is an estimate of the number of new funds each year, based on data reported by funds for 2017, 2018, and 2019. In practice, not all funds will use foreign custody managers. The actual figure therefore may be smaller.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         This estimate is based on staff research.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         Based on fund industry representations, the staff estimated in 2014 that the average cost of board of director time, for the board as a whole, was $4,000 per hour. Adjusting for inflation, the staff estimates that the current average cost of board of director time is approximately $4,465 per hour. The $233/hour figure for a trust administrator is from SIFMA's Management &amp; Professional Earnings in the Securities Industry 2013, modified by Commission staff to account for an 1800-hour work-year and inflation, and multiplied by 5.35 to account for bonuses, firm size, employee benefits, and overhead.
                    </P>
                </FTNT>
                <PRTPAGE P="25490"/>
                <P>The estimate of average burden hours is made solely for the purposes of the Paperwork Reduction Act. The estimate is not derived from a comprehensive or even a representative survey or study of the costs of Commission rules and forms.</P>
                <P>Written comments are invited on: (a) Whether the collection of information is necessary for the proper performance of the functions of the Commission, including whether the information has practical utility; (b) the accuracy of the Commission's estimate of the burden of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication.</P>
                <P>
                    Please direct your written comments to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, C/O Cynthia Roscoe, 100 F Street NE, Washington, DC 20549; or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09299 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-107 OMB Control No. 3235-0116]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <FP SOURCE="FP-1">
                    <E T="03">Upon Written Request Copies Available From:</E>
                     Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                    </FP>
                    <FP SOURCE="FP1-2">Form 6-K</FP>
                </EXTRACT>
                <P>
                    Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), the Securities and Exchange Commission (“Commission”) is soliciting comments on the collection of information summarized below. The Commission plans to submit this existing collection of information to the Office of Management and Budget for extension and approval.
                </P>
                <P>
                    Form 6-K (17 CFR 249.306) is a disclosure document under the Securities Exchange Act of 1934 (15 U.S.C. 78a 
                    <E T="03">et seq.</E>
                    ) that must be filed by a foreign private issuer to report material information promptly after the occurrence of specified or other important corporate events that are disclosed in the foreign private issuer's home country. The purpose of Form 6-K is to ensure that U.S. investors have access to the same information that foreign investors do when making investment decisions. Form 6-K takes approximately 8.7 hours per response and is filed by approximately 34,794 issuers annually. We estimate that 75% of the 8.7 hours per response (6.525 hours) is prepared by the issuer for a total annual reporting burden of 227,031 hours (6.525 hours per response × 34,794 responses).
                </P>
                <P>Written comments are invited on: (a) Whether this 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 imposed by the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication.</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 control number.</P>
                <P>
                    Please direct your written comment to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, c/o Cynthia Roscoe 100 F Street NE, Washington, DC 20549 or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09293 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-88752; File No. SR-CboeBZX-2020-035]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; Cboe BZX Exchange, Inc.; Notice of Filing and Immediate Effectiveness of a Proposed Rule Change Regarding the Listing Rule of the Hartford Core Bond ETF</SUBJECT>
                <DATE>April 27, 2020.</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 April 16, 2020, Cboe BZX Exchange, Inc. (“Exchange” or “BZX”) filed with the Securities and Exchange Commission (“Commission”) the proposed rule change as described in Items I and II below, which Items have been prepared by the Exchange. The Exchange filed the proposal as a “non-controversial” proposed rule change pursuant to Section 19(b)(3)(A)(iii) of the Act 
                    <SU>3</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(6) thereunder.
                    <SU>4</SU>
                    <FTREF/>
                     The Commission is publishing this notice to solicit comments on the proposed rule change from interested persons.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         15 U.S.C. 78s(b)(1).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         15 U.S.C. 78s(b)(3)(A)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         17 CFR 240.19b-4(f)(6).
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>Cboe BZX Exchange, Inc. (the “Exchange” or “BZX”) is filing with the Securities and Exchange Commission (“Commission”) a proposed rule change to allow the Hartford Core Bond ETF (the “Fund”), a series of the Hartford Funds Exchange-Traded Trust (the “Trust”), to expand the over-the-counter (“OTC”) derivative product types the Fund may hold and also to allow the Fund to hold credit default swap indices that are either listed or OTC derivatives.</P>
                <P>
                    The text of the proposed rule change is also available on the Exchange's website (
                    <E T="03">http://markets.cboe.com/us/equities/regulation/rule_filings/bzx/</E>
                    ), at the Exchange's Office of the Secretary, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>
                    In its filing with the Commission, the Exchange included statements concerning the purpose of and basis for the proposed rule change and discussed 
                    <PRTPAGE P="25491"/>
                    any comments it received on the proposed rule change. The text of these statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements.
                </P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>
                    The Exchange adopted a rule to permit the listing and trading the Shares.
                    <SU>5</SU>
                    <FTREF/>
                     On February 20, 2020, the Exchange commenced trading in the Shares. The Exchange now proposes to continue listing and trading the Shares pursuant to Rule 14.11(i) and expand the realm of derivatives in which the Fund may invest pursuant to the Initial Filing and allow the Fund to hold credit default swap indices that are either listed or OTC derivatives. As proposed, the Shares would continue to comply with all of the generic listing standards with the exception of the requirement of Rule 14.11(i)(4)(C)(ii)(d),
                    <SU>6</SU>
                    <FTREF/>
                     as described in the Initial Filing.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Securities Exchange Act No. 88107 (January 31, 2020) 85 FR 6988 (February 6, 2020) (SR-CboeBZX-2020-008) (the “Initial Filing”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         Rule 14.11(i)(4)(C)(ii)(d) provides that “component securities that in aggregate account for at least 90% of the fixed income weight of the portfolio must be either: (a) From issuers that are required to file reports pursuant to Sections 13 and 15(d) of the Act; (b) from issuers that have a worldwide market value of its outstanding common equity held by non-affiliates of $700 million or more; (c) from issuers that have outstanding securities that are notes, bonds, debentures, or evidence of indebtedness having a total remaining principal amount of at least $1 billion; (d) exempted securities as defined in Section 3(a)(12) of the Act; or (e) from issuers that are a government of a foreign country or a political subdivision of a foreign country.”
                    </P>
                </FTNT>
                <P>
                    As noted in the Initial Filing, the Exchange proposed a Rule amendment in order to allow the listing and trading of the Shares which would not meet the requirements of Rule 14.11(i)(4)(C)(ii)(d), which requires that component securities that in aggregate account for at least 90% of the fixed income weight of the portfolio must satisfy at least one of five conditions. Therefore, the Exchange proposed that the fixed income portion of the portfolio excluding Non-Agency ABS and MBS 
                    <SU>7</SU>
                    <FTREF/>
                     would satisfy the 90% requirement. In the Initial Filing, the Exchange also provided that the Fund would generally invest up to 20%, but may exceed 20%, of its assets in cash and Cash Equivalents,
                    <SU>8</SU>
                    <FTREF/>
                     certain listed derivatives,
                    <SU>9</SU>
                    <FTREF/>
                     and certain OTC derivatives.
                    <SU>10</SU>
                    <FTREF/>
                     Further, the Exchange provided that the Fund's holdings in cash and Cash Equivalents, listed derivatives, and OTC derivatives would be in compliance with all generic listing standards, including those in Rules 14.11(i)(4)(C)(iii), 14.11(i)(4)(C)(iv), 14.11(i)(4)(C)(v), and 14.11(i)(4)(C)(vi).
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         As noted in the Initial Filing, non-Agency ABS and MBS refers to non-agency, non-GSE (
                        <E T="03">i.e.,</E>
                         a type of financial services corporation created by the United States Congress, which include Fannie Mae and Freddie Mac), and privately-issued mortgage-related and other asset-backed securities.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         As defined in Exchange Rule 14.11(i)(4)(C)(iii)(b), Cash Equivalents are short-term instruments with maturities of less than three months, which includes only the following: (i) U.S. Government securities, including bills, notes, and bonds differing as to maturity and rates of interest, which are either issued or guaranteed by the U.S. Treasury or by U.S. Government agencies or instrumentalities; (ii) certificates of deposit issued against funds deposited in a bank or savings and loan association; (iii) bankers acceptances, which are short-term credit instruments used to finance commercial transactions; (iv) repurchase agreements and reverse repurchase agreements; (v) bank time deposits, which are monies kept on deposit with banks or savings and loan associations for a stated period of time at a fixed rate of interest; (vi) commercial paper, which are short-term unsecured promissory notes; and (vii) money market funds.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         As noted in the Initial Filing, listed derivatives include only the following instruments: Treasury futures, U.S. interest rate futures, and Eurodollar futures.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         As noted in the Initial Filing, OTC derivatives include only the following instruments: Interest rate swaps, currency forwards, and credit default swap indices.
                    </P>
                </FTNT>
                <P>Pursuant to the Initial Filing the Fund is permitted to invest in the following listed derivatives:</P>
                <P>• Treasury futures;</P>
                <P>• U.S. interest rate futures; and</P>
                <P>• Eurodollar futures.</P>
                <P>Additionally, pursuant to the Initial Filing, the Fund is permitted to invest in the following OTC Derivatives:</P>
                <P>• Interest rate swaps;</P>
                <P>• Currency forwards; and</P>
                <P>• Credit default swap indices.</P>
                <P>Now, the Exchange proposes to amend that credit default swap indices will continue to be held by the Fund, but may be listed derivatives or OTC derivatives. Therefore, the Exchange proposes that the Fund may invest in the following listed derivatives:</P>
                <P>• Treasury futures;</P>
                <P>• U.S. interest rate futures;</P>
                <P>• Eurodollar futures; and</P>
                <P>• Credit default swap indices.</P>
                <P>Additionally, the Exchange proposes to expand the types of OTC derivatives in which the Fund may invest to be the following instruments:</P>
                <P>• Interest rate swaps and consumer price index (“CPI”) swaps, credit default swaps, and total return swaps;</P>
                <P>• Interest rate options, options on interest rate swaps (“swaptions”), and options on credit default swaps;</P>
                <P>• Currency forwards and bond forwards; and</P>
                <P>
                    • Credit default swap indices.
                    <SU>11</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         As noted in the Initial Filing, intraday price quotations for OTC derivatives are available from major broker-dealer firms and from third-parties, which may provide prices free with a time delay or in real-time for a paid fee.
                    </P>
                </FTNT>
                <P>Rule 14.11(i)(4)(C)(v) is intended to mitigate concerns around the manipulability of a particular underlying reference asset or derivatives contract. As the proposal does not seek to allow the Fund to hold more than 20% of the weight of the portfolio (including gross notional exposures) in OTC derivatives, the Exchange believes the concerns around the manipulability of a particular underlying reference asset or derivatives contract are mitigated. Further, by allowing the Fund additional flexibility to further diversify its holdings to provide exposure to a broader array of OTC derivatives would allow the Fund to better achieve its investment objective, and, as such, benefit both investors and the Fund. As proposed, the Fund will continue to meet all generic listings standards related to OTC derivatives, including those in Rules 14.11(i)(4)(C)(v) and 14.11(i)(4)(C)(vi).</P>
                <P>
                    The Fund's investments, including those in derivatives, will continue to be consistent with the 1940 Act and the Fund's investment objective. Moreover, the Exchange represents that the Shares of the Fund will continue to comply with all other requirements applicable to Managed Fund Shares, which include the dissemination of key information such as the Disclosed Portfolio,
                    <SU>12</SU>
                    <FTREF/>
                     Net Asset Value,
                    <SU>13</SU>
                    <FTREF/>
                     and the Intraday Indicative Value,
                    <SU>14</SU>
                    <FTREF/>
                     suspension of trading or removal,
                    <SU>15</SU>
                    <FTREF/>
                     trading halts,
                    <FTREF/>
                    <SU>16</SU>
                     surveillance,
                    <SU>17</SU>
                    <FTREF/>
                     minimum price variation for quoting and order entry,
                    <SU>18</SU>
                    <FTREF/>
                     the information circular,
                    <SU>19</SU>
                    <FTREF/>
                     and firewalls 
                    <SU>20</SU>
                    <FTREF/>
                     as set forth in Exchange rules applicable to Managed Fund Shares and the orders approving such rules.
                </P>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(4)(A)(ii) and 14.11(i)(4)(B)(ii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(4)(A)(ii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(4)(B)(i).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(4)(B)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(4)(B)(iv).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(2)(C).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>18</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(2)(B).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(6).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>20</SU>
                         
                        <E T="03">See</E>
                         Rule 14.11(i)(7).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that the proposal is consistent with Section 6(b) of the Act 
                    <SU>21</SU>
                    <FTREF/>
                     in general and Section 6(b)(5) of the Act 
                    <SU>22</SU>
                    <FTREF/>
                     in particular in that it is designed to prevent fraudulent and manipulative acts and practices, to 
                    <PRTPAGE P="25492"/>
                    promote just and equitable principles of trade, to foster cooperation and coordination with persons engaged in facilitating transactions in securities, to remove impediments to and perfect the mechanism of a free and open market and a national market system and, in general, to protect investors and the public interest in that the Shares will meet each of the continued listing criteria in BZX Rule 14.11(i) with the exception of Rule 14.11(i)(4)(C)(ii)(d), as provided in the Initial Filing.
                </P>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         15 U.S.C. 78f(b)(5).
                    </P>
                </FTNT>
                <P>The Exchange believes the proposal to expand the types of derivatives in which the Fund may invest as discussed herein will allow the Fund additional flexibility to further diversify its holdings to better achieve its investment objective, and, as such, benefit both investors and the Fund. Further, as the proposal does not seek to allow the Fund to hold more than 20% of the weight of the portfolio (including gross notional exposures) in OTC derivatives, the Exchange believes the concerns around the manipulability of a particular underlying reference asset or derivatives contract are mitigated. The Exchange also believes the proposal to clarify that credit default swap indices that the Fund may hold may be listed or OTC derivatives will eliminate any potential investor confusion as to the types of derivatives the Fund may hold. Lastly, the Fund's investments in cash and Cash Equivalents, listed derivatives, and OTC derivatives will continue to be in compliance with all generic listing standards, including those in Rules 14.11(i)(4)(C)(iii), 14.11(i)(4)(C)(iv), 14.11(i)(4)(C)(v), and 14.11(i)(4)(C)(vi). The Fund will comply with all representations made in the Initial Filing, aside from the changes specifically discussed herein related to permitted derivatives.</P>
                <P>For the above reasons, the Exchange believes that the proposed rule change is consistent with the requirements of Section 6(b)(5) of the Act.</P>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>The Exchange does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purpose of the Act. The Exchange notes that the proposed rule change, rather, will facilitate the strategy of an actively-managed exchange-traded product that will allow the Fund to better compete in the marketplace, thus enhancing competition among both market participants and listing venues, to the benefit of investors and the marketplace.</P>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>The Exchange has neither solicited nor received written comments on the proposed rule change.</P>
                <HD SOURCE="HD1">III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action</HD>
                <P>
                    Because the foregoing proposed rule change does not: (i) Significantly affect the protection of investors or the public interest; (ii) impose any significant burden on competition; and (iii) become operative for 30 days from the date on which it was filed, or such shorter time as the Commission may designate, it has become effective pursuant to Section 19(b)(3)(A) of the Act 
                    <SU>23</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(6) thereunder.
                    <SU>24</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         15 U.S.C. 78s(b)(3)(A).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         17 CFR 240.19b-4(f)(6). In addition, Rule 19b-4(f)(6)(iii) requires a self-regulatory organization to give the Commission written notice of its intent to file the proposed rule change, along with a brief description and text of the proposed rule change, at least five business days prior to the date of filing of the proposed rule change, or such shorter time as designated by the Commission. The Exchange has satisfied this requirement.
                    </P>
                </FTNT>
                <P>
                    A proposed rule change filed under Rule 19b-4(f)(6) 
                    <SU>25</SU>
                    <FTREF/>
                     normally does not become operative for 30 days after the date of the filing. However, pursuant to Rule 19b-4(f)(6)(iii),
                    <SU>26</SU>
                    <FTREF/>
                     the Commission may designate a shorter time if such action is consistent with the protection of investors and the public interest. The Exchange has asked the Commission to waive the 30-day operative delay to allow the Fund to immediately modify its permitted investments in derivatives. The Exchange represents that all derivatives would be held in compliance with BZX's generic listing standards, including those in Rules 14.11(i)(4)(C)(iii), 14.11(i)(4)(C)(iv), 14.11(i)(4)(C)(v), and 14.11(i)(4)(C)(vi), and therefore the proposal raises no novel or substantive issues. Therefore, the Commission believes that waiver of the 30-day operative delay is consistent with the protection of investors and the public interest and hereby waives the 30-day operative delay and designates the proposed rule change operative upon filing.
                    <SU>27</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>25</SU>
                         17 CFR 240.19b-4(f)(6).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>26</SU>
                         17 CFR 240.19b-4(f)(6)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>27</SU>
                         For purposes only of waiving the operative delay, the Commission has considered the proposed rule's impact on efficiency, competition, and capital formation. 
                        <E T="03">See</E>
                         15 U.S.C. 78c(f).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act.</P>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:</P>
                <HD SOURCE="HD2">Electronic Comments</HD>
                <P>
                    • Use the Commission's internet comment form (
                    <E T="03">http://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-CboeBZX-2020-035 on the subject line.
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.</P>
                <FP>
                    All submissions should refer to File Number SR-CboeBZX-2020-035. 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">http://www.sec.gov/rules/sro.shtml</E>
                    ). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission's Public Reference Room, 100 F Street NE, Washington, DC 20549 on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. All comments received will be posted without change. Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR-CboeBZX-2020-035 and should be submitted on or before May 22, 2020.
                </FP>
                <SIG>
                    <PRTPAGE P="25493"/>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>28</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             17 CFR 200.30-3(a)(12).
                        </P>
                    </FTNT>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09248 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-88755; File No. SR-NYSEArca-2020-36]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; NYSE Arca, Inc.; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend Rule 6.40-O Relating to the Risk Limitation Mechanism</SUBJECT>
                <DATE>April 27, 2020.</DATE>
                <P>
                    Pursuant to Section 19(b)(1) 
                    <SU>1</SU>
                    <FTREF/>
                     of the Securities Exchange Act of 1934 (the “Act”) 
                    <SU>2</SU>
                    <FTREF/>
                     and Rule 19b-4 thereunder,
                    <SU>3</SU>
                    <FTREF/>
                     notice is hereby given that, on April 17, 2020, NYSE Arca, Inc. (“NYSE Arca” or the “Exchange”) filed with the Securities and Exchange Commission (the “Commission”) the proposed rule change as described in Items I and II below, which Items have been prepared by the self-regulatory organization. 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>
                         15 U.S.C. 78a.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>
                    The Exchange proposes to amend Rule 6.40-O (Risk Limitation Mechanism) to reflect modifications to the operation of the trade and trigger counters as well as the applicable time periods for determining if a risk setting is triggered in the event of a trading halt or for transactions at the open in regards to the Risk Limitation Mechanism. The Exchange also proposes to relocate certain text from Rule 6.40-O to Rule 6.86-O (Firm Quotes). The proposed rule change is available on the Exchange's website at 
                    <E T="03">www.nyse.com,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the self-regulatory organization included statements concerning the purpose of, and basis for, the proposed rule change and discussed any comments it received on the proposed rule change. The text of those statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant parts of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and the Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>The Exchange proposes to amend Rule 6.40-O (Risk Limitation Mechanism) (the “Rule”) to reflect modifications to the operation of the trade and trigger counters as well as the applicable time periods for determining if a risk setting is triggered in the event of a trading halt or for transactions at the open in regards to the Risk Limitation Mechanism. The Exchange also proposes to relocate certain text from Rule 6.40-O to Rule 6.86-O (Firm Quotes).</P>
                <HD SOURCE="HD3">Risk Limitation Mechanism</HD>
                <P>
                    Rule 6.40-O sets forth the risk-limitation mechanism (the “Mechanism”), which is designed to help Market Makers, as well as OTP Holders and OTP Firms (collectively, “OTP Holders” for the purpose of this filing) better manage risk related to quoting and submitting orders during periods of increased and significant trading activity.
                    <SU>4</SU>
                    <FTREF/>
                     Specifically, the Mechanism calculates for quotes and orders, respectively: The number of trades executed by the Market Maker or OTP Holder in a particular options class; the volume of contracts traded by the Market Maker or OTP Holder in a particular options class; or the aggregate percentage of the Market Maker's quoted size or OTP Holder's order size(s) executed in a particular options class.
                    <SU>5</SU>
                    <FTREF/>
                     To determine whether the Mechanism is triggered (
                    <E T="03">i.e.,</E>
                     the risk setting breached), the Exchange maintains separate trade counters that are incremented every time a trade is executed; that aggregate the number of contracts traded during each such execution; and that calculate applicable percentages depending on the risk setting at issue.
                    <SU>6</SU>
                    <FTREF/>
                     A breach of the Mechanism occurs if the number of increments to the trade counter, within a time period specified by the Exchange, exceeds the threshold set by the OTP Holder. Under the current Rule, the applicable time period will not be less than 100 milliseconds.
                    <SU>7</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         Market Makers are included in the definition of OTP Holders and therefore, unless the Exchange is discussing the quoting activity of Market Makers, the Exchange does not distinguish Market Makers from OTP Holders when discussing the risk limitation mechanisms. 
                        <E T="03">See</E>
                         Rule 1.1(nn) (defining OTP Holder as “a natural person, in good standing, who has been issued an OTP, or has been named as a Nominee” that is “a registered broker or dealer pursuant to Section 15 of the Securities Exchange Act of 1934, or a nominee or an associated person of a registered broker or dealer that has been approved by the Exchange to conduct business on the Exchange's Trading Facilities”). 
                        <E T="03">See also</E>
                         Rule 6.32-O(a) (defining a Market Maker as an individual “registered with the Exchange for the purpose of making transactions as a dealer-specialist on the Floor of the Exchange or for the purpose of submitting quotes electronically and making transactions as a dealer-specialist through the NYSE Arca OX electronic trading system”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         
                        <E T="03">See</E>
                         Rule 6.40-O(b)-(d) (setting forth the three risk limitation mechanisms available).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         
                        <E T="03">See</E>
                         Rule 6.40-O(a).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         
                        <E T="03">See</E>
                         Commentary .03 to Rule 6.40-O.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Proposed Clarification to Time Period for Triggering of Risk Limitation Mechanism</HD>
                <P>Currently, the timer elapses at the conclusion of the time period specified by the Exchange, unless a breach occurs sooner than the timer expiration. The Exchange proposes to modify this functionality such that the time period is rolling (as opposed to static) and is activated each time a trade counter is incremented such that the Exchange “looks back” at other trades that occurred within the time period specified by the Exchange to see if a breach has occurred (See examples at the end of this section). The Exchange believes this modification will enhance the operation of the timer—and hence the risk protection. The Exchange proposes to modify the Rule to ensure that it is consistent with this proposed functionality change.</P>
                <P>
                    First, the Exchange proposes to modify the Rule regarding the applicable time period during which the increments of the trade counters are tallied, including, to account for the occurrence of trading halts or transactions occurring at the open of trading in a series. Specifically, the Exchange proposes to modify Commentary .03 to Rule 6.40-O to provide that the minimum time period determined by the Exchange would be “inclusive of the duration of any trading halt occurring within that time”; however, “[f]or transactions occurring at the open per Rule 6.64-O, the applicable time period is the lesser of (i) the time between the opening of a series and the initial transaction or (ii) the time period specified by the Exchange.” 
                    <SU>8</SU>
                    <FTREF/>
                     The Exchange believes this 
                    <PRTPAGE P="25494"/>
                    proposed change adds clarity and transparency to Exchange rules making them easier to comprehend and navigate.
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .03 to Rule 6.40-O. 
                        <E T="03">See also</E>
                         Rule 6.65-O (Trading Halts and 
                        <PRTPAGE/>
                        Suspensions) and Rule 6.64-O (OX Opening Process).
                    </P>
                </FTNT>
                <P>
                    The Exchange also proposes to modify Commentary .06 to the Rule, which relates to the operation of trade and trigger counters once the Mechanism is activated. Current Commentary .06 to Rule provides that “[t]he trade counters will automatically reset and commence a new count for the OTP Holder (1) when a time period specified by the Exchange elapses or, (2) if one of the Risk Limitation Mechanisms is triggered”, upon the OTP Holder submitting a message to the Exchange to be re-enabled.
                    <SU>9</SU>
                    <FTREF/>
                     The Exchange proposes to clarify that the trade counters do not reset, per se, when the time period specified by Exchange elapses as the trade counters only commence a new count after a breach of the risk settings upon the OTP Holder's re-entry to the market. As proposed, modified Commentary .06 to the Rule would provide in relevant part that “[f]ollowing a breach of any of the Risk Limitation Mechanisms set forth in paragraphs (b), (c) or (d), the trade counters will commence a new count for the OTP Holder” upon the OTP Holder submitting a message to the Exchange to be re-enabled.
                    <SU>10</SU>
                    <FTREF/>
                     Consistent with this change, the Exchange also proposes to modify the rule text regarding the operation of the timer as it relates to the trigger counter.
                    <SU>11</SU>
                    <FTREF/>
                     As proposed, the Exchange would remove language regarding instances resulting in the automatic reset of the trigger counter and instead state simply that “[f]ollowing any breach pursuant to Rule 6.40-O(f), the trigger counter will commence a new count” when the OTP Holder submits a request to be re-enabled.
                    <SU>12</SU>
                    <FTREF/>
                     The Exchange believes this proposed clarification adds specificity and transparency to Exchange rules.
                </P>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         
                        <E T="03">See</E>
                         Commentary .06 to Rule 6.40-O.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .06 to Rule 6.40-O.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         
                        <E T="03">See</E>
                         Commentary .06 to Rule 6.40-O (providing that “[a]bsent a breach pursuant to Rule 6.40-O(f), the trigger counter will automatically reset and commence a new count for the OTP Holder (1) when a time period specified by the Exchange elapses; or (2) following any intraday update to configurable thresholds, as provided in Commentary .03 to this Rule 6.40-O” and that “[f]ollowing any breach pursuant to Rule 6.40-O (f), the trigger counter will be reset and commence a new count” when the OTP Holder makes non-automated contact requesting to be re-enabled).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .06 to Rule 6.40-O.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Examples Illustrating Current and Proposed Functionality</HD>
                <P>
                    <E T="03">Assumptions:</E>
                     The OTP Holder utilizes the transaction-based risk setting for orders with a maximum of three transactions before the setting is breached and the time period announced by the Exchange is 100ms.
                </P>
                <P>
                    <E T="03">Current Mechanism:</E>
                     Timer is asynchronous and covers fixed, non-overlapping periods. Timer starts at 10:10:00.101 (end of fixed period is 10:10:00.201).
                </P>
                <P>
                    <E T="03">Event 1:</E>
                     At 10:10:00.150, the OTP Holder trades 10 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there was one transaction (Event 1) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.101-10:10:00.201) = no breach.
                </FP>
                <P>
                    <E T="03">Event 2:</E>
                     At 10:10:00.190, the OTP Holder trades 15 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there were two transactions (Events 1 and 2) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.101-10:10:00.201) = no breach.
                </FP>
                <P>Timer expires at 10:10:00.201.</P>
                <P>Timer re-starts at 10:10:00.202 (end of fixed period is 10:10:00.302).</P>
                <P>
                    <E T="03">Event 3:</E>
                     At 10:10:00.210, the OTP Holder trades 20 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there was one transaction (Event 3 since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.202-10:10:00.302) = no breach.
                </FP>
                <P>
                    <E T="03">Event 4:</E>
                     At 10:10:00.220, the OTP Holder trades 10 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there were two transactions (Events 3 and 4) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.202-10:10:00.302) = no breach.
                </FP>
                <P>
                    <E T="03">Event 5:</E>
                     At 10:10:00.240, the OTP Holder trades 15 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there were three transactions (Events 3, 4 and 5) since start of timer (
                    <E T="03">i.e.,</E>
                     10:10:00.202-10:10:00.302) = BREACH.
                </FP>
                <P>
                    <E T="03">Proposed Mechanism:</E>
                     Timer “looks back” prior 100ms each time a transaction occurs.
                </P>
                <P>
                    <E T="03">Event 1:</E>
                     At 10:10:00.150, the OTP Holder trades 10 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there was one transaction (Event 1) that occurred in the prior 100ms (
                    <E T="03">i.e.,</E>
                     10:10:00.150-10:10:00.050) = no breach.
                </FP>
                <P>
                    <E T="03">Event 2:</E>
                     At 10:10:00.190, the OTP Holder trades 15 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there were two transactions (Events 1 and 2) that occurred in the prior 100ms (
                    <E T="03">i.e.,</E>
                     10:10:00.190-10:10:00.090) = no breach.
                </FP>
                <P>
                    <E T="03">Event 3:</E>
                     At 10:10:00.210, the OTP Holder trades 20 contracts.
                </P>
                <FP SOURCE="FP-1">
                    —The Exchange determines there were three transactions (Events 1, 2 and 3) that occurred in the prior 100ms (
                    <E T="03">i.e.,</E>
                     10:10:00.210-10:10:00.110) = BREACH.
                </FP>
                <HD SOURCE="HD3">Technical Changes</HD>
                <P>
                    Finally, the Exchange also proposes to delete the text located in Commentary .05 to Rule and to hold this Commentary as “Reserved.” 
                    <SU>13</SU>
                    <FTREF/>
                     Current Commentary .05 to the Rule relates to the Exchange's dissemination of a best bid and offer when no Market Makers are quoting in a class, which information is irrelevant to the operation of the Mechanism.
                    <SU>14</SU>
                    <FTREF/>
                     At the time Rule 6.40-O was implemented, the Exchange noted that it would “no longer generate two-sided quotes on behalf of a Specialist in the event that there are no Market Makers quoting in an issue” but would instead disseminate as the BBO “the best bids and offers of those orders residing in the Consolidated Book in the issue”—if such orders existed—or would “disseminate a bid of zero and an offer of zero in that issue.” 
                    <SU>15</SU>
                    <FTREF/>
                     In retrospect, the Exchange believes that Rule 6.40-O—which is focused on managing risk not quote dissemination—was not the optimal placement for this information. Instead, the Exchange believes such information would be more appropriately included with information regarding quote dissemination requirements. The Exchange therefore proposes to relocate this text to Rule 6.86-O (Firm Quotes) as market participants would be more likely to consult this rule (as opposed to Rule 6.40-O) in regards to quoting information. The Exchange believes the proposed relocation of this text would add clarity and consistency to Exchange rules, making them easier to navigate.
                    <SU>16</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         
                        <E T="03">See</E>
                         proposed Commentary .05 to Rule 6.40-O.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         
                        <E T="03">See</E>
                         Commentary .05 to Rule 6.40-O (providing that “[i]n the event that there are no Market Makers quoting in a class, the best bids and offers of those orders residing in the Consolidated Book in the class will be disseminated as the BBO. If there are no Market Makers quoting in the class and there are no orders in the Consolidated Book in the class, the System shall disseminate a bid of zero and an offer of zero”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>15</SU>
                         
                        <E T="03">See</E>
                         Securities Exchange Act Release No. 54238 (July 28, 2006), 71 FR 44758 (August 7, 2006) (SR-NYSEArca-2006-13) (order approving adoption of, among others, Rule 6.40-O).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>16</SU>
                         
                        <E T="03">See</E>
                         proposed Rule 6.86-O(b)(1)(A). The Exchange notes that it proposes to change “System” to “Exchange” regarding the source that disseminates the BBO for consistency with the rest of Rule 6.86-O.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that its proposal is consistent with Section 6(b) of the Act,
                    <SU>17</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Section 6(b)(5) of the Act,
                    <SU>18</SU>
                    <FTREF/>
                     in particular, in that it is designed to prevent fraudulent and manipulative acts and practices, to promote just and equitable principles of trade, to foster 
                    <PRTPAGE P="25495"/>
                    cooperation and coordination with persons engaged in regulating, clearing, settling, processing information with respect to, and facilitating transactions in securities, to remove impediments to and perfect the mechanism of a free and open market and a national market system and, in general, to protect investors and the public interest.
                </P>
                <FTNT>
                    <P>
                        <SU>17</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         15 U.S.C. 78f(b)(5).
                    </P>
                </FTNT>
                <P>OTP Holders are vulnerable to the risk from a system or other error or a market event that may cause them to send a large number of orders or receive multiple, automatic executions before they can adjust their exposure in the market. Without adequate risk management tools, such as the available risk settings, OTP Holders may opt to reduce the amount of order flow and liquidity that they provide to the market, which could undermine the quality of the markets available to market participants. The Exchange believes that the proposed change would remove impediments to and perfect the mechanism of a free and open market by adding clarity, transparency and specificity regarding the operation of the Mechanism thereby making Exchange rules easier to comprehend and navigate to the benefit of all market participants.</P>
                <P>
                    The Exchange believes the proposal to modify the time period to a rolling basis (as opposed to static time segments) would remove impediments to and perfect the mechanism of a free and open market and a national market system because it would provide OTP Holders with greater ability to monitor their risk. The proposed change, which allows for a count after each transaction on a rolling “look back” basis, would provide a more finely tuned tracking method for OTP Holders related to each transaction within a specified time period. As such, OTP Holders that use the Mechanism to reduce their risk, particularly in the event of a system issue or due to the occurrence of unusual or unexpected market activity, would have greater certainty of how the Mechanism would function with respect to each transaction. Moreover, the proposed rule change would provide OTP Holders with transparency regarding the manner in which the Exchange counts quotes and orders, which would provide OTP Holders with an increased ability to monitor transactions. Finally, the Exchange believes the proposed change is consistent with risk timers utilized by other options markets that offer similar risk limitation mechanisms.
                    <SU>19</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>19</SU>
                         
                        <E T="03">See, e.g.,</E>
                         MIAX Rule 519A, Risk Protection Monitor (providing that, for orders, MIAX utilizes a counter that will “look back over the specified time period'' to determine if a market participant has triggered its risk settings) and Rule 612, Aggregate Risk Manager (ARM) (providing that, for quotes, MIAX utilizes a counter that will “look back over the specified time period” to determine if a market maker has triggered its risk settings).
                    </P>
                    <P>The Exchange believes that the non-substantive change to Rule 6.40-O, Commentary .05 to delete and relocate text related to quote dissemination requirements from the Rule, which relates to managing risk, to the Firm Quote rule would make Exchange rules easier to navigate, thus adding clarity and transparency to Exchange rules to the benefit of the investing public.</P>
                </FTNT>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>The Exchange does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act.</P>
                <P>
                    Rather, the Exchange believes that the proposed rule change would enhance the Mechanism by providing OTP Holders with greater ability to monitor their risk by providing a more finely tuned tracking method for OTP Holders related to each transaction within a specified time period. In addition, the Exchange does not believe the proposal creates any significant impact on competition as the proposed “look back” time period is consistent with risk timers utilized by other options markets that offer similar risk limitation mechanisms.
                    <SU>20</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>20</SU>
                          
                        <E T="03">See id.</E>
                         (regarding MIAX risk mechanisms for orders and quotes, both of which utilize a counter that “looks back over the specified time period” to determine if risk settings have been triggered).
                    </P>
                </FTNT>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were solicited or received with respect to the proposed rule change.</P>
                <HD SOURCE="HD1">III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action</HD>
                <P>
                    Because the foregoing proposed rule change does not: (i) Significantly affect the protection of investors or the public interest; (ii) impose any significant burden on competition; and (iii) become operative for 30 days from the date on which it was filed, or such shorter time as the Commission may designate, it has become effective pursuant to Section 19(b)(3)(A) of the Act 
                    <SU>21</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(6) thereunder.
                    <SU>22</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>21</SU>
                         15 U.S.C. 78s(b)(3)(A).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>22</SU>
                         17 CFR 240.19b-4(f)(6). In addition, Rule 19b-4(f)(6)(iii) requires a self-regulatory organization to give the Commission written notice of its intent to file the proposed rule change, along with a brief description and text of the proposed rule change, at least five business days prior to the date of filing of the proposed rule change, or such shorter time as designated by the Commission. The Exchange has satisfied this requirement.
                    </P>
                </FTNT>
                <P>
                    A proposed rule change filed pursuant to Rule 19b-4(f)(6) under the Act 
                    <SU>23</SU>
                    <FTREF/>
                     normally does not become operative for 30 days after the date of its filing. However, Rule 19b-4(f)(6)(iii) 
                    <SU>24</SU>
                    <FTREF/>
                     permits the Commission to designate a shorter time if such action is consistent with the protection of investors and the public interest. The Exchange has requested that the Commission waive the 30-day operative delay so that the proposed rule change may become operative upon filing. Waiver of the operative delay would allow the Exchange to immediately amend its rules to provide OTP Holders with a more finely tuned tracking method for each transaction within a specified time period, which could provide greater certainty of how the Mechanism would function with respect to each transaction. The Commission believes that waiver of the 30-day operative delay is consistent with the protection of investors and the public interest. Accordingly, the Commission hereby waives the operative delay and designates the proposed rule change operative upon filing.
                    <SU>25</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>23</SU>
                         17 CFR 240.19b-4(f)(6).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>24</SU>
                         17 CFR 240.19b-4(f)(6)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>25</SU>
                         For purposes only of waiving the 30-day operative delay, the Commission also has considered the proposed rule's impact on efficiency, competition, and capital formation. 
                        <E T="03">See</E>
                         15 U.S.C. 78c(f).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule change should be approved or disapproved.</P>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:</P>
                <HD SOURCE="HD2">Electronic Comments</HD>
                <P>
                    • Use the Commission's internet comment form (
                    <E T="03">http://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-NYSEArca-2020-36 on the subject line.
                    <PRTPAGE P="25496"/>
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to: Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.</P>
                <FP>
                    All submissions should refer to File Number SR-NYSEArca-2020-36. 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">http://www.sec.gov/rules/sro.shtml</E>
                    ). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission's Public Reference Room, 100 F Street NE, Washington, DC 20549 on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. All comments received will be posted without change. Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR-NYSEArca-2020-36 and should be submitted on or before May 22, 
                    <FTREF/>
                    2020.
                </FP>
                <FTNT>
                    <P>
                        <SU>26</SU>
                         17 CFR 200.30-3(a)(12).
                    </P>
                </FTNT>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>26</SU>
                    </P>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09251 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-40, OMB Control No. 3235-0313]</DEPDOC>
                <SUBJECT>Submission for OMB Review; Comment Request</SUBJECT>
                <FP SOURCE="FP-1">
                    <E T="03">Upon Written Request, Copies Available From:</E>
                     Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                    </FP>
                    <FP SOURCE="FP1-2">Rule 203-2 and Form ADV-W</FP>
                </EXTRACT>
                <P>
                    Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), the Securities and Exchange Commission (“Commission”) is soliciting comments on the collection of information summarized below. The Commission plans to submit this existing collection of information to the Office of Management and Budget for extension and approval.
                </P>
                <P>The title for the collection of information is “Rule 203-2 (17 CFR 275.203-2) and Form ADV-W (17 CFR 279.2) under the Investment Advisers Act of 1940 (15 U.S.C. 80b).” Rule 203-2 under the Investment Advisers Act of 1940 establishes procedures for an investment adviser to withdraw its registration or pending registration with the Commission. Rule 203-2 requires every person withdrawing from investment adviser registration with the Commission to file Form ADV-W electronically on the Investment Adviser Registration Depository (“IARD”). The purpose of the information collection is to notify the Commission and the public when an investment adviser withdraws its pending or approved SEC registration. Typically, an investment adviser files a Form ADV-W when it ceases doing business or when it is ineligible to remain registered with the Commission.</P>
                <P>The respondents to the collection of information are all investment advisers that are registered with the Commission or have applications pending for registration. The Commission has estimated that compliance with the requirement to complete Form ADV-W imposes a total burden of approximately 0.75 hours (45 minutes) for an adviser filing for full withdrawal and approximately 0.25 hours (15 minutes) for an adviser filing for partial withdrawal. Based on historical filings, the Commission estimates that there are approximately 802 respondents annually filing for full withdrawal and approximately 454 respondents annually filing for partial withdrawal. Based on these estimates, the total estimated annual burden would be 715 hours ((802 respondents × .75 hours) + (454 respondents × .25 hours)).</P>
                <P>Rule 203-2 and Form ADV-W do not require recordkeeping or records retention. The collection of information requirements under the rule and form are mandatory. The information collected pursuant to the rule and Form ADV-W are filings with the Commission. These filings are not kept confidential. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid control number.</P>
                <P>Written comments are invited on: (a) Whether the documentation 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 of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication.</P>
                <P>
                    Please direct your written comments to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, C/O Cynthia Roscoe, 100 F Street NE, Washington, DC 20549; or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09290 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-559, OMB Control No. 3235-0621]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <FP SOURCE="FP-1">
                    <E T="03">Upon Written Request Copies Available From:</E>
                     Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                    </FP>
                    <FP SOURCE="FP1-2">Form 15F</FP>
                </EXTRACT>
                <P>
                    Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), the Securities and Exchange Commission (“Commission”) is soliciting comments on the collection of information summarized below. The Commission plans to submit this existing collection of information to the Office of Management and Budget for extension and approval.
                </P>
                <P>
                    Form 15F (17 CFR 249.324) is filed by a foreign private issuer when terminating its Exchange Act reporting 
                    <PRTPAGE P="25497"/>
                    obligations pursuant to Exchange Act Rule 12h-6 (17 CFR 240.12h-6). Form 15F requires a foreign private issuer to disclose information that helps investors understand the foreign private issuer's decision to terminate its Exchange Act reporting obligations and assists the Commission staff in determining whether the filer is eligible to terminate its Exchange Act reporting obligations pursuant to Rule 12h-6. Rule 12h-6 provides a process for a foreign private issuer to exit the Exchange Act registration and reporting regime when there is relatively little U.S. investor interest in its securities. Rule 12h-6 is intended to remove a disincentive for foreign private issuers to register their securities with the Commission by lessening concerns that the Exchange Act registration and reporting system would be difficult to exit once an issuer enters it. We estimate that Form 15F takes approximately 30 hours to prepare and is filed by approximately 30 issuers. We estimate that 25% of the 30 hours per response (7.5 hours per response) is prepared by the filer for a total annual reporting burden of 225 hours (7.5 hours per response × 30 responses).
                </P>
                <P>Written comments are invited on: (a) Whether this 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 imposed by the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication.</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 control number.</P>
                <P>
                    Please direct your written comment to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, c/o Cynthia Roscoe, 100 F Street NE, Washington, DC 20549 or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09291 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-88756; File No. SR-NYSEAMER-2020-32]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; NYSE American LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend Rule 1.1E To Modify the Definition of “UTP Exchange Traded Product” and Rule 5.1E To Incorporate the Modified Definition of “UTP Exchange Traded Product”</SUBJECT>
                <DATE>April 27, 2020.</DATE>
                <P>
                    Pursuant to Section 19(b)(1) 
                    <SU>1</SU>
                    <FTREF/>
                     of the Securities Exchange Act of 1934 (“Act”) 
                    <SU>2</SU>
                    <FTREF/>
                     and Rule 19b-4 thereunder,
                    <SU>3</SU>
                    <FTREF/>
                     notice is hereby given that on April 16, 2020, NYSE American LLC (“Exchange”) filed with the Securities and Exchange Commission (“Commission”) the proposed rule change as described in Items I and II below, which Items have been prepared by the self-regulatory organization. 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>
                         15 U.S.C. 78a.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>
                    The Exchange proposes to amend (1) Rule 1.1E to modify the definition of “UTP Exchange Traded Product” and (2) Rule 5.1E to incorporate the definition of UTP Exchange Traded Product as set forth in revised Rule 1.1E. The proposed rule change is available on the Exchange's website at 
                    <E T="03">www.nyse.com,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the self-regulatory organization included statements concerning the purpose of, and basis for, the proposed rule change and discussed any comments it received on the proposed rule change. The text of those statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant parts of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and the Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>The Exchange proposes to amend (1) Rule 1.1E to modify the definition of “UTP Exchange Traded Product” and (2) Rule 5.1E to incorporate the definition of UTP Exchange Traded Product as set forth in revised Rule 1.1E.</P>
                <HD SOURCE="HD3">Rule 1.1E</HD>
                <P>Rule 1.1E(bbb) currently provides that the term “Exchange Traded Product” means a security that meets the definition of “derivative securities product” in Rule 19b-4(e) under the Securities Exchange Act of 1934 and a “UTP Exchange Traded Product” means an Exchange Traded Product that trades on the Exchange pursuant to unlisted trading privileges. The Exchange proposes to amend the definition of “UTP Exchange Traded Product” to mean one of the following Exchange Traded Products that trades on the Exchange pursuant to unlisted trading privileges: Equity Linked Notes, Investment Company Units, Index-Linked Exchangeable Notes, Equity Gold Shares, Equity Index-Linked Securities, Commodity-Linked Securities, Currency-Linked Securities, Fixed-Income Index-Linked Securities, Futures-Linked Securities, Multifactor-Index-Linked Securities, Trust Certificates, Currency and Index Warrants, Portfolio Depository Receipts, Trust Issued Receipts, Commodity-Based Trust Shares, Currency Trust Shares, Commodity Index Trust Shares, Commodity Futures Trust Shares, Partnership Units, Paired Trust Shares, Trust Units, Managed Fund Shares, Managed Trust Securities, and Managed Portfolio Shares.</P>
                <P>
                    This proposed change is based on NYSE National, Inc. (“NYSE National”) Rule 1.1(m) and NYSE Chicago, Inc. (“NYSE Chicago”) Rule 1.1(k).
                    <SU>4</SU>
                    <FTREF/>
                     This list is designed to align the rules of the Exchange with the rules of NYSE National and NYSE Chicago and to enumerate the types of Exchange Traded Products to which the Exchange would extend unlisted trading privileges (“UTP”).
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         NYSE National and NYSE Chicago have filed proposed rule changes for immediate effectiveness to amend their respective rules to add Managed Portfolio Shares to their definitions of UTP Exchange Traded Products. 
                        <E T="03">See</E>
                         SR-NYSENAT-2020-16 (filed April 16, 2020) and SR-NYSECHX-2020-13 (filed April 16, 2020).
                    </P>
                </FTNT>
                <PRTPAGE P="25498"/>
                <HD SOURCE="HD3">Rule 5.1E</HD>
                <P>Rule 5.1E(a)(1) provides that the Exchange may extend UTP to any security that is an NMS stock (as defined in Rule 600 of Regulation NMS under the Act) that is listed on another national securities exchange or with respect to which unlisted trading privileges may otherwise be extended in accordance with Section 12(f) of the Act. Rule 5.1E(a)(2) further specifies that a UTP Exchange Traded Product, which is defined in that Rule as a “new derivative securities product” as defined in Rule 19b-4(e) under the Exchange Act and traded pursuant to Rule 19b-4(e) under the Act, would be subject to the additional rules enumerated in Rule 5.1E(a)(2)(A)-(E).</P>
                <P>Because the Exchange proposes to modify the definition of UTP Exchange Trading Product in Rule 1.1E(bbb) to conform to the rules of NYSE National and NYSE Chicago, the Exchange proposes to amend Rule 5.1E(a)(2) to eliminate redundant text and cross reference the term “UTP Exchange Traded Product” as it is defined in Rule 1.1E. This proposed change would also conform Rule 5.1E(a)(2) with the comparable NYSE National rule.</P>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that the proposed rule change is consistent with Section 6(b) of the Act,
                    <SU>5</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Section 6(b)(5) of the Act,
                    <SU>6</SU>
                    <FTREF/>
                     in particular, because it is designed to remove impediments to and perfect the mechanism of a free and open market, to promote just and equitable principles of trade, and, in general, to protect investors and the public interest.
                </P>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         15 U.S.C. 78f(b)(4) &amp; (5).
                    </P>
                </FTNT>
                <P>The Exchange believes its proposed rule change ensures that Rule 1.1E identifies and publicly states the complete list of Exchange Traded Products to which UTP may be extended for trading on the Exchange. The Exchange also believes that the proposed rule change removes impediments to and perfects the mechanism of a free and open market, promotes just and equitable principles of trade, and protects investors and the public interest by promoting consistency with the rules of the Exchange's affiliated markets and by providing additional specificity, clarity, and transparency in the Exchange's rules with respect to the Exchange Traded Products that may be traded on a UTP basis on the Exchange.</P>
                <P>
                    The Exchange believes that its proposal to amend Rule 5.1E(a)(2) also removes impediments to and perfects the mechanism of a free and open market, promotes just and equitable principles of trade, and protects investors and the public interest because it proposes to conform this rule governing the trading of UTP Exchange Traded Products with the comparable rule of the Exchange's affiliated market, NYSE National, which has been approved by the Commission.
                    <SU>7</SU>
                    <FTREF/>
                     The proposed rule change would also remove impediments to and perfect the mechanism of a free and open market and a national market system and protect investors and the public interest by promoting continuity across affiliated exchanges.
                </P>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         In its Order approving the NYSE National rule on which this proposed change is based, the Commission found that the NYSE National rules set forth an “appropriate framework for the trading of Exchange Traded Products on a UTP basis on the Exchange” and are consistent with Section 6(b)(5) of the Act. 
                        <E T="03">See</E>
                         Securities and Exchange Act Release No. 83289 (May 17, 2018), 83 FR 23968 (May 23, 2018), at 23975.
                    </P>
                </FTNT>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>The Exchange does not believe that the proposed rule change will impose any burden on competition that is not necessary or appropriate in furtherance of the purposes of the Act. The proposed change would conform Exchange rules, as described herein, with the comparable rules of its affiliated exchanges, NYSE National and NYSE Chicago, and permit UTP trading of Exchange Traded Products on the Exchange in a manner consistent with its affiliated exchanges.</P>
                <HD SOURCE="HD2">C. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were solicited or received with respect to the proposed rule change.</P>
                <HD SOURCE="HD1">III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action</HD>
                <P>
                    Because the foregoing proposed rule change does not: (i) Significantly affect the protection of investors or the public interest; (ii) impose any significant burden on competition; and (iii) become operative for 30 days from the date on which it was filed, or such shorter time as the Commission may designate, it has become effective pursuant to Section 19(b)(3)(A) of the Act 
                    <SU>8</SU>
                    <FTREF/>
                     and Rule 19b-4(f)(6) thereunder.
                    <SU>9</SU>
                    <FTREF/>
                </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)(6). In addition, Rule 19b-4(f)(6)(iii) requires a self-regulatory organization to give the Commission written notice of its intent to file the proposed rule change, along with a brief description and text of the proposed rule change, at least five business days prior to the date of filing of the proposed rule change, or such shorter time as designated by the Commission. The Exchange has satisfied this requirement.
                    </P>
                </FTNT>
                <P>
                    A proposed rule change filed under Rule 19b-4(f)(6) 
                    <SU>10</SU>
                    <FTREF/>
                     normally does not become operative for 30 days after the date of the filing. However, pursuant to Rule 19b-4(f)(6)(iii),
                    <SU>11</SU>
                    <FTREF/>
                     the Commission may designate a shorter time if such action is consistent with the protection of investors and the public interest. The Exchange has asked the Commission to waive the 30-day operative delay so that the proposal may become operative immediately upon filing. The Commission notes that the Exchange's proposal would conform the Exchange's rules, as described herein, to the corresponding rules of its affiliated exchanges.
                    <SU>12</SU>
                    <FTREF/>
                     Accordingly, the Commission believes that the proposal raises no new or novel regulatory issues and waiver of the 30-day operative delay is consistent with the protection of investors and the public interest. The Commission therefore waives the 30-day operative delay and designates the proposed rule change to be operative upon filing.
                    <SU>13</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         17 CFR 240.19b-4(f)(6).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         17 CFR 240.19b-4(f)(6)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         
                        <E T="03">See</E>
                         NYSE National Rules 1.1 and 5.1 and NYSE Chicago Rule 1.1.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>13</SU>
                         For purposes only of waiving the 30-day operative delay, the Commission has also considered the proposed rule's impact on efficiency, competition, and capital formation. 
                        <E T="03">See</E>
                         15 U.S.C. 78c(f).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act.</P>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:</P>
                <HD SOURCE="HD2">Electronic Comments</HD>
                <P>
                    • Use the Commission's internet comment form (
                    <E T="03">http://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-NYSEAMER-2020-32 on the subject line.
                    <PRTPAGE P="25499"/>
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.</P>
                <FP>
                    All submissions should refer to File Number SR-NYSEAMER-2020-32. 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">http://www.sec.gov/rules/sro.shtml</E>
                    ). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission's Public Reference Room, 100 F Street NE, Washington, DC 20549 on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. All comments received will be posted without change. Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR-NYSEAMER-2020-32 and should be 
                    <FTREF/>
                    submitted on or before May 22, 2020.
                </FP>
                <FTNT>
                    <P>
                        <SU>14</SU>
                         17 CFR 200.30-3(a)(12).
                    </P>
                </FTNT>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>14</SU>
                    </P>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09252 Filed 4-30-20; 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 Meeting; Cancellation</SUBJECT>
                <PREAMHD>
                    <HD SOURCE="HED">FEDERAL REGISTER CITATION OF PREVIOUS ANNOUNCEMENT:</HD>
                    <P>85 FR 23407, April 27, 2020</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">PREVIOUSLY ANNOUNCED TIME AND DATE OF THE MEETING:</HD>
                    <P>Wednesday, April 29, 2020 at 12:00 p.m.</P>
                </PREAMHD>
                <PREAMHD>
                    <HD SOURCE="HED">CHANGES IN THE MEETING:</HD>
                    <P>The Closed Meeting scheduled for Wednesday, April 29, 2020 at 12:00 p.m., has been cancelled.</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>
                </PREAMHD>
                <SIG>
                    <DATED>Dated: April 29, 2020.</DATED>
                    <NAME>Vanessa A. Countryman,</NAME>
                    <TITLE>Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09449 Filed 4-29-20; 4:15 pm]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-508, OMB Control No. 3235-0565]</DEPDOC>
                <SUBJECT>60 Day Notice—Proposed Collection; Comment Request</SUBJECT>
                <FP SOURCE="FP-1">
                    <E T="03">Upon Written Request, Copies Available From:</E>
                     Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                    </FP>
                    <FP SOURCE="FP1-2">Rule 482</FP>
                </EXTRACT>
                <P>
                    Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ) (“Paperwork Reduction Act”), the Securities and Exchange Commission (the “Commission”) is soliciting comments on the collection of information summarized below. The Commission plans to submit this existing collection of information to the Office of Management and Budget (“OMB”) for extension and approval.
                </P>
                <P>
                    Like most issuers of securities, when an investment company (“fund”) 
                    <SU>1</SU>
                    <FTREF/>
                     offers its shares to the public, its promotional efforts become subject to the advertising restrictions of the Securities Act of 1933 (15 U.S.C. 77) (the “Securities Act”). In recognition of the particular problems faced by funds that continually offer securities and wish to advertise their securities, the Commission has adopted advertising safe harbor rules. The most important of these is rule 482 (17 CFR 230.482) under the Securities Act, which, under certain circumstances, permits funds to advertise investment performance data, as well as other information. Rule 482 advertisements are deemed to be “prospectuses” under Section 10(b) of the Securities Act (15 U.S.C. 77j(b)).
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         “Investment company” refers to both investment companies registered under the Investment Company Act of 1940 (“Investment Company Act”) (15 U.S.C. 80a-1 
                        <E T="03">et seq.</E>
                        ) and business development companies.
                    </P>
                </FTNT>
                <P>Rule 482 contains certain requirements regarding the disclosure that funds are required to provide in qualifying advertisements. These requirements are intended to encourage the provision to investors of information that is balanced and informative, particularly in the area of investment performance. For example, a fund is required to include disclosure advising investors to consider the fund's investment objectives, risks, charges and expenses, and other information described in the fund's prospectus, and highlighting the availability of the fund's prospectus and, if applicable, its summary prospectus. In addition, rule 482 advertisements that include performance data of open-end funds or insurance company separate accounts offering variable annuity contracts are required to include certain standardized performance information, information about any sales loads or other nonrecurring fees, and a legend warning that past performance does not guarantee future results. Such funds including performance information in rule 482 advertisements are also required to make available to investors month-end performance figures via website disclosure or by a toll-free telephone number, and to disclose the availability of the month-end performance data in the advertisement. The rule also sets forth requirements regarding the prominence of certain disclosures, requirements regarding advertisements that make tax representations, requirements regarding advertisements used prior to the effectiveness of the fund's registration statement, requirements regarding the timeliness of performance data, and certain required disclosures by money market funds.</P>
                <P>
                    Rule 482 advertisements must be filed with the Commission or, in the alternative, with the Financial Industry Regulatory Authority (“FINRA”).
                    <SU>2</SU>
                    <FTREF/>
                     This information collection differs from many other federal information collections that are primarily for the use and benefit of the collecting agency.
                </P>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         
                        <E T="03">See</E>
                         note to rule 482(h) under the Securities Act, which states that “these advertisements, unless filed with [FINRA], are required to be filed in accordance with the requirements of § 230.497.” 
                        <E T="03">See also</E>
                         rule 24b-3 under the Investment Company Act (17 CFR 270.24b-3), which provides that any sales material, including rule 482 advertisements, shall be deemed filed with the Commission for purposes of Section 24(b) of the Investment Company Act upon filing with FINRA.
                    </P>
                </FTNT>
                <P>
                    Rule 482 contains requirements that are intended to encourage the provision to investors of information that is balanced and informative, particularly 
                    <PRTPAGE P="25500"/>
                    in the area of investment performance. The Commission is concerned that in the absence of such provisions fund investors may be misled by deceptive rule 482 advertisements and may rely on less-than-adequate information when determining in which funds they should invest money. As a result, the Commission believes it is beneficial for funds to provide investors with balanced information in fund advertisements in order to allow investors to make better-informed decisions.
                </P>
                <P>
                    The Commission estimates that 41,265 
                    <SU>3</SU>
                    <FTREF/>
                     responses to rule 482 are filed annually by 2,877 investment companies offering approximately 12,476 portfolios, or approximately 3.3 responses per portfolio annually.
                    <SU>4</SU>
                    <FTREF/>
                     The burden associated with rule 482 is presently estimated to be 5.16 hours per response. The annual hourly burden is therefore approximately 212,927 hours.
                    <SU>5</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         This estimated number of responses to rule 482 is composed of 41,003 responses filed with FINRA and 262 responses filed with the Commission in 2019.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         41,265 responses ÷ 12,476 portfolios = 3.3 responses per portfolio.
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         41,265 responses x 5.16 hours per response = 212,927 hours.
                    </P>
                </FTNT>
                <P>The estimate of average burden hours is made solely for the purposes of the Paperwork Reduction Act and is not derived from a comprehensive or even a representative survey or study of the costs of Commission rules and forms. The provision of information under rule 482 is necessary to obtain the benefits of the safe harbor offered by the rule. The information provided under rule 482 will not be kept confidential. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid OMB control number.</P>
                <P>Written comments are invited on: (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 of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication.</P>
                <P>
                    Please direct your written comments to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, C/O Cynthia Roscoe, 100 F Street NE, Washington, DC 20549; or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09300 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[Release No. 34-88753; File No. SR-Phlx-2020-21]</DEPDOC>
                <SUBJECT>Self-Regulatory Organizations; Nasdaq PHLX LLC; Notice of Filing and Immediate Effectiveness of Proposed Rule Change To Amend Various Phlx Rules Related to Routing, Remote Specialist, and Assistant Lead Market Maker</SUBJECT>
                <DATE>April 27, 2020.</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 April 15, 2020, Nasdaq PHLX LLC (“Phlx” or “Exchange”) filed with the Securities and Exchange Commission (“Commission”) the proposed rule change as described in Items I and II below, which Items have been prepared by the Exchange. The Commission is publishing this notice to solicit comments on the proposed rule change from interested persons.
                </P>
                <FTNT>
                    <P>
                        <SU>1</SU>
                         15 U.S.C. 78s(b)(1).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>2</SU>
                         17 CFR 240.19b-4.
                    </P>
                </FTNT>
                <HD SOURCE="HD1">I. Self-Regulatory Organization's Statement of the Terms of Substance of the Proposed Rule Change</HD>
                <P>The Exchange proposes to amend Phlx Rules at Options 2, Section 3, Allocation Application, Allocation, Reallocation, Transfer and Voluntary Resignation”; Options 2, Section 4, Obligations of Market Makers; Options 2, Section 11, Lead Market Maker Appointments; Options 5, Section 4, Order Routing; Options 8, Section 11, Floor Market Maker and Lead Market Maker Appointment; Options 8, Section 25, Floor Allocation; and Options 8, Section 39, Option Minor Rule Violations and Order and Decorum Regulations at E-2, Allocation, Time Stamping, Matching and Access to Matched Trades.</P>
                <P>
                    The text of the proposed rule change is available on the Exchange's website at 
                    <E T="03">http://nasdaqphlx.cchwallstreet.com/,</E>
                     at the principal office of the Exchange, and at the Commission's Public Reference Room.
                </P>
                <HD SOURCE="HD1">II. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <P>In its filing with the Commission, the Exchange included statements concerning the purpose of and basis for the proposed rule change and discussed any comments it received on the proposed rule change. The text of these statements may be examined at the places specified in Item IV below. The Exchange has prepared summaries, set forth in sections A, B, and C below, of the most significant aspects of such statements.</P>
                <HD SOURCE="HD2">A. Self-Regulatory Organization's Statement of the Purpose of, and Statutory Basis for, the Proposed Rule Change</HD>
                <HD SOURCE="HD3">1. Purpose</HD>
                <P>The Exchange proposes to amend Phlx Rules at Options 2, Section 3, Allocation Application, Allocation, Reallocation, Transfer and Voluntary Resignation”; Options 2, Section 4, Obligations of Market Makers; Options 2, Section 11, Lead Market Maker Appointments; Options 5, Section 4, Order Routing; Options 8, Section 11, Floor Market Maker and Lead Market Maker Appointment; Options 8, Section 25, Floor Allocation; and Options 8, Section 39, Option Minor Rule Violations and Order and Decorum Regulations at E-2, Allocation, Time Stamping, Matching and Access to Matched Trades. Each change is described below.</P>
                <HD SOURCE="HD3">Remote Specialist</HD>
                <P>
                    The Exchange proposes to amend Options 2, Section 4, Obligations of Market Maker, to replace rule text currently within Options 2, Section 4(b)(2) with more precise rule text. Currently, the rule text in the last two sentences of Options 2, Section 4(b)(2) provides, “An RSQT shall not submit option quotations in eligible options to which such RSQT is assigned to the extent that the RSQT is also approved as a Remote Lead Market Maker in the same options. An RSQT may only trade in a market making capacity in classes of options in which he is assigned or approved as a Remote Lead Market Maker.” The Exchange would like to replace this text with more precise language which it believes more clearly conveys the meaning of those sentences. The Exchange proposes to state, “An RSQT may not simultaneously quote both as RSQT and Remote Lead Market 
                    <PRTPAGE P="25501"/>
                    Maker in a particular security. If an RSQT is a Remote Lead Market Maker in a particular security, the Remote Lead Marker Maker must make a market as a Remote Lead Market Maker and may not make a market as an RSQT in that particular security.” This rule text, which the Exchange believes is clear and precise, is taken from the Order which approved this rule text.
                    <SU>3</SU>
                    <FTREF/>
                     This amendment is a non-substantive rule change which is merely intended to bring greater clarity to the obligation of an RSQT who is also the Remote Lead Market Maker in a particular security.
                </P>
                <FTNT>
                    <P>
                        <SU>3</SU>
                         
                        <E T="03">See</E>
                         Securities Exchange Act Release No. 63717 (January 14, 2011), 76 FR 4141at 4143 (January 24, 2011) (SR-Phlx-2010-145) (“Order Granting Accelerated Approval to a Proposed Rule Change, as Modified by Amendment No. 1 Thereto, Relating to the Establishment of Remote Specialists”).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Assistant Lead Market Maker</HD>
                <P>The Exchange proposes to amend rule text within Options 2, Section 3, Allocation Application, Allocation, Reallocation, Transfer and Voluntary Resignation; Options 2, Section 11, Lead Market Maker Appointments; Options 8, Section 11, Floor Market Maker and Lead Market Maker Appointment; Options 8, Section 25, Floor Allocation; and Options 8, Section 39, Option Minor Rule Violations and Order and Decorum Regulations at E-2, Allocation, Time Stamping, Matching and Access to Matched Trades to replace the term “assistant” with “back-up.” This amendment is non-substantive. The Exchange believes that the word “back-up” is a more precise term that emphasizes that the Market Maker must be able to take on all the duties of the Lead Market Maker. No obligations are being amended with respect to this role.</P>
                <HD SOURCE="HD3">Routing</HD>
                <P>
                    Phlx previously filed a rule proposal 
                    <SU>4</SU>
                    <FTREF/>
                     to amend this Options 5, Section 4, “Order Routing,” which was previously numbered Rule 1093.
                    <SU>5</SU>
                    <FTREF/>
                     At this time, the Exchange proposes to remove two sentences within Options 5, Section 4 for FIND and SRCH Orders. These sentences were inadvertently not removed in the Prior Rule Change.
                </P>
                <FTNT>
                    <P>
                        <SU>4</SU>
                         
                        <E T="03">See</E>
                         Securities Exchange Act Release No. 87811 (December 20, 2019), 84 FR 72017 (December 30, 2019) (SR-Phlx-2019-56) (“Prior Rule Change”).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>5</SU>
                         Phlx has recently renumbered its rules in connection with a Rulebook relocation to a new Rulebook shell. 
                        <E T="03">See</E>
                         SR-Phlx-2020-03.
                    </P>
                </FTNT>
                <HD SOURCE="HD3">FIND Orders</HD>
                <P>The Exchange proposes to delete a sentence within FIND Orders at Options 5, Section 4(a)(iii)(B)(5) which states, “If during the Route Timer, the ABBO moves and crosses the FIND Order, any new interest arrives opposite the FIND Order that is marketable against the FIND Order will trade at the FIND Order price.” This sentence is incorrect in that it contradicts a sentence at the end of Options 5, Section 4(a)(iii)(B)(5) which states, “If during the Route Timer any new interest arrives opposite the FIND Order that is marketable against the FIND Order such interest will trade against the FIND Order at the ABBO price unless the ABBO is improved to a price which crosses the FIND Order's already displayed price, in which case the incoming order will execute at the previous ABBO price as the away market crossed a displayed price.” The current last sentence within Options 5, Section 4(a)(iii)(B)(5) accurately describes the scenario for new interest arriving opposite the FIND Order that is marketable against the FIND Order.</P>
                <EXTRACT>
                    <FP>By way of example, assume a PHLX BBO: 1 × 1.25 and a CBOE BBO: 1.05 × 1.15.</FP>
                    <FP SOURCE="FP-1">If a FIND Order was entered to Buy 1 @1.20</FP>
                    <FP SOURCE="FP-1">FIND Order to buy is exposed on Phlx market data feeds @1.15 (then ABBO) and displayed on OPRA at 1.14</FP>
                    <FP SOURCE="FP-1">Route Timer begins</FP>
                    <FP SOURCE="FP-1">During Route Timer a Limit Order to sell 1 @1.15 arrives</FP>
                    <FP SOURCE="FP-1">CBOE adjusts its BBO to 1.05 × 1.10</FP>
                    <FP>The Route Timer ends and the Find Order will trade with the sell Limit Order at 1.15 in this example.</FP>
                </EXTRACT>
                <FP>The incorrect sentence provides that if the ABBO moves and crosses the FIND Order, any new interest that arrives opposite the FIND Order, which is marketable against the FIND Order, will trade at the FIND Order Price. This is incorrect because the new interest would trade against the FIND Order at the ABBO price, unless the ABBO is improved to a price which crosses the FIND Order's already displayed price, in which case the incoming order will execute at the previous ABBO price as the away market crossed a displayed price. The current sentence is incorrect because the FIND Order will not trade at the FIND Order price as noted in the first quoted sentence, rather it would execute at the previous ABBO price because the away market crossed a displayed price. The Exchange would display the order one MPV inferior to the away market offer, at 1.14. The FIND Order would execute at 1.15 which was the previous ABBO bid, as the away market crossed the displayed price of 1.14. Today, the System does not execute this trade at the FIND Order price as incorrectly noted. The Exchange would not trade-through the ABBO in this circumstance, Phlx would be bound by the Cboe's price in the above example. This specific rule text does not properly reflect the System operation. The rule text which provides that if the away market crossed Phlx's already displayed price the FIND Order will execute at the previous ABBO price, reflects the current System handling.</FP>
                <P>The Exchange proposes to correct the rule text by deleting the contradictory sentence. The remaining rule text will properly reflects the current System handling. Further, the Exchange proposes to relocate the correct sentence within Options 5, Section 4(a)(iii)(B)(5) to the same location as the deleted text to improve the flow of information presented within Options 5, Section 4(a)(iii)(B)(5).</P>
                <HD SOURCE="HD3">SRCH Orders</HD>
                <P>The Exchange proposes a similar correction to the SRCH Orders rule text. The Exchange proposes to similarly remove rule a contradictory sentence within current Options 5, Section 4(a)(iii)(C)(4) which provides, “If during the Route Timer, the ABBO moves and crosses the SRCH Order, any new interest arrives opposite the SRCH Order that is marketable against the SRCH Order will trade at the SRCH Order price.” Also, the Exchange proposes to replicate the last sentence of Options 5, Section 4(a)(iii)(C)(6), which contains the accurate scenario for new interest arriving opposite the SRCH Order that is marketable against the SRCH Order, to the same location as the deleted text within Options 5, Section 4(a)(iii)(C)(4) to improve the flow of information presented within that paragraph. The Exchange proposes to retain the exact sentence within Options 5, Section 4(a)(iii)(C)(6) because it applies equally to the scenarios described within Options 5, Section 4(a)(iii)(C)(6).</P>
                <HD SOURCE="HD3">2. Statutory Basis</HD>
                <P>
                    The Exchange believes that its proposal is consistent with Section 6(b) of the Act,
                    <SU>6</SU>
                    <FTREF/>
                     in general, and furthers the objectives of Section 6(b)(5) of the Act,
                    <SU>7</SU>
                    <FTREF/>
                     in particular, in that it is designed to promote just and equitable principles of trade and to protect investors and the public interest.
                </P>
                <FTNT>
                    <P>
                        <SU>6</SU>
                         15 U.S.C. 78f(b).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>7</SU>
                         15 U.S.C. 78f(b)(5).
                    </P>
                </FTNT>
                <HD SOURCE="HD3">Remote Specialist</HD>
                <P>
                    The Exchange's proposal to amend Options 2, Section 4, Obligations of Market Maker, to replace rule text currently within Options 2, Section 4(b)(2) with more precise rule text is consistent with the Act. The proposed new rule text is taken from the order approving the rule and more clearly explains the obligation of an RSQT who 
                    <PRTPAGE P="25502"/>
                    is also the Remote Lead Market Maker in a particular security. This rule change is non-substantive and will benefit market participants by bringing greater clarity to the rule text.
                </P>
                <HD SOURCE="HD3">Assistant Lead Market Maker</HD>
                <P>The Exchange's proposal to amend rule text within Options 2, Section 3, Allocation Application, Allocation, Reallocation, Transfer and Voluntary Resignation; Options 2, Section 11, Lead Market Maker Appointments; Options 8, Section 11, Floor Market Maker and Lead Market Maker Appointment; Options 8, Section 25, Floor Allocation; and Options 8, Section 39, Option Minor Rule Violations and Order and Decorum Regulations at E-2, Allocation, Time Stamping, Matching and Access to Matched Trades, to replace the term “assistant” with “back-up” is consistent with the Act. This amendment is non-substantive. The Exchange believes that the word “back-up” is a more precise term that emphasizes that the Market Maker must be able to take on all the duties of the Lead Market Maker and will benefit market participants by bringing greater clarity to the rule text. No obligations are being amended with respect to this role.</P>
                <HD SOURCE="HD3">Routing</HD>
                <P>With respect to the amendments to the Order Routing Rule, the Exchange's removal of two contradictory sentences is consistent with the Act because this will bring clarity and transparency to the rule. Further, relocating the correct rule text within the FIND and adding the correct rule text within SRCH rule language are non-substantive amendments which will improve the flow of information.</P>
                <HD SOURCE="HD2">B. Self-Regulatory Organization's Statement on Burden on Competition</HD>
                <P>The Exchange does not believe that the proposed rule change will impose any burden on competition not necessary or appropriate in furtherance of the purposes of the Act.</P>
                <HD SOURCE="HD3">Remote Specialist</HD>
                <P>The Exchange's proposal to amend Options 2, Section 4, Obligations of Market Maker” to replace rule text currently within Options 2, Section 4(b)(2) with more precise rule text does not impose an undue burden on competition. This non-substantive amendment more clearly explains the obligation of an RSQT who is also the Remote Lead Market Maker in a particular security.</P>
                <HD SOURCE="HD3">Assistant Lead Market Maker</HD>
                <P>The Exchange's proposal to amend rule text within Options 2, Section 3, Allocation Application, Allocation, Reallocation, Transfer and Voluntary Resignation; Options 2, Section 11, Lead Market Maker Appointments; Options 8, Section 11, Floor Market Maker and Lead Market Maker Appointment; Options 8, Section 25, Floor Allocation; and Options 8, Section 39, Option Minor Rule Violations and Order and Decorum Regulations at E-2, Allocation, Time Stamping, Matching and Access to Matched Trades, to replace the term “assistant” with “back-up” does not impose an undue burden on competition. This non-substantive amendment will bring greater clarity to the rule text. No obligations are being amended with respect to this role.</P>
                <HD SOURCE="HD3">Routing</HD>
                <P>The Exchange believes that deleting the two contradictory sentences will bring greater clarity to the rule. Further, relocating the correct rule text within the FIND and adding the correct rule text within the SRCH language is a non-substantive amendment which will improve the flow of information.</P>
                <HD SOURCE="HD2">2. Self-Regulatory Organization's Statement on Comments on the Proposed Rule Change Received From Members, Participants, or Others</HD>
                <P>No written comments were either solicited or received.</P>
                <HD SOURCE="HD1">III. Date of Effectiveness of the Proposed Rule Change and Timing for Commission Action</HD>
                <P>
                    Because the foregoing proposed rule change does not: (i) Significantly affect the protection of investors or the public interest; (ii) impose any significant burden on competition; and (iii) become operative for 30 days from the date on which it was filed, or such shorter time as the Commission may designate, it has become effective pursuant to Section 19(b)(3)(A)(iii) of the Act 
                    <SU>8</SU>
                    <FTREF/>
                     and subparagraph (f)(6) of Rule 19b-4 thereunder.
                    <SU>9</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>8</SU>
                         15 U.S.C. 78s(b)(3)(A)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>9</SU>
                         17 CFR 240.19b-4(f)(6). In addition, Rule 19b-4(f)(6) requires the Exchange to give the Commission written notice of its intent to file the proposed rule change, along with a brief description and text of the proposed rule change, at least five business days prior to the date of filing of the proposed rule change, or such shorter time as designated by the Commission. The Exchange has satisfied this requirement.
                    </P>
                </FTNT>
                <P>
                    A proposed rule change filed under Rule 19b-4(f)(6) 
                    <SU>10</SU>
                    <FTREF/>
                     normally does not become operative prior to 30 days after the date of the filing. However, pursuant to Rule 19b-4(f)(6)(iii),
                    <SU>11</SU>
                    <FTREF/>
                     the Commission may designate a shorter time if such action is consistent with the protection of investors and the public interest. The Exchange requests that the Commission waive the 30-day operative delay so that it may immediately remove incorrect and contradictory sentences in Phlx Options 5, Section 4, to bring greater clarity and transparency to the Phlx routing rules. The Commission believes that waiving the 30-day operative delay is consistent with the protection of investors and the public interest. Accordingly, the Commission waives the 30-day operative delay and designates the proposed rule change operative upon filing.
                    <SU>12</SU>
                    <FTREF/>
                </P>
                <FTNT>
                    <P>
                        <SU>10</SU>
                         17 CFR 240.19b-4(f)(6).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>11</SU>
                         17 CFR 240.19b-4(f)(6)(iii).
                    </P>
                </FTNT>
                <FTNT>
                    <P>
                        <SU>12</SU>
                         For purposes only of waiving the 30-day operative delay, the Commission has considered the proposed rule's impact on efficiency, competition, and capital formation. 
                        <E T="03">See</E>
                         15 U.S.C. 78c(f).
                    </P>
                </FTNT>
                <P>At any time within 60 days of the filing of the proposed rule change, the Commission summarily may temporarily suspend such rule change if it appears to the Commission that such action is necessary or appropriate in the public interest, for the protection of investors, or otherwise in furtherance of the purposes of the Act. If the Commission takes such action, the Commission shall institute proceedings to determine whether the proposed rule should be approved or disapproved.</P>
                <HD SOURCE="HD1">IV. Solicitation of Comments</HD>
                <P>Interested persons are invited to submit written data, views, and arguments concerning the foregoing, including whether the proposed rule change is consistent with the Act. Comments may be submitted by any of the following methods:</P>
                <HD SOURCE="HD2">Electronic Comments</HD>
                <P>
                    • Use the Commission's internet comment form (
                    <E T="03">http://www.sec.gov/rules/sro.shtml.</E>
                    ); or
                </P>
                <P>
                    • Send an email to 
                    <E T="03">rule-comments@sec.gov.</E>
                     Please include File Number SR-Phlx-2020-21 on the subject line.
                </P>
                <HD SOURCE="HD2">Paper Comments</HD>
                <P>• Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-1090.</P>
                <FP>
                    All submissions should refer to File Number SR-Phlx-2020-21. 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">
                        http://www.sec.gov/
                        <PRTPAGE P="25503"/>
                        rules/sro.shtml
                    </E>
                     ). Copies of the submission, all subsequent amendments, all written statements with respect to the proposed rule change that are filed with the Commission, and all written communications relating to the proposed rule change between the Commission and any person, other than those that may be withheld from the public in accordance with the provisions of 5 U.S.C. 552, will be available for website viewing and printing in the Commission's Public Reference Room, 100 F Street NE, Washington, DC 20549, on official business days between the hours of 10:00 a.m. and 3:00 p.m. Copies of the filing also will be available for inspection and copying at the principal office of the Exchange. All comments received will be posted without change. Persons submitting comments are cautioned that we do not redact or edit personal identifying information from comment submissions. You should submit only information that you wish to make available publicly. All submissions should refer to File Number SR-Phlx-2020-21 and should be submitted on or before May 22, 2020.
                </FP>
                <SIG>
                    <P>
                        For the Commission, by the Division of Trading and Markets, pursuant to delegated authority.
                        <SU>13</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             17 CFR 200.30-3(a)(12).
                        </P>
                    </FTNT>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09249 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                <DEPDOC>[SEC File No. 270-137, OMB Control No. 3235-0145]</DEPDOC>
                <SUBJECT>Proposed Collection; Comment Request</SUBJECT>
                <FP SOURCE="FP-1">
                    <E T="03">Upon Written Request Copies Available From:</E>
                     Securities and Exchange Commission, Office of FOIA Services, 100 F Street NE, Washington, DC 20549-2736
                </FP>
                <EXTRACT>
                    <FP SOURCE="FP-2">
                        <E T="03">Extension:</E>
                    </FP>
                    <FP SOURCE="FP1-2">Regulation 13D and Regulation 13G; Schedule 13D and Schedule 13G</FP>
                </EXTRACT>
                <P>
                    Notice is hereby given that, pursuant to the Paperwork Reduction Act of 1995 (44 U.S.C. 3501 
                    <E T="03">et seq.</E>
                    ), the Securities and Exchange Commission (“Commission”) is soliciting comments on the collection of information summarized below. The Commission plans to submit this existing collection of information to the office of Management and Budget for extension and approval.
                </P>
                <P>
                    Schedules 13D and 13G (17 CFR 240.13d-101 and 240.13d-102) are filed pursuant to Sections 13(d) and 13(g) of the Securities Exchange Act of 1934 (15 U.S.C. 78m(d) and 78m(g)) (“Exchange Act”) and Regulations 13D and 13G (17 CFR 240.13d-1—240.13d-7) thereunder to report beneficial ownership of equity securities registered under Section 12 (15 U.S.C. 78
                    <E T="03">l</E>
                    ) of the Exchange Act. Regulations 13D and 13G provide investors, the subject issuers, and market participants with information about the accumulation of equity securities that may have the potential to change or influence control of an issuer. Schedules 13D and 13G are filed by persons, including small entities, to report their ownership of more than 5% of a class of equity securities registered under Section 12. We estimate that it takes approximately 14.5 burden hours to prepare a Schedule 13D and it is filed by approximately 1,508 filers. In addition, we estimate that 25% of the 14.5 hours per response (3.625 hours per response) is carried internally by the filer for a total annual reporting burden of 5,467 hours (3.625 hours per response × 1, 508 responses).
                </P>
                <P>We estimate that it takes approximately 12.4 hours per response to prepare a Schedule 13G and it is filed by approximately 7,079 filers. In addition, we estimate 25% of the 12.4 hours per response (3.1 hours per response) is carried internally by the filer for a total annual reporting burden of 21,945 hours (3.1 hours per response × 7,079 responses)</P>
                <P>The Schedules combined are filed by 8,587 filers and they take approximately 12.769 hours per response. In addition, we estimate 25% of the 12.769 (3.19225 hours per response) is carried internally by the filer for a total annual reporting burden of 27,412 hours (3.1923 hours per response × 8,587 responses). The estimated burden hours are made solely for purposes of the Paperwork Reduction Act and are not derived from a comprehensive or even a representative survey or study of the costs of Commission rules and forms.</P>
                <P>Written comments are invited on: (a) Whether this 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 burden of the collection of information; (c) ways to enhance the quality, utility, and clarity of the information collected; and (d) ways to minimize the burden of the collection of information on respondents, including through the use of automated collection techniques or other forms of information technology. Consideration will be given to comments and suggestions submitted in writing within 60 days of this publication.</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 control number.</P>
                <P>
                    Please direct your written comments to David Bottom, Director/Chief Information Officer, Securities and Exchange Commission, c/o Cynthia Roscoe, 100 F Street, NE, Washington DC. 20549 or send an email to: 
                    <E T="03">PRA_Mailbox@sec.gov.</E>
                </P>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <NAME>J. Matthew DeLesDernier,</NAME>
                    <TITLE>Assistant Secretary.</TITLE>
                </SIG>
            </PREAMB>
            <FRDOC>[FR Doc. 2020-09294 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 8011-01-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">SMALL BUSINESS ADMINISTRATION</AGENCY>
                <DEPDOC>[Disaster Declaration # 16257 and # 16258; North Dakota Disaster Number ND-00074]</DEPDOC>
                <SUBJECT>Presidential Declaration Amendment of a Major Disaster for Public Assistance Only for the State of North Dakota</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 North Dakota (FEMA-4475-DR), dated 01/21/2020.</P>
                    <P>Incident: Flooding.</P>
                    <P>Incident Period: 10/09/2019 through 10/26/2019.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Issued on 04/24/2020.</P>
                    <P>Physical Loan Application Deadline Date: 03/23/2020.</P>
                    <P>Economic Injury (EIDL) Loan Application Deadline Date: 10/21/2020.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>Submit completed loan applications to: U.S. Small Business Administration, Processing and Disbursement Center, 14925 Kingsport Road, Fort Worth, TX 76155.</P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>A. Escobar, Office of Disaster Assistance, 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 North Dakota, dated 01/21/2020, is hereby amended to include the following areas as adversely affected by the disaster.</P>
                <PRTPAGE P="25504"/>
                <FP SOURCE="FP-2">Primary Counties: Dickey, Emmons.</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>Cynthia Pitts,</NAME>
                    <TITLE>Acting Associate Administrator for Disaster Assistance.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09340 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 8026-03-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Highway Administration</SUBAGY>
                <SUBJECT>Notice of Final Federal Agency Actions on Proposed Highway in Utah</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Utah Department of Transportation (UDOT); Federal Highway Administration (FHWA), Department of Transportation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of limitations on claims for judicial review of actions by UDOT and other Federal agencies.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FHWA, on behalf of UDOT, is issuing this notice to announce actions taken by UDOT that are final Federal agency actions. The final agency actions relate to design modifications to a planned and approved highway project, the West Davis Corridor project in Davis County, Utah, and more specifically to UDOT's re-evaluation of the Environmental Impact Statement and Section 4(f) Evaluation for the project in light of design modifications to the system interchange by which the West Davis Corridor project (State Route 67) will connect with Interstate 15 (I-15) and Legacy Parkway. Those actions grant licenses, permits and/or approvals for the project.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        By this notice, FHWA, on behalf of UDOT, is advising the public of final agency actions subject to 23 U.S.C. 139(
                        <E T="03">l</E>
                        )(1). A claim seeking judicial review of these Federal agency actions on the highway project will be barred unless the claim is filed on or before September 28, 2020. If the Federal law that authorizes judicial review of a claim provides a time period of less than 150 days for filing such claim, then that shorter time period still applies.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Elisa Albury, Environmental Program Manager, UDOT Environmental Services, P.O. Box 143600, Salt Lake City, UT 84114; (801)-965-4000; email: 
                        <E T="03">ealbury@utah.gov.</E>
                         UDOT's normal business hours are 8 a.m. to 5 p.m. (Mountain Time Zone), Monday through Friday, except State and Federal holidays.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    Effective January 17, 2017, FHWA assigned to UDOT certain responsibilities of FHWA for environmental review, consultation, and other actions required by applicable Federal environmental laws and regulations for highway projects in Utah, pursuant to 23 U.S.C. 327. FHWA maintained responsibility of the environmental review process of the West Davis Corridor project until its issuance of a Record of Decision (ROD). UDOT is responsible for conducting any additional environmental reviews (including re-evaluations) that are required for the West Davis Corridor project following the issuance of the ROD. Actions taken by UDOT on FHWA's behalf pursuant to 23 U.S.C. 327 constitute Federal agency actions for purposes of Federal law. Notice is hereby given that UDOT has taken final agency actions subject to 23 U.S.C. 139(
                    <E T="03">l</E>
                    )(1) by issuing licenses, permits, and approvals for a modification of the West Davis Corridor project in the State of Utah.
                </P>
                <P>
                    On June 23, 2017, FHWA approved the Final Environmental Impact Statement and Section 4(f) Evaluation (EIS) for the West Davis Corridor Project, and on September 29, 2017 FHWA issued a ROD approving the project. On October 6, 2017, FHWA published notice of the EIS and ROD in the 
                    <E T="04">Federal Register</E>
                     triggering the 150-day statute of limitations under 23 U.S.C. 139(l)(1) for the project. The project is included in UDOT's adopted 2020-2025 State Transportation Improvement Plan (STIP) as project number 11268 and is scheduled for right of way acquisition and construction to begin in fiscal year 2020, being let as a design-build contract. The project is also included in the Wasatch Front Regional Council's 
                    <E T="03">2019—2050 Regional Transportation Plan.</E>
                </P>
                <P>UDOT has now updated the design of the system interchange at the south end of the project by which the West Davis Corridor project (State Route 67) will interconnect with I-15 and Legacy Parkway to accommodate a planned widening of I-15 by one lane in each direction. With the planned widening of I-15, it was not possible to have the ramp connections as identified in the Selected Alternative in the EIS and ROD without either 1) having substantial impacts to the residential areas of Farmington and Centerville east of the Frontage Road or 2) relocating the Union Pacific Railroad tracks. To minimize costs and impacts while accommodating a planned additional lane in each direction on I-15, the design of the system interchange described in the Selected Alternative has been refined to have the ramp from southbound West Davis Corridor to southbound I-15 parallel Legacy Parkway for approximately 0.3 mile and then cross Legacy Parkway and the Union Pacific Railroad tracks before merging onto I-15 near 1800 North in Centerville (approximately 0.7 mile south of the EIS Selected Alternative's southbound I-15 merge). The design of the Legacy Parkway Trail in the area of the system interchange has also been refined.</P>
                <P>
                    These changes to the Selected Alternative are referred to as the Refined Selected Alternative and are the subject of, and are described in more detail in, UDOT's April 8, 2020 EIS re-evaluation (UDOT Project Number S-0067(14)0, S.R. 67, West Davis Corridor; WDC/I-15/Legacy Parkway System Interchange in Davis County, Utah (PIN 7176) 
                    <E T="03">Environmental Impact Statement Re-evaluation #13</E>
                    )(EIS Re-evaluation).
                </P>
                <P>The actions by UDOT, and the laws under which such actions were taken, are described in the EIS Re-evaluation and other documents in the UDOT project records. The EIS Re-evaluation is available for review by contacting UDOT at the address provided above. This notice applies to the EIS Re-evaluation, the Section 4(f) determination, the NHPA Section 106 review, the Endangered Species Act determination, the noise review and noise abatement determination, and all other UDOT and federal agency decisions and other actions with respect to the EIS Re-evaluation and the Refined Selected Alternative as of the issuance date of this notice and all laws under which such actions were taken, including but not limited to the following laws (including their implementing regulations):</P>
                <P>
                    1. 
                    <E T="03">General:</E>
                     National Environmental Policy Act [42 U.S.C. 4321-4351]; Federal-Aid Highway Act [23 U.S.C. 109 and 23 U.S.C. 128]; MAP-21, the Moving Ahead for Progress in the 21st Century Act [Pub. L. 112-141].
                </P>
                <P>
                    2. 
                    <E T="03">Air:</E>
                     Clean Air Act [42 U.S.C. 7401-7671(q)].
                </P>
                <P>
                    3. 
                    <E T="03">Land:</E>
                     Section 4(f) of the Department of Transportation Act of 1966 [49 U.S.C. 303]; Landscaping and Scenic Enhancement (Wildflowers) [23 U.S.C. 319].
                </P>
                <P>
                    4. 
                    <E T="03">Wildlife:</E>
                     Endangered Species Act [16 U.S.C. 1531-1544 and Section 1536], Fish and Wildlife Coordination Act [16 U.S.C. 661-667(d)]; Migratory Bird Treaty Act [16 U.S.C. 703-712]; The Bald and Golden Eagle Protection Act [16 U.S.C. 668].
                </P>
                <P>
                    5. 
                    <E T="03">Historic and Cultural Resources:</E>
                     Section 106 of the National Historic Preservation Act of 1966, as amended 
                    <PRTPAGE P="25505"/>
                    [16 U.S.C. 470(f) 
                    <E T="03">et seq.</E>
                    ]; Archeological Resources Protection Act of 1977 [16 U.S.C. 470(aa)-470(ll)]; Archeological and Historic Preservation Act [16 U.S.C. 469-469(c)]; Native American Grave Protection and Repatriation Act (NAGPRA) [25 U.S.C. 3001-3013].
                </P>
                <P>
                    6. 
                    <E T="03">Social and Economic:</E>
                     Civil Rights Act of 1964 [42 U.S.C. 2000(d)-2000(d)(1)]; American Indian Religious Freedom Act [42 U.S.C. 1996]; Farmland Protection Policy Act (FPPA) [7 U.S.C. 4201-4209].
                </P>
                <P>
                    7. 
                    <E T="03">Wetlands and Water Resources:</E>
                     Clean Water Act (Section 404, Section 401, Section 319) [33 U.S.C. 1251-1377]; Coastal Barrier Resources Act [16 U.S.C. 3501-3510]; Coastal Zone Management Act [16 U.S.C. 1451-1465]; Land and Water Conservation Fund (LWCF) [16 U.S.C. 4601-4604]; Safe Drinking Water Act (SDWA) [42 U.S.C. 300(f) -300(j)(6)]; Rivers and Harbors Act of 1899 [33 U.S.C. 401-406]; Wild and Scenic Rivers Act [16 U.S.C. 1271-1287]; Emergency Wetlands Resources Act [16 U.S.C. 3921, 3931]; TEA-21 Wetlands Mitigation [23 U.S.C. 103(b)(6)(M, 133(b)(11)]; Flood Disaster Protection Act [42 U.S.C. 4001-4128].
                </P>
                <P>
                    8. 
                    <E T="03">Hazardous Materials:</E>
                     Comprehensive Environmental Response, Compensation, and Liability Act [42 U.S.C. 9601-9675]; Superfund Amendments and Reauthorization Act of 1986; Resource Conservation and Recovery Act [42 U.S.C. 6901-6992(k)].
                </P>
                <P>
                    9. 
                    <E T="03">Noise:</E>
                     Federal-Aid Highway Act of 1970, Public Law 91-605 [84 Stat. 1713]; [23 U.S.C. 109(h) &amp; (i)].
                </P>
                <P>
                    10. 
                    <E T="03">Executive Orders:</E>
                     E.O. 11990 Protection of Wetlands; E.O. 11988 Floodplain Management; E.O. 12898, Federal Actions to Address Environmental Justice in Minority Populations and Low-Income Populations; E.O. 11593 Protection and Enhancement of Cultural Resources; E.O. 13287 Preserve America; E.O. 13175 Consultation and Coordination with Indian Tribal Governments; E.O. 11514 Protection and Enhancement of Environmental Quality; E.O. 13112 Invasive Species.
                </P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Program Number 20.205, Highway Planning and Construction. The regulations implementing Executive Order 12372 regarding intergovernmental consultation on Federal programs and activities apply to this program.)</FP>
                    <FP>
                        (Authority: 23 U.S.C. 139 (
                        <E T="03">l</E>
                        )(1))
                    </FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: April 24, 2020.</DATED>
                    <NAME>Ivan Marrero,</NAME>
                    <TITLE>Division Administrator, Federal Highway Administration, Salt Lake City, Utah.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09283 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-RY-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Highway Administration</SUBAGY>
                <SUBJECT>Notice of Availability of the Revised Record of Decision for the Mountain View Corridor Project in Utah and Final Federal Agency Actions</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Utah Department of Transportation (UDOT), Federal Highway Administration (FHWA), Department of Transportation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of availability and notice of limitations on claims for judicial review of actions by UDOT and other Federal agencies.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>The FHWA, on behalf of UDOT, is issuing this notice to announce the availability of the Revised Record of Decision (ROD) for the Mountain View Corridor Project in Salt Lake and Utah counties, Utah. In addition, this notice is being issued to announce actions taken by UDOT that are final Federal agency actions related to the project referenced above. Those actions grant licenses, permits and/or approvals for the project. The Revised ROD provides details on the Selected Alternative for the proposed improvements.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>
                        This decision became operative on January 15, 2020. By this notice, FHWA, on behalf of UDOT, is advising the public of final agency actions subject to 23 U.S.C. 139(
                        <E T="03">l</E>
                        )(1). A claim seeking judicial review of the Federal agency actions on the highway project will be barred unless the claim is filed on or before September 28, 2020. If the Federal law that authorizes judicial review of a claim provides a time period of less than 150 days for filing such claim, then that shorter time period still applies.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Elisa Albury, Environmental Program Manager, UDOT Environmental Services, PO Box 143600, Salt Lake City, UT 84114; (801) 834-5284; email: 
                        <E T="03">ealbury@utah.gov.</E>
                         UDOT's normal business hours are 8 a.m. to 5 p.m. (Mountain Time Zone), Monday through Friday, except State and Federal holidays.
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    The environmental review, consultation, and other actions required by applicable Federal environmental laws for this action are being, or have been, carried out by UDOT pursuant to 23 U.S.C. 327 and a Memorandum of Understanding (MOU) dated January 17, 2017, and executed by FHWA and UDOT. Under the MOU, UDOT is responsible for conducting any additional environmental review that is required for projects that were approved by FHWA prior to execution of the MOU. The Revised ROD was processed in accordance with the MOU, and UDOT is the agency responsible for approving the Revised ROD. Actions taken by UDOT on FHWA's behalf pursuant to 23 U.S.C. 327 and the MOU constitute Federal agency actions for purposes of Federal law. Notice is hereby given that UDOT has taken final agency actions subject to 23 U.S.C. 139(
                    <E T="03">l</E>
                    )(1) by issuing licenses, permits, and/or approvals for the Mountain View Corridor Project in the State of Utah.
                </P>
                <P>A Final Environmental Impact Statement (EIS) and Section 4(f) Evaluation for the Mountain View Corridor Project was completed in September 2008 and approved through the issuance of a ROD on November 17, 2008, by the FHWA. The overall Selected Alternative in the 2008 ROD included both a roadway alternative (the 5800 West Freeway Alternative) and a transit alternative (the 5600 West Transit Alternative with Dedicated Right-of-Way Option). Since the original ROD was issued, this overall Selected Alternative has been refined and is referred to as the Refined Selected Alternative.</P>
                <P>The 2008 ROD committed to a phased implementation approach for Selected Alternative. The roadway component and the transit component of the Selected Alternative each consisted of three phases. Under the phased implementation approach as defined in the 2008 ROD, UDOT committed that it would not proceed with Phase 2 of the roadway component (except in a few defined areas) until Phase 1 of the transit component was complete and in revenue operation. As described in the Final EIS and the 2008 ROD, the transit system would have started as Bus Rapid Transit (BRT) in Phase 1 and would have been converted to rail transit in Phase 3.</P>
                <P>
                    The Refined Selected Alternative modifies Phase 1 of the transit component of the 2008 Selected Alternative (5600 West Transit Alternative with Dedicated Right-of-Way Option). Instead of BRT service, the Phase 1 transit service would include construction of Express Bus transit service over a longer (29-mile) corridor from the Old Bingham Highway TRAX station following 5600 West to downtown Salt Lake City including service to the Salt Lake City International Airport. The service would include operational improvements as well as enhanced stops with associated park-and-ride lots. UDOT would acquire the necessary right-of-way for the 
                    <PRTPAGE P="25506"/>
                    service as required for Phase 1 transit to be in revenue operation.
                </P>
                <P>UDOT prepared an EIS Re-evaluation for the Refined Selected Alternative's proposed changes to the Phase 1 transit elements of the 2008 ROD's Selected Alternative. A 30-day public review and comment period on the EIS Re-evaluation was provided from April 17 to May 16, 2019. During the comment period, UDOT received 26 comments. The comments included support for the changes to Phase 1 transit, opposition to transit projects, requests for additional stops on the Phase 1 transit's Express Bus, requests for additional transit improvements or other transit projects, and questions about the Phase 1 transit's Express Bus. The decision to approve the Refined Selected Alternative for the MVC Project was based on UDOT's review of the entire record including the 2008 MVC Final EIS and the 2019 EIS Re-evaluation as well as technical reports, correspondence, and other information developed as part of the environmental review process for the project.</P>
                <P>
                    The actions by UDOT, and the laws under which such actions were taken, are described in the EIS Re-evaluation approved on August 26, 2019, the Revised ROD approved on January 15, 2020, and other documents in the UDOT project records. The EIS Re-evaluation and Revised ROD are available for review by contacting UDOT at the address provided above. In addition, these documents can be viewed and downloaded from the project website at 
                    <E T="03">http://www.udot.utah.gov/mountainview.</E>
                     This notice applies to the EIS Re-evaluation, the Revised ROD, and all other UDOT and federal agency decisions and other actions with respect to the project as of the issuance date of this notice and all laws under which such actions were taken, including but not limited to the following laws (including their implementing regulations):
                </P>
                <P>
                    1. 
                    <E T="03">General:</E>
                     National Environmental Policy Act [42 U.S.C. 4321-4351]; Federal-Aid Highway Act [23 U.S.C. 109 and 23 U.S.C. 128]; MAP-21, the Moving Ahead for Progress in the 21st Century Act [Pub. L. 112-141].
                </P>
                <P>
                    2. 
                    <E T="03">Air:</E>
                     Clean Air Act [42 U.S.C. 7401-7671(q)].
                </P>
                <P>
                    3. 
                    <E T="03">Land:</E>
                     Section 4(f) of the Department of Transportation Act of 1966 [49 U.S.C. 303]; Landscaping and Scenic Enhancement (Wildflowers) [23 U.S.C. 319].
                </P>
                <P>
                    4. 
                    <E T="03">Wildlife:</E>
                     Endangered Species Act [16 U.S.C. 1531-1544 and Section 1536], Fish and Wildlife Coordination Act [16 U.S.C. 661-667(d)]; Migratory Bird Treaty Act [16 U.S.C. 703-712]; The Bald and Golden Eagle Protection Act [16 U.S.C. 668].
                </P>
                <P>
                    5. 
                    <E T="03">Historic and Cultural Resources:</E>
                     Section 106 of the National Historic Preservation Act of 1966, as amended [16 U.S.C. 470(f) 
                    <E T="03">et seq.</E>
                    ]; Archeological Resources Protection Act of 1977 [16 U.S.C. 470(aa)-470(ll)]; Archeological and Historic Preservation Act [16 U.S.C. 469-469(c)]; Native American Grave Protection and Repatriation Act (NAGPRA) [25 U.S.C. 3001-3013].
                </P>
                <P>
                    6. 
                    <E T="03">Social and Economic:</E>
                     Civil Rights Act of 1964 [42 U.S.C. 2000(d)-2000(d)(1)]; American Indian Religious Freedom Act [42 U.S.C. 1996]; Farmland Protection Policy Act (FPPA) [7 U.S.C. 4201-4209].
                </P>
                <P>
                    7. 
                    <E T="03">Wetlands and Water Resources:</E>
                     Clean Water Act (Section 404, Section 401, Section 319) [33 U.S.C. 1251-1377]; Coastal Barrier Resources Act [16 U.S.C. 3501-3510]; Coastal Zone Management Act [16 U.S.C. 1451-1465]; Land and Water Conservation Fund (LWCF) [16 U.S.C. 4601-4604]; Safe Drinking Water Act (SDWA) [42 U.S.C. 300(f) -300(j)(6)]; Rivers and Harbors Act of 1899 [33 U.S.C. 401-406]; Wild and Scenic Rivers Act [16 U.S.C. 1271-1287]; Emergency Wetlands Resources Act [16 U.S.C. 3921, 3931]; TEA-21 Wetlands Mitigation [23 U.S.C. 103(b)(6)(M, 133(b)(11)]; Flood Disaster Protection Act [42 U.S.C. 4001-4128].
                </P>
                <P>
                    8. 
                    <E T="03">Hazardous Materials:</E>
                     Comprehensive Environmental Response, Compensation, and Liability Act [42 U.S.C. 9601-9675]; Superfund Amendments and Reauthorization Act of 1986; Resource Conservation and Recovery Act [42 U.S.C. 6901-6992(k)].
                </P>
                <P>
                    9. 
                    <E T="03">Noise:</E>
                     Federal-Aid Highway Act of 1970, Public Law 91-605 [84 Stat. 1713]; [23 U.S.C. 109(h) &amp; (i)].
                </P>
                <P>
                    10. 
                    <E T="03">Executive Orders:</E>
                     E.O. 11990 Protection of Wetlands; E.O. 11988 Floodplain Management; E.O. 12898, Federal Actions to Address Environmental Justice in Minority Populations and Low-Income Populations; E.O. 11593 Protection and Enhancement of Cultural Resources; E.O. 13287 Preserve America; E.O. 13175 Consultation and Coordination with Indian Tribal Governments; E.O. 11514 Protection and Enhancement of Environmental Quality; E.O. 13112 Invasive Species.
                </P>
                <EXTRACT>
                    <FP>(Catalog of Federal Domestic Assistance Program Number 20.205, Highway Planning and Construction. The regulations implementing Executive Order 12372 regarding intergovernmental consultation on Federal programs and activities apply to this program.)</FP>
                </EXTRACT>
                <AUTH>
                    <HD SOURCE="HED">Authority:</HD>
                    <P>
                        23 U.S.C. 139 (
                        <E T="03">l</E>
                        )(1).
                    </P>
                </AUTH>
                <SIG>
                    <DATED>Dated: April 24, 2020.</DATED>
                    <NAME>Ivan Marrero,</NAME>
                    <TITLE>Division Administrator, Federal Highway Administration, Salt Lake City, Utah.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09282 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-RY-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Federal Railroad Administration</SUBAGY>
                <DEPDOC>[Docket No. FRA-2020-0031]</DEPDOC>
                <SUBJECT>Program Approval: Union Pacific Railroad</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 approval.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        FRA is issuing this notice to explain its rationale for approving a Union Pacific Railroad (UP) petition for a Test Program designed to test track inspection technologies (
                        <E T="03">i.e.,</E>
                         autonomous track geometry measurement systems) and new operational approaches to track inspections and its rationale for granting a limited, temporary suspension of a substantive FRA rule that is necessary to facilitate the conduct of the Test Program.
                    </P>
                </SUM>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Yu-Jiang Zhang, Staff Director, Track Division, Office of Railroad Safety, FRA, 1200 New Jersey Avenue SE, Washington, DC 20590, telephone (202) 493-6460 or email 
                        <E T="03">yujiang.zhang@</E>
                        <E T="03">dot.gov;</E>
                         Aaron Moore, Attorney, Office of Chief Counsel, FRA, 1200 New Jersey Avenue SE, Washington, DC 20590, telephone (202) 493-7009 or email 
                        <E T="03">aaron.moore@dot.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P>
                    On March 23, 2020, UP petitioned FRA under Title 49 Code of Federal Regulations (CFR) Section 211.51 to suspend certain requirements of FRA's track safety regulations to conduct a program to test new track inspection technologies (
                    <E T="03">i.e.,</E>
                     autonomous track geometry measurement systems) and new operational approaches to track inspections. UP also submitted a written Test Program providing a description of the proposed tests and the geographic scope of the testing territory.
                </P>
                <P>The Test Program specifies that the tests will be conducted on approximately 1,700 miles of main line track in 5 subdivisions of UP's SPSCL and Sunset routes.</P>
                <P>
                    The Test Program is designed to test autonomous track geometry measurement systems and decreased 
                    <PRTPAGE P="25507"/>
                    manual visual inspections as an alternative to FRA's inspection frequency requirements. UP indicates that it will continue to use other inspection technologies during the Test Program, including: (1) Vehicle Track Interaction monitoring systems; (2) ultrasonic rail inspection systems; and (3) optical joint bar inspection systems. The Test Program will be carried out in two separate phases over the course of 12 months, as detailed in Exhibit C of the Test Program (available for review at 
                    <E T="03">www.regulations.gov</E>
                     (docket number FRA-2020-0031)).
                </P>
                <P>
                    After review and analysis of UP's petition for a Test Program, subject to certain conditions designed to ensure safety, FRA approved UP's Test Program and suspended the requirements of 49 CFR 213.233(c) as necessary to carry out the Test Program. A copy of FRA's letter approving UP's Test Program and granting the requested limited temporary suspension of 49 CFR 213.233(c), as well as a copy of the Test Program, is available in docket number FRA-2020-0031 at 
                    <E T="03">www.regulations.gov.</E>
                     FRA's letter approving UP's Test Program and granting the requested limited temporary suspension of certain regulations specifically details the conditions UP will need to undertake during the Test Program. As required by 49 CFR 211.51(c), FRA is providing this explanatory statement describing the Test Program.
                </P>
                <P>As explained more fully in its approval letter, FRA finds that the temporary, limited suspension of 49 CFR 213.233(c) is necessary to conduct the approved Test Program, which is specifically designed to evaluate the effectiveness of new automated track inspection technologies and operational methods. Furthermore, FRA also finds that the scope and application of the granted suspension of 49 CFR 213.233(c) as applied to the Test Program are limited to that necessary to conduct the Test Program. Finally, FRA's approval letter outlines the conditions of the Test Program that will ensure standards sufficient to assure safety.</P>
                <SIG>
                    <P>Issued in Washington, DC.</P>
                    <NAME>John Karl Alexy,</NAME>
                    <TITLE>Associate Administrator for Railroad Safety, Chief Safety Officer.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09281 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-06-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="S">DEPARTMENT OF TRANSPORTATION</AGENCY>
                <SUBAGY>Maritime Administration</SUBAGY>
                <DEPDOC>[Docket No. MARAD-2019-0011]</DEPDOC>
                <SUBJECT>Deepwater Port License Application: SPOT Terminal Services LLC; Correction and Comment Period Extension</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Maritime Administration, Department of Transportation.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice of Correction and Extension of the Public Comment Period.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>
                        By 
                        <E T="04">Federal Register</E>
                         notice of Friday, February 7, 2020, titled 
                        <E T="03">Deepwater Port License Application: SPOT Terminal Services LLC,</E>
                         the U.S. Coast Guard (USCG), in coordination with the Maritime Administration (MARAD), announced the availability of the Draft Environmental Impact Statement (DEIS) for the SPOT Terminal Services LLC (SPOT) deepwater port license application for the export of oil from the United States to nations abroad. Publication of that notice began a 45-day public comment period, which began on February 7, 2020 and ended on March 23, 2020. On April 28, 2020, the same notice was inadvertently published in the 
                        <E T="04">Federal Register</E>
                        . Additionally, both notices announced the date and location of an informational open house and public meeting that was held in Lake Jackson, Texas, on February 26, 2020, from 6:00 p.m. to 8:00 p.m., and was preceded by an open house from 4:00 p.m. to 6:00 p.m. However, nationwide impacts of the public health emergency under section 319 of the Public Health Services Act in response to Coronavirus Disease 2019 (COVID-19), the President's declaration of a national emergency due to the COVID-19 outbreak, and state and local actions in response to COVID-19, have impacted the public's ability to assemble and provide feedback on the SPOT deepwater port license application DEIS. Therefore, this notice supplants the April 28, 2020 notice and extends the public comment period for the SPOT DEIS 30-days from the publication date of this 
                        <E T="04">Federal Register</E>
                         notice.
                    </P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</HD>
                    <P>Comments or related material on the SPOT deepwater port license application must be received 30 days from the date of this notice.</P>
                </DATES>
                <ADD>
                    <HD SOURCE="HED">ADDRESSES:</HD>
                    <P>
                        The public docket for the SPOT deepwater port license application is maintained by the U.S. Department of Transportation, Docket Management Facility, West Building, Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590. The license application is available for viewing at the 
                        <E T="03">Regulations.gov</E>
                         website: 
                        <E T="03">http://www.regulations.gov</E>
                         under docket number MARAD-2019-0011.
                    </P>
                    <P>
                        We encourage you to submit comments electronically through the Federal eRulemaking Portal at 
                        <E T="03">http://www.regulations.gov.</E>
                         If you submit your comments electronically, it is not necessary to also submit a hard copy. If you cannot submit material using 
                        <E T="03">http://www.regulations.gov,</E>
                         please contact either Mr. William Nabach, USCG or Yvette Fields, MARAD, as listed in the following 
                        <E T="02">FOR FURTHER INFORMATION CONTACT</E>
                         section of this document, which also provides alternate instructions for submitting written comments. Additionally, if you go to the online docket and sign up for email alerts, you will be notified when comments are posted. Anonymous comments will be accepted. All comments received will be posted without change to 
                        <E T="03">http://www.regulations.gov</E>
                         and will include any personal information you have provided. The Federal Docket Management Facility's telephone number is 202-366-9317 or 202-366-9826, the fax number is 202-493-2251.
                    </P>
                </ADD>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Mr. William Nabach, Project Manager, USCG, telephone: 202-372-1437, email: 
                        <E T="03">William.A.Nabach2@uscg.mil;</E>
                         or Ms. Yvette Fields, Director, Office of Deepwater Port Licensing and Port Conveyance, MARAD, telephone: 202-366-0926, email: 
                        <E T="03">Yvette.Fields@dot.gov.</E>
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <HD SOURCE="HD1">Request for Comments</HD>
                <P>We request public comment on this proposal. The comments may relate to, but are not limited to, the environmental impact of the proposed action. All comments will be accepted. You may submit comments directly to the Federal Docket Management Facility during the public comment period (see Dates). We will consider all comments and material received during the extended scoping period.</P>
                <P>
                    The license application, comments and associated documentation, as well as the draft and final EISs (when published), are available for viewing at the Federal Docket Management System (FDMS) website: 
                    <E T="03">http://www.regulations.gov</E>
                     under docket number MARAD-2019-0011.
                </P>
                <P>Public comment submissions should include:</P>
                <P>
                    • Docket number MARAD-2019-0011.
                    <PRTPAGE P="25508"/>
                </P>
                <P>• Your name and address.</P>
                <P>Submit comments or material using only one of the following methods:</P>
                <P>
                    • Electronically (preferred for processing) to the Federal Docket Management System (FDMS) website: 
                    <E T="03">http://www.regulations.gov</E>
                     under docket number MARAD-2019-0011.
                </P>
                <P>• By mail to the Federal Docket Management Facility (MARAD-2019-0011, U.S. Department of Transportation, West Building, Ground Floor, Room W12-140, 1200 New Jersey Avenue SE, Washington, DC 20590-0001.</P>
                <P>• Personal deliveries are currently not being accepted due to the COVID-19 public health emergency.</P>
                <P>• By fax to the Federal Docket Management Facility at 202-493-2251.</P>
                <P>
                    Faxed or mail submissions must be unbound, no larger than 8
                    <FR>1/2</FR>
                     by 11 inches and suitable for copying and electronic scanning. The format of electronic submissions should also be no larger than 8
                    <FR>1/2</FR>
                     by 11 inches. If you mail your submission and want to know when it reaches the Federal Docket Management Facility, please include a stamped, self-addressed postcard or envelope.
                </P>
                <P>
                    Regardless of the method used for submitting comments, all submissions will be posted, without change, to the FDMS website (
                    <E T="03">http://www.regulations.gov</E>
                    ) and will include any personal information you provide. Therefore, submitting this information to the docket makes it public. You may wish to read the Privacy and Use Notice that is available on the FDMS website and the Department of Transportation Privacy Act Notice that appeared in the 
                    <E T="04">Federal Register</E>
                     on April 11, 2000 (65 FR 19477), see Privacy Act. You may view docket submissions at the Federal Docket Management Facility or electronically on the FDMS website.
                </P>
                <HD SOURCE="HD1">Privacy Act</HD>
                <P>
                    The electronic form of all comments received into the FDMS can be searched by the name of the individual submitting the comment (or signing the comment, if submitted on behalf of an association, business, labor union, etc.). The Department of Transportation Privacy Act Statement can be viewed in the 
                    <E T="04">Federal Register</E>
                     published on April 11, 2000 (Volume 65, Number 70, pages 19477-78) or by visiting 
                    <E T="03">http://www.regulations.gov.</E>
                </P>
                <EXTRACT>
                    <FP>
                        (Authority: 33 U.S.C. 1501, 
                        <E T="03">et seq.,</E>
                         49 CFR 1.93(h)).
                    </FP>
                </EXTRACT>
                <SIG>
                    <DATED>Dated: April 28, 2020.</DATED>
                    <P>By Order of the Maritime Administrator.</P>
                    <NAME>T. Mitchell Hudson, Jr.,</NAME>
                    <TITLE>Secretary, Maritime Administration.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09302 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD>BILLING CODE 4910-81-P</BILCOD>
        </NOTICE>
        <NOTICE>
            <PREAMB>
                <AGENCY TYPE="N">DEPARTMENT OF VETERANS AFFAIRS</AGENCY>
                <DEPDOC>[OMB Control No. 2900-0851]</DEPDOC>
                <SUBJECT>Agency Information Collection Activity: Status of Loan Account—Foreclosure or Other Liquidation</SUBJECT>
                <AGY>
                    <HD SOURCE="HED">AGENCY:</HD>
                    <P>Veterans Benefits Administration, Department of Veterans Affairs.</P>
                </AGY>
                <ACT>
                    <HD SOURCE="HED">ACTION:</HD>
                    <P>Notice.</P>
                </ACT>
                <SUM>
                    <HD SOURCE="HED">SUMMARY:</HD>
                    <P>In compliance with the Paperwork Reduction Act (PRA) of 1995, this notice announces that the Veterans Benefits Administration (VBA), 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; it includes the actual data collection instrument.</P>
                </SUM>
                <DATES>
                    <HD SOURCE="HED">DATES:</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. Refer to “OMB Control No. 2900-0851.
                    </P>
                </DATES>
                <FURINF>
                    <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                    <P>
                        Danny S. Green, Enterprise Records Service (005R1B), Department of Veterans Affairs, 811 Vermont Avenue NW, Washington, DC 20420, (202) 421-1354 or email 
                        <E T="03">Danny.Green2@va.gov.</E>
                         Please refer to “OMB Control No. 2900-0851.”
                    </P>
                </FURINF>
            </PREAMB>
            <SUPLINF>
                <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                <P/>
                <P>
                    <E T="03">Authority:</E>
                     Public Law 104-13; 44 U.S.C. 3501-3521.
                </P>
                <P>
                    <E T="03">Title:</E>
                     Status of Loan Account—Foreclosure or Other Liquidation, VA Form 26-0971.
                </P>
                <P>
                    <E T="03">OMB Control Number:</E>
                     2900-0851.
                </P>
                <P>
                    <E T="03">Type of Review:</E>
                     Extension without change of a currently approved collection.
                </P>
                <P>
                    <E T="03">Abstract:</E>
                     VA Form 26-0971 is used when the holder of a delinquent vendee account is legally entitled to repurchase the loan by VA when the loan has been continuously in default for 3 months and the amount of the delinquency equals or exceeds the sum of 2 monthly installments.
                </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 FR 85, 29 on February 12, 2020, page 8097.
                </P>
                <P>
                    <E T="03">Affected Public:</E>
                     Individuals or households.
                </P>
                <P>
                    <E T="03">Estimated Annual Burden:</E>
                     10 hours.
                </P>
                <P>
                    <E T="03">Estimated Average Burden per Respondent:</E>
                     30 minutes.
                </P>
                <P>
                    <E T="03">Frequency of Response:</E>
                     One-time.
                </P>
                <P>
                    <E T="03">Estimated Number of Respondents:</E>
                     20.
                </P>
                <SIG>
                    <P>By direction of the Secretary.</P>
                    <NAME>Danny S. Green,</NAME>
                    <TITLE>Department Clearance Officer, Office of Quality Performance and Risk, Department of Veterans Affairs.</TITLE>
                </SIG>
            </SUPLINF>
            <FRDOC>[FR Doc. 2020-09334 Filed 4-30-20; 8:45 am]</FRDOC>
            <BILCOD> BILLING CODE 8320-01-P</BILCOD>
        </NOTICE>
    </NOTICES>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <NEWPART>
        <PTITLE>
            <PRTPAGE P="25509"/>
            <PARTNO>Part II</PARTNO>
            <AGENCY TYPE="P">Department of Health and Human Services</AGENCY>
            <SUBAGY>Centers for Medicare &amp; Medicaid Services</SUBAGY>
            <HRULE/>
            <CFR>42 CFR Parts 406, 407, 422, Et al.</CFR>
            <CFR>45 CFR Part 156</CFR>
            <TITLE>Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers; Final Rule</TITLE>
        </PTITLE>
        <RULES>
            <RULE>
                <PREAMB>
                    <PRTPAGE P="25510"/>
                    <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                    <SUBAGY>Centers for Medicare &amp; Medicaid Services</SUBAGY>
                    <CFR>42 CFR Parts 406, 407, 422, 423, 431, 438, 457, 482, and 485</CFR>
                    <SUBAGY>Office of the Secretary</SUBAGY>
                    <CFR>45 CFR Part 156</CFR>
                    <DEPDOC>[CMS-9115-F]</DEPDOC>
                    <RIN>RIN 0938-AT79</RIN>
                    <SUBJECT>Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers</SUBJECT>
                    <AGY>
                        <HD SOURCE="HED">AGENCY:</HD>
                        <P>Centers for Medicare &amp; Medicaid Services (CMS), HHS.</P>
                    </AGY>
                    <ACT>
                        <HD SOURCE="HED">ACTION:</HD>
                        <P>Final rule.</P>
                    </ACT>
                    <SUM>
                        <HD SOURCE="HED">SUMMARY:</HD>
                        <P>This final rule is intended to move the health care ecosystem in the direction of interoperability, and to signal our commitment to the vision set out in the 21st Century Cures Act and Executive Order 13813 to improve the quality and accessibility of information that Americans need to make informed health care decisions, including data about health care prices and outcomes, while minimizing reporting burdens on affected health care providers and payers.</P>
                    </SUM>
                    <EFFDATE>
                        <HD SOURCE="HED">DATES:</HD>
                        <P>These regulations are effective on June 30, 2020.</P>
                    </EFFDATE>
                    <FURINF>
                        <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                        <P/>
                        <P>Alexandra Mugge, (410) 786-4457, for issues related to interoperability, CMS health IT strategy, and technical standards.</P>
                        <P>Denise St. Clair, (410) 786-4599, for issues related API policies and related standards.</P>
                        <P>Natalie Albright, (410) 786-1671, for issues related to Medicare Advantage.</P>
                        <P>Laura Snyder, (410) 786-3198, for issues related to Medicaid.</P>
                        <P>Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified Health Plans.</P>
                        <P>Meg Barry, (410) 786-1536, for issues related to CHIP.</P>
                        <P>Thomas Novak, (202) 322-7235, for issues related to trust exchange networks and payer to payer coordination.</P>
                        <P>Sharon Donovan, (410) 786-9187, for issues related to federal-state data exchange.</P>
                        <P>Daniel Riner, (410) 786-0237, for issues related to Physician Compare.</P>
                        <P>Ashley Hain, (410) 786-7603, for issues related to hospital public reporting.</P>
                        <P>Melissa Singer, (410) 786-0365, for issues related to provider directories.</P>
                        <P>CAPT Scott Cooper, USPHS, (410) 786-9465, for issues related to hospital and critical access hospital conditions of participation.</P>
                        <P>Russell Hendel, (410) 786-0329, for issues related to the Collection of Information or the Regulation Impact Analysis sections.</P>
                    </FURINF>
                </PREAMB>
                <SUPLINF>
                    <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                    <P/>
                    <HD SOURCE="HD1">Table of Contents</HD>
                    <EXTRACT>
                        <FP SOURCE="FP-2">I. Background and Summary of Provisions</FP>
                        <FP SOURCE="FP1-2">A. Purpose</FP>
                        <FP SOURCE="FP1-2">B. Overview</FP>
                        <FP SOURCE="FP1-2">C. Executive Order and MyHealthEData</FP>
                        <FP SOURCE="FP1-2">D. Past Efforts</FP>
                        <FP SOURCE="FP1-2">E. Challenges and Barriers to Interoperability</FP>
                        <FP SOURCE="FP1-2">F. Summary of Major Provisions</FP>
                        <FP SOURCE="FP-2">II. Technical Standards Related to Interoperability Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP1-2">A. Technical Approach and Standards</FP>
                        <FP SOURCE="FP1-2">B. Content and Vocabulary Standards</FP>
                        <FP SOURCE="FP1-2">C. Application Programming Interface (API) Standard</FP>
                        <FP SOURCE="FP1-2">D. Updates to Standards</FP>
                        <FP SOURCE="FP-2">III. Provisions of Patient Access Through APIs, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP1-2">A. Background on Medicare Blue Button</FP>
                        <FP SOURCE="FP1-2">B. Expanding the Availability of Health Information</FP>
                        <FP SOURCE="FP1-2">C. Standards-based API Proposal for MA, Medicaid, CHIP, and QHP Issuers on the FFEs</FP>
                        <FP SOURCE="FP-2">IV. API Access to Published Provider Directory Data Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP1-2">A. Interoperability Background and Use Cases</FP>
                        <FP SOURCE="FP1-2">B. Broad API Access to Provider Directory Data</FP>
                        <FP SOURCE="FP-2">V. The Health Information Exchange and Care Coordination Across Payers: Establishing a Coordination of Care Transaction To Communicate Between Plans Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP-2">VI. Care Coordination Through Trusted Exchange Networks: Trust Exchange Network Requirements for MA Plans, Medicaid Managed Care Plans, CHIP Managed Care Entities, and QHPs on the FFEs Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP-2">VII. Improving the Medicare-Medicaid Dually Eligible Experience by Increasing the Frequency of Federal-State Data Exchanges Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP1-2">A. Increasing the Frequency of Federal-State Data Exchanges for Dually Eligible Individuals</FP>
                        <FP SOURCE="FP1-2">B. Request for Stakeholder Input</FP>
                        <FP SOURCE="FP-2">VIII. Information Blocking Background and Public Reporting Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP1-2">A. Information Blocking Background</FP>
                        <FP SOURCE="FP1-2">B. Public Reporting and Prevention of Information Blocking on Physician Compare</FP>
                        <FP SOURCE="FP1-2">C. Public Reporting and Prevention of Information Blocking for Eligible Hospitals and Critical Access Hospitals (CAHs)</FP>
                        <FP SOURCE="FP-2">IX. Provider Digital Contact Information Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP1-2">A. Background</FP>
                        <FP SOURCE="FP1-2">B. Public Reporting of Missing Digital Contact Information</FP>
                        <FP SOURCE="FP-2">X. Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs) Provisions, and Analysis of and Responses to Public Comments</FP>
                        <FP SOURCE="FP1-2">A. Background</FP>
                        <FP SOURCE="FP1-2">B. Provisions for Hospitals (42 CFR 482.24(d))</FP>
                        <FP SOURCE="FP1-2">C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f))</FP>
                        <FP SOURCE="FP1-2">D. Provisions for CAHs (42 CFR 485.638(d))</FP>
                        <FP SOURCE="FP-2">XI. Provisions of the Final Regulations</FP>
                        <FP SOURCE="FP-2">XII. Collection of Information Requirements</FP>
                        <FP SOURCE="FP1-2">A. Background</FP>
                        <FP SOURCE="FP1-2">B. Wage Estimates</FP>
                        <FP SOURCE="FP1-2">C. Information Collection Requirements (ICRs)</FP>
                        <FP SOURCE="FP-2">XIII. Regulatory Impact Analysis</FP>
                        <FP SOURCE="FP1-2">A. Statement of Need</FP>
                        <FP SOURCE="FP1-2">B. Overall Impact</FP>
                        <FP SOURCE="FP1-2">C. Anticipated Effects</FP>
                        <FP SOURCE="FP1-2">D. Alternatives Considered</FP>
                        <FP SOURCE="FP1-2">E. Accounting Statement and Table</FP>
                        <FP SOURCE="FP1-2">F. Regulatory Reform Analysis Under E.O. 13771</FP>
                        <FP SOURCE="FP1-2">G. Conclusion</FP>
                        <FP SOURCE="FP-2">Regulation Text</FP>
                    </EXTRACT>
                    <HD SOURCE="HD1">I. Background and Summary of Provisions</HD>
                    <P>
                        In the March 4, 2019 
                        <E T="04">Federal Register</E>
                        , we published the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-facilitated Exchanges and Health Care Providers” proposed rule (84 FR 7610) (hereinafter referred to as the “CMS Interoperability and Patient Access proposed rule”). The proposed rule outlined our proposed policies that were intended to move the health care ecosystem in the direction of interoperability, and to signal our commitment to the vision set out in the 21st Century Cures Act and Executive Order 13813 to improve quality and accessibility of information that Americans need to make informed 
                        <PRTPAGE P="25511"/>
                        health care decisions, including data about health care prices and outcomes, while minimizing reporting burdens on affected health care providers and payers. We solicited public comments on the CMS Interoperability and Patient Access proposed rule. In this final rule, we address those public comments and outline our final policies in the respective sections of this rule.
                    </P>
                    <HD SOURCE="HD2">A. Purpose</HD>
                    <P>This final rule is the first phase of policies centrally focused on advancing interoperability and patient access to health information using the authority available to the Centers for Medicare &amp; Medicaid Services (CMS). We believe this is an important step in advancing interoperability, putting patients at the center of their health care, and ensuring they have access to their health information. We are committed to working with stakeholders to solve the issue of interoperability and getting patients access to information about their health care, and we are taking an active approach to move participants in the health care market toward interoperability and the secure and timely exchange of health information by adopting policies for the Medicare and Medicaid programs, the Children's Health Insurance Program (CHIP), and qualified health plan (QHP) issuers on the individual market Federally-facilitated Exchanges (FFEs). For purposes of this rule, references to QHP issuers on the FFEs excludes issuers offering only stand-alone dental plans (SADPs), unless otherwise noted for a specific proposed or finalized policy. Likewise, we are also excluding QHP issuers only offering QHPs in the Federally-facilitated Small Business Health Options Program Exchanges (FF-SHOPs) from the provisions of this rule and so, for purposes of this rule references to QHP issuers on the FFEs excludes issuers offering QHPs only on the FF-SHOPs. We note that, in this final rule, FFEs include FFEs in states that perform plan management functions. State-Based Exchanges on the Federal Platform (SBE-FPs) are not FFEs, even though consumers in these states enroll in coverage through HealthCare.gov, and QHP issuers in SBE-FPs are not subject to the requirements in this rule.</P>
                    <HD SOURCE="HD2">B. Overview</HD>
                    <P>
                        We are dedicated to enhancing and protecting the health and well-being of all Americans. One critical issue in the U.S. health care system is that people cannot easily access their health information in interoperable forms. Patients and the health care providers caring for them are often presented with an incomplete picture of their health and care as pieces of their information are stored in various, unconnected systems and do not accompany the patient to every care setting. Although more than 95 percent of hospitals 
                        <SU>1</SU>
                        <FTREF/>
                         and 75 percent of office-based clinicians 
                        <SU>2</SU>
                        <FTREF/>
                         are utilizing certified health IT, challenges remain in creating a comprehensive, longitudinal view of a patient's health history.
                        <E T="51">3 4 5</E>
                        <FTREF/>
                         This siloed nature of health care data prevents physicians, pharmaceutical companies, manufacturers, and payers from accessing and interpreting important data sets, instead, encouraging each group to make decisions based upon a part of the information rather than the whole. Without an enforced standard of interoperability, data exchanges are often complicated and time-consuming.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1</SU>
                             Office of the National Coordinator. (2019). Hospitals' Use of Electronic Health Records Data, 2015-2017. Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2019-04/AHAEHRUseDataBrief.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>2</SU>
                             Office of the National Coordinator. (2019, December 18). Health IT Playbook, Section 1: Electronic Health Records. Retrieved from 
                            <E T="03">https://www.healthit.gov/playbook/electronic-health-records/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>3</SU>
                             Powell, K. R. &amp; Alexander, G. L. (2019). Mitigating Barriers to Interoperability in Health Care. 
                            <E T="03">Online Journal of Nursing Informatics, 23</E>
                            (2). Retrieved from 
                            <E T="03">https://www.himss.org/library/mitigating-barriers-interoperability-health-care.</E>
                        </P>
                        <P>
                            <SU>4</SU>
                             Hochman, M., Garber, J., &amp; Robinson, E. J. (2019, August 14). Health Information Exchange After 10 Years: Time For A More Assertive, National Approach. Retrieved from 
                            <E T="03">https://www.healthaffairs.org/do/10.1377/hblog20190807.475758/full/.</E>
                        </P>
                        <P>
                            <SU>5</SU>
                             Payne, T. H., Lovis, C., Gutteridge, C., Pagliari, C., Natarajan, S., Yong, C., &amp; Zhao, L. (2019). Status of health information exchange: A comparison of six countries. Journal of Global Health, 9(2). doi: 10.7189/jogh.09.020427.
                        </P>
                    </FTNT>
                    <P>We believe patients should have the ability to move from payer to payer, provider to provider, and have both their clinical and administrative information travel with them throughout their journey. When a patient receives care from a new provider, a record of their health information should be readily available to that care provider, regardless of where or by whom care was previously provided. When a patient is discharged from a hospital to a post-acute care (PAC) setting there should be no question as to how, when, or where their data will be exchanged. Likewise, when an enrollee changes payers or ages into Medicare, the enrollee should be able to have their claims history and encounter data follow so that information is not lost. As discussed in more detail in section III. of this final rule, claims and encounter data can offer a more holistic understanding of a patient's health, providing insights into everything from the frequency and types of care provided and for what reason, medication history and adherence, and the evolution and adherence to a care plan. This information can empower patients to make better decisions and inform providers to support better health outcomes.</P>
                    <P>For providers in clinical and community settings, health information technology (health IT) should be a resource, enabling providers to deliver high quality care, creating efficiencies and allowing them to access all payer and provider data for their patients. Therefore, health IT should not detract from the clinician-patient relationship, from the patient's experience of care, or from the quality of work life for physicians, nurses, other health care professionals, and social service providers. Through standards-based interoperability and information exchange, health IT has the potential to facilitate efficient, safe, high-quality care for individuals and populations.</P>
                    <P>All payers should have the ability to exchange data seamlessly with other payers for timely benefits coordination or transitions, and with health care and social service providers to facilitate more coordinated and efficient care. Payers are in a unique position to provide enrollees with a comprehensive picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. This information can contribute to better informed decision making, helping to inform the patient's choice of coverage options and care providers to more effectively manage their own health, care, and costs.</P>
                    <P>We are committed to working with stakeholders to solve the issue of interoperability and patient access in the U.S. health care system while reducing administrative burdens on providers and are taking an active approach using all available policy levers and authorities to move participants in the health care market toward interoperability and the secure and timely exchange of health care information.</P>
                    <HD SOURCE="HD2">C. Executive Order and MyHealthEData</HD>
                    <P>
                        On October 12, 2017, President Trump issued Executive Order 13813 to Promote Healthcare Choice and Competition Across the United States. Section 1(c)(iii) of Executive Order 13813 states that the Administration will improve access to, and the quality of, information that Americans need to make informed health care decisions, including information about health care 
                        <PRTPAGE P="25512"/>
                        prices and outcomes, while minimizing reporting burdens on impacted providers, and payers, meaning providers and payers subject to this rule.
                    </P>
                    <P>In support of Executive Order 13813, the Administration launched the MyHealthEData initiative. This government-wide initiative aims to empower patients by ensuring that they have access to their own health information and the ability to decide how their data will be used, while keeping that information safe and secure. MyHealthEData aims to break down the barriers that prevent patients from gaining electronic access to their health information from the device or application of their choice, empowering patients and taking a critical step toward interoperability and patient data exchange.</P>
                    <P>In March 2018, the White House Office of American Innovation and the CMS Administrator announced the launch of MyHealthEData, and CMS's direct, hands-on role in improving patient access and advancing interoperability. As part of the MyHealthEData initiative, we are taking a patient-centered approach to health information access and moving to a system in which patients have immediate access to their computable health information such that they can be assured that their health information will follow them as they move throughout the health care system from provider to provider, payer to payer. To accomplish this, we have launched several initiatives related to data sharing and interoperability to empower patients and encourage payer and provider competition. We continue to advance the policies and goals of the MyHealthEData initiative through various provisions included in this final rule.</P>
                    <P>As finalized in this rule, our policies are wide-reaching and will have an impact on all facets of the health care system. Several key touch points of the policies in this rule include:</P>
                    <P>
                        • 
                        <E T="03">Patients:</E>
                         Enabling patients to access their health information electronically without special effort by requiring the payers subject to this final rule to make data available through an application programming interface (API) to which third-party software applications connect to make data available to patients for their personal use. This encourages patients to take charge of and better manage their health care, and thus these initiatives are imperative to improving a patient's long-term health outcomes.
                    </P>
                    <P>
                        • 
                        <E T="03">Clinicians and Hospitals:</E>
                         Ensuring that health care providers have ready access to health information about their patients, regardless of where the patient may have previously received care. We are also implementing policies to prevent health care providers from inappropriately restricting the flow of information to other health care providers and payers. Finally, we are working to ensure that better interoperability reduces the burden on health care providers.
                    </P>
                    <P>
                        • 
                        <E T="03">Payers:</E>
                         Implementing requirements to ensure that payers (that is, entities and organizations that pay for health care), such as payers in Medicare Advantage, Medicaid, and CHIP, make enrollee electronic health information held by the payer available through an API such that, with use of software expected to be developed by payers and third parties, the information becomes easily accessible to the enrollee and data flow seamlessly with the enrollee as such enrollees change health care and social service providers and payers. Additionally, our policies ensure that payers make it easy for current and prospective enrollees to identify which providers are within a given plan's network in a way that is simple and easy for enrollees to access and understand, and thus find the providers that are right for them.
                    </P>
                    <P>
                        As a result of our efforts to standardize data and technical approaches to advance interoperability, we believe health care providers and their patients, as well as other key participants within the health care ecosystem such as payers, will have appropriate access to the information necessary to coordinate individual care; analyze population health trends, outcomes, and costs; and manage benefits and the health of populations, while tracking progress through quality improvement initiatives. We are working with other federal partners including the Office of the National Coordinator for Health Information Technology (ONC) on this effort with the clear objectives of improving patient access and care, alleviating provider burden, and reducing overall health care costs, all while taking steps to protect the privacy and security of patients' personal health information. As evidence of this partnership, ONC is releasing the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) in tandem with this final rule. It is this coordinated federal effort, in conjunction with strong support and innovation from our stakeholders, that will help us move ever closer to true interoperability.
                    </P>
                    <HD SOURCE="HD2">D. Past Efforts</HD>
                    <P>The Department of Health and Human Services (HHS) has been working to advance the interoperability of electronic health information for over 15 years. For a detailed explanation of past efforts, see the CMS Interoperability and Patient Access proposed rule (84 FR 7612 through 7614).</P>
                    <HD SOURCE="HD2">E. Challenges and Barriers to Interoperability</HD>
                    <P>Through significant stakeholder feedback, we understand that there are many barriers to interoperability, which have obstructed progress over the years. We have conducted stakeholder meetings and roundtables; solicited comments via RFIs; and received additional feedback through letters and rulemaking. All of this input together contributed to the policies in our Interoperability and Patient Access proposed rule, and when combined with the comments we received on the proposed rule, the content of this final rule. Some of the main barriers shared with us, specifically patient identification, lack of standardization, information blocking, the lack of adoption and use of certified health IT among post-acute care (PAC) providers, privacy concerns, and uncertainty about the requirements of the Health Insurance Portability and</P>
                    <P>Accountability Act of 1996 (HIPAA) Privacy, Security, and Breach Notification Rules, were discussed in the proposed rule (84 FR 7614 through 7617). While we have made efforts to address some of these barriers in this final rule and through prior rules and actions, we believe there is still considerable work to be done to overcome some of these challenges toward achieving interoperability, and we will continue this work as we move forward with our interoperability efforts.</P>
                    <HD SOURCE="HD2">F. Summary of Major Provisions</HD>
                    <P>
                        This final rule empowers patients in MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, by finalizing several initiatives that will break down those barriers currently keeping patients from easily accessing their electronic health care information. Additionally, the rule creates and implements new mechanisms to enable patients to access their own health care information through third-party software applications, thereby providing them with the ability to decide how, when, and with whom to share their information.
                        <PRTPAGE P="25513"/>
                    </P>
                    <P>
                        We are finalizing with modifications our proposal to require MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to implement and maintain a standards-based Patient Access API. This Patient Access API must meet the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215 (currently including Health Level 7® (HL7) Fast Healthcare Interoperability Resources® (FHIR) Release 4.0.1) and the content and vocabulary standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.213, as well as content and vocabulary standards at 45 CFR part 162 and the content and vocabulary standards at 42 CFR 423.160. We are finalizing that through the Patient Access API, payers must permit third-party applications to retrieve, with the approval and at the direction of a current enrollee, data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221. Specifically, we are requiring that the Patient Access API must, at a minimum, make available adjudicated claims (including provider remittances and enrollee cost-sharing); encounters with capitated providers; and clinical data, including laboratory results (when maintained by the impacted payer). Data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received. We are requiring that beginning January 1, 2021, impacted payers make available through the Patient Access API the specified data they maintain with a date of service on or after January 1, 2016. This is consistent with the requirements for the payer-to-payer data exchange detailed in section V. of this final rule. Together these policies facilitate the creation and maintenance of a patient's cumulative health record with their current payer.
                    </P>
                    <P>
                        We are finalizing regulations to require that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities make standardized information about their provider networks available through a Provider Directory API that is conformant with the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215, excluding the security protocols related to user authentication and authorization and any other protocols that restrict availability of this information to particular persons or organizations. Authentication and authorization protocols are not necessary when making publicly available data accessible via an API. We are finalizing that the Provider Directory API must be accessible via a public-facing digital endpoint on the payer's website to ensure public discovery and access. At a minimum, these payers must make available via the Provider Directory API provider names, addresses, phone numbers, and specialties. For MA organizations that offer MA-PD plans, they must also make available, at a minimum, pharmacy directory data, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”). All directory information must be made available to current and prospective enrollees and the public through the Provider Directory API within 30 calendar days of a payer receiving provider directory information or an update to the provider directory information. The Provider Directory API is being finalized at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. Here we are finalizing that access to the published Provider Directory API must be fully implemented by January 1, 2021. We do strongly encourage payers to make their Provider Directory API public as soon as possible to make and show progress toward meeting all the API requirements being finalized in this rule.
                    </P>
                    <P>
                        We are finalizing our proposal, with certain modifications as detailed in section V. of this final rule, to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to coordinate care between payers by exchanging, at a minimum, the data elements specified in the current content and vocabulary standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.213 (currently the “United States Core Data for Interoperability” (USCDI) version 1 
                        <SU>6</SU>
                        <FTREF/>
                        ). This payer-to-payer data exchange requires these payers, as finalized at 42 CFR 422.119(f) for MA organizations, at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care plans (and by extension under § 457.1216 CHIP managed care entities), and at 45 CFR 156.221(f) for QHP issuers on the FFEs, to send, at a current or former enrollee's request, specific information they maintain with a date of service on or after January 1, 2016 to any other payer identified by the current enrollee or former enrollee. This is consistent with the Patient Access API detailed in section III. of this final rule. We are also finalizing a provision that a payer is only obligated to share data received from another payer under this regulation in the electronic form and format it was received. This is intended to reduce burden on payers. We are finalizing that this payer-to-payer data exchange must be fully implemented by January 1, 2022.
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             Office of the National Coordinator. (n.d.). U.S. Core Data for Interoperability (USCDI). Retrieved from 
                            <E T="03">https://www.healthit.gov/isa/us-core-data-interoperability-uscdi.</E>
                        </P>
                    </FTNT>
                    <P>In response to comments discussed more fully below, we are not finalizing our proposal to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in a trusted exchange network given the concerns commenters raised regarding the need for a mature Trusted Exchange Framework and Common Agreement (TEFCA) to be in place first, and appreciating that work on TEFCA is ongoing at this time.</P>
                    <P>We are finalizing the requirements that all states participate in daily exchange of buy-in data, which includes both sending data to CMS and receiving responses from CMS daily, and that all states submit the MMA file data to CMS daily by April 1, 2022 in accordance with 42 CFR 406.26, 407.40, and 423.910, respectively, as proposed. These requirements will improve the experience of dually eligible individuals by improving the ability of providers and payers to coordinate eligibility, enrollment, benefits, and/or care for this population.</P>
                    <P>
                        We are finalizing our proposal to include an indicator on Physician Compare for the eligible clinicians and groups that submit a “no” response to any of the three prevention of information blocking statements for MIPS. In the event that these statements are left blank, the attestations will be considered incomplete, and we will not include an indicator on Physician Compare. The indicator will be posted on Physician Compare, either on the profile pages or in the downloadable database, starting with the 2019 performance period data available for public reporting starting in late 2020.
                        <PRTPAGE P="25514"/>
                    </P>
                    <P>We are finalizing our proposal to include information on a publicly available CMS website indicating that an eligible hospital or critical access hospital (CAH) attesting under the Medicare FFS Promoting Interoperability Program had submitted a “no” response to any of the three attestation statements related to the prevention of information blocking. In the event that an eligible hospital or CAH leaves a “blank” response, the attestations will be considered incomplete, and no information will be posted related to these attestation statements. We will post this information starting with the attestations for the EHR reporting period in 2019 and expect this information will be posted in late 2020.</P>
                    <P>Additionally, as detailed in section IX. of this final rule, we are finalizing our proposal to publicly report the names and NPIs of those providers who do not have digital contact information included in the National Plan and Provider Enumeration System (NPPES) system beginning in the second half of 2020 as proposed. Additionally, we will continue to ensure providers are aware of the benefits of including digital contact information in NPPES, and when and where their names and NPIs will be posted if they do not include this information. We do strongly encourage providers to include FHIR endpoint information in NPPES if and when they have the information, as well.</P>
                    <P>To further advance electronic exchange of information that supports effective transitions of care we are finalizing the requirement for a hospital, psychiatric hospital, and CAH, which utilizes an electronic medical records system or other electronic administrative system that is conformant with the content exchange standard at 45 CFR 170.205(d)(2) to demonstrate that: (1) Its system's notification capacity is fully operational and that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information; (2) its system sends notifications that must include the minimum patient health information specified in section X. of this final rule; and (3) its system sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of a patient's registration in the emergency department or admission to inpatient services, and also prior to, or at the time of, a patient's discharge and/or transfer from the emergency department or inpatient services, to all applicable post-acute care services providers and suppliers, primary care practitioners and groups, and other practitioners and groups identified by the patient as primarily responsible for his or her care, and who or which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes. We are establishing that this policy will be applicable 12 months after publication of this rule for hospitals, including psychiatric hospitals, and CAHs to allow for adequate and additional time for these institutions, especially small and/or rural hospitals as well as CAHs, to come into compliance with the new requirements.</P>
                    <P>Finally, we note that we included two RFIs in the proposed rule: one related to interoperability and health IT adoption in PAC settings and one related to the role of patient matching in interoperability and improved patient care. We thank commenters for the insights shared on these two topics. We are reviewing these comments and will take them into consideration for potential future rulemaking.</P>
                    <P>
                        Throughout this final rule, we refer to terms such as “patient,” “consumer,” “beneficiary,” “enrollee,” and “individual.” We note that every reader of this final rule is a patient and has or will receive medical care at some point in their life. In this final rule, we use the term “patient” as an inclusive term, but because we have historically referred to patients using the other terms noted above in our regulations, we use specific terms as applicable in sections of this final rule to refer to individuals covered under the health care programs that CMS administers and regulates. We also note that when we discuss patients, we acknowledge a patient's personal representative. Per the HIPAA privacy regulations at 45 CFR 164.502(g), a personal representative is someone authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney).
                        <SU>7</SU>
                        <FTREF/>
                         Policies in this final rule that require a patient's action could be addressed by a patient's personal representative.
                    </P>
                    <FTNT>
                        <P>
                            <SU>7</SU>
                             See OCR guidance regarding personal representatives at 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>We also use terms such as “payer,” “plan,” and “issuer” in this final rule. Certain portions of this final rule are applicable to the Medicare Fee-for-Service (FFS) Program, the Medicaid FFS Program, the CHIP FFS program, Medicare Advantage (MA) organizations, Medicaid Managed Care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP Managed Care entities (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. We use the term “payer” in the preamble of this final rule as an inclusive term for all these programs (and plan types in the case of plans), but we also use specific terms as applicable in sections of this final rule. Finally, we use the term “provider,” too, as an inclusive term comprising individuals, organizations, and institutions that provide health services, such as clinicians, hospitals, skilled nursing facilities, home health agencies, hospice settings, laboratories, suppliers of durable medical equipment, community based organizations, etc., as appropriate in the context used.</P>
                    <HD SOURCE="HD1">II. Technical Standards Related to Interoperability Provisions, and Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Technical Approach and Standards</HD>
                    <HD SOURCE="HD3">1. Use of Health Level 7® (HL7) Fast Healthcare Interoperability Resources® (FHIR) for APIs</HD>
                    <P>
                        Section 106(b)(1)(B)(ii) of the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) defines health IT “interoperability” as the ability of two or more health information systems or components to exchange clinical and other information and to use the information that has been exchanged using common standards to provide access to longitudinal information for health care providers in order to facilitate coordinated care and improved patient outcomes. Interoperability is also defined in section 3000 of the Public Health Service Act (PHSA) (42 U.S.C. 300jj), as amended by section 4003 of the 21st Century Cures Act. Under that definition, “interoperability,” with respect to health IT, means such health IT that enables the secure exchange of electronic health information with, and use of electronic health information from, other health IT without special effort on the part of the user; allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law; and does not constitute information blocking as defined in section 3022(a) of the PHSA, which was added by section 4004 of the Cures Act. We believe the PHSA definition is consistent with the MACRA definition of “interoperability”. Consistent with the CMS Interoperability and Patient Access 
                        <PRTPAGE P="25515"/>
                        proposed rule (84 FR 7619), we will use the PHSA definition of “interoperability” for the purposes of this final rule.
                    </P>
                    <P>
                        We believe the PHSA definition of “interoperability” is useful as a foundational reference for our approach to advancing the interoperability and exchange of electronic health information for individuals throughout the United States, and across the entire spectrum of provider types and care settings with which health insurance issuers and administrators need to efficiently exchange multiple types of relevant data. We noted the PHSA definition of “interoperability” is not limited to a specific program or initiative, but rather can be applied to all activities under the title of the PHSA that establishes ONC's responsibilities to support and shape the health information ecosystem, including the exchange infrastructure for the U.S. health care system as a whole. The PHSA definition is also consistent with HHS's vision and strategy for achieving a health information ecosystem within which all individuals, their personal representatives, their health care providers, and their payers are able to send, receive, find, and use electronic health information in a manner that is appropriate, secure, timely, and reliable to support the health and wellness of individuals through informed, shared decision-making,
                        <SU>8</SU>
                        <FTREF/>
                         as well as to support consumer choice of payers and providers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>8</SU>
                             See, for example, Office of the National Coordinator. (2015). Connecting Health and Care for the Nation: A Shared Nationwide Interoperability Roadmap, Final Version 1.0. Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>We summarize the public comment we received on use of the PHSA definition of “interoperability” and provide our response.</P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter specifically supported the use of the PHSA definition of “interoperability”.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's support.
                    </P>
                    <P>A core policy principle we aim to support across all policies in this rule is that every American should be able, without special effort or advanced technical skills, to see, obtain, and use all electronically available information that is relevant to their health, care, and choices—of plans, providers, and specific treatment options. In the proposed rule, we explained this included two types of information: personal health information that health care providers and health plans, or payers, must make available to an individual, such as their current and past medical conditions and care received; and information that is of general interest and should be widely available, such as plan provider networks, the plan's formulary, and coverage policies (84 FR 7619).</P>
                    <P>We also discussed that while many consumers today can often access their own electronic health information through patient or enrollee portals and proprietary applications made available by various providers and health plans, they must typically go through separate processes to obtain access to each system, and often need to manually aggregate information that is delivered in various, often non-standardized, formats. The complex tasks of accessing and piecing together this information can be burdensome and frustrating to consumers.</P>
                    <P>
                        An API can be thought of as a set of commands, functions, protocols, or tools published by one software developer (“A”) that enable other software developers to create programs (applications or “apps”) that can interact with A's software without needing to know the internal workings of A's software, all while maintaining consumer privacy data standards.
                        <SU>9</SU>
                        <FTREF/>
                         This is how API technology enables the seamless user experiences associated with applications familiar from other aspects of many consumers' daily lives, such as travel and personal finance. Standardized, transparent, and pro-competitive API technology can enable similar benefits to consumers of health care services.
                        <SU>10</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>9</SU>
                             See 
                            <E T="03">https://www.hl7.org/fhir/security.html</E>
                             for information on how FHIR servers and resources integrate privacy and security protocols into the data exchange via an API.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             ONC has made available a succinct, non-technical overview of APIs in context of consumers' access to their own medical information across multiple providers' EHR systems, which is available at the HealthIT.gov website at 
                            <E T="03">https://www.healthit.gov/api-education-module/story_html5.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        While acknowledging the limits of our authority to require use of APIs to address our goals for interoperability and data access, we proposed to use our programmatic authority to require that a variety of data be made accessible by requiring that MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP agencies, CHIP managed care entities, and QHP issuers on the FFEs, adopt and implement “openly published,” or secure, standards-based APIs. In the CMS Interoperability and Patient Access proposed rule, we used the short form terminology, “open API”. We appreciate that this term can be misunderstood to mean “open” as in “not secure”. In actuality, an “open API” is a secure, standards-based API that has certain technical information openly published to facilitate uniform use and data sharing in a secure, standardized way. To avoid this misinterpretation, we will use the term “standards-based API” in this final rule where we used “open API” in the proposed rule. This is also in better alignment with the terminology used in the ONC 21st Century Cures Act proposed rule (84 FR 7453) and final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). We noted that having certain data available through standards-based APIs would allow impacted enrollees to use the application of their choice to access and use their own electronic health information and other related information to manage their health. See section III.C.2.a. of the CMS Interoperability and Patient Access proposed rule for further discussion (84 FR 7629).
                    </P>
                    <P>
                        Much like our efforts under Medicare Blue Button 2.0, also part of the MyHealthEData initiative, which made Parts A, B, and D claims and encounter data available via an API to Medicare beneficiaries, the policies in this rule extend these benefits to even more patients. As of January 2020, over 53,000 Medicare beneficiaries have taken advantage of Blue Button. Currently, there are 55 production applications and over 2,500 developers working in the Blue Button sandbox. For more information on Blue Button 2.0 see section III. of this final rule. As we noted in the CMS Interoperability and Patient Access proposed rule, we believe that our Patient Access API, in particular, will result in claims and encounter information becoming easily accessible for the vast majority of patients enrolled with payers regulated by CMS. As finalized, these policies will apply to all MA organizations, all Medicaid and CHIP FFS programs, all types of Medicaid managed care plans (MCOs, PIHPs, and PAHPs), as well as CHIP managed care entities, and QHP issuers on the FFEs. We hope that states operating Exchanges might consider adopting similar requirements for QHPs on the State-Based Exchanges (SBEs), and that other payers in the private sector might consider voluntarily offering data accessibility of the type included in the policies being finalized here so that even more patients across the American health care system can easily have and use such information to advance their choice and participation in their health care. In this way, we hope that the example being set by CMS will raise consumers' expectations and 
                        <PRTPAGE P="25516"/>
                        encourage other payers in the market to take similar steps to advance patient access and empowerment outside the scope of the requirements being finalized in this rule.
                    </P>
                    <P>
                        We explained in the CMS Interoperability and Patient Access proposed rule (84 FR 7620) that those seeking further information regarding what a standards-based API is are encouraged to review the discussion of the standardized API criterion and associated policy principles and technical standards included in ONC's 21st Century Cures Act proposed rule (84 FR 7424) and final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). These rules provide more detailed information on API functionality and interoperability standards relevant to electronic health information. We noted that while that discussion was specific to health IT, including Electronic Health Records (EHR) systems, certified under ONC's Health IT Certification Program rather than the information systems generally used by payers and plan issuers for claims, encounters, or other administrative or plan operational data, it included information applicable to interoperability standards, as well as considerations relevant to establishing reasonable and non-discriminatory terms of service for applications seeking to connect to the standards-based API discussed in this rule. While we reiterate that we did 
                        <E T="03">not</E>
                         propose to require payers to use Health IT Modules certified under ONC's program to make administrative data such as claims history or provider directory information available to enrollees, we believe that the discussion of APIs and related standards in the ONC 21st Century Cures Act rules will be of use to those seeking to better understand the role of APIs in health care information exchange.
                    </P>
                    <P>We also discussed in our proposed rule how other industries have advanced the sort of standards-based API-driven interoperability and innovation that we seek in the health system (84 FR 7620). We have sought to collaborate and align with ONC's proposed and final policies specifically related to APIs under the Cures Act as we developed and finalized these policies. In general, as we noted in our proposed rule, we believe the following three attributes of standards-based APIs are particularly important to achieving the goal of offering individuals convenient access, through applications they choose, to available and relevant electronic health and health-related information:</P>
                    <P>• The API technologies themselves, not just the data accessible through them, are standardized;</P>
                    <P>• The APIs are technically transparent; and</P>
                    <P>• The APIs are implemented in a pro-competitive manner.</P>
                    <P>In that section of the CMS Interoperability and Patient Access proposed rule, we discussed these concepts generally and how they were applicable in the health care context for all payers, and explained how these were relevant to our specific proposals, which are discussed in detail in section III. of this final rule. To revisit this full discussion, see the proposed rule (84 FR 7620 through 7621). We did not receive comments on this general discussion. Any comments on specific proposals that refer to these three attributes are discussed in this final rule in the context of the specific proposals.</P>
                    <HD SOURCE="HD3">2. Privacy and Security Concerns in the Context of APIs</HD>
                    <P>
                        As we noted in the CMS Interoperability and Patient Access proposed rule, HHS has received a wide range of stakeholder feedback on privacy and security issues in response to prior proposals 
                        <SU>11</SU>
                        <FTREF/>
                         about policies related to APIs that would allow consumers to use an app of their choosing to access protected health information (PHI) held by or on behalf of a HIPAA covered entity. Such feedback included concerns about potential security risks to PHI created by an API connecting to third-party applications and the implications of an individual's data being shared with these third-party apps at the direction of the individual.
                    </P>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             For instance, see discussion of stakeholder comments in the 2015 Edition final rule at 80 FR 62676.
                        </P>
                    </FTNT>
                    <P>As we discussed in our Interoperability and Patient Access proposed rule (84 FR 7621), deploying API technology would offer consumers the opportunity to access their electronic health information held by covered entities (including, but not limited to MA organizations, the Medicare Part A and B programs, the Medicaid program, CHIP, QHP issuers on the FFEs, and other health insurance issuers in the private markets), and would not lessen any such covered entity's duties under HIPAA and other laws to protect the privacy and security of information it creates, receives, maintains, or transmits, including but not limited to PHI. A covered entity implementing an API to enable individuals to access their health information must take reasonable steps to ensure an individual's information is only disclosed as permitted or required by applicable law. The entity must take greater care in configuring and maintaining the security functionalities of the API and the covered entities' electronic information systems to which it connects than would be needed if it was implementing an API simply to allow easier access to widely available public information. In accordance with the HIPAA Privacy and Security Rules, the covered entity is required to implement reasonable safeguards to protect PHI while in transit. If an individual requests their PHI in an EHR be sent to the third party by unencrypted email or in another unsecure manner, which the individual has a right to request, reasonable safeguards could include, for example, carefully checking the individual's email address for accuracy and warning the individual of risks associated with the unsecure transmission. We note that the standards-based APIs discussed in this final rule are secure methods of data exchange.</P>
                    <P>HIPAA covered entities and their business associates continue to be responsible for compliance with the HIPAA Rules, the Federal Trade Commission Act (FTC Act), and all other laws applicable to their business activities including but not limited to their handling of enrollees' PHI and other data. As we stated in the CMS Interoperability and Patient Access proposed rule (84 FR 7610), nothing proposed in that rule was intended to alter or should be construed as altering existing responsibilities to protect PHI under the HIPAA Rules or any other laws that are currently applicable.</P>
                    <P>However, we acknowledged that a number of industry stakeholders may mistakenly believe that they are responsible for determining whether an application to which an individual directs their PHI employs appropriate safeguards regarding the information it receives. In the proposed rule we discussed Office for Civil Rights (OCR) guidance that noted that covered entities are not responsible under the HIPAA Rules for the security of PHI once it has been received by a third-party application chosen by an individual (84 FR 7621 through 7622).</P>
                    <P>
                        Further, we noted in the CMS Interoperability and Patient Access proposed rule that the HIPAA Privacy Rule 
                        <SU>12</SU>
                        <FTREF/>
                         established the individual's right of access, including a right to inspect 
                        <PRTPAGE P="25517"/>
                        and/or receive a copy of PHI held in designated record sets by covered entities and their business associates as detailed at 45 CFR 164.524. We specifically noted in the proposed rule that OCR had indicated in regulations and guidance, that an individual could exercise their right of access by requesting that their information be sent to a third party.
                        <SU>13</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             More information on the Privacy Rule, including related rulemaking actions and additional interpretive guidance, is available at 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/index.html</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             See 45 CFR 164.524(c)(2) and (3), and 164.308(a)(1), OCR HIPAA Guidance/FAQ-2036: 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/2036/can-an-individual-through-the-hipaa-right/index.html,</E>
                             and OCR HIPAA Guidance/FAQ-2037: 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/2037/are-there-any-limits-or-exceptions-to-the-individuals-right/index.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        As we also noted in the proposed rule (84 FR 7622), we are aware of stakeholder concerns about which protections apply to non-covered entities, such as direct-to-consumer applications. As we explained in the proposed rule, when a non-covered entity discloses an individual's confidential information in a manner or for a purpose not consistent with the privacy notice and terms of use to which the individual agreed, the FTC has authority under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)) to investigate and take action against unfair or deceptive trade practices. The FTC has applied this authority to a wide variety of entities.
                        <SU>14</SU>
                        <FTREF/>
                         The FTC also enforces the FTC Health Breach Notification Rule, which applies to certain types of entities, including vendors of personal health records and third-party service providers, that fall outside of the scope of HIPAA, and therefore, are not subject to the HIPAA Breach Notification Rule.
                        <SU>15</SU>
                        <FTREF/>
                         This FTC Health Breach Notification Rule explains the process and steps third parties must follow when they discover a breach of identifiable personal health record information they maintain. Any violation of this Rule is enforced by the FTC as an unfair or deceptive act or practice under the FTC Act.
                    </P>
                    <FTNT>
                        <P>
                            <SU>14</SU>
                             See also cases where this authority was used, such as 2012 FTC action against Facebook (see 
                            <E T="03">https://www.ftc.gov/enforcement/cases-proceedings/092-3184/facebook-inc</E>
                            ) and 2012 FTC action against MySpace (see 
                            <E T="03">https://www.ftc.gov/enforcement/cases-proceedings/102-3058/myspace-llc-matter</E>
                            ).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             See 16 CFR part 318; see also 
                            <E T="03">https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>We recognized that this is a complex landscape for patients, who we anticipate will want to exercise due diligence on their own behalf in reviewing the terms of service and other information about the applications they consider selecting. Therefore, we proposed specific requirements on payers to ensure enrollees have the opportunity to become more informed about how to protect their PHI, important things to consider in selecting an application, and where they can submit a complaint if they believe a HIPAA covered entity or business associate may not be in compliance with their duties under the HIPAA Rules, or if they believe they have been subjected to unfair or deceptive acts or practices related to a direct-to-consumer application's privacy practices or terms of use. A full discussion of the Enrollee and Beneficiary Resources Regarding Privacy and Security provision can be found in section III.C.2.h. of this final rule.</P>
                    <P>
                        In some circumstances, we noted that the information that we proposed to require be made available through an API per a patient's request, under the various program-specific authorities authorizing this rulemaking, were also consistent with the enrollee's right of access for their data held by a covered entity or their business associate under the HIPAA Privacy Rule. But we also noted that some data to which an individual is entitled to access under HIPAA may not be required to be transferred through the API. For instance, when the covered entity does not hold certain information electronically. In those instances, we noted that the inability to access data via an API would in no way limit or alter responsibilities and requirements under other law (including though not limited to the HIPAA Privacy, Security, and Breach Notification Rules) that apply to the organizations that would be subject to this regulation. Even as these requirements are finalized, the organization may still be called upon to respond to individuals' request for information not available through the API, or for all of their information through means other than the API. We encouraged HIPAA covered entities and business associates to review the OCR website for resources on the individual access standard at 
                        <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html</E>
                         to ensure they understand their responsibilities.
                    </P>
                    <P>
                        We again encourage HIPAA covered entities and business associates to review their responsibilities under HIPAA in light of the recent decision in Ciox Health, LLC v. Azar, et al., No. 18-cv-0040 (D.D.C. January 23, 2020).
                        <SU>16</SU>
                        <FTREF/>
                         The court order vacates a portion of the HIPAA Privacy Rule related to the individual right of access “insofar as it expands the HITECH Act's third-party directive beyond requests for a copy of an electronic health record with respect to [protected health information] of an individual  . . . in an electronic format.” 
                        <SU>17</SU>
                        <FTREF/>
                         Generally, the court order vacates a portion of the HIPAA Privacy Rule that provides an individual the right to direct a covered entity to send protected health information that is not in an EHR to a third party identified by the individual.
                    </P>
                    <FTNT>
                        <P>
                            <SU>16</SU>
                             See, 
                            <E T="03">https://ecf.dcd.uscourts.gov/cgi-bin/show_public_doc?2018cv0040-51</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>17</SU>
                             See, 
                            <E T="03">https://hds.sharecare.com/wp-content/uploads/2020/01/CiOX-Health-v.-HHS-Court-Order-3-24-2020.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>This decision does not affect CMS' programmatic authorities, as discussed in detail in section III. of the CMS Interoperability and Patient Access proposed rule (83 FR 7629 through 7630) and section III. of this final rule, to propose and finalize the Patient Access API for the programs specified. Additionally, the court's decision did not alter individuals' right under HIPAA to request and obtain a copy of their records. Because the goal of the Patient Access API in our programs is to give patients access to their own information for their own personal use through a third-party app, we believe these policies as adopted in this rule remain consistent with the spirit of access rights under HIPAA.</P>
                    <P>As discussed in detail below, many commenters discussed the issues of privacy and security in regard to information made available to third-party applications. Here, we summarize the public comments we received on general issues and concerns around privacy and security of a standards-based API, and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters supported OCR's efforts to more clearly account for use cases, or specific situations, in which apps are used to exchange patients' electronic health information. Some commenters noted support for OCR's FAQ that specifies that covered entities are not responsible or liable for the privacy and security of PHI once it is transmitted at the individual's direction to and received by a third-party application. One commenter expressed concern that CMS and ONC proposed requirements would make the safeguards of HIPAA moot if HIPAA is not extended to third-party applications that are able under this rule to display patient data. Without extending HIPAA, the commenter fears payers and providers will be liable if the third-party misuses patient data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support. We reiterate that HIPAA covered entities and business associates are responsible for meeting their HIPAA privacy and security obligations to protect patient data they 
                        <PRTPAGE P="25518"/>
                        maintain, and absent patient requests to the contrary, are obligated to take reasonable measures to protect these data in transit. Once these data are transmitted and no longer under the control of the covered entity or business associate, those entities no longer have any obligations under HIPAA for the privacy and security of the PHI, because these data are no longer subject to HIPAA. We stress, as discussed in the CMS Interoperability and Patient Access proposed rule, nothing in this rule alters covered entities' or business associates' responsibilities to protect PHI under the HIPAA Privacy and Security Rules.
                    </P>
                    <P>The only instance per the policies proposed in this rule that would allow a payer to deny access to an app, as discussed in the proposed rule and underlying the rationale for finalizing 42 CFR 422.119(e), 431.60(e), 438.242(b)(6) (redesignated as § 438.242(b)(5) see section VI. in this rule), 457.730(e), 457.1233(d)(2), and 45 CFR 156.221(e), would be if the covered entity or its business associate's own systems would be endangered if it were to engage with a specific third-party application through an API, for instance if allowing such access would result in an unacceptable security risk. Therefore, as we also noted, covered entities and business associates are free to offer advice to patients on the potential risks involved with requesting data transfers to an application or entity not covered by HIPAA, but such efforts generally must stop at education and awareness or advice regarding concerns related to a specific app. For instance, if a payer notes that an app a patient requests receive their data does not lay out in its privacy policy specifically how the patient's personal data will be used, the payer could choose to inform the patient they may not want to share their data with that app without a clear understanding of how the app may use the data, including details about the app's secondary data use policy. If the patient still wants their data to be shared, or does not respond to the payer's warning, the payer would need to share these data via the API absent an unacceptable security risk to the payer's own system. For more information on this ability to inform patients, see section III.C.2.g. of this final rule. The requirements finalized in this rule do not impact or change obligations under the HIPAA Privacy and Security Rules in any way.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters noted discrepancies in the terminology used in the OCR FAQ mentioned in the CMS Interoperability and Patient Access proposed rule compared to terminology used throughout the CMS Interoperability and Patient Access proposed rule and the ONC 21st Century Cures Act proposed rule, and suggested that any terminology inconsistencies be addressed and harmonized. These commenters noted that the OCR FAQ pertains to “electronic protected health information” (ePHI), and uses the term “electronic health record (EHR) system developer”, which differs from terms used in the CMS Interoperability and Patient Access and the ONC 21st Century Cures Act proposed rules.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate comments regarding variance in the terminology used in OCR guidance and the CMS Interoperability and Patient Access proposed rule. Regarding the relationship between ePHI and electronic health information (EHI), we refer readers to the discussion in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). OCR guidance uses the term “electronic health record system developer” 
                        <SU>18</SU>
                        <FTREF/>
                         to refer to a health IT developer that develops and maintains electronic health record systems containing PHI for a covered entity, and therefore is a business associate of those covered entities. The guidance also uses “app developer” to describe the creator of the app that is designated to receive an individual's PHI. ONC uses related terms that have a specific meaning within the context of ONC programs. For instance, ONC uses the term “health IT developer” for the purposes of the ONC Health IT Certification Program to refer to a vendor, self-developer, or other entity that presents health IT for certification or has health IT certified under the program. In addition, the ONC 21st Century Cures Act proposed rule proposed to define the term “health IT developer of certified health IT” for the purposes of implementing provisions of the Cures Act (84 FR 7510). We do not use these ONC program-specific terms in this CMS rule. We simply refer to any developer of a third-party app, of which an electronic record systems developer may be one.
                    </P>
                    <FTNT>
                        <P>
                            <SU>18</SU>
                             See Office of the National Coordinator. (n.d.). Health Information Technology. Retrieved from 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/health-information-technology/index.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested clarification on a covered entity's liability under HIPAA if a patient transfers their health information from a covered entity's mobile access portal or application to a third-party application not covered under HIPAA.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As noted above, HIPAA covered entities and business associates are responsible for meeting their HIPAA privacy and security obligations to protect patient data they maintain, and absent patient requests to the contrary, are obligated to take reasonable measures to protect these data in transit. Once these data are received by a third-party and no longer under the control of the covered entity or its business associate, the covered entity and business associate are not liable for the privacy and security of the PHI or any electronic health information sent. While HIPAA covered entities and their business associates may notify patients of their potential concerns regarding exchanging data with a specific third-party not covered by HIPAA, they are not required to do so, and they may not substitute their own judgment for that of the patient requesting the data be transferred.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters recommended that CMS include a safe harbor provision in the regulatory text of this final rule to indicate that plans and providers are not responsible for the downstream privacy and security of PHI.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Regarding commenters' interest in a “safe harbor” provision for covered entities when data is transmitted to a third-party app, we do not have the authority, nor do we believe it is necessary, to incorporate these principles in a safe harbor provision under the HIPAA Privacy and Security Rules. Covered entities and business associates are not responsible for the data after the data have been received by the intended recipient. This has been taken into account in developing the requirements for the Patient Access API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters expressed concerns that app developers are not subject to many of the current laws protecting the privacy and security of electronic health information. Several commenters requested that HHS specify what requirements non-HIPAA covered app developers will be subject to.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7622), HIPAA protections do not extend to third-party apps (that is, software applications from entities that are not covered entities or business associates). However, the FTC has the authority to investigate and take action against unfair or deceptive trade practices under the FTC Act and the FTC Health Breach Notification Rule when a third-party app does not adhere to the stated privacy policy. We have shared these comments with the FTC. State laws may provide additional protections as well. 
                        <PRTPAGE P="25519"/>
                        Although CMS cannot regulate the third-party apps directly, and thus cannot establish specific requirements for them, we are sharing best practices and lessons learned from our experience with Blue Button 2.0, as applicable, with app developers to further support strong privacy and security practices: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index</E>
                        . Also, as previously noted, payers will be required to share educational resources with patients regarding how to choose a third-party application while protecting their health information. Further, as discussed in section III. of this final rule, we are providing payers with a framework they can use to request that third-party apps attest to covering certain criteria in their privacy policy, such as information about secondary data use, which payers can use to educate patients about their options.
                    </P>
                    <P>
                        In addition, there are technical requirements for APIs defined in the ONC 21st Century Cures Act proposed rule, and finalized by HHS in ONC's final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215, that enable and support persistent user authentication and app authorization processes. It is important to clarify that any app accessing the Patient Access API would be doing so only with the approval and at the direction of the specific patient. While these technical standards at 45 CFR 170.215 establish the requirements for the API itself, when implemented, these technical standards in turn set requirements on the app developer for the app's identity proofing and authentication processes that must be met in order to connect to the API and access the specific patient's data through the API, as further discussed in section III. of this final rule. These technical requirements do not, however, address concerns around data security and use once data are with the third-party. This level of privacy and security would be addressed in the app's terms and conditions or privacy notice.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed concern regarding the secondary use of health information by business partners of third-party applications. A few commenters noted that consumers may not always be aware of the business partners of third-party apps, especially as this information is typically part of a lengthy privacy notice or dense or difficult to understand terms and conditions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. As noted, we do not have the authority to directly regulate third-party apps. As a result, we cannot dictate how an app uses or shares data. We have chosen to require payers to educate patients about how to choose a third-party app that best mitigates potentially risks related to secondary data uses. One way we will address these concerns is to offer payers and app developers best practices from our own experiences using a patient-centered privacy policy, particularly related to Blue Button 2.0. As we discuss in section III.C.2.h. of this final rule, we recognize that the payers that will be subject to the API provisions of this final rule are in the best position to ensure that patients have the information that they need to critically assess the privacy and security of their designated third-party options, and may be best situated to identify for patients the potential implications of sharing data and to advise a patient if there is a breach of their data. This is why we proposed and are finalizing a requirement at 42 CFR 422.119(g), 431.60(f), 457.730(f), 438.242(b)(5) (proposed as § 438.242(b)(6) see section VI. in this rule), and 457.1233(d)(2), and 45 CFR 156.221(g), detailing the beneficiary and enrollee resources regarding consumer-friendly, patient facing privacy and security information that must be made available on the websites of the payers subject to this final rule. As discussed in greater detail in section III.C.2.h. of this final rule, CMS will be providing payers with suggested content they can consult and tailor as they work to produce the required patient resource document. We are also sharing best practices and links to model language of an easy-to-understand, non-technical, consumer-friendly privacy policy, again building off of our lessons learned with Blue Button 2.0, to support payers and developers in this effort: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index</E>
                        . Also, as noted above, we discuss in section III. of this final rule, a framework payers can use to request that third-party apps attest to covering certain criteria in their privacy policy, such as information about secondary data use. It will be important to encourage patients' understanding of app privacy policies, including secondary use policies. The policies we are finalizing in this rule help us support payers and developers as they work to make sure patients are informed consumers through education and awareness, and that patients understand their rights.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters expressed concerns over the complexity of overlapping federal and state privacy laws, which they noted would be perpetuated by uncertainty in privacy and security requirements when apps become more widely used in the health care space. These commenters requested work be done to harmonize state and federal privacy laws. Another commenter recommended that Congress enact comprehensive consumer privacy protections.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate these commenters' concerns and recommendations. However, these comments are beyond the scope of this regulation.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters recommended that CMS work closely with other HHS agencies and the FTC to establish a transparent regulatory framework for safeguarding the privacy and security of patient electronic health information shared with apps. A few commenters recommended CMS establish workgroups to share experiences and technical assistance for implementing privacy and security approaches.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' suggestions. As noted above, we have shared commenter's concerns with the FTC and relevant HHS Operating Divisions, such as OCR.
                    </P>
                    <HD SOURCE="HD3">3. Specific Technical Approach and Standards</HD>
                    <P>Achieving interoperability throughout the health system is essential to achieving an effective, value-conscious health system within which consumers are able to choose from an array of health plans and providers. An interoperable system should ensure that consumers can both easily access their electronic health information held by plans and routinely expect that their claims, encounter, and other relevant health history information will follow them smoothly from plan to plan and provider to provider without burdensome requirements for them or their providers to reassemble or re-document the information. Ready availability of health information can be especially helpful when an individual cannot access their usual source of care, for instance if care is needed outside their regular provider's business hours, while traveling, or in the wake of a natural disaster.</P>
                    <P>
                        The proposals described in section III.C.2. of the CMS Interoperability and Patient Access proposed rule (84 FR 7628 through 7639) would impose new requirements on MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs (excluding issuers offering only SADPs or issuers in the FF-SHOP, 
                        <PRTPAGE P="25520"/>
                        unless otherwise noted) to implement standardized, transparent APIs. Using the API, these entities would be required to provide current enrollees with specified claims and encounter data and certain clinical information if such information is maintained. We proposed that these entities would also be required to make available through the API information already required to be widely available, including provider directory and plan coverage information, such as formulary information. In developing the proposal delineating the information that would be required to be made available through an API, consistent with the proposed technical requirements, we were guided by an intent to have available through the API all of the individual's electronic health information held by the payer in electronic format that is compatible with the API or that can, through automated means, be formatted to be accurately rendered through the API. We were also guided by an intent to make available through standardized, secure API technology all of the provider directory and formulary information maintained by the impacted payers that can be made compatible with the API.
                    </P>
                    <P>
                        Both the API technology itself and the data it makes available must be standardized to support true interoperability. Therefore, as discussed in detail in the proposed rule, we proposed to require compliance with both (1) ONC's 21st Century Cures Act rule proposed regulations regarding content and vocabulary standards for representing electronic health information as finalized and (2) technical standards for an API by which the electronic health information would be required to be made available as finalized. For the proposals described in section III.C.2.b. of the CMS Interoperability and Patient Access proposed rule (which addressed transmissions for purposes 
                        <E T="03">other than</E>
                         those covered by HIPAA transaction standards, with which all the payers subject to this final rule will continue to be required to comply under 45 CFR part 162), we proposed requiring compliance with the interoperability standards proposed for HHS adoption in the ONC 21st Century Cures Act proposed rule (84 FR 7424) as finalized.
                    </P>
                    <P>In proposing to require that regulated entities comply with ONC-proposed regulations for non-HIPAA covered transactions (84 FR 7424) and therefore, requiring the use of specified standards, we noted that we intended to preclude regulated entities from implementing API technology using alternative technical standards to those ONC proposed for HHS adoption at 45 CFR 170.215, which details the API technical standards, including the use of FHIR. Other technical standards that would be precluded include, but are not limited to, those not widely used to exchange electronic health information in the U.S. health system. We further noted that we intended to preclude entities from using earlier versions of the technical standards adopted at 45 CFR 170.215 by requiring compliance with only specified provisions of 45 CFR part 170, and deliberately excluding others. We also discussed how by proposing to require use of the proposed content and vocabulary standards as finalized by requiring compliance with 42 CFR 423.160 and 45 CFR part 162, and proposed at 45 CFR 170.213, we intended to prohibit use of alternative standards that could potentially be used for these same data classes and elements, as well as earlier versions of the adopted standards named in 42 CFR 423.160, 45 CFR part 162, and proposed at 45 CFR 170.213.</P>
                    <P>While we generally intended to preclude regulated entities from using content and vocabulary standards other than those described in 42 CFR 423.160, 45 CFR part 162, or proposed 45 CFR 170.213 (and technical standards at 45 CFR 170.215), we recognized there may be circumstances that render the use of other content and vocabulary alternatives necessary. As discussed below, we proposed to allow the use of alternative content and vocabulary standards in two circumstances. First, where other content or vocabulary standards are expressly mandated by applicable law, we proposed to permit use of those other mandated standards. Second, where no appropriate content or vocabulary standard exists within 45 CFR part 162, 42 CFR 423.160, or proposed 45 CFR 170.213 and 170.215, we proposed we would permit use of any suitable gap-filling options, as may be applicable to the specific situation.</P>
                    <P>We used two separate rulemakings because the 21st Century Cures Act proposed rule (84 FR 7424), which included API interoperability standards proposed for HHS adoption, would have broader reach than the scope of the CMS Interoperability and Patient Access proposed rule (84 FR 7610). At the same time, we wished to assure stakeholders that the API standards required of MA organizations, state Medicaid agencies, state CHIP agencies, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs under the proposal would be consistent with the API standards proposed by ONC for HHS adoption because we would require that the regulated entities follow specified, applicable provisions of the ONC-proposed requirements as finalized.</P>
                    <P>Requiring that CMS-regulated entities comply with the regulations regarding standards finalized by HHS in ONC's 21st Century Cures Act rule will support greater interoperability across the health care system, as health IT products and applications that would be developed for different settings and use cases would be developed according to a consistent base of standards that supports more seamless exchange of information. In the CMS Interoperability and Patient Access proposed rule, we welcomed public comment on our proposal to require compliance with the standards proposed for adoption by HHS through ONC's 21st Century Cures Act proposed rule, as well as on the best method to provide support in identifying and implementing the applicable content and vocabulary standards for a given data element.</P>
                    <P>
                        Finally, while noting that we believed that the proposal to require compliance with the standards proposed by ONC for HHS adoption was the best approach, we sought public comment on any alternative by which CMS would separately adopt the standards proposed for adoption in the ONC 21st Century Cures Act proposed rule and identified throughout the CMS Interoperability and Patient Access proposed rule, as well as future interoperability, content, and vocabulary standards. We stated that we anticipated any alternative would include incorporating by reference the FHIR R2, R3, and/or R4 based on comments and OAuth 2.0 technical standards and the USCDI version 1 content and vocabulary standard (described in sections II.A.3.b. and II.A.3.a. of the CMS Interoperability and Patient Access proposed rule, respectively) in CMS regulation to replace the proposed references to ONC regulations at 45 CFR 170.215, 170.213, and 170.205, respectively. However, we specifically sought comment on whether this alternative would present an unacceptable risk of creating multiple regulations requiring standards or versions of standards across HHS' programs, and an assessment of the benefits or burdens of separately adopting new standards and incorporating updated versions of standards in CFR text on a program by program basis. Furthermore, we sought comment on: How such an option might impact health IT development timelines; how potentially creating multiple regulations regarding standards over time across HHS might impact system implementation; and other 
                        <PRTPAGE P="25521"/>
                        factors related to the technical aspect of implementing these requirements.
                    </P>
                    <P>We summarize the public comments we received regarding separately adopting standards in this CMS rule and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported CMS' proposed alignment with the standards proposed in ONC's 21st Century Cures Act proposed rule to be adopted by HHS to promote interoperability, noting it was the most effective and efficient approach. Commenters explained that this alignment was critical to ensure interoperability across the health care industry, and overwhelmingly preferred “one source of truth” for all standards referenced in the CMS Interoperability and Patient Access proposed rule. These commenters explained having highly technical standards, including content and vocabulary standards, in different CMS and ONC regulations would create the potential for error and misalignment of standards or versions of standards across HHS programs. Commenters supported alignment across agencies, and indicated concern that if the standards were adopted in different regulations, it would complicate the process of updating the standards when necessary, and increase the cost and burden of data capture, data management, and data exchange. Commenters did note opportunities for even greater alignment across the CMS and ONC rulemakings at the data element level, indicating that the ONC rule should include all data elements required in the CMS rule, specifically calling out data elements in an Explanation of Benefits (EOB) not specifically included in the USCDI (proposed for codification at 45 CFR 170.213).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support for alignment of the regulations adopted in this final rule with the standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). We agree that the best way to ensure continued alignment is to have the regulations we are adopting here—governing MA organizations, state Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and QHP issuers on the FFEs—cross reference the specific regulations codifying the standards adopted by HHS in the ONC 21st Century Cures Act final rule. Our intent is to ensure alignment and consistent standards across the regulated programs. We agree that this will help support interoperability across the health care industry and help set clear and consistent goals for all payers, providers, vendors, and developers. CMS and ONC will continue to coordinate closely on standards, including content and vocabulary standards and impacted data elements and use cases, and we will continue to work closely with all stakeholders to ensure that this process is consensus-based. Regarding the recommendation to add data elements from the EOB not yet included in the USCDI, we have shared these recommendations with ONC, and we refer readers to the discussion in ONC's 21st Century Cures Act final rule on the USCDI and the Standards Version Advancement Process (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ).
                    </P>
                    <HD SOURCE="HD2">B. Content and Vocabulary Standards</HD>
                    <P>
                        The content and vocabulary standards HHS ultimately adopts applicable to the data provided through the standards-based API will, by necessity, vary by use case and within a use case. For instance, content and vocabulary standards supporting consumer access vary according to what specific data elements MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs have available electronically. Where another law does not require use of a specific standard, we proposed to require use of, in effect, a catalogue of content and vocabulary standards from which the regulated entities may choose in order to satisfy the proposed requirements in 42 CFR 422.119, 431.60, 457.730, 438.252, and 457.1233, and 45 CFR 156.221. A further discussion of these proposals can be found in section II.B. of the CMS Interoperability and Patient Access proposed rule (84 FR 7623 through 7624). These proposals are detailed in section III.C.2.b. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639), and comments received on these proposals are summarized with our responses in section III.C.2.b. of this final rule. Specifically, we note that we proposed to adopt the content and vocabulary standards as finalized by HHS in ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.213. This standard is currently the USCDI version 1.
                    </P>
                    <HD SOURCE="HD2">C. Application Programming Interface (API) Standard</HD>
                    <P>
                        In section III.C.2.b. of the CMS Interoperability and Patient Access proposed rule, we proposed to require compliance with the API technical standard proposed by ONC for HHS adoption at 45 CFR 170.215 as finalized (84 FR 7589). By requiring compliance with 45 CFR 170.215, we proposed to require use of the foundational Health Level 7® (HL7) 
                        <SU>19</SU>
                        <FTREF/>
                         Fast Healthcare Interoperability Resources® (FHIR) standard,
                        <SU>20</SU>
                        <FTREF/>
                         several implementation specifications specific to FHIR, and complementary security and app registration protocols, specifically the Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Implementation Guide (IG) 1.0.0 (including mandatory support for “refresh tokens,” “Standalone Launch,” and “EHR Launch” requirements), which is a profile of the OAuth 2.0 specification, as well as the OpenID Connect Core 1.0 standard, incorporating errata set 1. A further discussion of these proposals can be found in section II.C. (84 FR 7624 through 7625) and the proposals are detailed in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639). Comments received on these proposals are summarized with our responses in section III. of this final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>19</SU>
                             Health Level Seven International® (HL7) is a not-for-profit, ANSI-accredited standards development organization (SDO) focused on developing consensus standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. Learn more at “About HL7” web page, last accessed 06/27/2018.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>20</SU>
                             
                            <E T="03">FHIR Overview. (n.d.). Retrieved from https://www.hl7.org/fhir/overview.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We proposed to adopt the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215. HHS is finalizing adoption of HL7 FHIR Release 4.0.1 as the foundational standard for APIs at 45 CFR 170.215(a)(1). Instead of the Argonaut IG and server to support exchange of the USCDI proposed at 45 CFR 170.215(a)(3) and (a)(4) (84 FR 7424), HHS is finalizing the HL7 FHIR US Core IG STU 3.1.0 at 45 CFR 170.215(a)(2). The HL7 SMART Application Launch Framework IG Release 1.0.0 was proposed at 45 CFR 170.215(a)(5) (84 FR 7424). HHS is finalizing the HL7 SMART Application Launch Framework IG Release 1.0.0 (which is a profile of the OAuth 2.0 specification), including mandatory support for the “SMART on FHIR Core Capabilities,” at 45 CFR 170.215(a)(3). HHS is finalizing as proposed adoption of OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(b), as well as adoption of version 1.0.0: STU 1 of the FHIR Bulk Data Access specification at 45 CFR 
                        <PRTPAGE P="25522"/>
                        170.215(a)(4). HHS is not finalizing the adoption of FHIR Release 2 or FHIR Release 3, API Resource Collection in Health (ARCH) Version 1, or the HL7 Consent2Share FHIR Consent Profile Design that were proposed at 45 CFR 170.215(a)(1), (c)(1), (a)(2), or (c)(2), respectively (84 FR 7424). For a full discussion, see the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). The content and vocabulary standards and technical standards finalized by HHS in the ONC 21st Century Cures Act final rule provide the foundation needed to support implementation of the policies as proposed and now finalized in this rule.
                    </P>
                    <HD SOURCE="HD2">D. Updates to Standards</HD>
                    <P>In addition to efforts to align standards across HHS, we recognized in the proposed rule that while we must codify in regulation a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulatory text. To address how standards development can outpace our rulemaking schedule, we proposed in section III.C.2.b. of the CMS Interoperability and Patient Access proposed rule (84 FR 7630 through 7631) that regulated entities may use updated versions of required standards if use of the updated version is required by other applicable law. In addition, under certain circumstances, we proposed to allow use of an updated version of a standard if the standard is not prohibited under other applicable law.</P>
                    <P>
                        For content and vocabulary standards at 45 CFR part 162 or 42 CFR 423.160, we proposed to allow the use of an updated version of the content or vocabulary standard adopted under rulemaking, unless the use of the updated version of the standard: Is prohibited for entities regulated by that part or the program under that section; Is prohibited by the Secretary for purposes of these policies or for use in ONC's Health IT Certification Program; or is precluded by other applicable law. We remind readers that other applicable law includes statutes and regulations that govern the specific entity. For the content and vocabulary standards proposed by ONC for HHS adoption at 45 CFR 170.213 (84 FR 7589) (currently, USCDI version 1),
                        <SU>21</SU>
                        <FTREF/>
                         as well as for API technical standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589) (including HL7 FHIR and other standards and implementation guides (IGs) as discussed above),
                        <SU>22</SU>
                        <FTREF/>
                         we proposed to allow the use of an updated version of a standard adopted by HHS, provided such updated version has been approved by the National Coordinator through the Standards Version Advancement Process described in the ONC 21st Century Cures Act proposed rule (84 FR 7424), as finalized. A further discussion of these proposals can be found in section II.D. of the CMS Interoperability and Patient Access proposed rule (84 FR 7625 through 7626). These proposals are also detailed in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639), and comments received on these proposals are summarized with our responses in section III. of this final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>21</SU>
                             For more information on the USCDI, see 
                            <E T="03">https://www.healthit.gov/USCDI</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>22</SU>
                             For more information on FHIR, see 
                            <E T="03">https://www.hl7.org/fhir/overview.html</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD1">III. Provisions of Patient Access Through APIs, and Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Background on Medicare Blue Button</HD>
                    <P>
                        As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7626), we are committed to advancing interoperability, putting patients at the center of their health care, and ensuring they have simple and easy access, without special effort, to their health information. With the establishment of the initial Medicare Blue Button® service in 2010, Medicare beneficiaries became able to download their Part A, Part B, and Part D health care claims and encounter data through 
                        <E T="03">MyMedicare.gov</E>
                         in either PDF or text format. While the original Blue Button effort was a first step toward liberating patient health information, we recognized that significant opportunities remain to modernize access to that health information and the ability to share health information across the health ecosystem. We believe that moving to a system in which patients have access to and use of their health information will empower them to make better informed decisions about their health care. Additionally, interoperability, and the ability for health information systems and software applications to communicate, exchange, and interpret health information in a usable and readable format, is vital to improving health care. Allowing access to health information only through PDF and text formats limit the utility of and the ability to effectively share the health information.
                    </P>
                    <P>Medicare Blue Button 2.0 is a new, modernized version of the original Blue Button service. It enables beneficiaries to access their Medicare Parts A, B, and D claims and encounter data and share that electronic health information through an Application Programming Interface (API) with applications, services, and research programs they select. As discussed in section II.A. of the CMS Interoperability and Patient Access proposed rule (see 84 FR 7618 through 7623), API technology allows software from different developers to connect with one another and exchange electronic health information in electronic formats that can be more easily compiled and leveraged by patients and their caregivers. Beneficiaries may also select third-party applications to compile and leverage their electronic health information to help them manage their health and engage in a more fully informed way in their health care.</P>
                    <P>
                        Today, Blue Button 2.0 contains 4 years of Medicare Part A, B, and D data for 53 million Medicare beneficiaries. These data are available to patients to help them make more informed decisions. Beneficiaries dictate how their data can be used and by whom, with identity and authorization controlled through 
                        <E T="03">MyMedicare.gov</E>
                        . Medicare beneficiaries can authorize sharing their information with an application using their 
                        <E T="03">MyMedicare.gov</E>
                         account information. Beneficiaries authorize each application, service, or research program they wish to share their data with individually. A beneficiary can go back to 
                        <E T="03">MyMedicare.gov</E>
                         at any time and change the way an application uses their information. Using Blue Button 2.0, beneficiaries can access their health information; share it with doctors, caregivers, or anyone they choose; and get help managing and improving their health through a wide range of apps and other computer-based services. Blue Button 2.0 is an optional service—beneficiaries choose the apps and services they want to use.
                    </P>
                    <P>
                        Today, Medicare beneficiaries using Blue Button 2.0 can connect with apps that keep track of tests and services they need and receive reminders, track their medical claims, make appointments and send messages to their doctors, get personalized information about their symptoms and medical conditions, find health and drug plans, keep track of their medical notes and questions, and connect to research projects.
                        <SU>23</SU>
                        <FTREF/>
                         These are 
                        <PRTPAGE P="25523"/>
                        just some of the ways Blue Button 2.0 is using a standards-based, FHIR-enabled API to lead the charge and unleash the power of health data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>23</SU>
                             To review a list of apps currently available to Blue Button 2.0 users, visit 
                            <E T="03">
                                https://
                                <PRTPAGE/>
                                www.medicare.gov/manage-your-health/medicares-blue-button-blue-button-20/blue-button-apps
                            </E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">B. Expanding the Availability of Health Information</HD>
                    <HD SOURCE="HD3">1. Patient Benefits of Information Access</HD>
                    <P>As discussed in the CMS Interoperability and Patient Access proposed rule, we believe there are numerous benefits associated with individuals having simple and easy access to their health care data under a standard that is widely used. Whereas EHR data are frequently locked in closed, disparate health systems, care and treatment information in the form of claims and encounter data is comprehensively combined in a patient's claims and billing history. Claims and encounter data, used in conjunction with EHR data, can offer a broader and more holistic understanding of an individual's interactions with the health care system than EHR data alone. As one example, inconsistent benefit utilization patterns in an individual's claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance. Identifying and finding opportunities to address the individual's non-adherence to a care plan are critical to keeping people with chronic conditions healthy and engaged so they can avoid hospitalizations. While a health plan can use claims and encounter data to help it identify which enrollees could benefit from an assessment of why they are not filling their prescriptions or who might be at risk for particular problems, putting this information into the hands of the individual's chosen care provider—such as the doctor or nurse practitioner prescribing the medications or the pharmacist who fills the prescriptions—helps them to engage the patient in shared decision making that can help address some of the reasons the individual might not be willing or able to take medications as prescribed. By authorizing their providers to access the same information through a standards-based API, individuals can further facilitate communication with their care teams. Enabling the provider to integrate claims and encounter information with EHR data gives the provider the ability to use the combined information, with relevant clinical decision support tools, as part of normal care delivery in a less burdensome way, leading to improved care. This may be particularly important during times of system surge, an event that generates a large and sudden demand for health services, for example, when access to such information may help to inform patient triage, transfer, and care decisions.</P>
                    <P>Further, we noted that we believe patients who have immediate electronic access to their health information are empowered to make more informed decisions when discussing their health needs with providers, or when considering changing to a different health plan. We discussed that currently not all beneficiaries enrolled in MA plans have immediate electronic access to their claims and encounter data and those who do have it, cannot easily share it with providers or others. The same is true of Medicaid beneficiaries and CHIP enrollees, whether enrolled in FFS or managed care programs, and enrollees in QHPs on the FFEs. As industries outside of health care continue to integrate multiple sources of data to understand and predict their consumers' needs, we believe it is important to position MA organizations, Medicaid and CHIP FFS programs and managed care entities, and QHP issuers on the FFEs to do the same to encourage competition, innovation, and value.</P>
                    <P>We noted that CMS has programmatic authority over MA organizations, Medicaid programs (both FFS and managed care), CHIP (both FFS and managed care), and QHP issuers on the FFEs. We proposed to leverage CMS authority to make claims and encounter data available through APIs as a means to further access for patients in these programs along with other plan data (such as provider directory data) as detailed in sections III.C. and IV. of the CMS Interoperability and Patient Access proposed rule. For a complete discussion of these proposals, see the proposed rule (84 FR 7626 through 7640).</P>
                    <HD SOURCE="HD3">2. Alignment with the HIPAA Right of Access</HD>
                    <P>
                        As discussed in section II. of this final rule, the recent decision in 
                        <E T="03">Ciox Health, LLC</E>
                         v. 
                        <E T="03">Azar, et al.</E>
                         vacates a portion of the HIPAA Privacy Rule that provides an individual the right to direct a covered entity to send protected health information that is not in an EHR to a third party identified by the individual. It does not alter a patient's right to request access to their records. In addition, the decision does not affect CMS' programmatic authorities, as discussed in detail in section III. of the CMS Interoperability and Patient Access proposed rule (83 FR 7629 through 7630) and later in this section of this final rule. Prior to this decision, in the CMS Interoperability and Patient Access proposed rule, we discussed that the HIPAA Privacy Rule, at 45 CFR 164.524, provides that an individual has a right of access to inspect and obtain a copy of their PHI 
                        <SU>24</SU>
                        <FTREF/>
                         that is maintained by or on behalf of a covered entity (a health plan or covered health care provider 
                        <SU>25</SU>
                        <FTREF/>
                        ) in a designated record set.
                        <SU>26</SU>
                        <FTREF/>
                         It was noted that, at that time, a covered entity was required to provide the access in any readily producible form and format requested by the individual, and that the right of access also includes individual's right to direct a covered entity to transmit PHI directly to a third party the individual designates to receive it.
                        <SU>27</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>24</SU>
                             
                            <E T="03">See</E>
                             45 CFR 160.103, definition of protected health information.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>25</SU>
                             The third type of HIPAA covered entity, a health care clearinghouse, is not subject to the same requirements as other covered entities with respect to the right of access. 
                            <E T="03">See</E>
                             45 CFR 164.500(b).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.501, definition of designated record set.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>27</SU>
                             For more information, see 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We explained that software applications using the Patient Access API proposed at 42 CFR 422.119, 431.60, 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), 457.730, and 457.1233(d)(2), and 45 CFR 156.221, and further discussed below, would provide an additional mechanism through which the individuals who so choose could exercise the HIPAA right of access to their PHI, by giving them a simple and easy electronic way to request, receive, and share data they want and need, including with a designated third party. However, as discussed in section II. of the CMS Interoperability and Patient Access proposed rule (84 FR 7621 through 7622), due to limitations in the current availability of interoperability standards for some types of health information, or data, we noted the API requirement may not be sufficient to support access to all of the PHI subject to the HIPAA right of access because a patient's PHI may not all be transferable through the API. For instance, we proposed to require payers to make claims and encounter data as well as a specified set of clinical data (that is, clinical data maintained by the applicable payer in the form of the USCDI version 1 data set) available through the Patient Access API. 
                        <PRTPAGE P="25524"/>
                        However, a patient may request access to an X-ray image as well. Currently, the X-ray image itself is not captured under the USCDI version 1 data set, and though the necessary FHIR resources to share this information via an API like the Patient Access API are available, use is not required under this rulemaking and so a payer may not be able to share such information via the API. Therefore, under our proposal, a HIPAA covered entity would have to share this type of information in a form and format other than the Patient Access API in order to comply with our program proposals and in keeping with the HIPAA Privacy Rule right of access.
                    </P>
                    <HD SOURCE="HD2">C. Standards-Based API Proposal for MA, Medicaid, CHIP, and QHP Issuers on the FFEs</HD>
                    <HD SOURCE="HD3">1. Introduction</HD>
                    <P>We proposed to add new provisions at 42 CFR 422.119, 431.60, 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.), 457.730, 457.1233(d), and 45 CFR 156.221, that would, respectively, require each MA organization, Medicaid FFS program, Medicaid managed care plan, CHIP FFS program, CHIP managed care entity, and QHP issuer on an FFE to implement, test, and monitor a standards-based API that is accessible to third-party applications and developers. We noted that states with CHIPs were not required to operate FFS systems and that some states' CHIPs were exclusively operated by managed care entities. We did not intend to require CHIPs that do not operate a FFS program to establish an API; rather, we noted that these states may rely on each of their contracted plans, referred to throughout the CMS Interoperability and Patient Access proposed rule and this final rule as CHIP managed care entities, to set up such a system.</P>
                    <P>As discussed, the API would allow enrollees and beneficiaries of MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to exercise their HIPAA right of access to certain health information specific to their plan electronically, through the use of common technologies and without special effort. We explained how “common technologies,” for purposes of the proposal, means those that are widely used and readily available, such as computers, smartphones, or tablets.</P>
                    <P>The proposals are detailed in section III.C. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639), and comments received on these proposals and our responses are noted below in this final rule.</P>
                    <HD SOURCE="HD3">2. The Standards-Based API Proposal</HD>
                    <P>In the proposed rule, we addressed the following components of the standards-based API. Specifically, we discussed:</P>
                    <P>• Authority to require implementation of a standards-based API by MA organizations, Medicaid and CHIP state agencies, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs;</P>
                    <P>• The API technical standard and content and vocabulary standards;</P>
                    <P>• Data required to be available through the standards-based API and timeframes for data availability;</P>
                    <P>• Documentation requirements for APIs;</P>
                    <P>• Routine testing and monitoring of standards-based APIs;</P>
                    <P>• Compliance with existing privacy and security requirements;</P>
                    <P>• Denial or discontinuation of access to the API;</P>
                    <P>• Enrollee and beneficiary resources regarding privacy and security;</P>
                    <P>• Exceptions or provisions specific to certain programs or sub-programs; and</P>
                    <P>• Applicability and timing.</P>
                    <FP>We also included an RFI on information sharing between payers and providers through APIs.</FP>
                    <P>Specifically, we proposed nearly identical language for the regulations requiring standards-based APIs at 42 CFR 422.119; 431.60, and 457.730, and 45 CFR 156.221 for MA organizations, Medicaid state agencies, state CHIP agencies, and QHP issuers on the FFEs; Medicaid managed care plans would be required, at 42 CFR 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), to comply with the requirement at 42 CFR 431.60, and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730. As discussed in detail in the CMS Interoperability and Patient Access proposed rule, we proposed similar if not identical requirements for these various entities to establish and maintain a standards-based API, make specified data available through that API, disclose API documentation, provide access to the API, and make resources available to enrollees. We noted that we believed that such nearly identical text is appropriate as the reasons and need for the proposal and the associated requirements are the same across these programs. We intended to interpret and apply the regulations proposed in section III.C. of the CMS Interoperability and Patient Access proposed rule similarly and starting with similar text is an important step to communicate that to the applicable entities that would be required to comply (except as noted below with regard to specific proposals).</P>
                    <P>In paragraph (a) of each applicable proposed regulation, we proposed that the regulated entity (that is, the MA organization, the state Medicaid or CHIP agency, the Medicaid managed care plan, the CHIP managed care entity, or the QHP issuer on an FFE, as applicable) would be required to implement and maintain a standards-based API that permits third-party applications to retrieve, with the approval and at the direction of the individual patient, data specified in paragraph (b) of each regulation through the use of common technologies and without special effort from the beneficiary. By “common technologies and without special effort” by the enrollee, we explained that the regulation means use of common consumer technologies, like smart phones, home computers, laptops, or tablets, to request, receive, use, and approve transfer of the data that would be available through the standards-based API technology. By “without special effort,” we proposed to codify our expectation that third-party software, as well as proprietary applications and web portals operated by the payer could be used to connect to the API and provide access to the data to the enrollee. In the CMS Interoperability and Patient Access proposed rule (84 FR 7628 through 7638), we addressed the data that must be made available through the API in paragraph (b); the regulation regarding the technical standards for the API and the data it contains in paragraph (c); the documentation requirements for the API in paragraph (d); explicit authority for the payer regulated under each regulation to deny or discontinue access to the API in paragraph (e); and, requirements for posting information about resources on security and privacy for beneficiaries in paragraphs (f) or (g). Additional requirements specific to certain programs, discussed in sections IV. and V. of the CMS Interoperability and Patient Access proposed rule, were also included in some of the regulations that address the API. We address those additional requirements in sections IV. and V. of this final rule.</P>
                    <HD SOURCE="HD3">a. Authority To Require Implementation of a Standards-Based API</HD>
                    <P>
                        As noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7629 through 7630), the proposal would apply to MA organizations, Medicaid 
                        <PRTPAGE P="25525"/>
                        state agencies and managed care plans, state CHIP agencies and managed care entities, and QHP issuers on the FFEs. We noted that the proposal for Medicaid managed care plans, at 42 CFR 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), would require MCOs, PIHPs, and PAHPs to comply with the regulation that we proposed for Medicaid state agencies at 42 CFR 431.60 as if that regulation applied to the Medicaid managed care plan. Similarly, we intended for CHIP managed care entities to comply with the requirements we proposed at 42 CFR 457.730 via the regulations proposed at 42 CFR 457.1233(d)(2). We proposed to structure the regulations this way to avoid ambiguity and to ensure that the API proposal would result in consistent access to information for Medicaid beneficiaries and CHIP enrollees, regardless of whether they are in a FFS delivery system administered by the state or in a managed care delivery system. We noted that CHIP currently adopts the Medicaid requirements at 42 CFR 438.242 in whole. We proposed revisions to 42 CFR 457.1233(d)(1) to indicate CHIP's continued adoption of 42 CFR 438.242(a), (b)(1) through (5), (c), (d), and (e), while we proposed specific text for CHIP managed care entities to comply with the regulations proposed at 42 CFR 457.1233(d)(2) in lieu of the proposed Medicaid revision, which we noted would add 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.). In our discussion of the specifics of the proposal and how we proposed to codify it at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221, we referred in the CMS Interoperability and Patient Access proposed rule and refer in this final rule only generally to 42 CFR 438.242(b)(5) (proposed as 438.242(b)(6); see section VI.) and 457.1233(d)(2) for this reason.
                    </P>
                    <HD SOURCE="HD3">(1) Medicare Advantage</HD>
                    <P>Sections 1856(b) and 1857(e) of the Social Security Act (the Act) provide CMS with the authority to add standards and requirements for MA organizations that the Secretary finds necessary and appropriate and not inconsistent with Part C of the Medicare statute. In addition, section 1852(c) of the Act requires disclosure by MA organizations of specific information about the plan, covered benefits, and the network of providers; section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information. The information required to be made available under these authorities through the APIs in this final rule is within the scope of information that MA organizations must make available under section 1852(c) and (h) of the Act and the implementing regulations at 42 CFR 422.111 and 422.118. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered “timely.” Thus, we noted in the CMS Interoperability and Patient Access proposed rule our belief that to align the standards with 21st century demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. We further noted that the proposed requirements were intended to achieve this goal by providing patients access to their health information through third-party apps retrieve data via the required APIs.</P>
                    <P>The CMS Interoperability and Patient Access proposed rule provisions for MA organizations relied on our authority in sections 1856(b) and 1857(e) of the Act (which provide CMS with the authority to add standards and requirements for MA organizations), and explained how the information to be provided is consistent with the scope of disclosure under section 1852(c) and (h) of the Act, to propose that MA organizations make specific types of information, at minimum, accessible through a standards-based API and require timeframes for update cycles. Requirements for the Patient Access API further implement and adopt standards for how MA organizations must ensure enrollee access to medical records or other health information as required by section 1852(h) of the Act. Similarly, the Provider Directory API is a means to implement the disclosure requirements in section 1852(c) regarding plan providers. Throughout section III.C. of the CMS Interoperability and Patient Access proposed rule, we explained how and why the standards-based API proposal was necessary and appropriate for MA organizations and the MA program. We discussed how these requirements would give patients simple and easy access to their health information through common technologies, such as smartphones, tablets, or laptop computers, without special effort on the part of the user by facilitating the ability of patients to get their health information from their MA organization through a user-friendly third-party app. The goals and purposes of achieving interoperability for the health care system as a whole are equally applicable to MA organizations and their enrollees. Thus, the discussion in section II. of the CMS Interoperability and Patient Access proposed rule served to provide further explanation as to how a standards-based API proposal is necessary and appropriate in the MA program. In addition, we noted that having easy access to their claims, encounter, and other health information would also facilitate beneficiaries' ability to detect and report fraud, waste, and abuse—a critical component of an effective programs.</P>
                    <P>To the extent necessary, we also relied on section 1860D-12(b)(3) of the Act to add provisions specific to the Part D benefit offered by certain MA organizations; that provision incorporates the authority to add program requirements to the contracts from section 1857(e)(1) of the Act. For MA organizations that offer MA Prescription Drug plans, we proposed requirements in 42 CFR 422.119(b)(2) regarding electronic health information for Part D coverage. We explained that this proposal was supported by the disclosure requirements imposed under section 1860D-4(a) of the Act, requiring Part D claims information, pharmacy directory information, and formulary information to be disclosed to enrollees. Also, we note here that 42 CFR 423.136(d) requires Part D plans to ensure timely access by enrollees to the records and information that pertain to them. The APIs in this rule further implement and build on these authorities for ensuring that Part D enrollees have access to information.</P>
                    <HD SOURCE="HD3">(2) Medicaid and CHIP</HD>
                    <P>We proposed new provisions at 42 CFR 431.60(a), 457.730, 438.242(b)(6) (finalized as 42 CFR 438.242(b)(5) in this rule; see section VI.), and 457.1233(d)(2) that would require states administering Medicaid FFS or CHIP FFS, Medicaid managed care plans, and CHIP managed care entities to implement a standards-based API that permits third-party applications with the approval and at the direction of the beneficiary or enrollee to retrieve certain standardized data. The proposed requirement would provide Medicaid beneficiaries' and CHIP enrollees simple and easy access to their information through common technologies, such as smartphones, tablets, or laptop computers, and without special effort on the part of the user.</P>
                    <P>
                        For Medicaid, we proposed these new requirements under our authority under section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient 
                        <PRTPAGE P="25526"/>
                        operation of the plan, and section 1902(a)(19) of the Act, which requires that care and services be provided in a manner consistent with simplicity of administration and the best interests of the recipients. For CHIP, we proposed these requirements under the authority in section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. Together we noted that these proposals would provide us with authority (in conjunction with our delegation of authority from the Secretary) to adopt requirements for Medicaid and CHIP that are necessary to ensure the provision of quality care in an efficient and cost-effective way, consistent with simplicity of administration and the best interest of the beneficiary.
                    </P>
                    <P>We noted that we believed that requiring state Medicaid and CHIP agencies and managed care plans/entities to take steps to make Medicaid beneficiaries' and CHIP enrollees' claims, encounters, and other health information available through interoperable technology would ultimately lead to these enrollees accessing that information in a convenient, timely, and portable way, which is essential for these programs to be effectively and efficiently administered in the best interests of beneficiaries. Further, we noted that there are independent statutory provisions that require the disclosure and delivery of information to Medicaid beneficiaries and CHIP enrollees; the proposal would result in additional implementation of those requirements in a way that is appropriate and necessary in the 21st century. We also noted that we believed making this information available in APIs and ultimately apps may result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system, including Medicaid and CHIP. Having easy access to their claims, encounter, and other health information may also facilitate beneficiaries' ability to detect and report fraud, waste, and abuse—a critical component of an effective programs.</P>
                    <P>We discussed that as technology has advanced, we have encouraged states, health plans, and providers to adopt various forms of technology to improve the accurate and timely exchange of standardized health care information. We noted that the proposal would move Medicaid and CHIP programs in the direction of enabling better information access by Medicaid beneficiaries and CHIP enrollees, which would make them active partners in their health care by providing a way for them to easily monitor and share their data. By requiring that certain information be available in and through standardized formats and technologies, we noted that the proposal moved these programs toward interoperability, which is key for data sharing and access, and ultimately, improved health outcomes. We also noted that states would be expected to implement the CHIP provisions using CHIP administrative funding, which is limited under sections 2105(a)(1)(D)(v) and 2105(c)(2)(A) of the Act to 10 percent of a state's total annual CHIP expenditures.</P>
                    <HD SOURCE="HD3">(3) Qualified Health Plan Issuers on the Federally-Facilitated Exchanges</HD>
                    <P>We proposed a new QHP minimum certification standard at 45 CFR 156.221(a) that would require QHP issuers on the FFEs to implement a standards-based API that would permit third-party applications, with the approval and at the direction of the individual enrollee, to retrieve standardized data as specified in the proposal. We also proposed to require that the data be made available to QHP enrollees through common technologies, such as smartphones or tablets, and without special effort from enrollees.</P>
                    <P>We proposed the new requirements under our authority in section 1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation Act of 2010 (Pub. L. 111-148, enacted March 23, 2010, and Pub. L. 111-152, enacted March 30, 2010, respectively) (collectively referred to as the Affordable Care Act), which afforded the Exchanges the discretion to certify QHPs that are in the best interests of qualified individuals and qualified employers. Specifically, section 1311(e) of the Affordable Care Act authorized Exchanges to certify QHPs that meet the QHP certification standards established by the Secretary, and if the Exchange determined that making available such health plan through such Exchange is in the interests of qualified individuals and qualified employers in the state in which such Exchange operates.</P>
                    <P>In the CMS Interoperability and Patient Access proposed rule, we noted specifically in our discussion on QHP issuers on the FFEs, but applicable to all payers impacted by this rule, that we believe there are numerous benefits associated with individuals having access to their health plan data that is built upon widely used standards. The ability to easily obtain, use, and share claims, encounter, and other health data enables patients to more effectively and easily use the health care system. For example, by being able to easily access a comprehensive list of their adjudicated claims, patients can ensure their providers know what services they have already received, can avoid receiving duplicate services, and can help their providers verify when prescriptions were filled. We noted that we believe these types of activities would result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system. Having simple and easy access, without special effort, to their health information, including cost and payment information, also facilitates patients' ability to detect and report fraud, waste, and abuse—a critical component of an effective program. We noted that existing and emerging technologies provide a path to make information and resources for health and health care management universal, integrated, equitable, accessible to all, and personally relevant. Specifically, for QHP issuers on the FFEs, we stated that we believe generally certifying only health plans that make enrollees' health information available to them in a convenient, timely, and portable way is in the interests of qualified individuals and qualified employers in the state or states in which an FFE operates. We also noted we encouraged SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange.</P>
                    <P>We did not receive comments on the authorities discussed in this section to implement the Patient Access API. We are finalizing these provisions, with the modifications discussed in section III.C. of this rule, under this authority. Additionally, we are making two modifications to the regulation text to more clearly identify issuers subject to the regulation. First, we are modifying the scope of the applicability of the regulation to issuers on the individual market FFEs, effectively excluding issuers offered through the FF-SHOP, and we are explicitly excluding QHP issuers on the FFEs that only offer SADPs.</P>
                    <HD SOURCE="HD3">b. API Technical Standard and Content and Vocabulary Standards</HD>
                    <P>
                        We proposed to require compliance with 45 CFR 170.215 as finalized at 42 CFR 422.119(a) and (c), § 431.60(a) and (c), 457.730(a) and (c), 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.) and 457.1233(d)(2), and 45 CFR 156.221(a) and (c), so that MA organizations, Medicaid and CHIP FFS 
                        <PRTPAGE P="25527"/>
                        programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs implement standards-based API technology conformant with the API technical standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ), as discussed in section II.A.3. of the CMS Interoperability and Patient Access proposed rule and section II. of this final rule. We further proposed to require that the data available through the API be in compliance with the regulations regarding the following content and vocabulary standards, where applicable to the data type or data element, unless an alternate standard is required by other applicable law: Standards adopted at 45 CFR part 162 and 42 CFR 423.160; and standards finalized by HHS in the ONC 21st Century Cures Act final rule at 45 CFR 170.213 (USCDI version 1). See section II.A.3. of the CMS Interoperability and Patient Access proposed rule for further information about how entities subject to this rule would be required to utilize these standards. We proposed that both the API technical standard and the content and vocabulary standards would be required across the MA program, Medicaid program, and CHIP, and by QHP issuers on the FFEs.
                    </P>
                    <P>
                        With the proposed requirements to implement and maintain an API at 42 CFR 422.119(a), 431.60(a), and 457.730(a), we proposed corresponding requirements at 42 CFR 422.119(c) for MA plans, 431.60(c) for Medicaid FFS programs, and 457.730(c) for CHIP FFS programs implementing the proposed API technology. At proposed 42 CFR 422.119(c), 431.60(c), and 457.730(c), MA plans and the state Medicaid or CHIP agency (for states that operate CHIP FFS systems) would be required to implement, maintain, and use API technology conformant with the standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215; for data available through the API, to use content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and finalized at 45 CFR 170.213, unless alternate standards are required by other applicable law; and to ensure that technology functions in compliance with applicable law protecting the privacy and security of the data, including but not limited to 45 CFR parts 162, 42 CFR part 2, and the HIPAA Privacy and Security Rules.
                    </P>
                    <P>
                        We similarly proposed at 45 CFR 156.221(c) that QHP issuers on the FFEs must implement, maintain, and use API technology conformant with the API technical standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215; for data available through the API, use content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and finalized at 45 CFR 170.213, unless alternate standards are required by other applicable law; and ensure that technology functions in compliance with applicable law protecting the privacy and security of the data, including but not limited to 45 CFR part 162, 42 CFR part 2, and the HIPAA Privacy and Security Rules.
                    </P>
                    <P>We noted that we believed these proposals would serve to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to better serve and compete for patients, thereby increasing quality, decreasing costs, and empowering patients with information that helps them live better, healthier lives. Additionally, under our proposal, clinicians would be able to review, with the approval and at the direction of the patient, information on the patient's current prescriptions and services received by the patient; the patient could also allow clinicians to access such information by sharing data received through the API with the clinician's EHR system—by forwarding the information once the patient receives it or by letting the clinician see the information on the patient's smartphone using an app that received the data through the API. Developers and providers could also explore approaches where patients can authorize release of the data through the API directly to the clinician's EHR system.</P>
                    <P>We also encouraged payers to consider using the proposed API infrastructure as a means to exchange health information for other health care purposes, such as to health care providers for treatment purposes. Sharing interoperable information directly with the patient's health care provider in advance of a patient visit would save time during appointments and ultimately improve the quality of care delivered to patients. Most clinicians and patients have access to the internet, providing many access points for viewing health information over secure connections. We noted that we believed these proposed requirements would significantly improve patients' experiences by providing a mechanism through which they can access their data in a standardized, computable, and digital format in alignment with other public and private health care entities. We stated that we designed the proposals to empower patients to have simple and easy access to their data in a usable digital format, and therefore, empower them to decide how their health information is going to be used. However, we reminded payers, and proposed to codify that the regulation regarding the API would not lower or change their obligations as HIPAA covered entities to comply with regulations regarding standard transactions at 45 CFR part 162.</P>
                    <P>Finally, we also proposed to add a new MA contract requirement at 42 CFR 422.504(a)(18) specifying that MA organizations must comply with the requirement for access to health data and plan information under 42 CFR 422.119.</P>
                    <P>We summarize the public comments we received on the Patient Access API proposal, generally, and the technical standards we proposed for the API and its content, and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters indicated support for the overall proposal to require the specified payers to provide patients access to their health care information through a standards-based API. These commenters supported the goals to provide patients near real-time, electronic access to their claims, treatment, and quality information. Many commenters were also supportive of provider access to patient data through APIs, if the patient consented to (or authorized) access, in order to support coordinated care. One commenter was specifically in favor of the patient access proposal noting it supports patient access to their historical claims information. Finally, one commenter requested that CMS explain whether “API technology” has the same definition as in the ONC proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support for the Patient Access API proposal and are finalizing this policy with modifications, as discussed in detail below. We also note that both the CMS and ONC rules use the term “API” consistently as we work together to align technology and standards and forward interoperability across the entire health care system. We do note, however, that the Patient Access API did not propose to include quality information.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested CMS specify the historical look-back period for API exchange. In addition, one commenter requested that CMS not require data older than from 2019 be made available through APIs due to the implementation costs of standardizing older information.
                        <PRTPAGE P="25528"/>
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' suggestions. The proposed rule did not specify a historical look-back period for the Patient Access API or limit the timeframe of the data that must be available through the API. To ensure consistent implementation and minimize the burden on payers, we are finalizing additional text in the applicable regulations to specify that MA organizations at 42 CFR 422.119(h), state Medicaid FFS programs at 42 CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii), CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at 42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221(i), beginning January 1, 2021 (or plan years beginning on or after January 1, 2021 for QHPs on the FFEs), must make available through the Patient Access API data that they maintain with a date of service on or after January 1, 2016. This means that no information with a date of service earlier than January 1, 2016 will need to be made available through the Patient Access API. By “date of service,” we mean the date the patient received the item or service, regardless of when it was paid for or ordered. This is consistent with how we are finalizing the payer-to-payer data exchange requirement for MA organizations at 42 CFR 422.119(f), Medicaid managed care plans at § 438.62(b)(1)(vi) (made applicable to CHIP managed care entities through incorporation in § 457.1216), and QHP issuers on the FFEs at 45 CFR 156.221(f). Aligning the years of data available through the Patient Access API with the payer-to-payer data exchange will minimize cost and burden specific to this regulatory requirement and will provide patients with the same timeframe of information as payers, furthering transparency. Together these policies facilitate the creation and maintenance of a patient's cumulative health record with their current payer.
                    </P>
                    <P>We do not believe limiting the Patient Access API to data only from January 1, 2019 forward is sufficient to help patients most benefit from this data availability. However, we do appreciate that making older data available for electronic data exchange via the Patient Access API is part of the cost of the API. As a result, limiting this to data with a date of service of January 1, 2016 forward minimizes cost and burden while maximizing patient benefit.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed concerns and indicated that they did not believe the Patient Access API proposal would move the health care industry toward the stated goal of helping patients make more informed care decisions. Several commenters were concerned that certain patient groups, such as those with low technology access and/or health literacy, would not make use of electronic applications for making health care decisions. A few commenters recommended CMS not limit patient access to health information through apps alone, especially for populations with low technology access and/or literacy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. However, more and more Americans are using portable technology like smart phones and tablets to conduct a myriad of daily activities. Approximately 81 percent of U.S. adults reported owning a smartphone and 52 percent reported owning a tablet computer in 2019.
                        <SU>28</SU>
                        <FTREF/>
                         An American Community Survey Report from the U.S. Census Bureau reported that in 2016, 82 percent of households reported an internet subscription and 83 percent reported a cellular data plan.
                        <SU>29</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             Pew Research Center. (2019, June 12). Retrieved from 
                            <E T="03">https://www.pewinternet.org/fact-sheet/mobile.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>29</SU>
                             Ryan, C. (2018). Computer and internet Use in the United States: 2016 (American Community Survey Reports, ACS-39). Retrieved from 
                            <E T="03">https://www.census.gov/content/dam/Census/library/publications/2018/acs/ACS-39.pdf.</E>
                        </P>
                    </FTNT>
                    <P>People have a right to be able to manage their health information in this way should they choose. We appreciate that not everyone is comfortable with, has access to, or uses electronic applications in making health care decisions. Such patients will maintain the same access that they have to their personal health information today. This regulation does not change any existing patient information rights. This regulation simply adds new options to ensure patients have the information they need, when, and how they need it.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters indicated concerns over what they believe would be a costly implementation. A few commenters questioned who would be required to bear the costs of implementation and maintenance of the APIs, with one commenter requesting CMS explicitly permit payers to charge patients and other third-party partners for the costs of API implementation and maintenance. In contrast, a few commenters recommended that payers should not be allowed to charge patients to access their information through APIs. A few commenters requested CMS provide federal grant funding to support payers in implementing the proposed APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. As discussed in section XIII. of this final rule, we are providing updated cost estimates for implementing and maintaining the Patient Access API, moving from a single point estimate to a range—including a low, primary, and high estimate—to better take into account the many factors that impact the cost of implementation. We have revised our original estimate of $788,414 per payer, to a primary estimate of $1,576,829 per payer, increasing our original estimate by a factor of 2 to account for additional information that was provided by commenters, which we still believe is relatively minimal in relation to the overall budget of these impacted payers. We have included a low estimate of $718,414.40 per organization, and a high estimate of $2,365,243 per organization. We refer readers to sections XII. and XIII. of this final rule for a detailed discussion of our revised cost estimates.
                    </P>
                    <P>We acknowledge that payers may pass these costs to patients via increased premiums. In this way, patients could absorb the cost of the API. However, we note the costs of “premiums” for MA, Medicaid, and CHIP enrollees are primarily borne by the government, as are some premium costs for enrollees of QHP issuers on the FFEs who receive premium tax credits. We believe that the benefits created by the Patient Access API outweigh the costs to patients if payers choose to increase premiums as a result.</P>
                    <P>At this time, we are not able to offer support for the implementation of this policy through federal grant funding. Regarding costs for Medicaid managed care plans—since the Patient Access API requirements must be contractual obligations under the Medicaid managed care contract—the state must include these costs in the development of a plan's capitation rates. These capitation rates would be matched at the state's medical assistance match rate. State Medicaid agency implementation costs would be shared by the state and federal government, based on the relevant level of Federal Financial Participation, which is 50 percent for general administrative costs and 90 percent for system development costs.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters described concerns with the maturity of APIs for data exchange, as well as the fact that implementation of FHIR-based APIs is so new in health care, and expressed that they believed there were challenges with meeting the proposed requirement given the newness of the needed standards, particularly regarding standardizing the required data elements and vocabularies. Several 
                        <PRTPAGE P="25529"/>
                        commenters were concerned that APIs would not be implemented in a standardized fashion, which could lead to interoperability challenges, and noted the need for testing for certain use cases, such as exchanging data from plan to patients and from plan-to-plan, as well as the exchange of provider directory and/or pharmacy/formulary information. Several commenters suggested CMS and/or HHS publish implementation guides to support consistent and standardized implementation of FHIR-based APIs and their associated data standards.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. As stated in section II. of this final rule, the content and vocabulary standards and technical standards HHS is finalizing in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) provide the foundation needed to support implementation of the policies as proposed and now finalized in this rule. That said, we have been working with HL7 and other industry partners to ensure the implementation guides requested are freely available to payers to use if they choose to use them. Use of these implementation guides is not mandatory; however, if a payer does choose to use the publicly available guidance, it will limit payer burden and support consistent, interoperable API development and implementation. Therefore, use of this publicly available guidance can help address the consistency concerns raised. Part of the development process of any implementation guide is consensus review, balloting, and testing. We are providing a link to specific implementations guides and reference implementations for all interested payers for both the Patient Access API and the Provider Directory API (discussed in section IV. of this final rule) that provide valuable guidance to further support sharing the needed data using the required standards: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                         The implementation guides provide information payers can use to meet the requirements of the policies being finalized in this rule without having to develop an approach independently, saving time and resources. In addition, the reference implementations allow payers to see the APIs in action and support testing and development.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters indicated concerns with an impending proliferation of multiple health plan APIs. Instead, commenters recommended a centralized, standardized approach where CMS would require the use of Blue Button 2.0 as the platform for providing patient access to their health data from all impacted programs (Medicare Advantage, Medicaid, CHIP, and QHPs on the FFEs). Commenters suggested this would also reduce the burden on app developers to develop to one API rather than multiple APIs for various regulated entities.
                    </P>
                    <P>One commenter requested CMS implement a pilot program for the API proposals, citing CMS' Blue Button pilot. One commenter suggested CMS convene a group of 10-12 subject matter experts from payers along with other relevant stakeholders, such as developers, to meet with CMS, ONC, and the FTC to facilitate a smooth path to the API compliance deadline and ensure a successful implementation.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. However, we do not wish to require use of the Blue Button 2.0 platform as a centralized solution. We believe that industry will best have the ability to take interoperability to the next level by leading the development of APIs that meet the requirements in the regulations at 42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233, as well as 45 CFR 156.221, and which they maintain and control. Blue Button is essentially the hub for the Medicare data that CMS, as a payer, is making available to our beneficiaries. We do not wish to require the centralization of other payer data under this rule. We are requiring other payers to also unleash their data and provide the same benefits to their enrollees in a standardized way. As noted above, we are providing a link to specific implementation guides and reference implementations to further support implementation of the Patient Access API, as well as the Provider Directory API (discussed in section IV. of this final rule), for all payers to use: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                         Use of these freely available materials is not required, but if used will reduce development burden for both payers and app developers and facilitate industry-wide interoperability.
                    </P>
                    <P>Although we appreciate the recommendation to consider a pilot, we believe it is important to move ahead with APIs at this time to help the health care sector as a whole—including patients, providers and payers—start to benefit from this technology as so many other sectors have. Also, as previously noted in this final rule, we will share lessons learned and best practices from our experience with Blue Button as relevant and appropriate to aid the successful implementation of the API requirements included in this final rule.</P>
                    <P>Regarding the request to convene subject matter experts, we reiterate our commitment to continuing our collaboration with our federal partners and a diversity of industry stakeholders to ensure a successful and smooth implementation of the requirements included in this final rule. As this collaboration is ongoing, we do not believe it is necessary to convene a new, dedicated group.</P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter recommended that CMS consider standards to allow payers and providers to upload patient data directly to a patient portal that is owned and managed by the patient. One commenter suggested that Health Information Exchanges (HIEs) and Health Information Networks (HINs) can be a central source for patients to obtain aggregated data in a single location.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for these recommendations. We appreciate that HIEs and HINs can provide patients with valuable information, and we look forward to innovative solutions from this community. One option would be to leverage APIs and support patient access via this technology. We did not propose to use a portal approach. One of the advantages of an API approach is that any system can make data available and that data can be used by any other system that is following the same approach to mapping and transporting data without a need to otherwise link the systems or ensure any system-level compatibility. Having APIs that can be accessed by third-party apps permits the patient to choose how they want to access their data, and it promotes innovation in industry to find ways to best help patients interact with their data in a way that is most meaningful and helpful to them. This same flexibility and interoperability is not easily realized through a portal solution, and thus we will not consider this recommendation at this time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters requested CMS confirm the proposed preclusion policy for versions of standards and standards themselves at 42 CFR 422.119(c)(4) for MA organizations, 42 CFR 431.60(c)(4) for Medicaid FFS programs, 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(c)(4) for CHIP FFS programs, 42 CFR 457.1233(d)(1) for CHIP managed care entities, and 45 CFR 156.221(c)(4) for QHP issuers on the FFEs. These commenters recommended CMS indicate that the preclusion policy would prohibit plans from using standards not named by CMS for the 
                        <PRTPAGE P="25530"/>
                        specified API functions, but would not prohibit them from using those standards for other use cases not regulated by CMS.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We confirm that the requirements in this regulation will not preclude a payer from using a standard not finalized in this rule for use cases that are not specifically discussed in this final rule as required for use with the Patient Access API requirement or the Provider Directory API requirement (discussed in section IV. of this final rule). The content and vocabulary standards being adopted are specifically applicable to the data identified and required to be made available through the Patient Access API and Provider Directory API; this means that if there is a content standard identified in the regulation text for the information specified in the regulation text as required to be made available through the API, the payer subject to the regulation must make available through the API at least these data elements using the named content standard. This final rule indicates the minimum data that must be made available via these APIs. This does not prevent a payer from including more information via either API using other available standards. We do strongly support the continued use and adoption of FHIR standards for additional use cases to promote interoperability and efficient and effective transfer of electronic health information, generally.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed concerns that contracts between health care providers and payers need to be standardized in order to support the requirements of the CMS Interoperability and Patient Access proposed rule. A few additional commenters specifically noted that timing requirements for making information available through APIs should be specified in these contracts. One commenter requested CMS prohibit payers from using the Patient Access API requirements to place additional contractual demands on health care providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns that there will be downstream impacts from the Patient Access API requirements on the relationship between payers and their contracted health care providers. It will be up to each payer's discretion to address whether this information needs to be included in contracts with providers. We do not believe it is necessary or appropriate for CMS to adopt regulations to standardize all contracts between payers and health care providers to accomplish this and are not convinced it would be wise to try to do so as each payer is unique, as are their relationships with their contracted providers. We are finalizing the implementation timeline with modifications from the proposal, as further discussed below, to provide payers and providers more time to address all implementation issues. We do not anticipate this will create significant additional provider burden.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters supported the CMS proposal to adopt FHIR as the technical standard for payer APIs. Several commenters recommended adopting FHIR Release 4 (R4), also referred to as “version 4,” noting it is more robust than Release 2 (R2), particularly regarding laboratory information. A few other commenters supported the use of FHIR R2 with the eventual transition to R4. One commenter indicated their recommendation on the version of FHIR to adopt (R2 vs R4) would depend on the timeline CMS provides payers for compliance. A few commenters also suggested CMS align with the version of FHIR that ONC adopts in its final rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their recommendations, which we have shared with ONC. We are adopting the standards as finalized by HHS in ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). As a result, the regulations we are finalizing will require the use of the standards identified at 45 CFR 170.215, which specifically include the use of HL7 FHIR Release 4.0.1. As previously stated, we believe that requiring regulated entities to comply with the specified standards regulations finalized by HHS in ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) will support greater alignment and interoperability across the health care system, as health IT products and applications that will be developed for different settings and use cases will be developed according to a consistent base of standards that support a more seamless exchange of information. Extending the implementation date, as further discussed below, should provide the necessary time to build to and use FHIR Release 4.0.1.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Although many commenters were generally in support of the proposal to use FHIR, several commenters did raise specific implementation concerns. Several commenters expressed concerns about the costs and burden for payers and providers to update to the necessary FHIR standard for content exchange, especially for historical data that may not currently be coded to support FHIR. Many of these commenters cautioned CMS from proceeding too quickly with FHIR adoption and implementation. One commenter noted that semantic interoperability is needed for true interoperability but that significant mapping and implementation efforts would be needed to achieve this goal. One commenter requested CMS provide federal funding to support adoption and implementation of FHIR-based APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. Regarding the readiness of the FHIR standards and the need for semantic interoperability, we agree that semantic interoperability is important. As noted in this section, though not required for use, we are providing a link to specific implementation guides and reference implementations that include information about the FHIR resources to use to code and map the required data elements as to facilitate interoperable data exchange via the Patient Access API, as well as the Provider Directory API (discussed in section IV. of this final rule). This addresses the concern raised regarding semantic interoperability.
                    </P>
                    <P>Regarding burden, as indicated in section XIII. of this final rule, we do not anticipate that upgrading to HL7 FHIR Release 4.0.1 and preparing historical data for electronic transfer via an API using these standards will be more than a relatively minimal expense. We are also limiting the amount of historic information that will need to be included in the Patient Access API to information with a date of service on or after January 1, 2016. This should also help address concerns around expense and burden. In addition, we note the discussion below regarding the implementation date for this policy appreciating the commenters' concerns about moving too quickly. Regarding federal funding and costs, we note that for several of the types of payers that must comply with the Patient Access API requirements, there is significant federal participation in the costs.</P>
                    <P>For Medicaid FFS, the provision of enhanced federal match rate is addressed in section 1903(a)(3)(A) of the Act and provides a 90 percent match rate for the sums expended during such quarter as are attributable to the design, development, or installation of such mechanized claims processing and information retrieval systems as the Secretary determines are likely to provide more efficient, economical, and effective administration of the plan.</P>
                    <P>
                        For Medicaid managed care plans, since the Patient Access API requirements must be contractual obligations under the Medicaid 
                        <PRTPAGE P="25531"/>
                        managed care contract, the costs must be included in the development of a plan's capitation rates. Approved capitation rates would be matched at the state's medical assistance match rate.
                    </P>
                    <P>As is discussed in section XIII. of this final rule, MA organizations may include in their bids the costs of implementing provisions of this rule that pertain to MA. The bid, as compared to the benchmark, is a significant component of what the government pays MA organizations for the provision of Part A and Part B benefits: (1) For bids at or below the benchmark, the government pays the bid as the capitation amount, and (2) for bids that are above the benchmark, the government pays the benchmark and the remainder of the bid amount is the premium charged to enrollees of the plan.</P>
                    <P>For CHIP, the federal government pays an enhanced federal medical assistance percentage (EFMAP) to states for all costs associated with CHIP, including systems costs. For federal FY 2020, the EFMAPS will range from approximately 65 to 81.5 percent. We note that states will be expected to implement the CHIP provisions using CHIP administrative funding, which is limited under section 2105(a)(1)(D)(v) and 2105(c)(2)(A) of the Act to 10 percent of a state's total annual CHIP expenditures.</P>
                    <P>For QHP issuers on the FFEs, we would expect that issuers would raise premiums in the short term in order to cover the costs associated with developing and implementing these new standards. To the extent that premiums are raised for all QHP issuers on the FFEs, federal contributions for the subsidized population in the form of advanced premium tax credits will increase proportionally in those initial years. Non-subsidized consumers will be expected to pay for the increase in premiums themselves and any increases may impact the ability of some consumers to afford coverage. Some consumers may instead select other options or opt out of coverage if they find QHPs unaffordable.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters indicated they did not support CMS' proposal to use one standard adopted by HHS (FHIR, which ONC had proposed for adoption at 45 CFR 170.215) as the foundational standard for standards-based APIs. A few commenters suggested CMS permit the use of other standards for exchanging the proposed patient data during a transition period or until the FHIR standards are more mature. One commenter recommended the use of HIPAA Administrative Simplification transaction standards such as those maintained by X12. One commenter noted that these HIPAA transaction standards were more accessible to payers to represent clinical and case management data. This commenter suggested CMS should precisely identify the specific claims data layout of the HIPAA Administrative Simplification transaction standards that payers would be required to generate and receive because the HIPAA Administrative Simplification transaction standards layout varies by payer type. However, one commenter noted that patients may not find information available through HIPAA standards useful.
                    </P>
                    <P>A few commenters suggested CMS should assist affected payers with meeting the technical implementation requirements by explaining the intent of the required use of the HIPAA Administrative Simplification transaction content and vocabulary standards with the HL7 FHIR standards. Commenters recommended that CMS review and reconcile differences between existing standards that are required for Medicaid programs, in particular. For example, commenters suggested identifying situations in which CMS has required the use of X12 Electronic Data Interchange standards and reconciling these requirements with the adoption of the HL7 FHIR standards.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. The policies included in this final rule are not intended to alter HIPAA requirements in any way, and these electronic data exchanges are not defined transactions under HIPAA regulations, therefore there is no need to reconcile use of X12 and the HL7 FHIR standards required in this rule. We appreciate that the HIPAA standards are more known to many payers at this time; however, we believe the use of FHIR standards is important for advancing the policies finalized in this rule, which require the transmission of information beyond what is available using X12 standards alone. At the same time, as discussed in the proposed rule, we are requiring entities subject to this rule to use HIPAA content and vocabulary standards at 45 CFR part 162 where required by other applicable law, or where such standards are the only available standards for the data type or element (84 FR 7623). The use of the FHIR standard supports making this information available through an API. This is not in conflict with the use of other standards to represent the data being transmitted through the API. Instead, the FHIR standard can be thought of as defining an envelope, while the contents of the envelope can be represented by different content and vocabulary standards used in conjunction with FHIR to make data interoperable and accessible. For additional information on FHIR standards, we direct commenters to the ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). To support implementation of the policies included in this final rule, we are providing a link to specific implementation guides and reference implementations that provide valuable guidance to further support sharing the needed data using the required standards: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                    </P>
                    <P>As discussed in section II.A.3. of the CMS Interoperability and Patient Access proposed rule (84 FR 7622 through 7623), we recognized that while we must codify in regulation a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulations. To address how standards development can outpace our rulemaking schedule, we offered several proposals. We proposed that regulated entities may use an updated version of a standard where required by other applicable law. We also proposed that regulated entities may use an updated version of the standard where not prohibited by other applicable law, under certain circumstances.</P>
                    <P>We summarize the public comments we received on our approach to allowing voluntary adoption of updated standards and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed support for the proposal to allow plans to upgrade to newer versions of standards supporting data classes in the USCDI as standards evolve. A few commenters specifically supported the proposal to align with ONC's proposed Standards Version Advancement Process and allow payers to adopt newer versions of FHIR once approved for use by HHS. A few commenters were concerned with backwards compatibility if implementers—payers and developers—are permitted to move to new versions of standards, while a few commenters supported the proposed requirement to maintain compatibility with adopted standards while upgrading to newer standards. One commenter expressed concerns with difficulty tracking compliance with standards as they move through different versions, generally, and requested CMS establish 
                        <PRTPAGE P="25532"/>
                        a versioning system or identifier for consistency and transparency.
                    </P>
                    <P>A few commenters specifically discussed the NCPDP SCRIPT standard; however, these comments are out of scope for this rulemaking because this rulemaking does not apply to ePrescribing transactions.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' input. We are adopting the ability to use updated standards. As proposed, implementers will need to ensure that use of the updated (or newer) standard (instead of the standard specified in the applicable regulation) does not disrupt an end user's ability to access the data available through the API, which should address concerns raised around backward compatibility. Specifically, we are finalizing at 42 CFR 422.119(c)(4) for MA organizations, 42 CFR 431.60(c)(4) for Medicaid FFS programs, 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(c)(4) for CHIP FFS programs, 42 CFR 457.1233(d)(1) for CHIP managed care entities, and 45 CFR 156.221(c)(4) for QHP issuers on the FFEs permission to use an updated version of standards adopted at 45 CFR 170.215, 45 CFR 170.213, 45 CFR part 162, or 42 CFR 423.160, subject to the conditions proposed. As long as use of the updated version of a standard is not otherwise prohibited, permitted in accordance with the conditions described, and, does not disrupt an end user's ability to access the data per the requirements of the API, it may be used.
                    </P>
                    <P>Regarding the recommendation for CMS to establish a versioning system or identifier, we appreciate this recommendation and will review the suggestion for future consideration.</P>
                    <HD SOURCE="HD3">c. Data Required To Be Available Through the Standards-Based API &amp; Timeframes for Data Availability</HD>
                    <P>We proposed the content that must be accessible for each enrollee of an entity subject to the standards-based API proposal as set out at proposed paragraph (b) of 42 CFR 422.119, 431.60, and 457.730, and 45 CFR 156.221; as noted previously, the regulations for Medicaid managed care plans and CHIP managed care entities cross-reference and incorporate the regulations we proposed for Medicaid and CHIP FFS programs. We noted that the types of content proposed would represent the minimum threshold for compliance; at their discretion, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs would have the option to use the API required by the proposed rule to make additional types of health information or plan information available, exceeding these minimum requirements.</P>
                    <P>We requested comment on the data proposed to be made available as detailed in the subsections below. We proposed that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs permit third-party applications to retrieve, with the approval and at the direction of an enrollee, certain specific data: Adjudicated claims data, including provider remittances and beneficiary or enrollee cost-sharing data; encounter data from capitated providers; and clinical data, including laboratory results (but only if maintained by the payer).</P>
                    <HD SOURCE="HD3">(1) Patient Claims and Encounter Data</HD>
                    <P>We proposed that the adjudicated claims data required to be provided include approved and denied claims. Under the proposal, adjudicated claims data includes that for which the plan has made an initial payment decision even when the period during which an enrollee can file an appeal is still in effect, or when the enrollee has filed an appeal and is awaiting a decision on that appeal. Such appeal decisions might be called reconsiderations, reconsidered decisions, organization determinations, or use other terms, but the term is not relevant. We specifically requested comments from plans regarding the feasibility of including such claims data, including any possible timing issues.</P>
                    <P>The proposal included timeframe requirements for making these various categories of data available through the standards-based API. For MA organizations, proposed 42 CFR 422.119(b)(1)(i), (ii), and (b)(2)(i) would require standards-based API access to all claims activity pertaining to standardized adjudicated claims (including cost, specifically provider remittances and enrollee cost-sharing) and standardized encounter data for benefits covered by the plan (that is, Medicare Part A and Part B items and services, Part D prescription drugs if covered by the MA plan, and any supplemental benefits) no later than one (1) business day after a claim is processed or the encounter data are received by the MA organization. We used the terms “adjudicated” and “processed” interchangeably in this context.</P>
                    <P>For Medicaid state agencies and managed care plans, we proposed that standardized claims data and encounter data would be required (specifically at 42 CFR 431.60(b)(1) and (2)) through the API no later than one (1) business day after the claim is processed or the data are received. For State Medicaid agencies in connection with the FFS program, we explained that the API would have to include all claims data concerning adjudicated claims and encounter data from providers (other than MCOs, PIHPs or PAHPs) that are paid using capitated payments. The requirement for Medicaid managed care plans to provide encounter data is specified, in conjunction with the incorporation of the Medicaid FFS requirement into the Medicaid managed care regulations, at 42 CFR 438.242(b)(6)(i) (finalized as § 438.242(b)(5)(i) in this rule; see section VI.). Similarly, we proposed that encounter data that Medicaid managed care plans must make available through the API would include any data from subcontractors and providers compensated by the managed care plan on the basis of capitation payments, such as behavioral health organizations, dental management organizations, and pharmacy benefit managers. The API for Medicaid managed care plans would have to include all claims and, therefore, encounter data that would be included regardless if it is adjudicated or generated by the managed care plan itself, a subcontractor, or a provider compensated on the basis of capitation payments. All data would need to be obtained in a timely manner to comply with these proposed requirements that these types of data be available through the API no later than one (1) business data after a claim is processed or the encounter data are received.</P>
                    <P>For CHIP agencies and managed care entities, access to standardized claims data and encounter data would be required (specifically at 42 CFR 457.730(b)(1) and (2)) through the API no later than one (1) business day after the claim is processed or the encounter data are received. The proposal for CHIP state agencies (regarding FFS programs) and CHIP managed care entities is identical to the proposal for Medicaid state agencies (regarding FFS programs) and Medicaid managed care plans. For QHP issuers on the FFEs, the proposed regulation at 45 CFR 156.221(b) would require claims and encounter data to be available through the Patient Access API no later than one (1) business day after adjudication or receipt, respectively.</P>
                    <P>
                        Specifically regarding QHP issuers on the FFEs, at 45 CFR 156.221(b)(1)(i) and (ii), we proposed to require that QHP issuers participating on the FFEs make available through the API standardized data concerning adjudicated claims (including cost) and standardized 
                        <PRTPAGE P="25533"/>
                        encounter data. Under proposed paragraph (b)(1)(i), we proposed that QHP issuers on the FFEs would be required to make available standardized data concerning adjudicated claim, provider remittance, and enrollee cost-sharing data through the API within one (1) business day after the claim is processed. Under proposed paragraph (b)(1)(ii), we proposed that QHP issuers on the FFEs would be required to provide standardized encounter data through the API no later than one (1) business day after the data are received by the issuer.
                    </P>
                    <P>As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7632 through 7633), the proposed timeframe—making the data available to the third-party app with the approval and at the direction of the patient through the API no later than one (1) business day after processing a claim or receiving encounter data—would ensure that data provided to the third-party app, and ultimately the patient, through the API would be the most current data available. Providing the most current data may be critical if the data are provided by an enrollee to his or her health care provider to use in making clinical decisions. As proposed, the claims and encounter data to be disclosed would include information such as enrollee identifiers, dates of service, payment information (provider remittance if applicable and available), and enrollee cost-sharing. Our proposal did not exclude any elements from the claims and encounter—or the clinical data—required to be made available through the Patient Access API. The ability for enrollees—created and facilitated by the API required under the proposal—to access this information electronically would make it easier for them to take it with them as they move from payer to payer or among providers across the care continuum.</P>
                    <P>Regarding the provision of encounter data through the API no later than one (1) business day after receiving the data, we noted that the proposal would mean that a payer must rely on capitated providers submitting their encounter data in a timely manner to ensure that patients receive a timely and complete set of data. To the extent providers do not submit in a timely manner, there would be a delay in patients having access to their data. We recommended that MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs that would need this information in order to meet the proposed API requirements in a timely manner should consider whether their contracts with network providers should include timing requirements for the submission of encounter data and claims so that the payer can comply with the API requirements more timely. For Medicaid and CHIP FFS programs, we encouraged states to consider other means to ensure that necessary encounter data from providers is also provided on a timely basis.</P>
                    <P>We summarize the public comments we received on making claims and encounter data available via the Patient Access API and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed concern that there are no named or mature industry FHIR-based standards available for representing and exchanging claims information. One commenter requested CMS only require a specific subset of claims information that would be most useful to patients, suggesting patient name, diagnoses codes, procedure codes, drug codes, service date(s), provider of service, and out-of-pocket costs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We have been working with industry partners to ensure the necessary FHIR standard and implementation guides as specified at 45 CFR 170.215 are now available to ensure that payers can fully implement sharing claims data via a FHIR-based API, as we are finalizing our proposal to have payers impacted by this rule make claims and encounter data available via the standards-based Patient Access API no later than one (1) business day after claims processing or encounter data receipt. To further support payers as they work to build the Patient Access API and map claims and encounter data for exchange via a FHIR-based API, in partnership with industry, we have worked to ensure relevant implementation guides and reference implementations are available. A link to specific implementation guides and reference implementations for claims and encounter data have been produced and tested and can be found at 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                         Though not mandatory, using these publicly available resources will reduce payer burden as they work to prepare their data for exchange via a FHIR-based API.
                    </P>
                    <P>We also appreciate the recommendation to only include a subset of claims information. However, we believe it is important for patients to have all of their claims information in order to facilitate informed decision making. Patients have a right to their claims data. While that information currently can be obtained through various means, we decline to require that only a subset of the available claims information be available through the Patient Access API.</P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter noted that health plans cannot verify the accuracy of all information contained in a claim. This commenter requested CMS should state that these policies do not mandate that payers audit and correct all information furnished by health care providers beyond what is currently necessary for existing rules, regulations, and internal business purposes.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's concern. We agree that our regulations, as proposed and as finalized, for this Patient Access API do not require that payers do any additional audit or review of the claims they receive beyond current practices. To the extent that payers wish to, they may include a disclaimer or other notice to enrollees as part of the API to indicate this. Such a disclaimer would be permissible under these regulations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters recommended that further standardization work be done to improve the accuracy of the claims data field that identifies the attributed health care provider administering services. If this data element is accurate, commenters note it will help ensure patients are reaching out to the right clinician. Commenters believe this could reduce confusion when patients seek clarification or request amendments to their health information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendation and will evaluate potential future options to address this concern through our work with HL7 and other industry partners. We do note, however, this seems to be a data accuracy issue and not a standardization issue. That said, we do strongly encourage all payers and providers to work together to ensure the accuracy of these and all data.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters were concerned that claims data were not accurate representations of clinical findings and therefore not valuable in assisting patients in making health care decisions. These commenters expressed fears that patients may misinterpret claims information for health care decision-making when claims data serve a payment use case.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We do note, however, that there is valuable information on the claim relevant to a patient's care and care history that can inform health care decision-making. For instance, this information provides patients with the names of the providers they have visited, when they visited 
                        <PRTPAGE P="25534"/>
                        certain providers for certain medical needs, when tests or procedures were conducted, and more information about these tests and procedures. This information alone is very useful to patients as they plan and discuss future care with their providers. Also, in the absence of clinical data (which is required to be provided through the Patient Access API under this rule only if the payer maintains such data), claims and encounter data provide a basis of information for patients to work with and get value from.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter sought clarification on the scope of Medicaid-covered services to which the requirement to make claims and encounter data available through an API applies. This commenter recommended that CMS specify that this requirement to make claims and encounter data available does not apply to long-term care waiver services, such as in-home care, meal preparation or delivery, and transportation. The commenter stated that providing claims and encounter data for these services through the API would be cumbersome for a variety of reasons including the fact that long-term care waiver services tend to have frequent (daily or weekly) utilization by each participant, which would result in an unwieldly number of claims or encounters being provided through the API for each individual.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We confirm that under 42 CFR 431.60(b)(1) and (2), 42 CFR 457.730(b)(1) and (2), 42 CFR 438.242(b)(5) (proposed as § 438.242(b)(6); see section VI.), and 42 CFR 457.1233(d), states and managed care plans must make adjudicated claims and encounter data available through the API for all Medicaid- or CHIP-covered services, including long-term services and supports (LTSS). This requirement extends to in-home care, transportation services, and all other Medicaid- or CHIP-covered services for which a claim or encounter is generated and adjudicated. We do not believe the number of claims generated by LTSS will make the data unwieldy or unusable by the beneficiary. We believe that the benefits of providing claims and encounter data to beneficiaries so they can make better health care decisions and know which providers have been paid for providing services to them is no less important simply because it is a frequently provided service. Some beneficiaries may find having such data on frequently rendered services more important since billing with such frequency may make it more prone to errors, fraud, waste, and abuse.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters were concerned with the appropriateness of sharing certain claims information, particularly specific costs such as negotiated rates that commenters believed could reveal trade secrets or be considered proprietary information. These commenters requested CMS ensure that confidential, proprietary cost information is excluded from the proposed requirements. One commenter believed that disclosure of information such as negotiated rates would lead to higher health prices in the industry and other anticompetitive behavior. Specifically, this commenter gave the example where dominant payers in a geographic or other market use this price information to deter competitors from entering into value-based payment arrangements. One commenter also requested that third-party apps be prohibited from aggregating or using any cost information for purposes other than transfer of the data to the patient.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We note that we take our obligations seriously to protect from disclosure information that is protected under current law. We also affirm our commitment to safeguarding data protected by law from inappropriate use and disclosure. We understand the concerns raised around sharing cost data. We appreciate the commenters' concerns, however we reiterate that we are committed to giving patients access to their health information, and we believe the benefits of making this information available to patients through third-party apps outweigh these concerns. It is critical for patients to better understand health care costs and be able to plan and budget as well as possible. Having cost information, which is already accessible to patients, available to them in a more easy-to-understand presentation would allow patients to get the maximum benefit from this information. If a patient uses an app to view their health information that does not clearly indicate it will not use this cost data for any other purpose, there is a chance the app could aggregate or otherwise analyze the data, assuming the single app has access to enough patient data in a given market or patients who use a particular payer or plan, to make such an analysis possible. Appreciating patients already have access to this information and understanding the possibility for secondary uses of such data, we are finalizing the policy as proposed to require plans to share adjudicated claims, including provider remittances and enrollee cost-sharing information, via the FHIR-based Patient Access API so patients can continue to access this information in ways that will be most useful to them. We reiterate, however, that we do not have the authority to directly regulate third-party apps.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters also indicated that even if patients had access to price information, they would not have the ability to negotiate or impact health care costs. One commenter noted that patients would find prospective cost information more valuable than retrospective payment information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' input. With access to price information, patients who would have cost sharing that is tied to such prices can be more informed consumers of their health care. Even patients who have no direct financial responsibility tied to these prices can benefit from knowing the information in the event their insurance coverage changes in the future or so they can appreciate the relationship between the services they receive and their cost to the health care system. It is important for patients to understand as much as they can about their care. For instance, understanding the costs of past services can help them plan for future services. As a result, this information has great value to patients even if it does not directly impact their ability to specifically influence what they pay for their care, or tell them exactly how much their next service will cost out of pocket.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many comments were received regarding price transparency, generally, and were beyond the scope of the discussion in this rule. Overall, these were out of scope for this final rule as they referenced other rulemaking activities within HHS.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' strong interest in greater price transparency in health care. We strongly support the Administration's and Department's efforts to continue to move toward greater transparency to help health care consumers make the most informed decisions. We point to the recent release of the CY 2020 Hospital Outpatient Prospective Payment System Policy Changes and Payment Rates and Ambulatory Surgical Center Payment System Policy Changes and Payment Rates. Price Transparency Requirements for Hospitals To Make Standard Charges Public final rule (84 FR 65524). This final rule establishes requirements for all hospitals operating in the United States to make their standard charges available to the public under section 2718(e) of the PHSA, as well as an enforcement scheme under section 2718(b)(3) to enforce those requirements. Specifically, sections 2718(b)(3) and 2718(e) of the PHSA require that for each year each hospital operating within the United States 
                        <PRTPAGE P="25535"/>
                        establish (and update) and make public a list of the hospital's standard charges for items and services provided by the hospital, including for diagnosis-related groups established under section 1886(d)(4) of the Act. This final rule requires hospitals (as defined at 45 CFR 180.20) to establish, update, and make public a list of their gross charges, payer-specific negotiated charges (including the de-identified minimum and maximum negotiated charges), and discounted cash prices for all items and services online in a single digital file that is in a machine-readable format, as well as their payer-specific negotiated charges (including the de-identified minimum and maximum negotiated charges) and discounted cash prices (or gross charges, if a discounted cash price is not offered by the hospital) for a more limited set of shoppable services online in a consumer-friendly format.
                    </P>
                    <P>We also direct commenters to the tri-agency Transparency in Coverage proposed rule (84 FR 65464) for additional proposals to further price transparency.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters generally opposed the proposal to make claims and encounter data available through a standards-based API no later than one (1) business day after receiving it. Some commenters suggested the proposed data availability timeframe is challenging due to the timeline for sharing adjudicated claims, in particular, noting the different timeframes for payment discharge, benefit determination, and settlement of the patient account. One commenter noted the reliance on third-party contractors to adjudicate claims and the time required to migrate data from one system to another and that validation could take longer than one (1) business day. Several commenters expressed concern about the timeframe based on revised determinations or revised decisions triggered by data that arrives after the initial determination. One commenter specifically questioned the value of third-party application use of claims data when an enrollee has filed an appeal and is awaiting a reconsideration decision. One commenter recommended CMS only permit finalized claims where a determination has been made be available to be shared via the Patient Access API.
                    </P>
                    <P>Some commenters specifically referenced the reliance of MA plans on pharmacy benefit management organizations for the administration of Part D benefits as a factor in the ability to make these claims data available within one (1) business day after receiving them. Other commenters referenced the Explanation of Benefit requirements that provide a timeframe for information adjustment, which means that the final information may not be available in one (1) business day.</P>
                    <P>Several commenters suggested an alternative timeframe of 3 or 5 days for vendor-adjudicated claims, citing time and costs. Some commenters recommended a grace period for plans when there is a delay due to delayed provider encounter data submission. In addition, some requested an exception for specific conditions attributable to certain claims and encounter data. Other commenters recommended that CMS work with stakeholders to determine an appropriate timeframe for making claims and encounter data available via the Patient Access API.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations, including comments regarding claims that may be under appeal. We are finalizing this policy as proposed that payers make available through the Patient Access API, no later than one (1) business day after the information is received: (1) Adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and (2) encounter data. We reiterate that this is one (1) business day after the claim is adjudicated or encounter data are received. This allows for potential delays in adjudication or delays in providers submitting their encounter data. It does not require payers and providers to change their contractual relationships or current processes for receipt, though we strongly encourage payers and providers to work together to make patient data available in as timely a manner as possible.
                    </P>
                    <P>We believe it is valuable to patients to be able to have their data in as timely a manner as possible. Having access to this information within one (1) business day could empower patients to have the information they need when they need it to inform care coordination and improve patient outcomes. If a patient needs to get follow-up care, having the information relevant to their previous visit is important and valuable. API technology allows this exchange to happen more quickly and efficiently, and we believe it is important to leverage this technological opportunity to ensure patients have the most current information about their care.</P>
                    <P>
                        It is also important for patients to get this information timely even if there is the possibility of a change in determination due to appeal or other factors. We conducted research to evaluate the maturity of claims to inform researchers using the Chronic Conditions Data Warehouse (CCW) data.
                        <SU>30</SU>
                        <FTREF/>
                         This research indicates that nearly half of all Medicare FFS or carrier claims are submitted once and unchanged, and nearly 85 percent of inpatient claims are never adjusted. For carrier claims, 99 percent are fully mature at 10 months; and of non-inpatient claims that were adjusted, 0.13 percent or less had the diagnosis code changed. What this research shows is that many claims remain unchanged, and those that do take more that 3 or 5 days after adjudication to begin to mature. This wait would not provide patients more accurate or complete data; it would only delay their ability to benefit from access to their information. Patients have a right to see the full lifecycle of their claims and encounter information, and we believe they should be able to have access to their information as soon as it is available. Even if the payment amounts may change due to appeal, for instance, the services received and the providers who rendered them are less likely to change. This is very useful information and could impact care decisions and facilitate better care coordination if available as soon as possible. We do appreciate that there are many factors that could influence when some data are available. Again, we encourage payers to work with health care providers and third-party contractors to ensure timely data processing.
                    </P>
                    <FTNT>
                        <P>
                            <SU>30</SU>
                             Chronic Conditions Data Warehouse. (2017, October). CCW White Paper: Medicare Claims Maturity (Version 2.0). Retrieved from 
                            <E T="03">https://protect2.fireeye.com/url?k=7bd1837b-2785aa50-7bd1b244-0cc47a6d17cc-590a0fb580f6d595&amp;u=http://www2.ccwdata.org/documents/10280/19002256/medicare-claims-maturity.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters expressed concern that the proposed timeframe for payers to share claims and encounter data with patients could require providers to accelerate their submissions to payers triggering additional requirements in existing contracts for the submission of claims and encounter data. Some commenters cautioned there could be potential downstream consequences such as narrowing a payer's provider network. One commenter recommended removal of proposed rule preamble language suggesting that MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs could consider adding time requirements for submission of claims and encounter data in their contracts with providers. One commenter recommended CMS provide sample contract language or dedicate resources 
                        <PRTPAGE P="25536"/>
                        to educating providers about the intent of these possible contract revisions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. As discussed in the CMS Interoperability and Patient Access proposed rule, we do appreciate that some payers may consider adding timeframes to contracts with providers to help ensure patients get timely access to their claims and encounter data. Again, we strongly encourage providers to make this information available in as timely a fashion as possible to best assist patients in having access to their health information. Adding language to contracts is one way for payers and providers to work together to ensure patients get this valuable information in as timely a manner as possible. We believe providers can benefit as well if this information is available sooner; it could be shared with them for the purposes of care coordination in a more timely manner, too. It may take some time for providers to improve internal efficiencies to meet potential new timeline requirements, but we believe the long-term benefit outweighs potential short term implementation burden. We do note, however, that the policy being finalized in this rule is specific to payers making adjudicated claims and encounter information available to patients via the Patient Access API within one (1) business day after the payer receives the information. Any additional timeframes are between the payers and their providers.
                    </P>
                    <HD SOURCE="HD3">(2) Provider Directory Data</HD>
                    <P>We proposed at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), 438.242(b)(6)(ii), 457.730(b)(3), and 457.1233(d)(2)(ii) that the required Patient Access API make available provider directory data, including updates to such data. The proposal at 45 CFR 156.221 would not require QHP issuers to permit third-party retrieval of provider directory (and preferred drug list information) because such information is already required to be provided by QHP issuers on the FFEs.</P>
                    <P>For MA organizations, at proposed 42 CFR 422.119(b)(1)(iii), we proposed to specify that MA organizations make specific provider directory information for their network of contracted providers accessible through their Patient Access APIs: The names of providers; addresses; phone numbers; and specialty. This information is the same information MA organizations are already required to disclose to their enrollees under 42 CFR 422.111(b)(3) and make available online under 42 CFR 422.111(h)(2)(ii). As proposed, MA organizations would be required to ensure the availability of this information through the Patient Access API for all MA plans. We noted that including this information in a standards-based API allows non-MA third-party applications to consume, aggregate, and display this data in different contexts, allowing patients to understand and compare plan information in a way that can best serve their individual needs. As proposed, MA plans would be required to update provider directory information available through the API no later than 30 business days after changes to the provider directory are made.</P>
                    <P>Under proposed 42 CFR 431.60(b)(3) and 457.730(b)(3), state Medicaid and CHIP agencies respectively would be required to make provider directory information available through the Patient Access API, including updated provider information no later than 30 calendar days after the state receives this provider directory information or updates to provider directory information. The proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(6) in this final rule; see section IV. of this final rule) and for CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same timeframe, with the addition of specific provider directory information as noted in 42 CFR 438.242(b)(6)(ii) and 457.1233(d)(2)(ii). For Medicaid managed care plans and CHIP managed care entities, we proposed the provider directory information available through the API must include all information that is specified in 42 CFR 438.10(h)(1) about provider directories for disclosure to managed care enrollees. We proposed that the Patient Access API be updated with new provider directory information within 30 calendar days from when the updated information is received by the state (or the managed care plan under 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(6) in this final rule; see section IV. of this final rule) and § 457.1233(d)(2)) to be consistent with existing Medicaid managed care rules at 42 CFR 438.10(h)(3). We proposed that the API implemented by the state Medicaid agency would include the data elements specified for disclosure by Medicaid state agencies in section 1902(a)(83) of the Act; we proposed at 42 CFR 438.242(b)(6)(ii) that the Patient Access API implemented by Medicaid managed care plans would have the data elements specified for disclosure at 42 CFR 438.10(h)(1). For CHIP agencies that operate FFS systems and CHIP managed care entities at 42 CFR 457.730(b)(3) and 457.1233(d)(2)(ii), respectively, we also proposed that provider directory data be available through the API no later than 30 calendar days after receipt of updated information.</P>
                    <P>We did not propose a similar requirement for QHP issuers on the FFEs. As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7633), these issuers are already required, under 45 CFR 156.230(c) and implementing guidance, to make provider directory information accessible in a machine-readable format. Because this information is already highly accessible in this format, we noted that we did not believe the benefits of making it also available through a standards-based API outweigh the burden for QHP issuers on the FFEs. However, we sought comment as to whether this same requirement should apply to QHP issuers, or if such a requirement would be overly burdensome for them.</P>
                    <P>To avoid unnecessary duplication of effort and potential confusion, we are not finalizing the proposal to include provider directory information in the Patient Access API. Instead, we are finalizing the inclusion of this information (consistent in scope as proposed for the Patient Access API) in the public facing Provider Directory API discussed in section IV. of this final rule, which requires MA organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities to provide public access to complete and accurate provider directory information at 42 CFR 422.120, 431.70, 438.242(b)(6), 457.760, and 457.1233(d)(3). Appreciating that the comments we received on provider directory information and APIs addressed issues relevant to both including these data in the Patient Access API discussed in this section of the final rule, but more so making this information more widely available through the Provider Directory API as discussed in section IV. of this final rule, all comments and our responses related to provider directory information via APIs can be found in section IV. of this final rule.</P>
                    <HD SOURCE="HD3">(3) Clinical Data Including Laboratory Results</HD>
                    <P>
                        Regarding the provision of clinical data, including laboratory results, we proposed at 42 CFR 422.119(b)(1)(iv) that MA organizations make clinical data, such as laboratory test results, available through the API if the MA organization maintains such data. We also proposed in paragraph (c)(3)(i) that 
                        <PRTPAGE P="25537"/>
                        the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be used as the content and vocabulary standard for the clinical data made available through the API. We intended the proposal to mean that the data required under paragraph (b)(1)(iv) be the same as the data that is specified in that content and vocabulary standard defined at 45 CFR 170.213. In effect, we proposed that at a minimum any clinical data included in the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be available through the Patient Access API if such data are maintained by the MA organization. We recognized that some MA organizations receive this information regularly, or as a part of their contracted arrangements for health services, but that not all MA organizations do. Therefore, we proposed that this requirement would apply to MA organizations, regardless of the type of MA plan offered by the MA organization, but only under circumstances when the MA organization receives and maintains this clinical data as a part of its normal operations. The proposed requirement aligned with existing regulations at 42 CFR 422.118, which required MA organizations to disclose to individual enrollees any medical records or other health or enrollment information the MA organizations maintain with respect to their enrollees. We proposed that this data be available through the API no later than one (1) business day from its receipt by the MA organization.
                    </P>
                    <P>Similarly, the proposed regulations for Medicaid and CHIP FFS programs and managed care plans (proposed 42 CFR 431.60(b)(4) and § 457.730(b)(4)), required provision through the Patient Access API of standardized clinical data, including laboratory results, if available, no later than one (1) business day after the data are received (by the state or the managed care plan or entity). We noted that this would ensure that data provided through the API would be the most current data available, which may be critical if the data are being shared by an enrollee with a health care provider who is basing clinical decisions on these data. As noted, like proposed 42 CFR 422.119(c), the Medicaid and CHIP regulations proposed compliance with the regulations regarding the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, as the content and vocabulary standard for the clinical data available through the Patient Access API; therefore, we proposed that at a minimum any clinical data included in that USCDI standard be made available through the Patient Access API within one (1) business day of receipt. For state agencies managing Medicaid or CHIP FFS programs, we proposed that such data be made available through the API under the proposal if the state maintains clinical data. The proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.) and CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same standard in terms of the scope of information and the timing of its availability through the Patient Access API; the limitation that the clinical data be maintained by the entity for it to be required to be sent via the Patient Access API would carry through to managed care plans and entities under the proposal.</P>
                    <P>Proposed 45 CFR 156.221(b)(1)(iii) would require QHP issuers on the FFEs to also make these clinical data, including laboratory results, available via the Patient Access API, with the approval and at the direction of the enrollee, if the QHP maintains such data.</P>
                    <P>We recognized not all of the entities subject to this requirement have uniform access to this type of data and sought comment on what barriers exist that would discourage them from obtaining, maintaining, and making these data available through the Patient Access API.</P>
                    <P>We summarize the public comments we received on the inclusions of clinical data, specifically the data included in the USCDI standard, via the Patient Access API and provide our responses below.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters expressed concerns that payers are typically not the original source of clinical information, including data elements that are part of the USCDI, and would not be the best source of the most accurate clinical data for patients. These commenters noted concerns with data accuracy provided by payers who are typically secondary sources of this clinical information and explained that payers do not verify this information. One commenter believed the originator should be providing the data, or that payers should be allowed to indicate the provenance of the data and where to direct questions regarding data accuracy. There was concern that the administrative burden on providers could increase due to patient inquiries and requests to correct or clarify their data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We understand that payers are not the source of this clinical information; however, payers do maintain clinical data that can be of great value to patients. We note that provenance is one data class within the USCDI. As such, this information would be available to patients. We also note, that as discussed above, we intend to provide suggested content for educational information that payers will be able to tailor and use to communicate with their patients about the Patient Access API. Payers can choose to indicate the part of a data exchange that was received from an outside source so the receiving party understands where to direct questions. This will also help patients understand how to address incorrect information as it can be made clear where questions should be directed. Payers are under no obligation under this Patient Access API requirement to validate or correct clinical data received from another source; and, providers are under no obligation to submit updated data to payers should patients suggest there is an error in their data. We do encourage payers and providers to continually work to ensure the accuracy of the patient data they maintain and share to the extent possible. The Patient Access API must include all of the specified clinical information for the enrollee maintained by the payer with a date of service on or after January 1, 2016.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters were concerned that payers could use clinical data to discriminate against providers, such as through discriminatory reimbursement models, for instance offering lower reimbursement rates for certain types of care that a physician deems necessary or in the best interest of the patient based on the data viewed about the doctor and the care they provide.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns; however, we note the fact that some payers are already automatically accessing a physician's EHR for other purposes, either as an elective offering or through contractual requirements. As a result, additional data than is required to meet the requirements of this final rule are already being shared between providers and payers. We reiterate that payers are not entitled to receive information from a health care provider if such information is protected by applicable federal, state, or local law from disclosure to the payer. This final rule does not change any such existing legal obligations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed concerns over provider liability for the quality or accuracy of 
                        <PRTPAGE P="25538"/>
                        clinical data and for being given certain sensitive patient diagnosis and problems information, particularly if the provider is a downstream recipient of such data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns, but reiterate that the policies finalized in this regulation do not change any payer or provider's obligations to abide by existing federal and state regulations and law, including 42 CFR part 2, which governs certain substance use disorder records, which are some of the most sensitive health information. We note, however, that the patient can direct the entity to transfer this sensitive data upon their designation of a recipient, or may provide consent or authorization for the transfer, as applicable. As a provider, and likely as a covered entity under HIPAA, providers are experienced in handling sensitive data. Access through an API will provide a new route to receiving sensitive data, not add to the burden of protecting such information, given the continued need to maintain compliance with all applicable rules and regulations. These policies just allow this information to be transmitted via an API with the approval and at the direction of the patient.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters expressed concern that patients may not understand, or may be confused by, the health information that will be available, and questioned if this information will all be relevant to patients. A few commenters recommended that educational materials and resources be developed to ensure that the data are useful and do not cause alarm.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We appreciate that every patient may not understand every piece of information in their medical record. We intend to provide suggested content for educational materials or other patient resources that payers can tailor and use to ensure that patients have information about how to accurately and productively navigate their health care information, as further discussed below in this section. It is important for patients to have access to their records, review them, and have an opportunity to raise questions and seek clarification about the information maintained in them.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested CMS explain the requirement that MA organizations make clinical data available through the Patient Access API if the entity “manages such data,” particularly what is meant by “manages such data.” This commenter noted that providers manage clinical data and requested clarification of whether the requirement applies to MA organizations. Another commenter expressed similar concerns and inquired whether “managed by the payer” would include only lab results or all clinical data. Commenters questioned if “manage” meant “electronically stored in a database under the payer's control”?
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' request for additional information. As noted in the CMS Interoperability and Patient Access proposed rule, payers, including MA organizations, need to make these data available through the API when the payer receives and maintains these data as a part of its normal operations (84 FR 7633). We used the verb “manages” to communicate that this proposed requirement would apply when the payer has access to the data, control over the data, and the authority to make the data available through the API. In order to more closely align with how the relevant HIPAA Privacy Rule requirement refers to such activity, we are finalizing the regulation text at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), as well as 45 CFR 156.221(b)(1)(iii) with the verb “maintains” in place of the verb “manages”. As such, we define “maintain” to mean the payer has access to the data, control over the data, and authority to make the data available through the API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter questioned if Medicaid agencies will be required to provide clinical data regardless of the type of transaction by which the agency received the data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We confirm that Medicaid and CHIP agencies, and their respective managed care plans, will be required under 42 CFR 431.60(b)(3), 457.730(b)(3), 438.242(b)(5), and 457.1233(d) to provide clinical data through the API if the state or managed care plan maintains such clinical data. Clinical data subject to this requirement includes laboratory results and other clinical data, and must be made available through the Patient Access API regardless of the type of transaction by which the state or managed care plan received the data originally. However, if the data were received under the payer-to-payer data exchange requirement finalized in section V. of this final rule at 42 CFR 422.119(f), 438.62(b)(1)(vi), and 457.1216, and 45 CFR 156.221(f), then the payer would only need to share the clinical data received via the payer-to-payer data exchange via the Patient Access API if the data were received from another payer via a standards-based API. As required at 42 CFR 422.119(f)(1)(iii), 438.62(b)(1)(vi)(C), and 457.1216 and 45 CFR 156.221(f)(1)(iii), data received via the payer-to-payer data exchange only need to be made available to share in the electronic form and format they were received from another payer. If a payer receives data specifically for the payer-to-payer data exchange via an API, they can then make these data available via the Patient Access API without additional burden—the payer will not be required per this final rule to take data from another payer received as a direct result of the payer-to-payer data exchange policy and prepare it to be shared via the Patient Access FHIR-based API; the payer will only be required to incorporate that data into the enrollee's record so that it can be shared with a new payer, if requested by the patient, in the electronic form and format received. Appreciating concerns raised around the burden of preparing data for exchange via an API, we have provided this guidance to minimize this burden. We note that Medicaid and CHIP state agencies are not subject to the payer-to-payer data exchange requirement in this rulemaking, as we did not propose this policy for these entities.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters recommended that patients have access to detailed and accurate lab test and results information through the Patient Access API. A few commenters were not supportive of CMS' proposal that laboratory information be made available only where available. One commenter recommended that these same API requirements apply to laboratories providing service to Medicare and Medicaid patients as any provider receiving reimbursement for medical services. One commenter expressed concern that lab information is not standardized and may be difficult to exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. These regulations requiring the Patient Access API and detailing the data available through the Patient Access API, as proposed and as finalized, do not apply to laboratories or to any providers—these requirements are specific to payers as detailed above, but we will review the recommendations made for potential future consideration.
                    </P>
                    <P>
                        Regarding concerns about standardized data exchange of laboratory information, the regulations finalized in this rule provide the content and vocabulary standards at 45 CFR 170.213 needed to address sharing laboratory data through the API. Implementation guidance, now 
                        <PRTPAGE P="25539"/>
                        available at 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index,</E>
                         though not mandatory, can be used to further support sharing these data utilizing the content and vocabulary standards adopted in this rule. These implementation guides and reference implementations provide additional support to help payers implement this policy in a standardized way that facilitates interoperability.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters were concerned about the proposed timeline and challenges specifically because of the nature of laboratory data, specifically laboratory results. Final results can replace preliminary results, and laboratory data coming from third parties can take time to receive. Additionally, there may be conflicting disclosure requirements that permit up to 30 days to pass before laboratory data are available to a payer.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We do understand that there are many factors that could influence when some data are available. However, we reiterate that this Patient Access API policy requires the information to be shared no later than one (1) business day after it is received by the regulated payer. If it takes additional time for laboratory information to be provided to a payer, that does not impact the payer's obligation to make the data available via the Patient Access API no later than one (1) business day after the receipt of the information by the payer. Therefore, we strongly encourage all payers and providers to work to make data available in as timely a fashion as possible to ensure an optimally informed health care ecosystem.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the proposal to require providing the information in the USCDI via the Patient Access API. Commenters supported alignment with ONC on this and encouraged additional alignment across government data sets. Commenters also supported the data classes and associated standards in the proposed ONC USCDI. One commenter specifically noted support for the pediatric vital signs proposed as part of the USCDI. A few commenters recommended the addition of data classes that are already proposed as part of the USCDI, such as clinical notes, provenance, and unique device identifiers. A few commenters strongly supported the inclusion of notes in the USCDI, citing several studies of the benefits of patients having this information including, but not limited to, patient literacy, empowerment, health care coordination, medication adherence, and safety. One commenter recommended only final notes be considered applicable to the USCDI and that the imaging note be removed from the types of required notes. This commenter also indicated that notes that contain sensitive information were likely subject to a variety of state privacy laws. A few commenters noted further standardization work was needed for provenance data fields.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support and recommendations; we have shared these comments about the USCDI with ONC for future consideration. We agree that aligning with ONC and finalizing exchange of the USCDI as defined at 45 CFR 170.213 in ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) has many benefits and will help us reach our interoperability goals. We refer readers to ONC's final rule for the specifics of exactly how the USCDI standard is being finalized by HHS. As finalized here, the clinical data required to be made available through the Patient Access API at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii) at a minimum are the USCDI version 1 as defined at 45 CFR 170.213 and specified in this rule at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and 457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i). We do note the policies finalized in this regulation do not alter obligations under existing federal and state laws. We reiterate that we are working closely with HL7 and other partners leading the effort to develop standards to ensure helpful guidance is available for payers to consult as they work to implement the policies being finalized in this rule. Again, we note that, though not mandatory, we are providing a link to specific implementation guides and reference implementations that provide valuable guidance to support payers as they work to implement the Patient Access API: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested that all the data elements in the USCDI be specifically enumerated in the regulation text of this final rule for clarity. A few commenters recommended CMS and ONC limit the definition of electronic health information to solely the data classes included in the USCDI. Another commenter did not believe this definition should be limited to identifiable information. One commenter suggested that the definition of electronic health information should include real price information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations. We are finalizing our regulation text that requires use of the standard specified at 45 CFR 170.213 in ONC's separate rulemaking to ensure alignment and consistency across the two regulations. That specific standard is currently the USCDI version 1 and therefore the USCDI will be the initial standard applicable under this final rule. Additional information about the data classes and data elements included in USCDI can be found at 
                        <E T="03">http://www.healthit.gov/USCDI.</E>
                         We continue to use “electronic health information” as defined by ONC at 45 CFR 171.102. With regard to specifically listing the data elements in the USCDI, we believe cross referencing ONC's regulation better supports our goal of aligning with ONC's policy regarding this information.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter did not support the proposed requirement to provide patients with the USCDI data because the commenter believed it was not feasible for payers. The commenter indicated that payers do not typically collect clinical data. One commenter recommended that CMS use FHIR bundles, or a collection of relevant FHIR resources, rather than the USCDI. One commenter was concerned with how free text fields would be addressed in the USCDI. One commenter expressed concern that CMS would require the use of non-HIPAA standards in the USCDI for providing data to patients.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We acknowledge that payers do not maintain all clinical data for all patients and our regulation text at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii), as finalized, specifically limits the obligation to make clinical data available through the Patient Access API to those payers that maintain any such data. If a payer subject to these regulations (including the Medicaid and CHIP managed care plans that are subject to regulations that incorporate these requirements) maintain the data elements specified in this final rule, these data elements must be shared as noted in this final rule using the standards indicated. If payers do maintain valuable clinical data about patients, patients have a right to these data. This is a first step in providing patients with information from their medical record in an efficient electronic format.
                    </P>
                    <P>
                        We appreciate the recommendation to look at alternatives to the USCDI, but we believe it is critical for interoperability to align with ONC and see great value 
                        <PRTPAGE P="25540"/>
                        in the continued coordination between CMS, ONC, and partners such as HL7 to ensure helpful guidance is available for payers to consult as they work to successfully implement these final rule policies. To this end, we again note that we have provided a link to specific implementation guides and reference implementations that, though not mandatory, can be used to support consistent implementation. We refer readers to additional information on the USCDI at 
                        <E T="03">http://www.healthit.gov/USCDI</E>
                         and available guidance at 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index</E>
                         to best understand how to implement all data classes and elements included in the USCDI including text fields. Regarding the use of non-HIPAA versus HIPAA standards, we do not believe there is a conflict, and we refer readers to the discussion of Administrative Simplification transaction standards in section III.C.2.b. of this final rule for more information.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter suggested that standards development organizations such as HL7 would be better positioned to support data standardization rather than the proposed USCDI approach. A few commenters noted there are different use cases for various data types and that coordination is required to expand the data in the USCDI. One commenter recommended CMS allow voluntary extensions to data sets outside of the USCDI to support the growth of new standards and data types from a payer perspective.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations. In addition, we appreciate the valuable role of standards development organizations, like HL7, and reiterate our commitment to working with such partners as industry develops the necessary standards and associated guidance to implement the policies being finalized in this rule. We will continue to refer to the USCDI as finalized by HHS in ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.213 to ensure alignment and consistency across the two regulations. We further refer readers to additional information about the USCDI and the expansion process as defined by ONC at 
                        <E T="03">http://www.healthit.gov/USCDI.</E>
                         We note that this expansion process is a consensus process that allows for public input and comment and strongly recommend stakeholders continue to engage in this valuable process. This coordination and consensus is a cornerstone of our interoperability efforts. We also note that the data elements required in this final rule represent the minimum data that must be shared under our finalized policy through a payer's Patient Access API. We strongly encourage payers to share more data as the more data that patients have access to, the more they will benefit from this access. We agree that continuing to push these limits will spur innovation and growth.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters requested additional information regarding the definitions of terminology used when discussing the USCDI in the CMS Interoperability and Patient Access proposed rule. One commenter requested more information on the meaning of “state agencies,” in reference to “any clinical data included in the USCDI standard . . . be available through the API,” and if this meant that if the state agency managed an immunization registry it would be required to make the data available through an API. Another commenter requested CMS to provide more information about the use of “forward” (in the preamble) versus “send” (in the regulatory text) regarding the USCDI, including whether the information needs to be available to the receiving payer and whether use of a trusted exchange network is required.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' requests for additional information. We note that the term “state agencies” in this instance in the proposed rule (84 FR 7634) refers to those state agencies that manage Medicaid and CHIP programs. If a Medicaid or CHIP state agency has immunization data in connection with its Medicaid program or CHIP as defined in the USCDI, these data would be required to be available via the Patient Access API per our proposal as finalized. We note that in section V. of this final rule, we require the exchange of the USCDI between payers subject to this regulation; this payer-to-payer data exchange does not require the use of an API. As finalized, our policies do not require the use of a trusted exchange network. Regarding the use of terms “forward” and “send,” we note this means that the data must be exchanged with the patient as specified here in section III. of this final rule or between payers as discussed in section V. of this final rule.
                    </P>
                    <HD SOURCE="HD3">(4) Drug Benefit Data, Including Pharmacy Directory, and Formulary Data</HD>
                    <P>We proposed that drug benefit data, including pharmacy directory information and formulary or preferred drug list data, also be available through the Patient Access API at proposed 42 CFR 422.119(b)(2)(ii) and (iii), 431.60(b)(5), and 457.730(b)(5). (Our proposal for providing prescription drug claims through this API is discussed in section III.C.2.c.(1) of the CMS Interoperability and Patient Access proposed rule (84 FR 7632).) As previously discussed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.) to comply with the requirement at 42 CFR 431.60(b)(5), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(b)(5).</P>
                    <P>We proposed at 42 CFR 422.119(b)(2)(ii) and (iii) that MA organizations offering MA-PD plans must make available through the API the following pharmacy benefit data: (1) Pharmacy directory data, including the number, mix (specifically the type of pharmacy, such as “retail pharmacy”), and addresses of pharmacies in the plan network; and (2) formulary data including covered Part D drugs and any tiered formulary structure or utilization management procedure which pertains to those drugs. The pharmacy directory information is the same information that MA-PD plans—like all Part D plans—must provide on their websites under 42 CFR 423.128(b)(5) and (d)(2). While prescription drug claims would have to be made available through the Patient Access API no later than one (1) business day after the MA-PD plan's receipt of that information, we did not propose a specific timeframe for pharmacy directory or formulary information to be available (or updated) through the API. We noted that we intended that the requirements in 42 CFR part 423 requiring when and how information related to pharmacy directories be updated would apply to the provision of this information through the API; we solicited comment whether we should address this in the regulation text or otherwise impose a timeframe for this information to be made available through the API.</P>
                    <P>At 42 CFR 431.60(b)(5), for Medicaid FFS programs, and at 42 CFR 457.730(b)(5) for CHIP FFS programs, we proposed that states would be required to include and update information about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of any such information or updates to such information.</P>
                    <P>
                        We did not propose a similar requirement for QHP issuers on the FFEs because, like the provider 
                        <PRTPAGE P="25541"/>
                        directory information, QHP issuers are required to make drug formulary data accessible in a machine-readable format.
                    </P>
                    <P>As discussed above for the provider directory information, to avoid unnecessary duplication of effort and potential confusion, we are also not finalizing the proposal to include pharmacy directory information in the Patient Access API. Instead, we are only finalizing the inclusion of this information as proposed and explained above be included in the public facing Provider Directory API discussed in section IV. of this final rule, which requires MA organizations that offer MA-PD plans to provide public access to pharmacy directory information at 42 CFR 422.120(b). Relevant comments are also discussed in section IV. of this final rule.</P>
                    <P>We summarize the public comments received on our proposal that information about drug coverage and pharmacy benefit coverage be available through the Patient Access API and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter recommended CMS require that MA plans make information about patients' step therapy available for sharing electronically. This commenter opposes step therapy and recommended that it not be used in MA or Part D.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The use of step therapy is beyond the scope of this rule. However, because step therapy is a utilization management procedure, it is included among the types of information MA-PDs must make available about Part D drugs through the API. In regard to information about utilization management that pertains to basic benefits, which was not addressed in this rule, we appreciate the commenter's recommendations and will evaluate them for potential future consideration.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter strongly recommended the inclusion and standardization of prescription drug monitoring program data (PDMP) for exchange through APIs, although this commenter referred more to exchange between providers for downstream clinical decision support and analytics rather than for patient access. A few commenters were not in favor of sharing PDMP data through APIs. A few commenters were not supportive of PDMP data being available to other providers and payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations and concerns. However, we note that this information is not required to be available through the Patient Access API as it is not within the scope of 422.119(b)(2).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters expressed concern that the proposals in 42 CFR 431.60(b)(5), 457.730(b)(5), 438.242(b)(6) (finalized as 42 CFR 431.60(b)(4), 457.730(b)(4), and 438.242(b)(5) in this rule), and 45 CFR 457.1233(d) to provide information on covered outpatient drugs and preferred drug lists through an API within one (1) business day after the effective date of the information or updates to the information may be a challenge for state Medicaid and CHIP agencies and Medicaid and CHIP managed care entities. One commenter recommended to first require state Medicaid pharmacy programs to focus on developing interoperable standards for API development and only require managed care entities to adopt the standards once the API has been tested and scaled at the state level.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We understand that our proposed timeframe of one (1) business day may be operationally challenging for states and managed care plans but continue to believe that this timeframe is critical in order for beneficiaries and prescribers to have this information as soon as the information is applicable to coverage or in near real time since this information could improve care and health outcomes. We believe that timely data are particularly important during urgent or emergency situations. We note that having access to this information as soon as, or even before, it is effective is necessary for patients and their providers to make important decisions about which medications should be included in a patient's care plan. This is particularly important for patients who may not be able to cover a medication out of pocket if it is not covered by their plan. Therefore, we are finalizing the timeframe. We decline to only apply these requirements to state Medicaid programs (and decline to postpone application of the timeframe to managed care plans until a future time as recommended by the commenter) because this approach would not be consistent with our goal of ensuring that the patients covered by the payers impacted by this requirement have access to the specified data. We also note that we are providing a link to specific implementation guidance and reference implementations for all payers to further support sharing the needed data using the required standards: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                         We are finalizing these requirements for the API to include formulary information for MA organizations offering MA-PD plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities.
                    </P>
                    <P>In addition to comments about the specific types of information we proposed be made available through the Patient Access API, we also received comments on additional types of information stakeholders would like to see included. We summarize the public comments we received on this topic and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters made a number of suggestions for additional data to be made available to patients via the Patient Access API. Some of the data requested is already included in the proposal and being finalized for inclusion as proposed. In addition to these requests, a few commenters recommended CMS also require the inclusion of information regarding prior authorization decisions, drug pricing, and a direct phone number for patients to call providers and their staff about prior authorization issues. A few commenters specifically requested prior authorization decision information, including active prior authorizations, be made accessible to patients; a few other commenters suggested this prior authorization information be available to providers.
                    </P>
                    <P>
                        Commenters recommended future versions of the USCDI include additional data so that these data would be available via the Patient Access API. A few commenters recommended the USCDI include social determinants of health data. One commenter recommended CMS and ONC include additional immunization data elements from the CDC endorsed data elements for immunization and the American Immunization Registry Association's Functional Guide. One commenter recommended Care Team Data Class as well as Data Class Provenance “Author Health Profession” be added. One commenter recommended including coverage and explanation of benefit data to the USCDI per the CARIN Alliance's Implementation Guide. Another commenter recommended CMS include data elements related to administrative transactions. One commenter recommended the USCDI include Digital Imaging and Communications in Medicine (DICOM) images in addition to the already included imaging notes. A few commenters requested CMS specifically require the use of Systematized Nomenclature of Dentistry (SNODENT) for dentistry findings, disorders, and diagnoses, versus making SNODENT optional as part of the proposed USCDI.
                        <PRTPAGE P="25542"/>
                    </P>
                    <P>A few commenters recommended that additional care settings or provider types are considered for additional USCDI data classes in the future. These included anesthesiology, registered dietitian nutritionists, and post-acute care settings (including hospice). One commenter recommended that the USCDI include additional FHIR-based pharmacy benefit standard-based formulary and drug benefit data. Another commenter requested that Admission, Discharge, and Transfer (ADT) data classes and data elements be included in the USCDI. One commenter recommended CMS work with the industry to standardize unstructured encounter data. One commenter was concerned that the USCDI includes data traditionally collected in EHRs and that data/standards for non-health care transactions are not included (for example, home modifications). One commenter expressed concerns that the USCDI does not include the entire designated record set, such as images and genomic test reports and recommends this be included.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations and will work with ONC to evaluate these recommendations for possible future consideration, as appropriate and feasible.
                    </P>
                    <P>We also received comments detailing concerns with the volume of data being proposed to be made available through the Patient Access API. We summarize the public comments we received on this topic and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters were concerned with the potential volume of data that will be made available to patients through the Patient Access API. A few commenters requested CMS provide more information regarding the minimum information required to be shared under our policies. One commenter suggested that an advisory panel determine the volume and types of information that patients should receive.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. Regarding the data to be made available to patients, as noted in section III.C.2.b. of this final rule, to ensure consistent implementation and minimize the burden on payers, we are finalizing in the applicable regulations additional text to specify that MA organizations at 42 CFR 422.119(h), state Medicaid FFS programs at 42 CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii), CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at 42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221(i), beginning January 1, 2021 (or beginning with plan years beginning on or after January 1, 2021 for QHPs on the FFEs), must make available through the Patient Access API data they maintain with a date of service on or after January 1, 2016. We are also finalizing the same years of data be available through the Patient Access API and for the payer-to-payer data exchange requirement discussed in section V. of this final rule. These policies support the ultimate goal to provide patients access to their cumulative health information.
                    </P>
                    <P>
                        We are finalizing as proposed the minimum content required to be accessible through the Patient Access API in the regulation text at 42 CFR 422.119(b), 431.60(b), 438.242(b)(5), and 457.730(b), and 45 CFR 156.221(b). This specifically includes adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data (including laboratory results) (where maintained by the applicable payer), as well as formularies or preferred drug lists for all impacted payers except QHP issuers on the FFEs. As discussed above, these data must be shared using the content and vocabulary standards at 45 CFR 170.213, finalized by HHS in ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ), and in 45 CFR part 162 and 42 CFR 423.160. We believe that patients have a right to their health care information so they can use and share this information to best inform their health care decisions. We appreciate the recommendation to create an advisory panel, and will evaluate it for potential future consideration.
                    </P>
                    <HD SOURCE="HD3">d. Documentation Requirements for APIs</HD>
                    <P>We proposed that the specific business and technical documentation necessary to interact with the proposed APIs be made freely and publicly accessible. As discussed in section II.A.1 of the CMS Interoperability and Patient Access proposed rule (84 FR 7620), we believed transparency about API technology is needed to ensure that any interested third-party application developer can easily obtain the information needed to develop applications technically compatible with the organization's API. Transparency is also needed so that third-parties can understand how to successfully interact with an organization's API. This includes how to satisfy any requirements the organization may establish for verifying a developer's identity and their applications' authenticity, consistent with the payer's security risk analysis and related organizational policies and procedures. In this way payers can ensure they maintain an appropriate level of privacy and security protection for data on their systems.</P>
                    <P>Specifically, at 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 CFR 156.221(d), we proposed virtually identical text to require the regulated entities to make complete accompanying documentation regarding the API publicly accessible by posting this documentation directly on the applicable entity's website or via a publicly accessible hyperlink. As previously discussed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.) to comply with the requirement at 42 CFR 431.60(d), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(d). In requiring that this documentation be made “publicly accessible,” we noted that we expected that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps beyond downloading and using a third-party application to access data through the API. We also noted that this was not intended to preclude use of links the user would click to review the full text of lengthy documents or access sources of additional information, such as if the technology's supplier prefers to host technical documentation at a centralized location. Rather, we meant “additional steps” to include actions such as: Collecting a fee for access to the documentation; requiring the reader to receive a copy of the material via email; or requiring the user to read promotional material or agree to receive future communications from the organization making the documentation available.</P>
                    <P>We summarize the public comments received on our proposal regarding API documentation and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters opposed the API documentation proposal indicating payers and providers will be required to provide data without a charge, but the freely and publicly accessible documentation would enable applications to collect data and possibly sell the data back to payers and providers if needed for secondary uses such as provider directories.
                    </P>
                    <P>
                        Some commenters supported fees for documentation noting the funds required to create and maintain data for sharing between payers and enrollees. 
                        <PRTPAGE P="25543"/>
                        Commenters believed third parties should be charged a fee to maintain the API. One commenter expressed concern that the business model of the third-party applications hinges on their ability to sell the data they collect for secondary uses while payers and providers would be required to provide information to vendors absent a fee. This commenter argued that charging third-party vendors a fee for documentation could be one way for vendors to absorb some of the cost of maintaining the API in exchange for the data they could potentially use to make a profit.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We also appreciate the concerns raised around the secondary uses of data shared with third-parties. We note that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it is considered a deceptive act to use a person's sensitive information without disclosing in product documentation how this information will be shared.
                        <SU>31</SU>
                        <FTREF/>
                         In addition, we do not believe that charging a fee to access API documentation is appropriate to offset secondary data use concerns. We refer readers to the additional discussion below regarding informing patients about potential secondary uses of data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>31</SU>
                             See also cases where this authority was used, such as 2012 FTC action against Facebook (see 
                            <E T="03">https://www.ftc.gov/enforcement/cases-proceedings/092-3184/facebook-inc</E>
                            ), the 2012 FTC action against MySpace (see 
                            <E T="03">https://www.ftc.gov/enforcement/cases-proceedings/102-3058/myspace-llc-matter</E>
                            ), and the 2017 FTC action against VIZIO (see 
                            <E T="03">https://www.ftc.gov/enforcement/cases-proceedings/162-3024/vizio-inc-vizio-inscape-services-llc</E>
                            ).
                        </P>
                    </FTNT>
                    <P>The data that must be shared via the API under this policy are data that the payers have and must currently share with patients under existing law. The public directory data is already public information. We do not believe it is appropriate to charge a fee for documentation required to access such available data. Taking the example of provider directory data raised by commenters, currently there are vendors that collect the publicly available directory data, clean these data, supplement these data, and offer this enhanced data product back to payers and providers. It is not the data the vendors are charging for as much as it is the service of cleaning and enhancing these data. Vendors may generate revenue from their third-party apps, but a major component of this is the service they are providing—building the app, making the data the patient directs to them most usable and valuable—that generates the revenue. Payers must already make these data available to patients. These data alone may also drive revenue, but it is the patient's prerogative to provide their data to a third-party in order to get a service in exchange. Being sure patients are as informed as possible about secondary uses of data and how this may impact them is important. As a result, we discuss this issue more below.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters indicated support for permitting access to documentation without access fees, citing concern that the fees would be extended to consumers as well as logistical concerns for how they would be paid. A few commenters specifically recommended alignment with the ONC 21st Century Cures Act proposed rule API documentation requirement by using the language included in the discussion of the proposed requirement at 45 CFR 170.315(g)(10) stating that the documentation should be “accessible to the public via a hyperlink without additional access requirements, including, without limitation, any form of registration, account creation, `click-through' agreements, or requirement to provide contact details or other information prior to accessing the documentation” (84 FR 7484).
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We do appreciate the requests to explicitly state what we mean by “public access” and ensure it is clear this does not permit any additional restrictions or fees. As a result, to further align with the discussion in the ONC 21st Century Cures Act proposed rule (84 FR 7477), and the CMS Interoperability and Patient Access proposed rule (84 FR 7620), we are finalizing regulation text stating that “publicly accessible” means we expect that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available. We are finalizing this requirement at 42 CFR 422.119(d), 431.60(d), 438.242(b)(5) (through cross-reference to Medicaid FFS), 457.730(d), 457.1233(d)(2) (through cross-reference to CHIP FFS), and 45 CFR 156.221(d).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter did not support this documentation proposal for security reasons as the commenter believed that if the documentation was public, any third-party or organization could potentially call, or connect to, a payer's API. This commenter preferred an alternate approach where CMS stipulates in order to call an API, there would need to be appropriate security tokens in place between the two parties engaged in the data exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We note, however, that making the documentation available publicly does not impact the security of the standards-based API itself. This level of transparency is common in other industries and across standards, and has been shown to lead to innovation and competition. HL7 is built on free and open documentation to ensure that all developers can equally access information. Reviewing the documentation available for FHIR is one way of appreciating the value of this information and how having it freely accessible can allow innovators to engage with health care data in the most meaningful ways.
                        <SU>32</SU>
                        <FTREF/>
                         Having access to the documentation is not the same as access to the actual API for the purposes of data exchange.
                    </P>
                    <FTNT>
                        <P>
                            <SU>32</SU>
                             HL7 International. (n.d.). FHIR Overview. Retrieved from 
                            <E T="03">https://www.hl7.org/fhir/overview.html.</E>
                        </P>
                    </FTNT>
                    <P>Appreciating the comments received and the need to have documentation available to ensure successful implementation and use of the Patient Access API, we are finalizing our proposal to make publicly accessible documentation that includes, at a minimum: (1) 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; (2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and (3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API. As noted, we have made one modification by adding the definition of “publicly accessible” to the relevant regulation text.</P>
                    <HD SOURCE="HD3">e. Routine Testing and Monitoring of Standards-Based APIs</HD>
                    <P>
                        At 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2) for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs, respectively, we proposed that the API must be routinely tested and monitored to ensure it is functioning properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as but not limited to those required to 
                        <PRTPAGE P="25544"/>
                        comply with the HIPAA Privacy and Security Rules, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable health information. As proposed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) (redesignated as 438.242(b)(5) in this final rule; see section VI. of this final rule) to comply with the requirement at 42 CFR 431.60(c), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(c).
                    </P>
                    <P>Additionally, we noted that while federal laws that regulate MA organizations and MA plans supersede any state law except where noted under section 1856(b)(3) of the Act, some state, local, or tribal laws that pertain to privacy and security of individually identifiable information generally, and that are not specific to health insurance, may also apply to MA organizations and MA plans in the context of the proposal. For the other entities regulated under the proposals in these various programs, we noted that we also intended the phrase “other applicable law” to include federal, state, tribal or local laws that apply to the entity.</P>
                    <P>We proposed this requirement to establish and maintain processes to routinely test and monitor the standards-based APIs to ensure they are functioning properly, especially with respect to their privacy and security features. We explained in the preamble of the proposed rule that under the proposal, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs would have to implement, properly maintain, update (as appropriate), and routinely test authentication features that will be used to verify the identity of individual enrollees who seek to access their claims and encounter data and other PHI through the API. Similarly, as discussed, compliance with the proposed requirements would mean that these entities must implement, maintain, update (as appropriate), and routinely test authorization features to ensure an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee. As is the case under existing HIPAA Privacy Rule requirements, where an individual is also a properly designated personal representative of another enrollee, the HIPAA covered entity must provide the personal representative appropriate access to the information about the enrollee that has designated them as their personal representative, just as they would if the personal representative were the enrollee.</P>
                    <P>We summarize the public comments we received on routine testing and monitoring and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters supported the proposal to require that payers routinely test and monitor the standards-based API needed to meet the requirements of this proposal. One commenter recommended that this be self-regulated rather than mandated, however. A few commenters expressed concern with the requirement to test and monitor the API. A few additional commenters expressed concern that there is no consensus on a common testing environment. One commenter believed that testing and monitoring will be costly.
                    </P>
                    <P>Several commenters urged CMS to provide additional information and guidance on any requirements for testing and monitoring APIs, including the expected frequency of testing. A few commenters requested additional information on whether payers will be required to demonstrate compliance by submitting or reporting on testing plans. One commenter requested clarification on the process if an issue is found during testing or monitoring. One commenter requested that CMS specify what “routine” means.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We did not specify exactly at what intervals or frequency testing should be done, and thus did not quantify “routine,” as we believe it is important that payers put a process in place that works best for them to conduct testing and monitoring at regular intervals to ensure the required API remains in compliance and is working as expected. We will provide best practice information, including information on available API testing tools to support payers with this required activity. In our review of the proposed regulation text, we realized that the regulation text at 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2) did not specify the requirement to also update (as appropriate) the API to ensure it functions properly and includes assessments to verify an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee. We are finalizing additional text to this effect. We are also removing the word “minimally” from this regulation text in order to ensure it is clear that privacy and security features must be reasonable and appropriate, consistent with the requirements of the HIPAA Security Rule. We note that this testing requirement is accounted for in sections XII. and XIII. of this final rule as one of the expected steps of implementing and maintaining an API. This is part of the cost factored into implementation of the API and is a necessary part of using an API. It is also part of current software development best practices. Payers implementing APIs can incorporate testing tools into a comprehensive testing plan and continuous integration (CI) system, which can automatically validate adherence to the implementation guide when changes are made to further mitigate this cost.
                    </P>
                    <HD SOURCE="HD3">f. Compliance With Existing Privacy and Security Requirements</HD>
                    <P>In the hands of a HIPAA covered entity or its business associate, individually identifiable health information, including information in patient claims and encounter data, is PHI and protected by the HIPAA Rules. Ensuring the privacy and security of the claims, encounter, and other health information when it is transmitted through the API is important. Therefore, in the CMS Interoperability and Patient Access proposed rule (84 FR 7635), we reminded MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs that mechanisms and practices to release PHI, including but not limited to authorization and authentication protocols and practices, must provide protection sufficient to comply with the HIPAA Rules and other privacy and security law (whether federal, state, tribal, or local) that may apply based on the specific circumstances. As proposed, the entities subject to these requirements would need to continuously ensure that all authorization and authentication mechanisms provide sufficient protections to enrollee PHI and that they function as intended. We specifically requested public comment on whether existing privacy and security standards, including but not limited to those in 45 CFR part 164, are sufficient with respect to these proposals, or whether additional privacy and security standards should be required by CMS as part of the proposal.</P>
                    <P>
                        We note that comments and our responses related to privacy and security issues, generally, can be found in section II.A.2. of this final rule. Here, we summarize the public comments we received on privacy and security as it relates to consent, authentication, and identity verification and provide our responses.
                        <PRTPAGE P="25545"/>
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed concerns with using the proposed FHIR standards for obtaining patient consent, with some noting the lack of mature consent mechanisms supported through FHIR. A few commenters expressed concerns that there are no mature or widely accepted standards for documenting patient consent electronically, generally. One commenter suggested that the patient be able to see their consent preferences and the types of data that have been authorized for sharing from a central location.
                    </P>
                    <P>One commenter recommended that CMS or OCR develop a standardized data sharing patient consent form that payers, providers, and health IT vendors can use to ensure appropriate consent. A few commenters recommended that CMS require payers and/or apps to use ONC's Model Privacy Notice. One commenter recommended that CMS and FTC should develop plain language consumer notifications that could be used by app developers. One commenter recommended that CMS require payers to include in their enrollment process an efficient “check off” authorization for an enrollee to release their information to their providers. A few commenters noted that it should be the responsibility of the app to verify the patient's ability to provide consent.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters concerns and recommendations, and we have shared these with ONC for consideration. Regarding FHIR standards for consent, we refer readers to discussion in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ), which considers the status of current development efforts around consent resources. We will continue to work with ONC and industry partners to monitor the development of FHIR resources to support consent management. We believe that the security protocols at 45 CFR 170.215 are sufficient to authenticate users and authorize individuals to access their data maintained by payers in accordance with the requirements described in this rule and, therefore, provide the necessary consent mechanisms for payers to implement the policies in this rule.
                    </P>
                    <P>
                        We appreciate the additional recommendations made regarding developing consent materials for all payers to use, as well as recommendations around the use of the ONC Model Privacy Notice. More information on available consent options can be found at 
                        <E T="03">https://gforge.hl7.org/gf/project/cbcc/frs/,</E>
                         and ONC's Model Privacy Notice is available at 
                        <E T="03">https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn,</E>
                         which interested payers or app vendors can use. We will evaluate recommendations made that would add requirements on payers that we had not proposed, including any centralized solution, for possible future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters supported efforts to verify if an entity is authorized to access the data they are seeking. One commenter supported the proposed use of the OAuth standard. One commenter believes that the use of OAuth 2.0 for client application authorization and OpenID Connect for client application authentication should include authenticity, integrity, and non-repudiation standards. Another commenter suggested CMS permit flexibility in the implementation of security standards. A few commenters expressed concerns with using the proposed FHIR standards for identity proofing alone and supported additional measures, such as biometrics, be employed as well. A few commenters expressed concern about open-ended token access once initially authenticated and instead recommended CMS implement a 90-day timeframe for the authentication token to remain open. One commenter suggested that encryption of authentication credentials is not sufficient.
                    </P>
                    <P>One commenter believed that the only true means by which an individual can assert their identity is through a government-issued ID, and if this cannot be produced, the commenter noted several limitations that should be put in place to prohibit data sharing until further authentication can be done. Another commenter suggested CMS look into biometrics as a means for improving identity proofing. A few commenters recommended the use of multi-factor authentication to verify the identification of an individual.</P>
                    <P>A few commenters recommended requiring payers give their members an online way to self-enroll for the necessary credentials to access their health information via an API. One commenter stated that this will reduce the time it takes for an organization to verify a request. One commenter recommended that this should apply to any of a payer's patients who have been a member in the past 5 years. One commenter expressed concern that without clear guidelines for how patients can access their data, patients may face barriers such as trying to get authentication credentials, and trying to get an app authorized.</P>
                    <P>A few commenters recommended CMS develop a common method to validate the identity and authority of the requesting party. One commenter recommended CMS issue guidance on authenticating the requestor that offers a simple, secure method to obtain authentication across all entities. A few commenters supported efforts to develop methods to verify a caregiver for a patient and allow that caregiver to access all health information systems.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We are finalizing as proposed to require compliance with 45 CFR 170.215 as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). This requires use of HL7 FHIR Release 4.0.1, and complementary security and app registration protocols, specifically the SMART Application Launch Implementation Guide (SMART IG) 1.0.0 (including mandatory support for the “SMART on FHIR Core Capabilities”), which is a profile of the OAuth 2.0 specification, and the OpenID Connect Core 1.0 standard, incorporating errata set 1). Additional information and implementation guidance can be found at 
                        <E T="03">http://hl7.org/fhir/smart-app-launch/.</E>
                         The goal of using these resources is to make authorization electronic, efficient, and secure so that patients can access their health information as effortlessly as possible.
                    </P>
                    <P>
                        We agree that multifactor authentication represents a best practice for privacy and security in health care settings, and we note that an important benefit of the OAuth 2.0 standard HHS is finalizing is that it provides robust support for multifactor authentication. By requiring that payers subject to our Patient Access API requirement use an API that is conformant with 45 CFR 170.215, where HHS has finalized the SMART IG, we are supporting the use of multifactor authentication. We also note that as part of ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ), HHS is finalizing a new provision in the ONC certification program that would require health IT developers to attest as to whether they support multifactor authentication, further encouraging adoption of such security practices. We also strongly encourage payers subject to the requirements in this final rule to employ robust privacy and security protocols, and use multifactor authentication, where appropriate. Multifactor authentication is industry accepted, routinely used across many sectors, 
                        <PRTPAGE P="25546"/>
                        known to patients, and a low burden option that could significantly increase security.
                    </P>
                    <P>Though we appreciate commenters' requests to leave flexibility here, we do believe adopting the standards as finalized by HHS in ONC's 21st Century Cures Act final rule regarding the use of the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0 is an important starting point. In addition, we note that the technical standards at 45 CFR 170.215 address the comments regarding tokens, as HHS is finalizing use of tokens at 45 CFR 170.215 as part of the SMART IG. We note that ONC is requiring that a token be valid for at least 3 months for certified health IT; we encourage payers subject to this final rule to align with this best practice. We appreciate recommendations for a centralized solution to patient authentication and identity proofing, and caregiver access, and will take these under consideration as appropriate.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed that patients should have ultimate authority and the ability to consent to what type of information can be shared as well as who can access their health information. One commenter recommended CMS require that patients have the ability to filter or request only the specific data that they want to be shared. One commenter requested that payers be able to access the specific types of data a patient authorized the app to access. One commenter added patients should also have an accounting of disclosures or access to their data.
                    </P>
                    <P>A few commenters expressed concerns over the sharing of patient electronic health information with health care providers that the patient has not consented to share with. A few commenters expressed specific concerns with sharing electronic health information beyond the immediate health care provider, such as with providers with which a patient may be seeking a second opinion or additional care. One commenter was concerned with the sharing of family health history data particularly for family members who have not consented.</P>
                    <P>A few commenters recommended that providers be able to pre-filter or select which data can be made available to the patient, citing concerns with the sensitivity of some provider notes or patient confusion in interpreting certain information. A few commenters also suggested that providers be able to select which information can be made available to the payer.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and suggestions. Collectively, HHS has been working to evaluate various technical specifications for data segmentation to enhance privacy protections and comply with applicable law (such as laws regarding privacy for minors or 42 CFR part 2). Both HHS and the industry as a whole are currently evaluating future use cases related to segmenting data at the patient request. At this time, however, the policies as they are being finalized under this rule require that the payers, with the approval and at the direction of the patient, provide all of the data as specified in the applicable regulation text. Beyond this, payers, providers, and patients cannot direct specific segments of data be made available via this Patient Access API. The necessary technical specifications to allow a patient to request some data elements be shared but not others are not widely adopted.
                        <SU>33</SU>
                        <FTREF/>
                         If the patient requests their data via the Patient Access API from a payer, the payer must make available all of the data allowed per current law, such as 42 CFR part 2 and relevant state laws, including the data as specified in this final rule. We reiterate, however, that the data that are available to be shared are only to be shared at the patient's request. If there are data elements the patient does not want to be shared, they can choose not to make the request. In addition, we note that this policy allows data to be exchanged from the payer to a third-party app of the patient's choice for their personal use. This rule does not require any data exchange directly between or with providers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>33</SU>
                             For information on adoption levels for technical specifications related to data segmentation, see the Interoperability Standards Advisory at 
                            <E T="03">https://www.healthit.gov/isa/data-segmentation-sensitive-information.</E>
                        </P>
                    </FTNT>
                    <P>Specifically regarding the comment on sharing family history, we note that the health information required to be shared under this policy includes claims and encounter data as well as the data included in the USCDI version 1. At this time, “family history” is not a specific data class within the USCDI. As a result, we do not believe this should be an issue under this current policy. We will, however, take this into consideration as we consider future policy options.</P>
                    <P>We appreciate the recommendation for patients to have a full record of disclosures or access to their health information via the API. At present, the HIPAA Privacy Rule requires accountings of certain disclosures. Consistent with the spirit of this accounting of disclosures, we encourage payers to consider setting up functionality to allow patients to view a record of when and with whom their data have been shared via the API.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed concerns over the complexity with parsing or segmenting electronic health information that is considered sensitive and/or is subject to 42 CFR part 2 rules. Commenters requested CMS take into account these situations with these API proposals and cited use cases such as women's health, sexual health, young adult health, mental health, and substance abuse treatment. A few commenters noted concerns that some health care providers may discriminate or treat a patient differently if they were able to access certain patient's health information. A few commenters recommended that HHS align part 2 and HIPAA regulations. One commenter recommended the use of the Consent2Share (C2S) FHIR Consent Profile developed by SAMHSA. Another commenter suggested CMS defer adoption of the Data Segmentation for Privacy standards until an API FHIR standard version is finalized and the Consent2Share guide is revised to conform to that version.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters concerns and recommendations. We are currently evaluating future options around parsing or segmenting data, generally, using the API. As noted above, HHS is collectively working to explore standards and technical supports for data segmentation for privacy and consent management and point commenters to the ONC 21st Century Cures Act final rule for additional discussion on this. We also note that using the appropriate FHIR profiles, such as those being finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) for API technical standards, including the SMART IG (using the OAuth 2.0 standard) and OpenID Connect as finalized at 45 CFR 170.215, can be leveraged to support this. Again, we note that additional information and implementation guidance can be found at 
                        <E T="03">http://hl7.org/fhir/smart-app-launch/.</E>
                         However, we reiterate that payers' privacy and security obligations under the HIPAA Rules and 42 CFR part 2 are not impacted by this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed particular concern for appropriate authorization of parent/guardian proxies for minor patients. One commenter recommended CMS align the CMS Interoperability and Patient Access proposed rule with the Children's Online Privacy Protection Act (COPPA), which was created to 
                        <PRTPAGE P="25547"/>
                        protect the privacy of children under 13 and has been in effect since 2000.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters concerns and recommendations, which we are reviewing for future possible consideration in regulation. We note that this current regulation does not change any existing privacy relationships between minors and parents. If, for instance, a teenage minor has asserted their protections to not have their guardians see their Explanation of Benefits, the payer would be obligated to maintain these protections when sharing data via the API. For non-minor dependents, again the existing policies hold true.
                    </P>
                    <P>
                        Regarding privacy in an enrollment group, at this time, a policyholder can see the claims for all members of their enrollment group unless there is an agreed upon privacy provision available and in place. The HIPAA Privacy Rule states at 45 CFR 164.522 that individuals have a right to request restrictions on how a covered entity will use and disclose protected health information about them for treatment, payment, and health care operations. However, a covered entity is not generally required to agree to an individual's request for a restriction unless certain limited exceptions are met 
                        <SU>34</SU>
                        <FTREF/>
                        , but is bound by any restrictions to which it does agree. After the Affordable Care Act extended the age that group health plans and issuers of health insurance coverage in the group or individual market that offer dependent coverage of children must continue to make such coverage available to adult children until age 26, some states, including California, Colorado, Washington, Oregon, and Maryland, have enacted stricter protections regarding privacy rights, and although all of these states operate their own SBEs and issuers on these Exchanges are not implicated in this rule, to the extent issuers are operating in both these and FFE states and have applied their privacy policies across markets, consumers in FFE states may also benefit from these stricter protections. This final rule does not alter obligations under any existing federal, state, local, or tribal law. Again, we note that this data sharing is currently ongoing; the API just provides an additional way to facilitate this exchange.
                    </P>
                    <FTNT>
                        <P>
                            <SU>34</SU>
                             See 45 CFR 154.522(a)(1)(vi) for a discussion of the limited exceptions.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">g. Issues Related to Denial or Discontinuation of Access to the API</HD>
                    <P>We believe patients have a right to their health information. However, a covered entity is not expected to tolerate unacceptable levels of risk to the PHI held by the covered entity in its systems, as determined by its own risk analysis. Accordingly, it may be appropriate for an organization to deny or terminate specific applications' connection to its API under certain circumstances in which the application poses an unacceptable risk to the PHI on its systems.</P>
                    <P>At 42 CFR 422.119(e), § 431.60(e), 438.242(b)(6) (redesignated as § 438.242(b)(5) in this rule; see section VI.), 457.730(e), 457.1233(d)(2) and 45 CFR 156.221(e) for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, respectively, we proposed to specify the circumstances under which these regulated entities, which are all HIPAA covered entities subject to HIPAA privacy and security requirements, may decline to establish or may terminate a third-party application's connection to the covered entity's API while remaining in compliance with the proposed requirement to offer patients access through standards-based APIs. We noted in the CMS Interoperability and Patient Access proposed rule that we intended for the proposal to be consistent with the HIPAA Rules, and we noted that these circumstances apply to specific applications, rather than the third party itself (84 FR 7635 through 7636).</P>
                    <P>Specifically, we proposed that a payer subject to our API proposal could deny access to the API if the payer reasonably determined that allowing that application to connect or remain connected to the API would present an unacceptable level of risk to the security of PHI on the payer's systems. We further proposed that this determination would be made consistent with the payer's HIPAA Security Rule obligations and based on objective, verifiable criteria that would be applied fairly and consistently across all applications through which enrollees seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.</P>
                    <P>Where we proposed to require access through standards-based APIs to otherwise publicly available information, such as provider directories, the entities subject to the proposal may also deny or terminate an application's connection to the API when it makes a similar determination about risk to its systems. However, depending on how the organization's systems are designed and configured, we recognize that the criteria and tolerable risk levels appropriate to assessing an application for connection to an API for access to publicly available information may differ from those required for API access to non-published personally identifiable information (PII).</P>
                    <P>We also anticipated that, where an application's connection has been terminated under these circumstances, it might be feasible in some instances for the organization to allow the application to reconnect to the API if and when the flaw or compromise of the application has been addressed sufficiently that the organization can no longer fairly say the application's API connection continues to pose an unacceptable risk.</P>
                    <P>We summarize the public comments we received on denial or discontinuation of service and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters supported the proposal to allow payers to deny or discontinue access to apps that pose security risks. One commenter specifically supported that the proposal does not allow payers to deny requests based on concerns about the worthiness of the third-party as a recipient of PHI, because patients have the right to share their health information with the app they choose.
                    </P>
                    <P>
                        Several commenters encouraged CMS to develop and/or further define guidelines for identifying “unacceptable risk” and establish a clearer standard for acceptable circumstances when API access can be restricted or denied. A few commenters expressed concerns that the proposed requirements may be interpreted differently among payers, apps, users, and providers. One commenter expressed concern because payers are liable for breaches that occur during data exchange and the commenter does not believe the proposal provides clear authority to deny access based on such security concerns. A few commenters requested that CMS provide more information regarding whether payers may delay and/or deny certain apps that are suspected, or proven to be bad actors. One commenter requested that CMS make the distinction between the risk posed by providing PHI and providing other widely available payer data. A few commenters requested CMS define a time period for how long the ban on access may remain in place. One commenter sought additional 
                        <PRTPAGE P="25548"/>
                        information on whether payers will be able to deny third-party access across the board for all patient queries and plans. A few commenters suggested that CMS should develop a clear process for app developers to follow in the event that a covered entity denies access to an API. A few commenters recommended that CMS include in the final rule a reference to ONC's information blocking definition and clarify that unacceptable levels of risk could be an exception to information blocking.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. As discussed in the CMS Interoperability and Patient Access proposed rule, the criteria and process for assessing unacceptable risk to a payer's system are part of the payer's responsibilities under the HIPAA Security Rule (84 FR 7635). The HIPAA Security Rule requires a covered entity to perform risk analysis as part of its security management processes.
                        <SU>35</SU>
                        <FTREF/>
                         HHS makes a number of tools available to assess risk.
                        <SU>36</SU>
                        <FTREF/>
                         Additional tools are available through the National Institute of Standards and Technology (NIST).
                        <SU>37</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>35</SU>
                             45 CFR 164.308(a)1)(ii)(A).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>36</SU>
                             For more information, see 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/index.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>37</SU>
                             Brooks, S., Garcia, M., Lefkovitz, Ligthman, S., &amp; Nadeau, E. (2017, January). NISTIR 8062
                        </P>
                        <P>
                            An Introduction to Privacy Engineering and Risk Management in Federal Systems. Retrieved from 
                            <E T="03">https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        We note that this policy regarding denial or discontinuation of service refers to a payer's determination that allowing access to their API by a third party would result in risk to their system. As also noted previously, covered entities, in accordance with HIPAA privacy and security obligations, should take reasonable measures to protect data in transit, unless an individual expressly asks that the information be conveyed in an unsecure form or format (assuming the individual was warned of and accepted the risks associated with the unsecure transmission). As explained in this section above, it is the responsibility of payers to assess the risk to their system and act accordingly regardless of whether the data being accessed via the API is PHI or not. If the concern is the security of the payer's system, the type of data being transferred is not at issue. Absent an individual's instruction to disregard in-transit security, if while assessing the security of the app's connection to the API, the covered entity determines the data could be compromised in transit, the payer could discontinue or deny access in order to project the ePHI on its system. Again, this assessment must be based on objective, verifiable criteria in accordance with obligations under the HIPAA Security Rule. Having considered comments, we are finalizing that payers may deny or discontinue any third-party application's connection to their API if the payer reasonably determines, consistent with its security analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the payer's systems or in transit in instances in which the individual did not tell the payer to disregard in-transit risk. For example, where an individual requests that their unencrypted ePHI be transmitted to an app, the payer would not be responsible for unauthorized access to the individual's ePHI while in transmission to the app. When access has been denied or discontinued due to security concerns, we encourage payers and third parties to work together to address the concerns if and as possible to best serve patients. We are not able to set a specific time period or process for this as it is beyond our authority, however, we do note that the HIPAA Privacy Rule requires access to be provided to the individual in a timely manner. Regarding information blocking, we refer readers to the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested that CMS indicate whether third-party applications will be subject to HIPAA or FTC regulations. One commenter requested information about whether patients will be able to terminate third-party access to their health data.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' request for more information. We refer commenters to OCR and FTC for additional information about jurisdiction over third-party apps. We do note, as discussed earlier, that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), the FTC does regulate such third-party apps. Regarding a patient's ability to terminate third-party access, this would be something determined in the terms and conditions of each app.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters recommended that covered payers should have the flexibility to establish additional terms and conditions when denying third-party applications access to their systems. One commenter stated that payers should be able to develop their own validation process for enrollees and have the right to not release the data where the full scope cannot be validated. One commenter stated the payers should be able to refuse to connect to non-vetted apps. Another commenter stated that payers should be able to restrict access if the information exchanged is not permitted under the HIPAA Privacy Rule or if the exchange or use would compromise the confidentiality, integrity, and availability of the information. One commenter recommended that CMS allow covered entities to remove an app from their system if the app does not follow the approved privacy policy. One commenter recommended that providers should be allowed to require a business associate agreement (BAA) with third-party app developers that connect to the API required under this final rule. One commenter suggested allowing restrictions on data mining. However, one commenter expressed concern that payers may place unnecessary barriers and burdens on third-party app developers. The commenter encouraged CMS to ensure that payers cannot place additional constraints on apps, such as requiring a BAA, additional security audits, or requiring that apps make commitments about how it will or will not use the information patients store on it.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations. Specifically, regarding the ability to deny access to a third-party app, we are finalizing this policy as proposed with one modification to add additional clarity around what it means to reasonably determine risk. As such, and as noted above, we are finalizing that payers may deny or discontinue any third-party application's connection to their API if the payer reasonably determines, consistent with its security analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the payer's systems and the payer makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers. As patients have a right to their data and this proposal provides the payers the ability to appropriately protect their systems and the data they hold on it, we do not believe any additional restrictions are needed at this time. We also note it would not be appropriate to require a patient-designated third party to enter into a BAA with a payer as the API-facilitated exchange is taking place per the request of the patient and not by, 
                        <PRTPAGE P="25549"/>
                        on behalf of, or in service to the payer.
                        <SU>38</SU>
                        <FTREF/>
                         In addition, we reiterate that it is beyond our authority to regulate third parties directly. We do note that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it is considered a deceptive act to use a person's sensitive information without disclosing in product documentation how this information will be shared. We do, however, believe patient privacy and security are vitally important. As a result, we lay out an option for payers to ask a third-party app to attest to certain privacy provisions, to help make patients aware of the privacy risks associated with their choices, as detailed in the next section.
                    </P>
                    <FTNT>
                        <P>
                            <SU>38</SU>
                             See 45 CFR 164.103 Definitions, regarding functions of business associate.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters had suggestions on how to further this proposal. A few commenters recommended that CMS could require apps to attest to certain privacy and security provisions, and if they did not, payers could deny access to the API. One commenter recommended that payers be required to vet third-party applications centrally, rather than requiring vetting for every payer and plan. A few commenters expressed concern that it will be significantly burdensome for payers and providers to vet every app that patients may choose to use in support of more central vetting. One commenter suggested that app developers should be able to proactively request to be vetted by a payer, even if the app developer has not received a request from a member.
                    </P>
                    <P>Many commenters recommended CMS and/or HHS establish a certification, independent verification, or vetting process for third-party applications and vendors that would vet or test apps for certain functions, including privacy and security assurances. As an alternative, one commenter recommended CMS require apps generate an accounting of disclosures or join a trusted exchange network.</P>
                    <P>A few commenters requested CMS share its best practices with app authorization and access under the Blue Button 2.0 initiative. A few commenters recommended CMS, or the payers pre-approve and/or maintain a list of approved apps in order for them to access data. Several commenters supported CMS' proposal to allow patients to select any app of their choice. One commenter recommended that providers and payers be required to authenticate the apps their patients choose to use to gain access.</P>
                    <P>One commenter recommended that third-party application should be clear in their terms and conditions when a consumer downloads an app, and if they are not, a payer should not be required to interface with the app. One commenter recommended that the proposal for payers to deny or terminate specific applications from connecting to its API if the risk posed to its systems is unacceptable should be extended to hospitals, health systems, and other health care providers. One commenter suggested that payers should be required to consider the security risks related to provider EHR systems when determining whether to deny or terminate a third-party application. One commenter recommended that CMS develop three options for denial of an application: denial at each API endpoint, centralized application denial, or no denial. One commenter suggested that CMS could consider allowing providers to voluntarily seek assurances or certifications that third-parties are abiding by the API's terms.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations, and we appreciate the concerns raised around privacy and security and the discussion regarding additional steps we can take to protect patient health information. We note that hospitals, health systems, and other health care providers are considered covered entities under HIPAA, and the HIPAA Privacy and Security Rules apply.
                    </P>
                    <P>
                        We do appreciate that app vetting, in particular, is an issue of great interest to payers and providers. We note that we strongly value the role that industry can play in this capacity, and we support efforts within industry to facilitate efficient and effective, publicly accessible information on vetted apps and vendors. We believe industry is in the best position to collectively find the best ways to identify those apps with strong privacy and security practices. We also appreciate the commenters' request for best practices learned through our experience with Blue Button 2.0. You can find this information at 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                    </P>
                    <P>We are not going to pursue the recommendation to develop a CMS or HHS app certification program. Under our current authorities, we do not believe we have the ability to require a third-party app to take part in such a certification program.</P>
                    <P>We do appreciate that, above all else, stakeholders commented on privacy and security and the need to do more to protect patient health information. Throughout this rule we have noted the limitations to our authority to directly regulate third-party applications. We have also explained that we are finalizing that payers can deny API access to a third-party app that a patient wishes to use only if the payer assesses that such access would pose a risk to the PHI on their system. We appreciate, however, that more needs to be done.</P>
                    <P>
                        In the ONC 21st Century Cures Act final rule (published elsewhere in this 
                        <E T="04">Federal Register</E>
                        ), ONC notes that it is not information blocking to inform a patient about the advantages and disadvantages and any associated risks with sharing their health information with a third party. In this rule, we are finalizing that impacted payers must share educational resources with patients to help them be informed stewards of their health information and understand the possible risk of sharing their data with third-party apps. As discussed above, commenters believe it is a risk when patients do not understand what happens after their data leaves the protection of HIPAA and are transmitted to a third-party app. Commenters were specifically concerned about secondary uses of data. A clear, plain language privacy policy is the primary way a patient can be informed about how their information will be protected and how it will be used once shared with a third-party app.
                    </P>
                    <P>
                        Taking into consideration comments indicating strong public support for additional privacy and security measures, we are further building off of the privacy and security policies we are finalizing in this rule by asserting that MA organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and QHP issuers on the FFEs are encouraged, but are not required, to request third-party apps attest to having certain privacy and security provisions included in their privacy policy prior to providing the app access to the payer's API. If a payer chooses, they can ask that the apps requesting access to their API with the approval and at the direction of the patient to attest that important provisions that can help keep a patient's data private and secure are in place. Explaining certain practices around privacy and security in a patient-friendly, easy-to-read privacy policy helps inform patients about an app's practices for handling their data. It helps patients understand if and how the app will protect their health information and how they can be an active participant in the protection of their information. Also, as explained earlier in this final rule, if an app has a written privacy policy and does not follow the policies as written, the FTC has authority to intervene. As a result, 
                        <PRTPAGE P="25550"/>
                        we assert that impacted payers can, but are not required to, ask a third-party app to attest that:
                    </P>
                    <P>
                        • The app has a publicly available privacy policy, written in plain language,
                        <SU>39</SU>
                        <FTREF/>
                         that has been affirmatively shared with the patient prior to the patient authorizing app access to their health information. To “affirmatively share” means that the patient had to take an action to indicate they saw the privacy policy, such as click or check a box or boxes.
                    </P>
                    <FTNT>
                        <P>
                            <SU>39</SU>
                             Plain Language Action and Information Network. (2011, May). Federal Plain Language Guidelines. Retrieved from 
                            <E T="03">https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf.</E>
                        </P>
                    </FTNT>
                    <P>• The app's privacy policy includes, at a minimum, the following important information:</P>
                    <P>++ How a patient's health information may be accessed, exchanged, or used by any person or other entity, including whether the patient's health information may be shared or sold at any time (including in the future);</P>
                    <P>++ A requirement for express consent from a patient before the patient's health information is accessed, exchanged, or used, including receiving express consent before a patient's health information is shared or sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction);</P>
                    <P>++ If an app will access any other information from a patient's device; or</P>
                    <P>++ How a patient can discontinue app access to their data and what the app's policy and process is for disposing of a patient's data once the patient has withdrawn consent.</P>
                    <P>
                        Payers can look to industry best practices, including the CARIN Alliance's Code of Conduct 
                        <SU>40</SU>
                        <FTREF/>
                         and the ONC Model Privacy Notice
                        <SU>41</SU>
                        <FTREF/>
                         for other provisions to include in their attestation request that best meet the needs of their patient population. If a payer chooses to request third-party apps provide this attestation, the payer must not discriminate in its implementation, including for the purposes of competitive advantage. Specifically, if a payer requests this attestation of one app, it must request it of all apps that seek to obtain data. If the third-party app does not attest that their privacy policy meets the provisions indicated by the payer, the payer may inform patients that the app did not attest and advise them to reconsider using this third-party app. The notification to the patient should make it clear that the app has not attested to having the basic privacy and security protections and indicate what those are, and that the patient should exercise caution before opting to disclose their information to the app. If the patient still requests the payer make their data available to the third-party app, the payer must provide API access to the app unless doing so would endanger the security of PHI on the payer's systems. This process should not overly delay the patient's access. If the app does not attest positively or at all, the payer must work to quickly inform the patient and provide a short window for the patient to cancel their request the data be shared. If the patient does not actively respond, the payer must move forward as the patient has already directed their data be shared and this initial request must be honored.
                    </P>
                    <FTNT>
                        <P>
                            <SU>40</SU>
                             See 
                            <E T="03">https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>41</SU>
                             See 
                            <E T="03">https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.</E>
                        </P>
                    </FTNT>
                    <P>We believe it is important for patients to have a clear understanding of how their health information may be used by a third-party, as well as how to stop sharing their health information with a third-party, if they so choose. We believe the use of this attestation, in combination with patient education, will help patients be as informed as possible while providing payers with a lower burden vetting option. We believe this will better help protect patient privacy and security and mitigate many of the concerns raised. Together, this framework and the requirement for payers to provide patients with educational resources will help continue to move us toward a safer data exchange environment. This is a critical focus for CMS, and we look forward to continuing to work with stakeholders to keep patient privacy and data security a top priority.</P>
                    <HD SOURCE="HD3">h. Enrollee and Beneficiary Resources Regarding Privacy and Security</HD>
                    <P>As discussed in section II.A. of the CMS Interoperability and Patient Access proposed rule (84 FR 7618 through 7623), we are committed to maximizing enrollees' access to and control over their health information. We noted that we believed this calls for providing enrollees that would access data under the proposal with essential information about the privacy and security of their information, and what to do if they believe they have been misled or deceived about an application's terms of use or privacy policy.</P>
                    <P>At 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g), we proposed to require MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, to make available to their current and former enrollees certain information about: factors to consider in selecting a health information management application, practical strategies to help them safeguard the privacy and security of their data, and how to submit complaints to OCR or FTC. The proposed obligations would apply to Medicaid managed care plans and CHIP managed care entities through cross-references proposed in 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this final rule; see section VI. of this final rule) and § 457.1233(d)(2).</P>
                    <P>The general information about the steps individuals can take to help protect the privacy and security of their health information should not be limited to, but should specifically include and emphasize the importance of understanding the privacy and security practices of any application to which they entrust their data. Information about submitting complaints should include both specific contact information for the OCR and FTC complaints processes and a brief overview, in simple and easy-to-understand language, of: What organizations are HIPAA covered entities, OCR's responsibility to oversee compliance with HIPAA, and FTC's complementary responsibility to take action against unfair or deceptive practices, including by non-covered entities that may offer direct-to-consumer health information management applications.</P>
                    <P>We proposed that this information must be made available on the website of the payers subject to the proposed requirement, and through other appropriate mechanisms through which the payer ordinarily communicates with enrollees that are seeking to access their health information held by the payer. This could include customer portals, online customer service help desks, and other locations, such as any portals through which enrollees and former enrollees might request disclosure of their data to a third-party application through the payer's API. We also proposed that the payer must make this information available in non-technical, simple, and easy to understand language.</P>
                    <P>
                        We explained in the proposed rule how we anticipate that payers could meet the requirement to provide information to current and former enrollees in whole or in part using materials designed for consumer audiences that are available on the HHS website. However, we noted that whether the organization chooses to draft its own resource materials to provide the required information or to 
                        <PRTPAGE P="25551"/>
                        rely on governmental or other sources for such materials, the organization will be responsible for ensuring that the content of the materials is adequate to inform the patient regarding the privacy and security risks, and that it remains current as relevant law and policy may evolve over time. We sought comment on the proposal, and we invited additional comments on what specific information resources in addition to those already available on the websites noted above would be most useful to entities in meeting this requirement. We anticipated using this feedback to help inform HHS planning and prioritization of informational resource development work in addition to making a decision on the final rule regarding the proposal.
                    </P>
                    <P>We summarize the public comments we received on enrollee resources and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters supported the enrollee resources proposal that would require payers to make information available to consumers about selecting an app, safeguarding data, and submitting complaints. Several commenters supported the recommendation that the resources be available in consumer-friendly language and be presented in a way that is easy for consumers to understand. One commenter requested more information about whether payers may make the educational information available through electronic disclosures, such as emailing the information to enrollees, in addition to making the information available online.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support. We do note that payers may share the information through other appropriate mechanisms usually used to communicate with patients, such as secure email, as well as include the information on a payer website.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters recommended that CMS provide patient education resources to help patients understand the information available to them through the payers' APIs. These commenters expressed concerns that patients may not fully understand the context of the data, such as detailed claims information that may not be intuitive to understand. Several commenters expressed concern with consumers' lack of knowledge about the privacy and security of their health information as it relates to third-party applications. Several commenters expressed concern that consumers may not understand that their health information is not protected by HIPAA once the information is sent to a non-covered third-party app or how an app may use their health information.
                    </P>
                    <P>Many commenters recommended that CMS develop and/or support education for consumers. Several commenters stated that CMS should have the responsibility to develop educational materials, rather than the payers or providers. Many commenters recommended that CMS collaborate with other regulatory agencies, including OCR and the FTC, to provide consumer education and notification materials. Several commenters recommended that CMS and other HHS agencies develop a campaign to educate patients about the privacy and security of health information, including the risks and challenges when connecting to third-party apps as well as differences between HIPAA and non-HIPAA covered entities and how the differences may affect how their data are used, stored, and shared.</P>
                    <P>Specifically, a few commenters recommended that CMS and FTC should require that third-party app developers inform consumers that HIPAA privacy rules will not apply when they agree to share their data with apps and describe how they will use the consumer's data. One commenter recommended that educational materials include information on the differences between HIPAA and FTC protections. One commenter recommended that CMS, OCR, or FTC publish the resources on their website and maintain a complaint portal. A few commenters stated that it is the responsibility of all stakeholders to inform consumers of their rights and use of PHI. One commenter recommended that the responsibility of providing educational materials to the consumer should fall on an organization where the patient may have a longer-term, non-transactional relationship, such as an HIE.</P>
                    <P>Several commenters expressed concern that educational resources will not be enough to promote privacy and security. Several commenters recommended that CMS and ONC should require third-party apps to provide notifications on how they may use, share, or sell their health information. One commenter expressed concern that there will not be enough oversight over third-party apps. The commenter recommended that CMS use HIPAA as a framework for developing a privacy structure for third-party apps.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We agree it is important to help ensure patients fully understand their health information, their rights, and the implications of sharing their information. It is also important patients know what to do if there is a breach of their health information. We appreciate that it would eliminate some burden from payers and providers if we assist with the production of the educational materials needed for the purposes of the requirements in this final rule. As a result, CMS is providing suggested content for educational materials that payers can use to tailor to their patient population and share with patients. We are finalizing the requirement with modification that payers must publish on their websites the necessary educational information, but we will help supply the content needed to meet this requirement. The suggested content we are providing for the educational materials will be shared through our normal communication channels including via listservs and is available via our website: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                         The modification we are making is to refine the language in the regulation text to expressly state that payers must include a discussion about a third-party app's secondary uses of data when providing factors to consider in selecting an application at 42 CFR 422.119(g)(1), 431.60(f)(1), and 457.730(f)(1), and 45 CFR 156.221(g)(1). In addition, at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g), we are modifying the regulation text to state the payer must make these materials available in an easily accessible location on its public website.
                    </P>
                    <P>We note, however, that our authority is limited to helping payers educate patients about their privacy and security rights and where they can go for additional information. We have shared commenter feedback with our federal partners and will continue to work with all stakeholders to ensure patients, providers, and payers have the information they need to address privacy and security issues relevant to the regulations finalized in this rule. We will also continue coordinating with ONC and all of our federal partners through the Federal Health IT Coordinating Council and other federal partnering opportunities to ensure we are tracking the impact of this final rule together, as appropriate. Privacy and security, however, is a much larger issue, and we remind commenters that CMS does not have authority to regulate third-party apps or their developers or develop privacy frameworks that exceed the scope of our authority or this final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters provided additional recommendations related to patient resources. One commenter recommended requiring 
                        <PRTPAGE P="25552"/>
                        payers to include information on how the consumer can contact the payer directly to report a privacy or security breach. One commenter recommended that CMS develop an easy-to-understand questionnaire for third-party applications to fill out that included information about how the app plans to use the data. This questionnaire could be available to patients. One commenter recommended that educational information about tools be available to family members and clinicians and not just the patient. One commenter suggested including educational content for specific conditions or patient populations, such as for pediatric care.
                    </P>
                    <P>Several commenters recommended that CMS include a requirement that the educational materials developed for consumers should also include materials for consumers who may be limited English proficient or have low health literacy. A few commenters recommended that educational materials should be developed with special considerations for vulnerable populations. One commenter recommended that consistent information be available across multiple settings to accommodate varying levels of technology literacy.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations. As indicated above, we will be providing suggested content for educational materials to assist payers in meeting their educational obligations under this final rule as detailed at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g). We note that this would also be available to caregivers and family members as we are requiring this material to be posted on the payer's website. Payers can tailor these materials to best meet the needs of their patient populations, including literacy levels, languages spoken, conditions, etc. Regarding recommendations to have patients contact the payer directly in the event of a breach, that is the patient's prerogative; a payer is required by the HIPAA Privacy Rule to have procedures for individuals to submit complaints, and to provide directions for doing so in its Notice of Privacy Practices. Individuals may also submit complaints to the OCR and FTC, in the appropriate situations, to address these concerns. Finally, we reiterate that we do not have the authority to regulate apps, so we cannot ask apps to fill out a questionnaire or facilitate sharing that information with patients. We do note that we are making available a document containing best practices for app developers to follow, with a special emphasis on ways to protect the privacy and security of patient data: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                    </P>
                    <HD SOURCE="HD3">i. Exceptions or Provisions Specific to Certain Programs or Sub-Programs</HD>
                    <P>We proposed certain exceptions or specific additional provisions as part of the CMS Interoperability and Patient Access proposed rule (84 FR 7637) for certain QHP issuers on the FFEs. We also proposed specifics about how MA organizations subject to the regulations finalized here would have to include certain information about the Part D benefit if the MA organization also offered Part D benefits; those aspects of the proposals are addressed in section III.C.2.c(1) of this final rule.</P>
                    <P>
                        Related to QHP issuers, we specifically proposed two exceptions. First, we proposed that the requirements proposed in 45 CFR 156.221(a) not apply to issuers offering only SADPs on the FFEs. In contrast to QHP issuers of medical plans, issuers offering only SADPs offer enrollees access to a unique and specialized form of medical care. We believed the proposed standards and health IT investment would be overly burdensome for SADP issuers as related to their current enrollment and premium intake and could result in SADP issuers no longer participating in FFEs, which would not be in the best interest of enrollees. Additionally, we believed much of the benefit to enrollees from requiring issuers of QHPs to make patient data more easily available through a standard format depends upon deployment of standards-based API technology that conforms to standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589) and a corresponding energetic response by the developer community in developing innovative, useful, usable, and affordable consumer-facing applications through which plan enrollees can conveniently access, use, and share their information as they choose. Based on the proposals to require implementation of standards-based API technology in the Medicare, Medicaid and CHIP programs, as well as by QHP issuers on the FFEs, we would anticipate significantly expanding the implementation of standards-based APIs by medical plans. However, we noted that we did not anticipate similar widespread usage with respect to SADPs. Therefore, we believed that the utility of access to issuers' data is less applicable to dental coverage, and did not believe it would be in the interest of qualified individuals and qualified employers in the states in which an FFE operates to 
                        <E T="03">not</E>
                         certify SADPs because they do not provide patient access to their data through a standards-based API. We sought comment on whether we should apply this policy to SADP issuers in the future.
                    </P>
                    <P>We also proposed to provide an exceptions process through which the FFEs may certify health plans that do not provide patient access through a standards-based API, but otherwise meet the requirements for QHP certification. We proposed in 45 CFR 156.221(h)(1) that if a plan applying for QHP certification that is to be offered through an FFE does not provide patient access to their data through a standards-based API, the issuer must include as part of its QHP application a narrative justification outlining the reasons why the plan cannot reasonably satisfy the requirements in proposed 45 CFR 156.221(a), (b), or (c), the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and proposed solutions and timeline to achieve API compliance. In 45 CFR 156.221(h)(2), we proposed that the FFE may grant an exception to the requirement to provide enrollees access to data through standards-based API technology, if the FFE determines that making available such health plan is in the interest of qualified individuals and qualified employers in a particular FFE state. We anticipated that this exception would be provided in limited situations. For example, we would consider providing an exception for small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the FFEs who demonstrate that deploying standards-based API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to consumers, and not certifying the issuer's QHP or QHPs would result in consumers having few or no plan options in certain areas. We sought comment on other circumstances in which the FFE should consider providing an exception.</P>
                    <P>We summarize the public comments we received on QHP exemptions and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters supported CMS' proposal to exempt SADPs from the requirements to provide a patient API. These commenters agreed with the justification offered that dental information may not be as useful to patients, as well as the resource burden concern for SADPs. A few commenters did not support the proposal to exempt SADPs from the patient API proposed requirements, suggesting it may help dentists and their patients make more 
                        <PRTPAGE P="25553"/>
                        informed decisions and that dental information may help other health care providers for patient treatment.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters support, as well as the concerns raised. We believe the financial impact on SADP issuers may result in fewer SADPs available in the FFEs. We may consider the application of this policy to SADP issuers in future rulemaking. We are finalizing this policy as proposed and exempting SADPs from the Patient Access API at this time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed support for the proposal to allow CMS to review a QHP issuer's justification for an exception to the Patient Access API proposal. One commenter recommended CMS require QHPs that are granted an exception to notify potential enrollees that they will not be compliant with the requirement to provide enrollees access to data through standards-based API technology. A few commenters did not support or expressed concern with CMS' proposal to grant QHPs an exception process, fearing an impact to patient care and uneven patient access to health data. One commenter did not want plans and entities to function solely as data consumers or aggregators. One commenter suggested that exceptions should be rare, limited, and for a defined duration.
                    </P>
                    <P>A few commenters recommended CMS establish or work with plans to make clear the evaluation criteria for reviewing exception requests to ensure parity. One commenter recommended CMS define a standard for expected alternative API implementation timeline. This commenter also recommended CMS establish a timeline for evaluating exception requests. One commenter requested CMS specify how justifications will be submitted as well as guidance in its annual Letter to Issuers in the FFEs to assist providers in understanding the requirements of the exception application process.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. Regarding concerns that this exception would impact care and access to health data, we believe it is more important to ensure patients have access to QHPs, and if an exception can provide consumers continued coverage, the exception is the preferable approach. We are evaluating the additional recommendations provided for future consideration. Further, in order to better clarify the applicability of the API-related requirements, we are revising 45 CFR 156.221(h) to expand the exceptions process to encompass all requirements in paragraphs (a) through (g), rather than (a) through (c) in the proposed rule. This will ensure that QHP issuers on the FFEs that are not able to meet any of the standards will be subject to the exceptions process. Again, we believe that ensuring patients have access to QHPs is paramount. We also note that additional guidance will be provided to QHP issuers in the future in order to specify how issuers will demonstrate compliance with these standards.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters recommended that CMS expand the proposal to provide exemptions to the Patient Access API proposal to other types of plans for similar reasons including implementation burden and potential unintended consequences, such as driving plans out of the market. The types of payers that the commenters recommended be provided exemptions include MA, Medicaid (including MCOs, Medicare-Medicaid Plans, Fully Integrated Dual-Eligible Special Needs Plan, Long-Term Services and Supports), CHIP, public health agencies, smaller QHPs and small plans, and new and current QHP issuers. A few commenters recommended CMS include “local plans” in the definition of “small issuer.” One commenter recommended that tribes also be exempt from this policy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' recommendations, and we appreciate the concerns that certain payers may have unique circumstances making new requirements potentially more challenging. We note that these policies only apply to Medicare Advantage organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We are only finalizing one exemption, the exception noted below, not identified in the proposed rule, however. We do not believe the burden or potential unintended consequences outweigh the immense benefit to patients and the potential for improved health outcomes these policies can facilitate.
                    </P>
                    <P>As noted earlier in this final rule, we are modifying the scope of the applicability of the regulations to QHP issuers on an individual market FFE. In considering the application to issuers offering plans through the FF-SHOPs, we believe that, like the exception for issuers of SADPs discussed above, the financial burden to implement these policies may result in fewer issuers offering plans through the FF-SHOPs and could result in small employers and consumers having fewer or no FF-SHOP plan options. Further, we believe that most FF-SHOP issuers likely would qualify for exclusion via the exceptions process we are finalizing. We have modified 45 CFR 156.221(h)(2) to remove the reference to “qualified employers” and paragraph (i) to include applicability to individual market FFEs.</P>
                    <HD SOURCE="HD3">j. Applicability and Timing</HD>
                    <P>At 42 CFR 422.119(h) and 45 CFR 156.221(i), we proposed specific provisions regarding applicability and timing for MA organizations and QHP issuers on the FFEs that would be subject to the proposal. We did not propose specific regulation text for 42 CFR 431.60 or 438.242 because we intended to make the regulation text effective on the applicable date, as discussed below. We noted that we expected that state Medicaid and CHIP agencies would be aware of upcoming new regulations and planning for compliance with them when they are applicable, even if the new regulation is not yet codified in the CFR; we similarly expected that such agencies will ensure that their managed care plans/entities will be prepared for compliance. Unlike Medicaid state agencies and managed care plans and state CHIP agencies and managed care entities, MA organizations and QHP issuers on the FFEs generally are subject to rules regarding bid and application submissions to CMS in advance of the coverage period; for example, MA organizations must submit bids to CMS by the first Monday in June of the year before coverage starts in order to be awarded an MA contract. In an abundance of caution and to ensure that these requirements for MA organizations and QHP issuers on the FFEs are enforceable and reflected in the bids and applications these entities submit to us in advance of when the actual requirements must be met, we proposed to codify the actual compliance and applicability dates of these requirements. We solicited comment on this approach.</P>
                    <P>For MA organizations, under 42 CFR 422.119(h), we proposed that the requirements would be applicable beginning January 1, 2020. Under the proposal, the requirements at 42 CFR 422.119 would be applicable for all MA organizations with contracts to offer any MA plan on that date and thereafter. We requested feedback about the proposed timing from the industry. In particular, we solicited information and requested comment from MA organizations about their current capability to implement an API consistent with the proposal and the costs associated with compliance by January 1, 2020, versus compliance by a future date.</P>
                    <P>
                        For Medicaid FFS at 42 CFR 431.60, CHIP agencies that operate FFS systems at 42 CFR 457.730, Medicaid managed 
                        <PRTPAGE P="25554"/>
                        care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.), and CHIP managed care entities at 42 CFR 457.1233(d)(2), we proposed that the API requirements would be applicable beginning July 1, 2020, regardless of when the managed care contract started. We noted that given the expected date of publication of the final rule, we believed July 1, 2020, would provide state Medicaid agencies and CHIP agencies that operate FFS systems, Medicaid managed care plans, and CHIP managed care entities sufficient time to implement. We solicited comment on the proposal and whether additional flexibility would be necessary to take into account the contract terms that states use for their Medicaid managed care plans.
                    </P>
                    <P>For CHIP, we noted that we are aware that some states do not provide any benefits on a FFS basis, and we did not intend for those states to implement an API outside their managed care plans. Therefore, we proposed in 42 CFR 457.700(c) that separate CHIP agencies that provide benefits exclusively through managed care entities may meet the requirements of 42 CFR 457.730 by requiring the managed care entities to meet the requirements of 42 CFR 457.1233(d)(2) beginning July 1, 2020.</P>
                    <P>For QHP issuers on the FFEs, we proposed in 45 CFR 156.221(i) that these requirements would be applicable for plan years beginning on or after January 1, 2020. We sought comment on the timing of these requirements, and on how long issuers, particularly smaller issuers, anticipate it would take to come into compliance with these requirements.</P>
                    <P>We explained in the CMS Interoperability and Patient Access proposed rule our belief that these proposals would help to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, and helping them live better, healthier lives. Additionally, under these proposals, physicians would be able to access information on their patient's current prescriptions and services by reviewing the information with the patient on the patient's personal device or by the patient sharing data with the provider's EHR system, which would save time during appointments and ultimately improve the quality of care delivered to beneficiaries. Most health care professionals and consumers have widespread access to the internet, providing many access points for viewing health care data over secure connections. These proposed requirements would significantly improve beneficiaries' experiences by providing a secure mechanism through which they can access their data in a standardized, computable format.</P>
                    <P>We noted that these proposals were designed to empower patients by making sure that they have access to health information about themselves in a usable digital format and can make decisions about how, with whom, and for what uses they will share it. By making claims data readily available and portable to the enrollee, these initiatives supported efforts to move our health care system away from a FFS payment system that pays for volume and toward a payment system that pays for value and quality by reducing duplication of services, adding efficiency to patient visits to providers; and, facilitating identification of fraud, waste, and abuse. Data interoperability is critical to the success of new payment models and approaches that incentivize high quality, efficient care. All of the health care providers for a patient need to coordinate their care for a value-based system to work, and that requires information to be securely shareable in standardized, computable formats. Moreover, we noted that patients needed to understand and be actively involved in their care under a value-based framework. We committed to supporting requirements that focus on these goals, and we noted we believe that the specific proposals supported these efforts.</P>
                    <P>We summarize the public comments we received on applicability and timing of the Patient Access API and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters supported the proposed timeline for implementing APIs. One commenter believes that payers have sufficient time to prepare APIs and recommended that CMS maintain the proposed timeline. One commenter suggested that to address payer concerns CMS could reward plans, such as through higher HEDIS scores, who are able to meet the January 1, 2020 date.
                    </P>
                    <P>Many commenters expressed concern with the proposed implementation timelines. Many commenters believed that payers and developers will need more time to implement the requirements and encouraged CMS to delay the implementation date. A few commenters were concerned that without sufficient time and resources to implement security protocols, payers will be unable to meet the proposed requirements. Many commenters believed that additional time will allow health IT vendors and payers to develop, test, and implement the necessary systems. Several commenters expressed concern with the costs needed to implement the proposals under the proposed timelines.</P>
                    <P>Several commenters recommended an implementation deadline no earlier than 2021, while several other commenters recommended a proposed implementation date of January 1, 2022. One commenter each suggested January 1, 2023 and January 1, 2024, while another recommended 12 months after the publication of the rule. Many commenters recommended a timeline of at least 18 to 24 months after publication of the final rule. Several commenters recommended aligning the CMS timelines with the ONC timelines, therefore recommending CMS implement policies in this final rule 2 years after the publication of this final rule. A few commenters recommended a 36-month timeline for all proposed policy implementation dates included in this rulemaking.</P>
                    <P>A few commenters did not support proposing a timeline yet. The commenters noted that the standards and the infrastructure should be more mature before implementation dates are set. One commenter suggested that CMS and ONC convene a planning group to establish a more appropriate timeline.</P>
                    <P>Several commenters encouraged CMS take a phased approach, which some explained as creating a “glide path” from “proof of concept” to more advanced use cases and a more expansive set of data. Commenters had a few different recommendations for which data elements could be included in which phase of the implementation in such a scenario. A few commenters suggested an approach where smaller plans meet fewer requirements initially and phase-in to full adoption. One commenter requested that CMS exempt small issuers from the requirements of the rule.</P>
                    <P>A few commenters recommended delaying any disincentives and/or penalties until 2 years after implementation. One commenter expressed concern that the different implementation dates for different payers may create confusion, particularly for dual eligible beneficiaries.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and recommendations. We understand that payers need time to be able to develop, test, and implement the APIs being finalized in this rule. We appreciate that it will take time to map and prepare historic data for sharing via the standards-based FHIR API. We want to be sure that payers have the time and guidance needed to fully and accurately 
                        <PRTPAGE P="25555"/>
                        implement the policies being finalized in this rulemaking. We do not agree, however, that it is necessary to convene a planning group to develop a timeline for implementation. The public has had the opportunity to provide feedback on this issue as part of this rulemaking. As a result, we are finalizing the implementation date of the Patient Access API as January 1, 2021 for all payers impacted by this rulemaking, except for QHP issuers on the FFEs, for which the rule will be applicable beginning with plan years beginning on or after January 1, 2021. We strongly encourage payers to implement these policies as soon as they are capable, but the Patient Access API will not be required until January 1, 2021. For Medicaid managed care, we remind states that should they determine that obligations in this rule warrant a retroactive adjustment to capitation rates, those adjustments must be certified by an actuary in a revised rate certification and submitted to CMS as a contract amendment, pursuant to 42 CFR 438.7(c).
                    </P>
                    <P>We do appreciate the commenters' suggestion to evaluate a phased implementation approach. As a result, you will see in section IV. of this final rule how we are using the Provider Directory API proposal as a way for payers to show they are making progress toward API development and access.</P>
                    <HD SOURCE="HD3">k. Request for Information on Information Sharing Between Payers and Providers Through APIs</HD>
                    <P>We proposed the implementation of standards-based APIs for making accessible data that a third party could use to create applications for patients to access data in order to coordinate and better participate in their medical treatment. While in some instances, direct provider to health plan transmission of health information may be more appropriate than sharing data through a standards-based API, in other instances a patient may wish to send a provider a copy of their health information via another health care provider's API. In such cases, patients could direct the payer to transmit the health information to an application (for example, an application offered by a health care provider to obtain patient claims and encounter data, as well as lab test results (if applicable)) on a one-off and as-needed basis. To the extent a HIPAA covered entity offers patients access to their records via a standards-based application, another HIPAA covered entity may be able to obtain an individual's health information from the app for treatment, payment, or certain health care operations purposes, without need of an individual's authorization, consistent with the HIPAA Rules (see 45 CFR 164.506). Under other laws, providers may need to obtain specific individual consent to obtain health information related to care provided by a behavioral health provider, treatment received at a substance use disorder treatment facility, certain 42 CFR part 2-covered diagnoses or other claims-related information, or labs that suggest a part 2 diagnosis. We explained in the CMS Interoperability and Patient Access proposed rule how we did not intend to expand any scope of authority to access patient data nor to contravene existing requirements related to disclosure of PHI under the HIPAA Rules and other legal standards, but instead specified a new and additional mechanism by which to share health information as directed by the individual, through the use of API technology in compliance with all existing federal, state, local, and tribal privacy and security laws.</P>
                    <P>We explained how, in the future, we anticipate payers and providers may seek to coordinate care and share information in such a way as to request data on providers' or a payer's patient/insured overlapping population(s) in one transaction. We sought comment for possible consideration in future rulemaking on the feasibility of providers being able to request a download on a shared patient population using a standards-based API. We thank commenters for their insights and are reviewing the comments received for inclusion in potential future rulemaking.</P>
                    <P>In addition to the comments we received about the specific sections of this Patient Access API proposal, we also received a number of comments that were specific to the types of payers impacted by the proposal, generally. We summarize these public comments by payer type and provide our responses.</P>
                    <P>We received these public comments related to Medicare Advantage.</P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter suggested CMS require that MA organizations make patient data maintained in connection with the organizations' various individual and small group market plans available for access and exchange through the Patient Access API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's suggestion. However, in light of the limits on CMS's authority over MA organizations, commercial insurance, and group health plans, we are not adopting requirements to apply as broadly as the commenter suggested. We note that QHP issuers on the individual market FFEs are required under this final rule to implement the Patient Access API, and we encourage other individual markets, as well as small group market plans and group health plans to do so, as well.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter recommended CMS specify the expectations of MA organizations regarding supplemental benefits in relation to the Patient Access API. One commenter recommended CMS evaluate whether the standards proposed for this API are appropriate for the dental care space.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's request for additional information. We note that MA claims data, encounter data, and clinical data related to supplemental benefits, including dental services, are subject to the API requirement, even if issuers only offering SADPs on FFEs are not subject to the requirement.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested additional information on whether Medicare Advantage D-SNPs would be required to provide patients an API.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's request for additional information. We note D-SNPs are MA plans offered by MA organizations and therefore subject to the API requirement adopted at 42 CFR 422.119.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested additional information of whether data shared via an API would be subject to member communication rules, such as Medicare Communications and Marketing Guidelines.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's request for additional information. Whether or not data shared via the Patient Access API being finalized at 42 CFR 422.119(b) falls under the purview of CMS's communication and marketing rules would be dependent on factors such as the relationship of the developer and the MA plan(s), the content accompanying the API data, and the intended outcome of the application using the API data. MA plans must continue to follow the provisions of 42 CFR part 422 (such as but not limited to 42 CFR 422.118(d), 422.2260 through 422.2268), including in circumstances when their communications and marketing materials include data that is retrieved through an API. For example, if a field marketing organization (FMO) uses API data to create a software application that compares the provider networks for the plans the FMO is contracted to sell, the application would fall under the MA marketing and communications regulations and CMS's oversight. Conversely, if a developer uses API data to create an independent application that provides an alternative 
                        <PRTPAGE P="25556"/>
                        means of scheduling provider appointments, the application would fall outside of CMS's purview.
                    </P>
                    <P>We received these public comments related to Medicaid and CHIP.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters requested additional information on which Medicaid programs would be required to implement and maintain a standards-based API. One commenter wanted additional information as to whether all state's Medicaid Management Information Systems (MMIS) would be required to develop APIs. This commenter stated that while it seemed clear that the rule does not require health plans to use Health IT modules to make administrative data available, the role of a payer's claims adjudication system (including MMIS) is unclear.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' request for information. In proposed 42 CFR 431.60 and 457.730, we specified that states would have to implement and maintain an API for FFS Medicaid programs and CHIP; we also proposed in 42 CFR 438.242(b)(6) (finalized as 42 CFR 438.242(b)(5) in this rule; see section VI.) and 457.1233(d) that states would have to require each MCO, PIHP, and PAHP to comply with 42 CFR 431.60 (under Medicaid managed care contracts) and 457.730 (under CHIP managed care contracts) as if such requirements applied directly to them. We are finalizing these policies as proposed. Sections 431.60 and 457.730 do not require a specific system to be used for the implementation and maintenance of the API, thus we defer to each state and Medicaid managed care plan to determine which of their systems would be the most appropriate.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested that CMS clarify if an arrangement in which a state provided beneficiaries access to their FFS data by delegating the API function to a managed care plan would be sufficient to satisfy the rule, or if each entity in the chain is required to implement their own systems, portals, and/or API interfaces. This commenter questioned if CMS envisioned the creation of a national network to exchange Medicare/Medicaid records that would satisfy these requirements in a centralized fashion.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's request for information. We are, however, somewhat unclear what the commenter meant by “delegating the API function to a managed care plan.” We believe the commenter may be questioning if a state could utilize a managed care plan to implement the API required for the state's FFS beneficiaries in lieu of the state implementing the API required in 42 CFR 431.60. If so, the proposed rule did not anticipate nor prohibit that type of an arrangement. As such, this final rule could permit such an arrangement, but we remind a state contemplating using such an arrangement that it must meet the all of the requirements in this final rule, including the timelines and scope specified for data accessibility in § 431.60(b). There is no plan for a national network to exchange Medicare/Medicaid records in lieu of the APIs being finalized in this rule at this time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter suggested that CMS establish a stakeholder workgroup to identify best practices in data-sharing with Medicaid beneficiaries.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate this suggestion and encourage states and Medicaid managed care plans to work with their stakeholders to identify best practices for data-sharing with Medicaid beneficiaries in their states.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter expressed concern that reimbursing states for modification of their IT systems at an enhanced match rate while reimbursing managed care plans for their system modifications at the state's standard match rate creates an uneven playing field for Medicaid managed care plans and a disparity of funding. This commenter noted that in states that make extensive use of managed care, the bulk of system modifications needed to carry out and maintain the proposed interoperability capabilities for Medicaid enrollees will be borne by Medicaid managed care plans and requested that CMS revise its proposal to reflect that all costs attributable to design, development, installation, enhancement, or ongoing operation of both state and Medicaid managed care plan systems will receive the appropriate enhanced federal match. Finally, this commenter requested that CMS take a more rigorous approach and update its methodology for review of state MCO capitation rates to ensure that proposed rates include reasonable allowances for costs of IT systems work performed by the state's Medicaid managed care plans in furtherance of the proposals in this regulation.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's concern. However, we do not agree that the difference in the federal match rate creates an uneven playing field. Capitation rates must be actuarially sound independent of the federal matching rate that applies to the payment of those rates. The provision of enhanced federal match rate is addressed in section 1903(a)(3)(A) of the Act and provides a 90 percent match rate for “. . . the sums expended during such quarter as are attributable to the design, development, or installation of such mechanized claims processing and information retrieval systems as the Secretary determines are likely to provide more efficient, economical, and effective administration of the plan . . .” It does not specifically provide an enhanced match rate for the portion of a capitation rate that may be included for information technology expenditures, and we do not have the authority to extend the enhanced match rate beyond the conditions specified in statute. We already have a very rigorous capitation rate review process and will review any changes noted by the states in those rates, including any specifically noted for IT system enhancements specific to the requirements finalized in this rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested that the new requirement to implement and maintain an API must be uniform across the system and non-negotiable to Medicaid managed care plans, state government, and providers. One commenter noted that CMS should address situations where states may choose to adopt additional or conflicting data sharing requirements in Medicaid or CHIP managed care contracts. This commenter further stated that it is critical that covered health plans be subject to uniform standards for data accessed through an API and that CMS should work with state Medicaid and CHIP programs to ensure that any state mandated requirements for data accessed through an API are harmonized with the new federal standards. This commenter suggested that submission of the encounters in a timely manner by all involved with the new rule must be a non-negotiable condition for the receipt of Medicare or Medicaid reimbursement. In addition, the commenter noted that enforcement cannot be left to plans based on variable contract terms but must be provided by federal agencies.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with the commenter that implementation of standards-based APIs should be consistent across states and Medicaid and CHIP managed care plans and have codified the requirements for APIs in 42 CFR 431.60(b), 457.730(b), 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), and 457.1233(d) to ensure an appropriate level of uniformity and consistency while still providing states with an adequate level of flexibility to go beyond the minimum standards included in this final rule when they believe doing so benefits their beneficiaries. While we do not have a specific provisions that 
                        <PRTPAGE P="25557"/>
                        conditions payment on the timely receipt of encounters, states and managed care plans may find that a useful provision to include in their contracts. States must have a monitoring system in effect for their Medicaid managed care programs under § 438.66(b)(6), which also specifies “information systems, including encounter data reporting” as a required element. Similarly, we have certain program oversight responsibilities, such as the review of certain Medicaid and CHIP managed care contracts and all capitation rates, and will incorporate oversight of requirements in this final rule to the extent appropriate.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter noted that CMS encourages the Medicaid and CHIP FFS programs to use the API as a means to exchange PHI with providers for treatment purposes, suggesting the data would be shared in advance of a patient's visit. But CMS also states that this proposal can empower the patient to decide how their health information is going to be used. This commenter requested additional information of the role CMS intends for the patient and the provider to have in the use of APIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we believe that a beneficiary's use of an API to obtain their health care data will play an important role in their health care, as proposed and finalized, this rule does not set standards for health care provider use of apps to obtain information from payers. As proposed and finalized in 42 CFR 431.60(a) and 457.730(a), the API permits third-party applications to retrieve a patient's data at the patient's request. A beneficiary may make the decision to obtain their health care data through such an app and share it with a provider in advance of a visit or otherwise.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested clarity on whether the proposed rule requires all states' MMIS [Medicaid Management Information System] to make information available to patients within one (1) business day of receipt or adjudication of administrative data (adjudicated claims, encounters, provider remittance, etc.). This commenter expressed concern that these data could appear to conflict with data obtained by a patient directly from a managed care plan, causing confusion and increasing administrative overhead.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's request for additional information. Medicaid beneficiaries should not be receiving the information from both the state and managed care plan for the same service. If the beneficiary is receiving a service under the state's Medicaid FFS program, the requirements in § 431.60 apply; that is, the state is responsible for providing the specified data elements in § 431.60(b) through the API. If the beneficiary is enrolled in a managed care plan (receiving the service under the managed care plan's contract), the requirements in § 438.242(b)(5) (proposed as § 438.242(b)(6); see section VI.) apply; that is, the managed care plan is responsible for providing the specified data elements in § 431.60(b) through the API. The beneficiary should not receive data that is in conflict with other data that is made available through the API. The same is true for CHIP. If the beneficiary is in CHIP FFS, the requirements in § 457.730 apply; that is, the state is responsible for providing the specified data elements in § 457.730(b) through an API. If the beneficiary is enrolled in a managed care plan, the requirements in § 457.1233(d) apply; that is, the managed care plan is responsible for providing the specified data elements in § 457.730(b) through the API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter expressed concerns regarding the ongoing burden for state Medicaid and CHIP agencies to monitor the API, privacy and security features, and potential security risks posed by the numerous applications that may connect to the API. This commenter recommended that states be required to monitor the compliance of each of their managed care plans regarding the API requirements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand the commenter's concerns about burden related to the API, as well as the need for states to monitor the API for privacy and security. These requirements are specified at 42 CFR 431.60(c)(1) and (2) and 457.730(c)(1) and (2). While we understand that there is some burden for states and managed care plans related to the development and implementation of the API, we continue to believe that the benefits and potential for improved health outcomes outweigh the burden associated with these requirements. We also confirm for commenters that states are required to monitor compliance for their contracted managed care plans in regard to the API requirements under 42 CFR 438.242(b)(5) (proposed as 42 CFR 438.242(b)(6); see section VI.) and 457.1233(d). Since these requirements apply to managed care plans, states are required to include the requirements under their managed care contracts and must ensure that plans comply with the standards specified in 42 CFR 431.60 and 457.730 as if those requirements applied directly to the managed care plan.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters stated that the Patient Access API proposal places a significant burden on Medicaid and CHIP beneficiaries to monitor the privacy and security of their own health information while it is being accessed by non-HIPAA covered entities. One commenter recommended that CMS consider how educational efforts could be uniquely tailored to specific populations, such as Medicaid beneficiaries, particularly given the need for special considerations when attempting to engage with vulnerable populations. This commenter recommended that CMS amend or revise the current language in its proposed rule to explicitly require that API vendors be responsible for the education of consumers. Another commenter noted that many Medicaid and CHIP beneficiaries are children and that app developers, states, and managed care plans will also need to develop resources for minor access and control over health information and educate members accordingly.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns, and we acknowledge that some Medicaid beneficiaries may find negotiating the privacy and security app landscape burdensome. Any patient, including one who is not comfortable with technology, may choose not to use this method of data exchange. However, we would like all beneficiaries to be able to benefit from these apps. One way we are looking to mitigate this burden is through education. We believe that it is important for beneficiaries to have the educational resources to be able to best evaluate their third-party options. States and managed care plans must comply with the requirements 42 CFR 431.60(f) and 457.730(f) that require states and managed care plans to develop and provide on a public website beneficiary resources regarding privacy and security, including information on how beneficiaries can protect the privacy and security of their health information in non-technical, simple and easy-to-understand language. We note in section III.C.2.h. of this final rule, that CMS will provide suggested content for educational material payers can use to meet this requirement. States, Medicaid managed care plans, and CHIP managed care entities have vast experience with techniques for creating effective communications for their beneficiaries and we encourage states and managed care plans to tailor these resources for their Medicaid and CHIP populations. We also agree that states and managed care plans will need to develop or refine resources to address patient access for minor populations and for populations based on health literacy levels. We do 
                        <PRTPAGE P="25558"/>
                        note that we do not have the authority to regulate vendors. While we agree that API vendors should have a role in educating consumers, states and managed care plans are the entities responsible for developing and implementing the API; therefore, we believe it is more appropriate for states and managed care plans to develop and provide the educational resources for beneficiaries.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters requested that CMS modify the rule to exempt Medicaid managed care plans. Commenters noted that Medicaid managed care plans are already operating with razor thin margins and the proposed rule will substantially increase the costs for Medicaid managed care plans. Further, commenters noted that due to the substantial increase in costs, plans may not be able to meet the MLR requirements in 42 CFR 438.8. Another commenter suggested that CMS explicitly exclude from the requirements of the rule long‐term services and supports (LTSS) plans. Some commenters also recommended that CMS exclude dental plans from the requirements in the proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns, however we are not exempting Medicaid or CHIP managed care plans, including LTSS or dental plans, from the requirements in this rule, as such an approach would not be consistent with our goal of ensuring that all beneficiaries across the health care market, including Medicaid FFS and managed care, have access to and can exchange specified health care data. We are finalizing the Patient Access API requirements for state Medicaid and CHIP agencies and managed care plans, including LTSS and dental plans. States and managed care plans must make adjudicated claims and encounter data available through the API for all Medicaid-covered services, including LTSS and dental. This requirement extends to all Medicaid-covered services for which a claim, or encounter claim, is generated and adjudicated. Regarding costs for managed care plans—since the Patient Access API requirements must be contractual obligations under the managed care contract—the state must include these costs in the development of a plan's capitation rates.
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing with modifications our proposal to require MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to implement and maintain a standards-based Patient Access API that meets the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215, content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and finalized by HHS at 45 CFR 170.213 (USCDI version 1), unless alternate standards are required by other applicable law; includes the data elements specified in this final rule, and permits third-party applications to retrieve, with the approval and at the direction of the enrollee, data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221. Specifically, we are finalizing that the Patient Access API must, at a minimum, make available adjudicated claims; encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where maintained by the impacted payer). Data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received by the impacted payer. We are not finalizing a requirement for the Patient Access API to make provider directory and pharmacy directory information available. Instead, to limit burden, we are only requiring provider and, in the case of MA-PD plans, pharmacy directory information be included in the Provider Directory API discussed in section IV. of this final rule.
                    </P>
                    <P>
                        We are finalizing the proposed documentation requirements noting business and technical documentation necessary to interact with the API must be made freely and publicly accessible. We note that the APIs need to comply with all existing federal and state privacy and security laws. We are finalizing, consistent with the HIPAA Rules that a payer may deny access to the Patient Access API if the payer reasonably determines that allowing a specific third-party application to connect or remain connected to the API would present an unacceptable level of risk to the security of PHI on the payer's systems based on objective and verifiable criteria. We are also finalizing that payers need to make available to enrollees resources explaining factors to consider in selecting an app for their health information, practical strategies to safeguard their privacy and security, and how to submit complaints to OCR or FTC. We do note that we are providing payers with suggested content they can use and tailor to meet this requirement, available here: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                         We also note that impacted payers are allowed to request that third-party apps attest to having certain information included in their privacy policy, and inform patients about this attestation, to help ensure patients are aware of the privacy risks associated with their choices.
                    </P>
                    <P>
                        We are finalizing this policy with the following technical corrections and additional information. At 42 CFR 422.119(a) and (b)(1); 42 CFR 431.60(a) and (b); 42 CFR 457.730(a) and (b); and, 45 CFR 156.221(a) and (b) we specify these policies apply to current patients and their personal representatives. At 42 CFR 422.119(b)(1)(i), (1)(ii), and (2)(i); 42 CFR 431.60(b)(1) and (2); 42 CFR 457.730(b)(1) and (2); and, 45 CFR 156.221(b)(1)(i) and (ii) we are removing the word “standardized” to avoid confusion as the standards are specified elsewhere. We are finalizing the regulation text at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), with the verb “maintains” in place of the verb “manages” in order to more closely align with the relevant HIPAA Privacy Rule requirement. We are finalizing a technical correction at 42 CFR 431.60(b)(2) and 42 CFR 457.730(b)(2) to replace “within one (1) business day” with “no later than 1 business day after” to be consistent across payers. We have added text to specifically indicate that the technical requirements at 42 CFR 422.119(c), 431.60(c), and 457.730(c), and 45 CFR 156.221(c) apply to the API under paragraph (a) of the respective sections. We are finalizing at 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2), to include additional text to explicitly require, as described in the CMS Interoperability and Patient Access proposed rule (84 FR 7635) the requirement to also update (as appropriate) the API to ensure it functions properly and includes assessments to verify an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee. In addition, we are removing the word “minimally” from this regulation text in order to ensure it is clear that privacy and security features must be reasonable and appropriate, consistent with the requirements of HIPAA Privacy and Security Rules, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable health information. We are making a technical 
                        <PRTPAGE P="25559"/>
                        change for readability only at 42 CFR 422.119(c)(3) and (4)(ii)(C), 431.60(c)(3) and (4)(ii)(C), 438.242(b)(5), 457.730(c)(3) and (4)(ii)(C), 457.1233(d)(1), and 45 CFR 156.221(c)(3) and (4)(ii)(C). In addition, we have refined the language at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g) to state the payer must make education materials available “in an easily accessible location on its public website,” and at 42 CFR 422.119(g)(1), 431.60(f)(1), and 457.730(f)(1), and 45 CFR 156.221(g)(1) to include a reference to “secondary uses of data.”
                    </P>
                    <P>At 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 CFR 156.221(d), we are finalizing additional text to specify that “publicly accessible” means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available.</P>
                    <P>In the CMS Interoperability and Patient Access proposed rule, the criteria and process for assessing unacceptable risk to a payers system was explained as part of the payer's responsibilities under the HIPAA Security Rule (84 FR 7635). At 42 CFR 422.119(e)(1), 431.60(e)(1), 438.242(b)(5), 457.730(e)(1), and 457.1233(d), as well as 45 CFR 156.221(e)(1) we are finalizing additional text to note that payers should determine risk consistent with its security risk analysis under 45 CFR part 164 subpart C to indicate the specific section of the HIPAA Security Rule implicated here. We are modifying 45 CFR 156.221(h)(2) to remove the reference to “qualified employers” and 45 CFR 156.221(i) to include applicability to “individual market” FFEs to exclude issuers offering plans through the FF-SHOPs. Finally, we are finalizing for MA organizations at 42 CFR 422.119(h), Medicaid FFS programs at 42 CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii), CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at 42 CFR 457.1233(d), that beginning January 1, 2021, and for QHP issuers on the FFEs at 45 CFR 156.221(i) beginning with plan years beginning on or after January 1, 2021, these payers must make available through the Patient Access API data they maintain with a date of service on or after January 1, 2016, consistent with the payer-to-payer data exchange requirement discussed in section V. of this final rule.</P>
                    <HD SOURCE="HD1">IV. API Access to Published Provider Directory Data Provisions, and Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Interoperability Background and Use Cases</HD>
                    <P>In section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639), we focused on patient access to their own data through a standardized, transparent API—the Patient Access API. As part of this proposal, we discussed and sought comment on requiring payers at 42 CFR 422.119(b)(1)(iii) and (b)(2)(ii) for MA organizations, 42 CFR 431.60(b)(3) for Medicaid FFS programs, 42 CFR 438.242(b)(6)(ii) for Medicaid managed care plans, 42 CFR 457.730(b)(3) for CHIP FFS programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed care entities to provide their provider directory information through that same Patient Access API. In addition, the proposed rule sought comment on making the provider directory information available through a public-facing standards-based API. As we discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7639), making provider directory information available through a public-facing API raised different issues than API access proposals related to patient data. Based on our consideration of public comments summarized and responded to below, and in an effort to avoid duplicative effort and additional burden resulting from having the provider directory information included in both the Patient Access API and the Provider Directory API, we are finalizing the requirement for a public-facing Provider Directory API at 42 CFR 422.120 for MA organizations, 42 CFR 431.70 for Medicaid FFS programs, 42 CFR 438.242(b)(6) for Medicaid managed care plans, 42 CFR 457.760 for CHIP FFS programs, and 42 CFR 457.1233(d)(3) for CHIP managed care entities, but we will not finalize our proposal to also provide access to this provider directory information through the Patient Access API at 422.119, 42 CFR 431.60, 42 CFR 438.242(b)(6), 42 CFR 457.730, and 42 CFR 457.1233(d)(2), respectively.</P>
                    <P>Provider directories make key information about health care professionals and organizations available to help consumers identify a provider when they enroll in an insurance plan or as new health needs arise. For example, such information might include hours of operation, languages spoken, specialty/services, and availability for new patients. Provider directories also function as a resource used by the provider community to discover contact information of other providers to facilitate referrals, transitions of care, and care coordination for enrollees.</P>
                    <P>As discussed in the CMS Interoperability and Patient Access proposed rule, the current applicable regulations for MA plans (42 CFR 422.111) and Medicaid and CHIP managed care plans (42 CFR 438.10(e)(2)(vi) and (h) and 457.1207, respectively) already require that provider directories be made available to enrollees and potential enrollees in hard copy and on the plan's website. Section 1902(a)(83) of the Act requires state Medicaid agencies to publish a directory of certain physicians on the public website of the State agency. A regulation for QHP issuers (45 CFR 156.230(b)) requires public access to the QHP's provider directory in addition to distribution and access for enrollees. In addition to mandating that this information be accessible, the current regulations also address the content of such directories and the format and manner in which MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs must make the information available.</P>
                    <P>
                        Making this required provider directory information available to enrollees and prospective enrollees through an API could support development of third-party software applications, or apps, (whether standalone or integrated with providers' EHR technology) that would pull in current information about available providers to meet enrollees' current needs. Broad availability of provider directory data through interoperable API technology would also allow for innovation in applications or other services that help enrollees and prospective enrollees to more easily compare provider networks while they are considering their options for changing health plans. Finally, we noted in our proposal that a consistent, FHIR-based API-driven approach to making provider directory data accessible could reduce provider burden by enabling payers to more widely share basic information about the providers in their networks, such as provider type, specialty, contact information, and whether or not they are accepting new patients.
                        <PRTPAGE P="25560"/>
                    </P>
                    <HD SOURCE="HD2">B. Broad API Access to Provider Directory Data</HD>
                    <P>
                        In sections III.C. and IV. of the CMS Interoperability and Patient Access proposed rule (84 FR 7633, 7639 through 7642), we proposed to require at 42 CFR 422.119(b)(1)(iii) for MA organizations, 42 CFR 431.60(b)(3) for Medicaid FFS programs, 42 CFR 438.242(b)(6)(ii) for Medicaid managed care plans, 42 CFR 457.730(b)(3) for CHIP FFS programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed care entities that payers subject to the proposed rule make standardized information about their provider networks available through API technology, so that the public, including third-party app developers and patients, could access and use that information, including republishing the information or information derived from that information in a user-friendly way. As discussed in the preamble of the CMS Interoperability and Patient Access proposed rule, we sought comment on making provider directory information more generally available (84 FR 7639 through 7642). We discussed requiring that the API technology conform to the API standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589). Currently, because QHP issuers on the FFEs are already required to make provider directory information available in a specified, machine-readable format,
                        <SU>42</SU>
                        <FTREF/>
                         we did not propose that QHP issuers would have to make provider directory information available through an API. However, we requested information regarding whether this same requirement should apply to QHP issuers, or if such a requirement would be overly burdensome for them. We thank commenters for their insights on this request for information and are reviewing the comments received for inclusion in potential future rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>42</SU>
                             Available at 
                            <E T="03">http://cmsgov.github.io/QHP-provider-formulary-APIs/developer/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        We noted in the preamble of the proposed rule that, since this provider directory information is already available and accessible to enrollees without cost to them under existing law, this information should be as accessible through the API as it is required to be when posted on the organization's websites. Therefore, we proposed that the technical standards proposed (now finalized) by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215 (specifically at paragraphs (a)(3) and (b)) that are specific to authenticating users and confirming individuals' authorization or request to disclose their personal information to a specific application through an API, namely the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0, should not apply to our proposed public access to provider directory information through APIs (84 FR 7639). We noted that while we were aware the organization will nevertheless need to take appropriate steps to mitigate the potential security risks of allowing any application to connect to the API through which it offers provider directory access, we emphasized that these steps should be appropriate to the level of risk associated with the specific use case of accessing otherwise public information through API technology. We also noted that those wishing to access these data should not be unduly burdened by security protocols that are not necessary to provide the appropriate degree of protection for the organization's systems and data.
                    </P>
                    <P>As referenced in sections II. and III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7618 through 7639), we intended to develop additional guidance, incorporating feedback from industry that provides implementation best practices relevant to FHIR-conformant standards-based APIs to help organizations subject to the requirements proposed in this rulemaking. To that end, we solicited comment on what specific resources would be most helpful to organizations implementing APIs under requirements proposed in the proposed rule.</P>
                    <P>We summarize all public comments we received on making provider directory information available through an API—in terms of requiring a dedicated, publicly accessible Provider Directory API and more generally sharing provider directory information via an API, including as proposed under the Patient Access API discussed in section III. of this final rule and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported a requirement for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to make standardized information about their provider networks available through API technology to current enrollees, prospective enrollees, and possibly the general public. Commenters stated that they believe accurate provider directory data will improve transparency and accessibility of information regarding a provider's network status, which will help with efforts to address surprise billing and other coverage issues related to whether providers are in or out-of-network.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support. Appreciating that provider information is already publicly available, and unlike the other information included in the Patient Access API discussed in section III. of this final rule, is of a less sensitive nature, to avoid potential confusion and reduce burden resulting from having the provider directory information included in both the Patient Access API and the Provider Directory API, we are only requiring that one API—the Provider Directory API—provide access to provider directory information. As a result, we are finalizing additional regulation text to require the Provider Directory API at 42 CFR 422.120 for MA organizations; at 42 CFR 431.70 for Medicaid state agencies; at 42 CFR 438.242(b)(6) for managed care plans; at 42 CFR 457.760 for CHIP state agencies; and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. This Provider Directory API must include the same information about the provider directory as originally proposed for the Patient Access API. Specifically, the Provider Directory API must include provider directory data on a payer's network of contracted providers, including names, addresses, phone numbers, and specialties, updated no later than 30 calendar days after a payer receives provider directory information or updates to provider directory information. We are finalizing the applicable regulation text with the phrase “complete and accurate” to emphasize our intent that the directory data meet this standard. For MA organizations that offer MA-PD plans, the Provider Directory API must also make available pharmacy directory data, we are specifying that the plans must make available, at a minimum, pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”). As with the provider directory information, we are finalizing that pharmacy directory information must be updated no later than 30 calendar days after the MA organization that offers the MA-PD plan receives pharmacy directory information or updates to pharmacy directory information.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters disagreed with the proposal. They stated that payers are already required to make this information available and this proposal could result in unnecessary duplication of effort and additional costs. One commenter suggested CMS provide an exemption for payers that are 
                        <PRTPAGE P="25561"/>
                        already providing this information in a manner that aligns with the requirements in the proposed rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concern about potentially duplicative effort. While we understand that different payers are already required to make this information available in a machine readable format or on a public website according to the different rules associated with each program, we believe that making this information available through a standardized API will bring additional benefits to enrollees and prospective enrollees by making it easier for developers to incorporate this information into consumer-facing applications. We note that we did not propose to extend the requirement regarding provider directory information to QHP issuers on the FFEs, as these issuers are already required to make provider directory information available according to a specific standard for the electronic transfer of this information, as discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7633).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters raised concerns about the accuracy of provider directory information that would be available through the API, and how these inaccuracies can have a negative impact on consumers. One commenter stated that there is a high prevalence of inaccurate provider directories issued by MA organizations, in particular, and for other public and private payers, generally, and that this can bring into question the adequacy and validity of a network. Another noted that inaccurate provider directories have also resulted in patients receiving surprise bills as a result of seeing an out-of-network physician. Commenters expressed concern that making provider directory information more accessible through an API could exacerbate the impact of inaccuracies resulting in conflicting and confusing information for consumers, for instance, where an enrollee participates in two plans and receives different information about the same provider from each.
                    </P>
                    <P>Commenters discussed a variety of steps that CMS should take in concert with the proposal to ensure that provider directory information made available through the API is tested to ensure it is current, correct, and accurate. One commenter suggested CMS require payers to provide API vendors with accurate provider directory information.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns and thank the commenters for their suggestions. We have taken a number of steps to improve the accuracy of provider directory information for plans subject to direct regulation by CMS, such as implementing a process to audit directory information with MA organizations to identify deficiencies in an effort to increase data accuracy (for more information see 
                        <E T="03">https://www.cms.gov/Medicare/Health-Plans/ManagedCareMarketing/Downloads/Provider_Directory_Review_Industry_Report_Round_3_11-28-2018.pdf</E>
                        ). We will take the suggestions provided into consideration as we continue this effort. We encourage all enrollees to check with a new provider about network participation to avoid surprises and continue to explore ways to work with the payers that we directly regulate (like MA organizations) to improve the accuracy of directories.
                    </P>
                    <P>We are finalizing regulation text on the Provider Directory API at 42 CFR 422.120(b), 431.70(b), 438.242(b)(6), 457.760(b), and 457.1233(d)(3) to require that accurate and complete provider directory information be made available through the API. We believe that this language will clarify our expectation that payers take steps to ensure provider directory information made available through the API accurately reflects the current providers within the payer's network.</P>
                    <P>
                        <E T="03">Commenter:</E>
                         Several commenters responded to our proposal that impacted payers update provider directory information made available through the API to current and prospective enrollees within 30 days of receiving an update to their directory information. The commenters suggested that CMS should decrease the amount of time allowed for updates; for instance, one commenter suggested that CMS should require that provider directory information is updated within 48 hours of a change, while another recommended directory updates occur in real time, or on a regular basis as frequently as possible.
                    </P>
                    <P>Some commenters who supported the requirement that provider directories be publicly available through API technology specifically expressed concerns with how frequently directories must be updated in the case of Medicaid and CHIP programs. One commenter recommended that the clock for the 30-day requirement begins from the date the state provides the information to the Medicaid or CHIP managed care plan. Another commenter recommended that entities should be required to update provider directories in real-time.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions, and agree that more frequent updates of the provider directory information made available through the API could help to increase the accuracy of this information. Our proposed 30-day time frame was not intended to preclude payers from updating the information available via the API on a shorter timeframe, or from making updates in real time. However, we understand that payers may have different operational processes for making updates to their provider directories and are seeking to set a minimum floor for how frequently information available through the API must be updated. This is consistent with timeframes for other updates some of these payers are required to make. For instance, Medicaid managed care plans must update paper provider directories monthly and electronic provider directories no later than 30 days after the plan receives the updated information under § 438.10(h)(3).
                    </P>
                    <P>The Provider Directory API regulations finalized here require that state Medicaid and CHIP agencies, and managed care plans, make available through the API provider directory information no later than 30 calendar days after the state or managed care plan receives the provider directory information or updates to the provider directory information. We confirm that the state or managed care plan must make the provider directory information available through the API within 30 calendar days of receiving the information. This timeframe for managed care plans is consistent with the requirement in § 438.10(h)(3) for Medicaid managed care plans, which applies to CHIP managed care entities under § 457.1207.</P>
                    <P>We decline to require updates to provider directories in real-time as we do not believe that such a timeframe is operationally feasible for MA organizations, states or Medicaid and CHIP managed care plans at this time. We are finalizing our proposal that MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities update provider directory information made available through this API within 30 days of receiving a change as proposed.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters believe that, in order to increase the accuracy of provider directory data, CMS should take steps to hold providers responsible for the accuracy of their provider directory information. One commenter suggested CMS require health care providers to update their information with a centralized entity, for instance a trusted health information exchange, rather than looking to impacted payers to include these mandates in their contracts with 
                        <PRTPAGE P="25562"/>
                        providers. Another suggested that CMS should require providers to submit rosters to CMS each month indicating which health plans they contract with, enabling CMS to validate information provided through the proposed API. Another commenter suggested CMS ensure that CMS-regulated payers are provided with updated provider information in a timely manner by making such reporting requirements a condition of participation in Medicare.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions, and agree that providers have an important role to play in ensuring that provider directory information about them, provided to, and used by the payers with which they contract or participate, is up-to-date. While we did not include any proposals in this rulemaking specifically focused on provider responsibility for updating the information to be made available through the proposed API, we will continue to work with federal and industry partners to identify opportunities to improve the accuracy of provider directory information across the health care system.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters noted that a centralized repository that can serve as a “source of truth” for provider directory information is needed to ensure accuracy, and urged CMS to support work across stakeholders for such an approach. One commenter noted that health information exchanges (HIEs) could help payers to update their information through access to the directories that HIEs use for clinical data exchange.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their input. Our policy is focused around payers making provider directory information available through APIs to provide greater access to specific information on the providers in their networks. However, we believe entities focused on aggregating provider directory information can serve an important role, and we encourage payers to work with partners that maintain this information to improve accuracy.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested additional information for inclusion as part of the provider directory information made available through the API for current and prospective enrollees (in addition to provider names, addresses, phone numbers, and specialties), such as NPIs for individual and group providers, practice group name, health system name, as well as the specific plan(s) and tiers a provider participates in. One commenter also suggested including minimum provider demographics to be included in the clinical and administrative transactions to ensure accurate provider matching; whether the provider is accepting new patients; information about which providers are in-network for a plan by geography and/or specialty regardless of whether the individual is a member of a particular plan or is researching plan options; and which clinicians are in-network for care coordination and plan switching purposes.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions and agree that this additional information may be helpful to consumers. However, at this time we are seeking to minimize the burden for the regulated payers that must comply with this proposal, and have sought to identify a minimum set of provider directory information that aligns with existing requirements applicable to MA organizations (including MA organizations that offer MA-PD plans), state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities regarding such directories. We do encourage payers to explore how they can make additional provider directory data available through the API to most benefit current and prospective enrollees. Also, we note that the requirements in this final rule set out the minimum requirements; payers are strongly encouraged to go beyond that minimum, if and as possible, to make useful information available for their enrollees and beneficiaries.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter who supported our proposal also urged CMS to take additional steps to make provider directories more accessible to enrollees, for instance by integrating a provider directory in future iterations of Plan Finder for MA plans, and ensuring the directory data is accurate and up to date.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenter for the suggestions. We will take these suggestions into consideration.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters addressed issues with technical standards for provider directory information, with several stating that appropriate standards for making this information available through an API are still emerging. For instance, one commenter noted that current provider directory standards were written for FHIR Release 3 and that the standard has not been adopted by the field. The commenter stated that before CMS requires payers to make provider directory information available via a standards-based API, more work is needed to build the provider directory specification in FHIR Release 4.
                    </P>
                    <P>Several commenters suggested that CMS should delay implementing this proposal, proposed to be applicable starting January 1, 2020, until stakeholders have been able to establish consensus-based standards for the creation and display of directory information. One commenter encouraged CMS to develop a voluntary, multi-stakeholder partnership to establish data content FHIR-based standards related to provider directories and then wait to establish the timeframe for provider directory data updates until the development of these FHIR-based standards are completed.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns, and agree that updated FHIR-based provider directory implementation guidance is important for implementation of this policy. We confirm here that HL7 FHIR Release 4.0.1—the API standard adopted at 45 CFR 170.215 and which must be used under our Provider Directory API requirement—provides a base standard for moving information through an API. The basic information (name, phone number, address, and specialty) required for this Provider Directory API can all be represented through FHIR Release 4.0.1. Additional implementation guidance will provide additional information for how to use the FHIR Release 4.0.1 base standard to make provider directory information available and ensure greater uniformity in implementation and reduce implementation burden for payers. As noted in section III. of this final rule, we have been working with HL7 and partners to ensure the necessary consensus-based standards and associated guidance are available so that impacted payers can consistently implement all of the requirements included in this final rule. We are providing a link to a specific FHIR Release 4.0.1 implementation guide and reference implementation for all interested payers for the Provider Directory API that provide valuable guidance to further support sharing the needed data using the required standards: 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.</E>
                         Though not mandatory, using this guidance will lower payer burden and support consistent implementation of the FHIR Release 4.0.1 APIs.
                    </P>
                    <P>
                        Appreciating the time needed for payers to build, implement, and test these APIs, we are providing additional time for implementation, and are finalizing January 1, 2021 as the implementation date for the Provider Directory API for all payers subject to this requirement. Appreciating the value of making this information publicly accessible, we do encourage payers to 
                        <PRTPAGE P="25563"/>
                        implement this Provider Directory API as soon as they are able. We are requiring at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities that these payers make the Provider Directory API accessible via a public-facing digital endpoint on their website. We will check a random sample of payer websites for links to these publicly accessible APIs, starting in January 2021 to evaluate compliance.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter suggested that, as CMS already requires provider directory information to be made available online by payers subject to this rule, for interoperability transactions CMS should require use of a standard described as “the HIPAA 274 transaction.” The commenter stated that the metadata defined within this transaction can drive a consistent payload for an API to support provider directory information sharing.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's suggestion, but at this time we are finalizing requirements for provider directory information to be available through an API using the standards at 45 CFR 170.215, including, FHIR Release 4.0.1 standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) to consistently align all various API formats throughout the rule with a single modern standard capable of meeting all requirements. CMS understands that some information within the X12 274 Transaction (Healthcare Provider Information Transaction Set for use within the context of an Electronic Data Interchange (EDI) environment) may provide the basic provider information to support an API. HHS, however, has not adopted the X12 274 transaction standard under HIPAA or for any other use. Moreover, the required availability of a plan's entire provider directory via an API is not a HIPAA transaction that has been defined or associated with a specific transaction under HIPAA. We believe that using FHIR Release 4.0.1 for the purpose of this Provider Directory API will provide greater long term flexibility for payers subject to this rule, allowing them the ability to meet minimum requirements, and extend beyond these requirements based on the industry's diverse and evolving needs surrounding provider directories, while reducing impact on those who may not be ready to receive additional information beyond the minimum set of data required by this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested that CMS ensure public health agencies are also able to access provider directory information made available through the API, while another commenter requested that approved agents and brokers be granted access to this information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Under this final rule, the Provider Directory API must be publicly accessible, so that any third party can access an impacted payer's provider directory information. Our regulation text reflects this by requiring that the Provider Directory API be accessible via a public-facing digital endpoint on the applicable payer's website. The value of making this information available via an API is that third-party developers will be able to access it to make it available in valuable and useful ways for all interested stakeholders. We therefore anticipate that public health agencies, agents, and brokers, and any other member of the public would be able to access these data via third-party apps.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested CMS require payers to include other types of non-physician professionals within their provider directories, such as nurse practitioners, certified registered nurse anesthetists, physical therapists, and post-acute care providers. Commenters stated that including additional qualified licensed non-physician providers could help increase patient access to care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions. We did not propose to change the parameters of the information required to be included in provider directories for the payers subject to the Provider Directory API requirement here. Existing requirements for paper and on-line provider directories, such as those in 42 CFR 422.111 and 438.10(h), are not changed or limited by this final rule. Instead, our API proposals and this final rule focus on making certain payers (that is, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities) share provider directory information through an API. How “provider” is defined in this context is outside the scope of this regulation.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter recommended that CMS amend the API requirement to also include FHIR endpoint information for providers as part of provider directory information, to ensure access to regional/national directories in addition to the current partial ones.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters that FHIR endpoint information is important to improve interoperability across providers. We discuss FHIR endpoints in section IX. of this final rule. For this Provider Directory API, we have focused on a minimum set of information of primary interest to patients and typically found in provider directories. However, we encourage payers to consider including other data elements that may add value to the Provider Directory API. We may consider expanding this minimum set of information in potential future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter suggested that CMS impose penalties on plans that do not comply with the provider directory requirement.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank the commenter for this suggestion. We did not propose to establish additional penalties for noncompliance with the requirement to make provider directory information available through an API; however, we note that the requirement to make provider directory information available through an API will be a requirement for MA organizations, Medicaid managed care plans and CHIP managed care entities to fulfill under their contracts in their respective programs. Therefore, existing enforcement authority for ensuring compliance with those contracts will apply. Further, the API requirements, including the provider directory components of the required API(s) will be required for state Medicaid and CHIP agencies operating FFS Medicaid programs and CHIPs.
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing regulations to require that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities make standardized information about their provider networks available via a FHIR-based API conformant with the standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215 (including FHIR Release 4.0.1), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to anyone wishing to access it. At a minimum, these payers must make available via the Provider Directory API provider names, addresses, phone numbers, and specialties. For MA organizations that offer MA-PD plans, we are specifying that they must make available, at a minimum, pharmacy 
                        <PRTPAGE P="25564"/>
                        directory data, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”), updating the regulation text from the proposed rule, which simply stated “number, mix, and addresses of network pharmacies”. All directory information must be available through the API within 30 calendar days of a payer receiving the directory information or an update to the directory information. We note we have also revised the proposed regulation text for making directory information available through an API to specify consistently that the directory information must be complete and accurate and that updates must be made in “calendar” days.
                    </P>
                    <P>The Provider Directory API is being finalized at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. We are finalizing that access to the published Provider Directory API must be fully implemented by January 1, 2021 for all payers subject to this new requirement. We encourage payers to implement this Provider Directory API as soon as they are able to make and show progress toward the API requirements in this final rule and to signal their commitment to making the information that will empower their patients easily accessible and usable. Under this final rule, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must make the Provider Directory API accessible via a public-facing digital endpoint on their website to ensure public discovery and access.</P>
                    <HD SOURCE="HD1">V. The Health Information Exchange and Care Coordination Across Payers: Establishing a Coordination of Care Transaction To Communicate Between Plans Provisions, and Analysis of and Responses To Public Comments</HD>
                    <P>
                        We proposed a new requirement for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to require these payers to maintain a process to coordinate care between payers by exchanging, at a minimum, the USCDI at the enrollee's request as specified in the proposed regulation text. Instead of specifically proposing use of the USCDI, we proposed use of a content standard adopted by ONC at 45 CFR 170.213, which was proposed in a companion proposed rule, the ONC 21st Century Cures Act proposed rule as the USCDI (version 1) (84 FR 7441 through 7444). Understanding that enrollees' information is already exchanged between plans for use in carrying out various plan functions,
                        <SU>43</SU>
                        <FTREF/>
                         payers have experience exchanging, receiving, and incorporating data from other plans into an enrollee's record. We proposed requiring the USCDI data set be exchanged at the enrollee's direction, and when received by a payer, incorporated into the recipient payer's data system. As proposed, upon request from an enrollee, the USCDI data set would have to be sent to another payer that covers the enrollee or a payer identified by the enrollee at any time during coverage or up to 5 years after coverage ends, and the payer would have to receive the USCDI data set from any payer that covered the enrollee within the preceding 5 years. These proposals were intended to support patient directed coordination of care; that is, each of the payers subject to the requirement would be required to, upon an enrollee's request: (1) Receive the data set from another payer that had covered the enrollee within the previous 5 years; (2) send the data set at any time during an enrollee's enrollment and up to 5 years later, to another payer that currently covers the enrollee; and (3) send the data set at any time during enrollment or up to 5 years after enrollment has ended to a recipient identified by the enrollee.
                    </P>
                    <FTNT>
                        <P>
                            <SU>43</SU>
                             See Office for Civil Rights. (2016, August 16). 3014-HIPAA and Health Plans—Uses and Disclosures for Care Coordination and Continuity of Care. Retrieved from 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/faq/3014/uses-and-disclosures-for-care-coordination-and-continuity-of-care/index.html.</E>
                        </P>
                    </FTNT>
                    <P>We identified in the proposed rule that this proposal is based on our authority under sections 1856(b) and 1857(e) of the Act to adopt standards and contract terms for MA plans; section 1902(a)(4) of the Act to adopt methods of administration for state Medicaid plans, including requirements for Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a) of the Act for CHIP managed care entities (MCOs, PIHPs, and PAHPs); and section 1311(e)(1)(B) of the Affordable Care Act for QHP issuers on the FFEs. We explained in the CMS Interoperability and Patient Access proposed rule our belief that the proposal will help to reduce provider burden and improve patient access to their health information through coordination of care between payers (84 FR 7640 through 7642). We also noted that the CHIP regulations incorporate and apply, through an existing cross-reference at 42 CFR 457.1216, the Medicaid managed care plan requirements codified at 42 CFR 438.62(b)(1)(vi). Therefore, the proposal for Medicaid managed care plans described also applied to CHIP managed care entities even though we did not propose new regulation text in part 457. We proposed that this new requirement would be applicable starting January 1, 2020 for MA organizations, Medicaid managed care plans, CHIP managed care entities, and beginning with plan years beginning on or after January 1, 2020 for QHP issuers on the FFEs. Among other topics related to the proposal, we solicited comments on the proposed date these policies would be applicable.</P>
                    <P>We proposed to codify this new requirement at 42 CFR 422.119(f) for MA organizations; at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care plans (and by extension under existing rules at 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(f) for QHP issuers on the FFEs. The proposed new requirement was virtually identical for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, with modifications in the proposal necessary for specific payer types to account for the program needs of each. The proposed regulation text references the content standard adopted at 45 CFR 170.213, which ONC proposed as the USCDI (version 1) data set (84 FR 7441 through 7444). We noted we believed that exchanging this data set would help both enrollees and health care providers coordinate care and reduce administrative burden to ensure that payers provide coordinated high-quality care in an efficient and cost-effective way that protects program integrity. For a full discussion of the benefits we anticipate from this data exchange requirement, see the discussion in the CMS Interoperability and Patient Access proposed rule (84 FR 7640).</P>
                    <P>
                        In addition to the benefits for care coordination at the payer level and reduced provider burden, we noted that once the requested information, as specified by the USCDI standard, was made available to the patient's current plan, the enrollee would have access to multiple years of their health information through the proposed Patient Access API, discussed in section III.C. of the CMS Interoperability and Patient Access proposed rule and in this final rule. This is the case because the proposal required the receiving payer to incorporate the received data into its records about the patient, therefore making these data the payer maintains, and data available to share with the 
                        <PRTPAGE P="25565"/>
                        patient via the Patient Access API. The USCDI data set includes clinical data points essential for care coordination. Access to these data would provide the patient with a more comprehensive history of their medical care, helping them to make better informed health care decisions. We sought comment on how plans might combine records and address error reconciliation or other factors in establishing a more longitudinal record for each patient.
                    </P>
                    <P>We proposed to allow multiple methods for electronic exchange of the information, including use of the APIs proposed in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7627 through 7639), to allow for patient-mediated exchange of payer information or direct payer-to-payer communication, subject to HIPAA requirements, 42 CFR part 2, and other applicable federal and state laws. We noted that we considered requiring the use of the FHIR-based API discussed in section III. of the proposed rule for this information exchange; however, we understood that some geographic areas might have a regional health information exchange (HIE) that could coordinate such data transfers for any HIE-participating MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs that are subject to the proposal. We sought comment on whether it would be beneficial to interoperability and patient care coordination for us to require the use of the FHIR-based API otherwise proposed, and whether this should be the only mechanism allowed for this exchange, or whether multiple methods for electronic exchange of the information should be allowed under the proposed policy and whether CMS might be able to leverage its program authority to facilitate the data exchanges contemplated by the proposal. We expected enrollees to have constant access to requesting an exchange of data as the proposal would require exchange of the USCDI data set whenever an enrollee makes such a request, which may occur at times other than enrollment or disenrollment. We acknowledged that in some cases payers subject to the proposed requirement may be exchanging patient health information with other payers that are not similarly required to exchange USCDI data sets for enrollees, for example, if a consumer changes their health coverage from a QHP on an FFE to employer-sponsored coverage, and we requested comment on how to support patients and providers in those situations.</P>
                    <P>
                        We also proposed that a patient should be able to request his or her information from their prior payer up to 5 years after dis-enrollment, which is considerably less than existing data retention policies for some of the payers.
                        <SU>44</SU>
                        <FTREF/>
                         Further, we proposed that the health information received as part of the USCDI (version 1) data set under our proposal would have to be incorporated into the IT and data systems of each payer that receives the USCDI data set under the proposed requirement, such that the enrollee's data would be cumulative and move with the enrollee as he or she changes enrollment. For example, if a patient is enrolled in Plan 1 in 2020 and Plan 2 in 2021, then requests the data from Plan 1 to be sent to Plan 2, Plan 2 would have at least 2 years (2020 and 2021) of health information for that patient. If the patient moves to Plan 3 in 2022, Plan 3 should receive both 2020 and 2021 data from Plan 2 at the patient's request. While the proposal would require compliance (and thus exchange of these data sets) only by MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, we noted that we hoped that compliance by these payers could be the first step toward adoption and implementation of these standards on a voluntary basis by other payers throughout the health care system.
                    </P>
                    <FTNT>
                        <P>
                            <SU>44</SU>
                             Under 42 CFR 422.504(d) and 438.3(u), MA organizations and Medicaid managed care plans, and CHIP plans must retain records for at least 10 years. Under 45 CFR 156.705; 45 CFR 155.1210(b)(2), (3) and (5), QHP issuers on the FFEs must also retain records for 10 years.
                        </P>
                    </FTNT>
                    <P>
                        Research indicates that the completeness of a patient record and the availability of up-to-date and relevant health information at the point of care can have a significant impact on patient outcomes.
                        <SU>45</SU>
                        <FTREF/>
                         We noted that we believe the proposal for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to exchange the USCDI data set in particular scenarios would support improvement in care coordination by allowing for sharing of key patient health information when an enrollee requests it.
                    </P>
                    <FTNT>
                        <P>
                            <SU>45</SU>
                             Office of the National Coordinator. (2019, June 4). Improved Diagnostics &amp; Patient Outcomes. Retrieved from
                            <E T="03"> https://www.healthit.gov/topic/health-it-and-health-information-exchange-basics/improved-diagnostics-patient-outcomes.</E>
                        </P>
                    </FTNT>
                    <P>We proposed that the payers subject to this new requirement would be required to exchange, at a minimum, the data classes and elements included in the content standard proposed to be adopted at 45 CFR 170.213 in the ONC 21st Century Cures Act proposed rule, specifically, the USCDI (version 1) data set. On behalf of HHS, ONC proposed to adopt the USCDI as a standard (84 FR 7441 through 7444), to be codified at 45 CFR 170.213, and the proposed regulation text cross-references this regulation. These data exchanges would provide the enrollee's new payer with a core set of data that could be used to support better care coordination and improved outcomes for the enrollee. We considered requiring plans to exchange all the data that we proposed be available through an API (see section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7627 through 7639)) but we understood that ingesting data and reconciling errors has challenges and proposed this more limited data set to address those concerns. We sought comment on whether the USCDI data set would be comprehensive enough to facilitate the type of care coordination and patient access described in the proposal, or whether additional data fields and data elements that would be available under the API proposal in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7627 through 7639) should also be required. For a full discussion of the benefits of the USCDI for this data exchange, see the CMS Interoperability and Patient Access proposed rule (84 FR 7641).</P>
                    <P>We stated that we believed that the proposed requirement would also support dually eligible individuals who are concurrently enrolled in MA plans and Medicaid managed care plans. Under the proposal, both of the dually eligible individual's payers would be subject to the requirement to exchange that individual's data in the form of the USCDI, which should improve the ability of both payers to coordinate care based on that data, as discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7642). We sought comment on how payers should coordinate care and exchange information for dually eligible individuals. We also sought comment on the associated burden on plans to exchange the USCDI data set under the proposal. In addition, we noted that we were interested in comments about potential legal barriers to exchanging the USCDI data set as would be required under the proposal; for example, whether there were federal, state, local, and tribal laws governing privacy for specific use cases (such as in the care of minors or for certain behavioral health treatments) that would raise additional considerations that we should address in this regulation or in guidance.</P>
                    <P>
                        We stated that activities related to the proposed requirement could qualify as a quality improvement activity (QIA) 
                        <PRTPAGE P="25566"/>
                        meeting the criteria described in section 2718(a)(2) of the PHSA for purposes of the Medical Loss Ratio (MLR) requirements for QHP issuers on an FFE,
                        <SU>46</SU>
                        <FTREF/>
                         and similar standards for treatment of QIA standards applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP managed care entities under 42 CFR 457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. An entity's MLR is generally calculated as the proportion of revenue spent on clinical services and QIA. There are several specific criteria an expense must meet, such as being designed to improve health quality and health outcomes through activities such as care coordination, in order to qualify as QIA.
                        <SU>47</SU>
                        <FTREF/>
                         We requested comments related to this assumption and its implications.
                    </P>
                    <FTNT>
                        <P>
                            <SU>46</SU>
                             While this rulemaking is specific to QHP issuers participating on the FFEs, we note that to the extent other commercial market issuers incur similar costs for coverage sold in the individual or group markets, those expenses may similarly qualify as QIA.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>47</SU>
                             See, for example, 45 CFR 158.150 and 45 CFR 158.151.
                        </P>
                    </FTNT>
                    <P>We summarize the public comments we received on the payer-to-payer data exchange, as well as on whether these new activities may qualify as QIA for MLR purposes, and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters were very supportive of this proposal and indicated their belief that these new data exchange requirements could improve care coordination by reducing burden on both beneficiaries and providers by limiting the need for duplicative letters of medical necessity, preventing inappropriate step therapy, and reducing unnecessary utilization reviews and prior authorizations.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support for this payer-to-payer data exchange proposal. We are finalizing this proposal with some modifications as detailed below. Under this final rule, payers subject to this requirement must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.213, which is currently version 1 of the USCDI. We are also finalizing that payers must use this process to exchange the USCDI-defined data set with the approval and at the direction of a current or former enrollee, or the enrollee's personal representative, to align with the language used for the API requirements. Furthermore, we are finalizing the proposal that upon receipt, the receiving payer must incorporate the data set into the payer's own records about the enrollee with a clarification that this obligation applies to records about current enrollees. We clarify here that incorporating the data into the payer's records under this specific regulation would not require that the payer treat or rely on these data as its own, but that the payer must include these data in the record it maintains for each enrollee. While the obligation to incorporate data received from other payers into the receiving payer's records applies only for data about current enrollees, once incorporated, these data must be maintained even after a current enrollee leaves the payer's coverage. We do not want to be overly prescriptive about how these data are used by each payer at this time. Initially, we are only requiring that these data are incorporated into the existing record to facilitate the creation and maintenance of a patient's cumulative health record with their current payer. In subsequent rulemaking, however, we may be more specific, depending on proposed use cases, and propose more prescriptive use of specific data.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters expressed concern about each payer's increased access to clinical information impacting coverage decision-making. Commenters noted that while historically physicians have controlled the patient's clinical data in determining what to submit to obtain reimbursement for care provided, payers would now have access to information outside of the scope of the specific service being billed by a provider. Commenters noted that a payer may access the exchanged health data from a prior payer and determine that a patient has already received treatment for a condition and deny, delay, and/or require prior authorization for allegedly duplicative treatment. Additionally, a few commenters expressed concern that payers may use prior information to restrict coverage for medically necessary care that a patient may have received previously. A few commenters recommended that CMS require that payers must attest that the exchanged data cannot be used to deny or delay treatment, increase rates, or implement step therapy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We note that this regulation does not make any changes to when payers can deny coverage. The data received via this data exchange must be used per all applicable law, regulation, and in accordance with payer contracts as it relates to coverage decisions and, specifically, coverage denial. Nothing in this regulation changes any existing obligations or policies related to coverage or services. Further, as proposed and finalized, the regulations regarding the exchange of data among payers is triggered by an enrollee's request that the information be sent or received and incorporated. The individual enrollee retains control in this situation and can refrain from requesting information be sent to a new or current payer. We do note, however, that there are currently scenarios where payers can exchange data without an enrollee's request, such as for payment and health care operations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters were concerned about the responsibility of MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to forward information from other payers or information from outside their organization where they did not control data integrity. Also, commenters were concerned there might be information that is contradictory and were unsure of each payer's responsibilities in that case.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We do believe that patients have a right to their data. In addition, they have a right to request that their health data follow them throughout their health care journey. It is only when patients are able to facilitate the sharing of their data, and even see it themselves, such as via the Patient Access API, that they will be able to understand where there may be opportunities to work with their previous and current providers and payers to ensure they have an accurate health record. Today, to the extent permitted by law, payers may exchange patient data without the patient's consent for various purposes including payment and health care operations. The policy we are finalizing here will allow the patient to facilitate that exchange of their health information. In using this process, patients can ensure their payers and providers have the most accurate and up-to-date information about them.
                    </P>
                    <P>
                        Payers can choose to indicate which data being exchanged were received from a previous payer so the receiving payer, or even a patient, understands where to direct questions and is aware of the scope of control over data integrity. This will also help receiving payers and patients understand how to reconcile contradictory information as it can be made clear where questions should be directed. Payers are under no obligation under this regulation to update, validate, or correct data received from another payer.
                        <PRTPAGE P="25567"/>
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters agreed with the proposed suggestion that activities related to this proposal may qualify as QIA meeting the criteria described in section 2718(a)(2) of the PHSA for purposes of the MLR requirements for QHP issuers on the FFEs, and similar standards for treatment of quality improvement standards applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP managed care entities under 42 CFR 457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We confirm that we continue to believe that expenses for the care coordination data exchanges required by this final rule may qualify as QIA for purposes of calculating the MLR for payers that engage in such exchanges. As noted above, while this rulemaking is specific to QHP issuers participating on the FFEs, to the extent other commercial market issuers incur similar costs for coverage sold in the individual or group markets, those expenses may similarly qualify as QIA. We appreciate the commenters' support and will consider recognizing the expenses related to this data exchange as QIA in future rulemaking or guidance, as may be necessary.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters were concerned about the time frame to implement this provision and were concerned making this policy applicable in 2020 would not provide enough time to operationalize this policy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and understand that it will take time to fully and properly implement this policy. We are finalizing this payer-to-payer data exchange requirement with an applicability date of January 1, 2022 with respect to the exchange of the USCDI data set.
                    </P>
                    <P>Although we did not propose to require payers to use an API to exchange the USCDI under this payer-to-payer data exchange proposal, we appreciate and support that some payers would like to leverage the Patient Access API (discussed in section III. of this final rule) to meet the requirements of this payer-to-payer data exchange. The Patient Access API requirement makes USCDI data available to the patient or a third party at the patient's direction. Because the Patient Access API is facilitating the exchange of the USCDI, some of the work to develop an API to exchange these data and the work to map the relevant USCDI data will be completed by January 1, 2021, when the Patient Access API must be made available as finalized in section III. of this rule. In addition, if a payer receives data via an API, the payer could then incorporate it into a patient's record and in turn share it with the patient via the Patient Access API with little additional work needed.</P>
                    <P>We appreciate the value of using an API for this data exchange, and we understand the efficiencies that it can add to both this payer-to-payer data exchange as well as the Patient Access API policy. We also appreciate that incorporating data from other payers received via an API will be a new experience for payers, however. For instance, payers will need to develop a process to incorporate data from other payers into their systems, including potentially processes for tagging these data as originating with another payer so they can efficiently share that information with patients and future payers. These are additional processing steps that take time to implement.</P>
                    <P>In evaluating the comments on the proposals in this rule, and appreciating the value of sharing and exchanging data via APIs, we see the benefit of having all data exchanged via APIs. Therefore, we may consider for future rulemaking an API-based payer-to-payer data exchange. At this time, we believe that an applicability date of January 1, 2022 for compliance with this requirement is appropriate. This provides time for payers to get experience with the Patient Access API, and provides payers with additional time to fully and successfully implement this payer-to-payer data exchange requirement.</P>
                    <P>To support a more seamless data exchange and to further clarify this payer-to-payer data exchange requirement, we are finalizing some modifications of the proposed regulation text at 42 CFR 422.119(f)(1)(ii) and (iii) for MA organizations; at 42 CFR 438.62(b)(1)(vi)(B) and (C) for Medicaid managed care plans (and by cross-reference from 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(f)(1)(ii) and (iii) for QHP issuers on the FFEs to clearly indicate payers are obligated under this proposal to, with the approval and at the direction of a current or former enrollee, exchange data with any other payer identified by the enrollee. The proposed regulation text used both the term “recipient” and “any other health care plan” to identify where these data would be sent at an enrollee's request; the term “recipient” could have been interpreted more broadly than we intended. In the final regulation text, we are using “payer” instead and consolidating the proposed provisions that would require the payer that is subject to these rules to send data at the enrollee's request at any time during enrollment or up to 5 years after enrollment ends. As discussed in section III. of this final rule, we are also specifying in the final regulations that a payer is only required to send data received under this payer-to-payer data exchange requirement in the electronic form and format it was received. In this way, a payer would not be asked to receive paper records from another payer under this policy and then in turn share those paper records with another payer in the future at the patient's direction. If the payer received a patient's information via an API, the payer must share it via an API if the payer they are sending to has the capacity to receive it. If a patient requests that a former payer send their information to their new payer and then requests that their new payer make their data accessible via that new payer's Patient Access API, the new payer would only be required to include the information received from the former payer at the patient's direction if this newly acquired information was received via a FHIR-based API. Otherwise, the new payer is only required to share data via the Patient Access API that the payer already maintains and has prepared to be shared via a FHIR-based API.</P>
                    <P>
                        We are also finalizing new regulation text, at 42 CFR 422.119(h) for MA organizations; at 42 CFR 438.62(b)(1)(vii) for Medicaid managed care plans (and by cross-reference from 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(i) for QHP issuers on the FFEs, that these regulated payers will need to comply with the payer-to-payer data exchange requirements beginning January 1, 2022 (or beginning with plan years beginning on or after January 1, 2022 for QHP issuers on the FFEs). In addition, this requirement, as finalized, provides that payers are required to exchange data they maintain with a date of service on or after January 1, 2016. In this way, payers only have to prepare a defined initial historical set of data for sharing via this payer-to-payer data exchange policy, as also required under the Patient Access API policy discussed in section III. of this final rule. We believe that delaying implementation to January 1, 2022 and specifying that only data with a date of service on or after January 1, 2016 must be exchanged under the new requirement addresses concerns about the timing and level of burden involved in meeting this requirement. This also clarifies that if certain information is not maintained by the 
                        <PRTPAGE P="25568"/>
                        payer, the payer is not obligated to seek out and obtain the data.
                    </P>
                    <P>We also sought comment on how this policy might impact dually eligible individuals. We summarize the public comments we received on this payer-to-payer data exchange specifically regarding our request for comment for how this policy might impact dually eligible individuals who are concurrently enrolled in MA plans and Medicaid managed care plans and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters supported the proposal because it could improve care coordination for dually eligible beneficiaries. One commenter noted that because of this proposal, MA plans and Medicaid MCO plans would have the same data and health history for an individual. One commenter believed that this could help states that do not have an easily accessible source of data for knowing when their Medicaid beneficiaries are enrolled for Medicare. This commenter recommended including enrollment source and enrollment and disenrollment dates in the data exchanged between payers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support and the suggestion noted. We will further evaluate this suggestion for future consideration.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter requested additional information regarding how plans should account for gaps in plan coverage over the course of 5 years. The commenter believed this will be particularly important for dual eligible and Medicaid beneficiaries who may move in and out of a health plan program as their status may change due to changing circumstances.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's request for information. We note that one payer would only be obligated to send another payer information that the payer maintains (which could include data received from other payers under this final rule that must be incorporated into the current payer's records). If in the 5 years prior to January 1, 2022, a patient was in a Medicaid managed care plan for 1 year in 2019 and then there was a break in service with the patient returning for 1 year in 2021, this Medicaid managed care plan would be required to share data from 2019 and 2021 if requested by the patient. It would not be the managed care plan's responsibility to address the gaps in the data that the plan maintains. Assuming that the patient was enrolled in an MA plan or another Medicaid managed care plan in 2020, the patient could request that the plan they had in 2020 independently send their data to the payer they have indicated. In this way, the indicated payer is now the holder of the comprehensive information, as under this requirement a payer must incorporate the data received from other payers under this policy into their data system. If the patient leaves to go to a new payer in 2023, the one payer that now maintains their data from 2019 to 2022 would be the one payer that could forward the data to the new payer, in the electronic form and format it was received. We acknowledge that this may be complex for dually eligible beneficiaries.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters noted advantages, burdens, and complexities associated with plans serving dually eligible beneficiaries continuously aggregating real-time member data from multiple plans. One commenter noted that each payer should only be responsible for their own data set and the coordination of data across multiple plans and providers would be more ideally done through a Trusted Exchange Framework and Common Agreement (TEFCA). This commenter noted that additional technical capabilities will be required due to the possibility of overlapping coverage when combining and incorporating records.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate these thoughtful comments. We note that this payer-to-payer data exchange is only required when initiated by an enrollee's request, and only applies to the payers who are subject to our final regulations at 42 CFR 422.119(f)(1) and (h) for MA organizations; 42 CFR 438.62(b)(1)(vi) and (vii) for Medicaid managed care plans (and by cross-reference from 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(f) and (i) for QHP issuers on the FFEs. The enrollee may request this payer-to-payer exchange just once, or more frequently. We did not propose, and are not finalizing, any requirement for continuous data exchange, however.
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing with modifications our proposal at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213 (currently version 1 of the USCDI), as outlined in section III. of this final rule. Specifically, we are finalizing as proposed that the payers subject to these regulations incorporate the data they receive into the enrollee's record. In the final regulation text, we are using the language “with the approval and at the direction” of the enrollee versus “at the request” of the enrollee to align with the language used for the API requirements.
                    </P>
                    <P>We are finalizing modifications to the proposed regulation text to streamline the text and best specify the scope of the policy as intended, as well as to align the text for all payer types as appropriate. Specifically, at 42 CFR 422.119(f)(1)(i), 438.62(b)(1)(vi)(A) (and by cross-reference from 42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(i), the regulation text states that relevant payers “receive” versus “accept” data for current enrollees. At 42 CFR 422.119(f)(1)(ii), 438.62(b)(1)(vi)(B) (and by cross-reference from 42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(ii), the final regulations provide that a payer must send the defined information set to any other payer. In addition, at 42 CFR 422.119(f)(1)(iii), 438.62(b)(1)(vi)(C) (and by cross-reference from 42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(iii), we specify that a payer is only obligated to send data received from another payer under this policy in the electronic form and format it was received. This is intended to reduce burden on payers. We note the final regulations do use the term “payer” in place of “health care plan” to clarify that the scope of the obligations are for all payers impacted by this regulation. Also at 45 CFR 156.221(f)(1), we updated the title of the paragraph to align with the parallel regulations for other payers types, and we corrected an incomplete sentence. Finally, we specify that this policy also applies to an enrollee's personal representative.</P>
                    <P>
                        We are also finalizing regulation text to address when these regulated payers must comply with these new requirements at 42 CFR 422.119(h) for MA organizations; at 42 CFR 438.62(b)(1)(vii) for Medicaid managed care plans (and at 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(i) for QHP issuers on the FFEs. Starting January 1, 2022, and for QHP issuers on the FFEs starting with plan years beginning on or after January 1, 2022, the finalized regulation requires these payers to exchange data with a date of service on or after January 1, 2016 that meets the requirements of this section and which the payer maintains. In this way, payers only have to prepare an initial historical set of data for sharing via this payer-to-payer data exchange policy that is consistent with the data set to be available through the 
                        <PRTPAGE P="25569"/>
                        Patient Access API, as finalized in section III. of this final rule.
                    </P>
                    <HD SOURCE="HD1">VI. Care Coordination Through Trusted Exchange Networks: Trust Exchange Network Requirements for MA Plans, Medicaid Managed Care Plans, CHIP Managed Care Entities, and QHP Issuers on the FFEs Provisions, and Analysis of and Responses to Public Comments</HD>
                    <P>We proposed to require MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in trust networks in order to improve interoperability in these programs. We noted that we would codify this requirement in, respectively, 42 CFR 422.119(f)(2), § 438.242(b)(5), and § 457.1233(d) (which cross-references the requirements in 42 CFR 438.242(b)(5)) and 45 CFR 156.221(f). In general, payers and patients' ability to communicate between themselves and with health care providers could considerably improve patient access to data, reduce provider burden, and reduce redundant and unnecessary procedures. Trusted exchange networks allow for broader interoperability beyond one health system or point to point connections among payers, providers, and patients. Such networks establish rules of the road for interoperability, and with maturing technology, such networks are scaling interoperability and gathering momentum with participants, including several federal agencies, EHR vendors, retail pharmacy chains, large provider associations, and others.</P>
                    <P>The importance of a trusted exchange framework to such interoperability is reflected in section 4003(b) of the Cures Act, which was discussed in more detail in section I.D. of the CMS Interoperability and Patient Access proposed rule (84 FR 7612 through 7614). In section VI. of the CMS Interoperability and Patient Access proposed rule (84 FR 7642), we discussed and explained our proposal to require certain payers to participate in trusted exchange networks. A trusted exchange framework allows for the secure exchange of electronic health information with, and use of electronic health information from, other health IT. Widespread payer participation in such a framework might allow for more complete access and exchange of all electronically accessible health information for authorized use under applicable state or federal law, which we believe would lead to better use of such data. We noted that while we cannot require widespread payer participation in trust networks, we proposed to use our program authority in the MA program, Medicaid managed care program, CHIP managed care program, and QHP certification program for the FFEs to increase participation in trust networks and to bring the potential benefits of participating in such programs, including improved interoperable communication and care coordination, which result in opportunities for improved patient outcomes and burden reduction.</P>
                    <P>We proposed to require, beginning January 1, 2020, that MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs participate in a trusted exchange network. The proposal was based on our authority under: Sections 1856(b) and 1857(e) of the Act to adopt standards and contract terms for MA plans; section 1902(a)(4) of the Act to adopt methods of administration for the administration state Medicaid plans, including requirements for Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a) for CHIP managed care entities (MCOs, PIHPs, and PAHPS); and section 3001(c)(9)(F)(iii) of the PHSA and section 1311(e)(1)(B) of the Affordable Care Act for QHP issuers on an FFE. Under the proposal, and consistent with section 4003(b) of the Cures Act, participation would be required in a trusted exchange framework that met the following criteria:</P>
                    <P>(1) The trusted exchange network must be able to exchange PHI, defined at 45 CFR 160.103, in compliance with all applicable state and federal laws across jurisdictions.</P>
                    <P>(2) The trusted exchange network must be capable of connecting both inpatient EHRs and ambulatory EHRs.</P>
                    <P>(3) The trusted exchange network must support secure messaging or electronic querying by and between patients, providers, and payers.</P>
                    <P>We proposed to codify these requirements for these payers at 42 CFR 422.119(f)(2) for MA organizations, § 438.242(b)(5) for Medicaid managed care plans, § 457.1233(d)(2) for CHIP managed care entities, and 45 CFR 156.221(f) for QHPs on the FFEs.</P>
                    <P>
                        On April 19, 2019, ONC released the draft Trusted Exchange Framework and Common Agreement (TEFCA Draft 2) for public comment.
                        <SU>48</SU>
                        <FTREF/>
                         Previous commenters on draft 1 of the TEFCA, particularly payers providing comments, requested that existing trust networks that are operating successfully be leveraged in further advancing interoperability; thus, we considered a possible future approach to payer-to-payer and payer-to-provider interoperability that leverages existing trust networks to support care coordination and improve patient access to their data. We requested comments on this approach and how it might be aligned in the future with section 4003(b) of the Cures Act. We also requested comments on the applicability date we proposed for the trusted exchange network participation requirement and what benefits and challenges the payers subject to our proposal might face meeting this requirement for additional consideration in future rulemaking.
                    </P>
                    <FTNT>
                        <P>
                            <SU>48</SU>
                             See 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf.</E>
                             For additional information about TEFCA, see 
                            <E T="03">https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement.</E>
                        </P>
                    </FTNT>
                    <P>We summarize the public comments we received on this topic and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Although many stakeholders supported the concept of this proposal, there were strong exceptions. Many commenters, particularly payers, indicated that it was premature for CMS to finalize a proposal related to trusted exchange network participation before the first version of the Common Agreement under ONC's TEFCA was finalized. Commenters noted that, even though they supported using a trusted exchange network, it would not be advisable until after TEFCA as outlined in section 4003 of the 21st Century Cures Act was available to facilitate this proposal.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate that although commenters supported the general concept of trusted exchange network participation and how it could advance interoperability and data exchange, the true value of this concept might be best realized via TEFCA in the future. We agree that trusted exchange networks can play a positive role, but given the concerns commenters raised regarding the need for a mature TEFCA, and appreciating the ongoing work on TEFCA being done at this time, we are not finalizing this policy at this time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters noted that more detail would be needed to understand how this proposal would be operationalized. These commenters also indicated more information would be needed to understand how this policy would relate to existing Health Information Exchanges (HIEs) and Health Information Networks (HINs) and whether these entities would qualify as trusted exchange networks. A few commenters indicated this policy may be redundant appreciating the existing role of HIEs and HINs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and requests for 
                        <PRTPAGE P="25570"/>
                        additional information. We will keep these in mind as we consider possible future proposals around participation in trusted exchange networks.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed concerns with the proposed implementation timeline. They did not believe this policy could be implemented by January 1, 2020. Commenters indicated it would take more time to meet the necessary requirements and fully understand the implications of the policy, particularly for HIEs and HINs. Many commenters suggested a delay ranging from 12 to 24 months. Other commenters suggested CMS align the timeline of this proposal with TEFCA implementation milestones. In addition to a delay, some commenters suggested an exemption process.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters concerns, and based on these concerns and those summarized from other commenters, we are not finalizing this proposal at this time. To reflect this in this final rule, the regulation text proposed for all impacted payers is not being finalized. In addition, as 42 CFR 438.242(b)(5) is not being finalized, the regulation text proposed at 42 CFR 438.242(b)(6) is being redesignated as 42 CFR 438.242(b)(5).
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our response to these comments, we are not finalizing this proposal to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in a trusted exchange network.
                    </P>
                    <HD SOURCE="HD1">VII. Improving the Medicare-Medicaid Dually Eligible Experience by Increasing the Frequency of Federal-State Data Exchanges Provisions, and Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Increasing the Frequency of Federal-State Data Exchanges for Dually Eligible Individuals</HD>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>The Medicare and Medicaid programs were originally created as distinct programs with different purposes. The programs have different rules for eligibility, covered benefits, and payment. The programs have operated as separate and distinct systems despite a growing number of people who depend on both programs (known as dually eligible individuals) for their health care. There is an increasing need to align these programs—and the data and systems that support them—to improve care delivery and the beneficiary experience for dually eligible individuals, while reducing administrative burden for providers, health plans, and states. The interoperability of state and CMS eligibility and Medicaid Management Information System (MMIS) systems is a critical part of modernizing the programs and improving beneficiary and provider experiences. Improving the accuracy of data on dual eligibility by increasing the frequency of federal-state data exchanges is a strong first step in improving how these systems work together.</P>
                    <HD SOURCE="HD3">2. Data Exchanges To Support State Buy-In for Medicare Parts A and B</HD>
                    <P>States and CMS routinely exchange data on who is enrolled in Medicare and Medicaid, and which parties are liable for paying that beneficiary's Parts A and B premiums. These data exchanges support state, CMS, and Social Security Administration (SSA) premium accounting, collections, and enrollment functions. Section 1843 of the Act permits states to enter into an agreement with the Secretary to facilitate state “buy-in,” that is, payment of Medicare premiums, in this case Part B premiums, on behalf of certain individuals. For those beneficiaries covered under the agreement, the state pays the beneficiary's monthly Part B premium. Section 1818(g) of the Act establishes the option for states to amend their buy-in agreement to include enrollment and payment of the Part A premium for certain specified individuals. All states and the District of Columbia have a Part B buy-in agreement; 36 states and the District of Columbia have a Part A buy-in agreement.</P>
                    <P>To effectuate the state payment of Medicare Part A or Part B premiums, a state submits data on a buy-in file to CMS via an electronic file transfer (EFT) exchange setup. The state's input file includes a record for each Medicare beneficiary for whom the state is adding or deleting coverage, or changing buy-in status. In response, CMS returns an updated transaction record that provides data identifying, for each transaction on the state file, whether CMS accepted, modified, or rejected it, as well a Part A or Part B billing record showing the state's premium responsibility. In addition, the CMS file may “push” new updates obtained from SSA to the state, for example, changes to the Medicare Beneficiary Identifier number or a change of address.</P>
                    <P>
                        We have issued regulations for certain details of the state buy-in processes. For Medicare Part A, 42 CFR 407.40 describes the option for states to amend the buy-in agreement to cover Part A premiums for Qualified Medicare Beneficiaries (QMBs). For Medicare Part B, 42 CFR 406.26 codifies the process for modifying the buy-in agreement to identify the eligibility groups covered. CMS subregulatory guidance, specifically Chapter 3 of the State Buy-in Manual,
                        <SU>49</SU>
                        <FTREF/>
                         specifies that states should exchange buy-in data with CMS at least monthly, but describes the option for states to exchange buy-in data with CMS daily or weekly. Likewise, states can choose to receive the CMS response data file daily or monthly. We note that 35 states and the District of Columbia are now submitting buy-in data to CMS daily; 31 states and the District of Columbia are now receiving buy-in response files from CMS daily.
                    </P>
                    <FTNT>
                        <P>
                            <SU>49</SU>
                             Centers for Medicare and Medicaid Services. (2003). State Buy-In Manual: Chapter 3—Data Exchange. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/downloads/buyin_c03.pdf.</E>
                             (Last accessed June 24, 2019).
                        </P>
                    </FTNT>
                    <P>While many states submit and receive buy-in files daily, some continue to only do so on a monthly basis. We have become increasingly concerned about the limitations of monthly buy-in data exchanges with states. The relatively long lag in updating buy-in data means that the state is not able to terminate or activate buy-in coverage sooner, so the state or beneficiary may be paying premiums for longer than appropriate. In most cases, funds must be recouped and redistributed—a burdensome administrative process involving debits and payments between the beneficiary, state, CMS, and SSA. Additionally, transaction errors do occur in the current data exchange processes. In a monthly exchange, it can take multiple months to correct and resubmit an improperly processed transaction, exacerbating the delays in appropriately assigning premium liability, leading to larger mispayment, recoupment, and redistribution of premiums. Exchanging the buy-in data with greater frequency supports more timely access to coverage.</P>
                    <P>
                        All states' systems already have the capacity to exchange buy-in data. We acknowledge that states that do not already exchange data daily will need an initial, one-time systems change to do so. However, moving to a daily data exchange would result in a net reduction of burden for states, and further, reduce administrative complexity for beneficiaries and providers. More frequent submission of updates to individuals' buy-in status positively impacts all involved. For a full discussion of the benefits, see the CMS Interoperability and Patient Access 
                        <PRTPAGE P="25571"/>
                        proposed rule (84 FR 7643 through 7644).
                    </P>
                    <P>While there exist opportunities to modernize the platform for buy-in data exchange, we believe that an important first step is to promote the exchange of the most current available data. Section 1843(f) of the Act specifies that Part B buy-in agreements shall contain such provisions as will facilitate the financial transactions of the State and the carrier with respect to deductions, coinsurance, and otherwise, and as will lead to economy and efficiency of operation. Further, section 1818(g)(2)(A) of the Act on Part A buy-in identifies this section 1843(f) requirement as applicable to Part A buy-in. While the regulations governing buy-in agreements (see 42 CFR 406.26 and 407.40) are silent on the frequency of buy-in data exchanges, current guidance articulates that the required buy-in data may be submitted daily, weekly, or monthly. Therefore, we proposed to establish frequency requirements in the regulations at 42 CFR 406.26(a)(1) and 407.40(c) to require all states to participate in daily exchange of buy-in data with CMS, with “daily” meaning every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. We noted that we believe these requirements will improve the economy and efficiency of operation of the buy-in process. We proposed that states would be required to begin participating in daily exchange of buy-in data with CMS by April 1, 2022. We noted that we believe this applicability date would allow states to phase in any necessary operational changes or bundle them with any new systems implementation. In the CMS Interoperability and Patient Access proposed rule, we estimated that 19 states would need to make a system change to send buy-in data to CMS daily and 22 states would need to make a system change to receive buy-in data from CMS daily (84 FR 7668). Based on more recent data, we estimate that 26 and 19 states would require such system changes, respectively. We updated our estimates to determine the one-time cost to be $85,000 per state, per change, so a state that needs to make systems updates to both send buy-in data daily, and receive buy-in data daily would have a one-time cost of just over $170,000. We sought comment on the proposals.</P>
                    <P>We summarize the public comments we received on data exchanges to support state buy-in for Medicare Parts A and B and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Almost all those who commented on these provisions supported the proposal to require that all states participate in daily exchange of buy-in data with CMS by April 1, 2022. Commenters stated that the changes would improve the timeliness and accuracy of eligibility and enrollment data, and enhance capability for coordination of benefits.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the strong support for the proposed change to the regulation.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter supported the change, but also encouraged CMS to modify its own processes and systems to effectively leverage daily data exchanges to support enhanced care for dually eligible individuals. Another commenter requested clarification if the daily state submission of the buy-in file encompasses a reciprocal daily response from CMS to the states.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree that CMS and states both play important roles in implementing systems changes to support the state buy-in process. Currently, states can choose to exchange buy-in data with CMS daily, weekly, or monthly; and separately, they can choose to 
                        <E T="03">receive</E>
                         the CMS response data file daily, weekly, or monthly. We proposed that all states both send data to CMS and receive responses from CMS on a daily basis. We will continue to look for opportunities to optimize CMS systems and processes to support better care for dually eligible individuals.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter supported requiring frequent exchanges of this data as a way to eliminate current inefficiencies and improve benefit coordination for the dually eligible population so long as this requirement does not impose additional reporting requirements on clinicians.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the support for our proposal. We confirm that the regulation as proposed does not create additional reporting requirements on clinicians. As noted in the preamble to the CMS Interoperability and Patient Access proposed rule, we estimate that the change to a daily submission would result in a net reduction of burden for states, and further, reduce administrative complexity for beneficiaries and providers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter noted that the proposed applicability date of April 1, 2022 will be sufficient for this change, but for overall unity in the rule's proposed changes, encouraged CMS to consider aligning the applicability date of this proposal with an overall extended implementation time frame of at least 2 years—and ideally 5 years—for the remainder of the rule's provisions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the value in aligned implementation timelines. However, given that other provisions in this rule for health plans and states are distinct from this requirement, and will be required beginning in 2020, we continue to believe that the April 1, 2022 implementation timeline proposed for daily exchange of buy-in data is appropriate.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters recommended that CMS establish a process for states to provide Medicare dual eligible special needs plans (D-SNPs) with, at a minimum, data on beneficiaries' Medicaid coverage. Commenters requested CMS align the eligibility and enrollment information that health plans receive with the information being shared between states and the federal government so there is a single “source of truth” on these data. Commenters noted this consistency is critical to improving care coordination for dually eligible individuals.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         D-SNPs have an important role in supporting their enrollees' access to Medicaid benefits. We understand that in many states D-SNPs have limited access to timely data on Medicaid enrollment. We note that we do provide data to D-SNPs and other MA plans on the Medicaid status of their members. While we appreciate the value of D-SNPs getting additional Medicaid coverage data such as Medicaid plan enrollment, we decline to modify the regulations to require states to do so as it is beyond the scope of this proposal. However, we continue to explore opportunities to provide plans with data that would assist them in better coordinating benefits and coverage for their dually eligible enrollees.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter noted that the CMS Interoperability and Patient Access proposed rule does not require states to input the latest eligibility data in a specific timeframe on their claims platforms. The commenter noted that not having this clarity means that there could be a potential for inconsistent data. The commenter recommended that CMS require state Medicaid programs to update their claims platforms daily to assist with accurate data exchanges.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the point the commenter is making. Our proposal did not explicitly address how states incorporate eligibility data with claims and other systems. We will consider this recommendation for the future as we gain additional experience with daily data exchange.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Two commenters stated that daily exchange of buy-in data would require significant systems changes and costs. One of these commenters recommended that CMS revise the proposal to update the frequency of exchange from monthly to 
                        <PRTPAGE P="25572"/>
                        weekly, rather than daily. The commenter noted that it would seldom have new information to send on a daily basis, but that determining on a daily basis whether there was any new information to send would be a large effort. Finally, the commenter requested if CMS finalized the regulation to require daily updates, that provisions be made for states whose systems cycles are other than within a calendar day, for example, 6 p.m. to 6 a.m.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the costs that the state may bear to make the systems changes necessary to implement these provisions. We will provide technical assistance and opportunities for shared learning through webinars and training to support states' transition.
                    </P>
                    <P>We also note that federal matching funds at the standard rate of 50 percent for administration will reduce the states' costs. States may also be eligible for enhanced 90 percent federal matching funds for the costs of developing and implementing any necessary system changes required by regulation, and enhanced 75 percent federal matching funds for their system's maintenance and operation costs. These enhanced federal matching funds would be available for their Eligibility and Enrollment (E&amp;E) systems (and, if necessary, their Medicaid Management Information System (MMIS)). States would request enhanced funding through the Advance Planning Document (APD) process.</P>
                    <P>Even though there are costs to the states in implementing daily exchange of buy-in data, other commenters uniformly supported the value of daily exchanges in improving the experience of dually eligible individuals, and in reducing burden on states, providers, and plans to reconcile payment. As a result, we decline to make the suggested change.</P>
                    <P>With respect to the point that there would often not be updates on a daily basis, we reiterate that no file would be required on business days where there were no updates. We expect that states would be able to automate their systems so that they check daily for changes to buy-in status that would need to be submitted to CMS on the buy-in file, but also automate a process by which the system only generates a buy-in file upon identifying such a change. We appreciate the additional coding required to implement this logic but expect that once implemented, no additional interventions would be needed. We will work with states that have implemented these changes to identify and share best practices in identifying data changes to trigger daily submissions.</P>
                    <P>Finally, in response to the concern about whether states that have an overnight processing cycle would be permitted to continue doing so, we affirm that the proposed regulation would permit this.</P>
                    <P>After consideration of the public comments and for the reasons articulated in the CMS Interoperability and Patient Access proposed rule and our responses to comments, we are finalizing changes to 42 CFR 406.26 and 407.40 as proposed.</P>
                    <HD SOURCE="HD3">3. Exchange of State MMA Data Files</HD>
                    <P>States submit data on files at least monthly to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible individuals (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The file is called the “MMA file,” but is occasionally referred to as the “State Phasedown file.” The MMA file was originally developed to meet the need to timely identify dually eligible individuals for the then-new Medicare Part D prescription drug benefit. The Medicare Modernization Act (MMA) established that, beginning January 1, 2006, Medicare would be primarily responsible for prescription drug coverage for full-benefit dually eligible individuals; established auto-enrollment of full-benefit dually eligible individuals into Medicare prescription drug plans (with regulations further establishing facilitated enrollment into prescription drug plans for partial-benefit dually eligible individuals), provided that dually eligible individuals are treated as eligible for the Medicare Part D Low Income Subsidy (LIS), sometimes called Extra Help; defined phased down state contributions to partly finance Part D costs for dually eligible individuals; and required risk-adjusting capitation payments for LIS (which include dually eligible) enrollees of Part D plans. To support these new requirements, we issued 42 CFR 423.910, establishing monthly reporting by states, in which states would submit, at least monthly, a data file identifying dually eligible individuals in their state. Over time, we used these files' data on dual eligibility status to support Part C capitation risk-adjustment, and most recently, to feed dual eligibility status to Part A and B eligibility and claims processing systems so providers, suppliers, and individuals have accurate information on beneficiary cost-sharing obligations.</P>
                    <P>Currently, regulations require states to submit at least one MMA file each month. However, states have the option to submit multiple MMA files throughout the month (up to one per day). Most states submit MMA data files at least weekly. In the CMS Interoperability and Patient Access proposed rule, we estimated that 37 states and DC would need to make a system change to send MMA data to CMS daily (84 FR 7668). Based on more recent data, we estimate that 36 states and DC would require such system changes. As CMS now leverages MMA data on dual eligibility status into systems supporting all four parts of the Medicare program, it is becoming even more essential that dual eligibility status is accurate and up-to-date. Dual eligibility status can change at any time in a month. Waiting up to a month for status updates can negatively impact access to the correct level of benefit at the correct level of payment. Based on our experience with states that exchange data daily, more frequent MMA file submissions benefit states, individuals, and providers, in a number of ways. For a full discussion of the benefits, see the CMS Interoperability and Patient Access proposed rule (84 FR 7644).</P>
                    <P>
                        As noted, current regulation requires that each state submit an MMA file at least monthly. We have implemented “work-arounds” for lags in dual eligibility status for Part D, including the “Best Available Evidence” policy (see 42 CFR 423.800(d)), as well as the Limited Income Newly Eligible Transition demonstration, which provides short term drug coverage for dually eligible individuals with no Part D plan enrollment in a given month (see Medicare Prescription Drug Benefit Manual, Chapter 3, Section 40.1.4).
                        <SU>50</SU>
                        <FTREF/>
                         While these work-arounds provide needed protections, more frequent data exchanges would mitigate the need for them.
                    </P>
                    <FTNT>
                        <P>
                            <SU>50</SU>
                             Centers for Medicare and Medicaid Services. (2017). Medicare Prescription Drug Benefit Manual: Chapter 3—Eligibility, Enrollment and Disenrollment. Retrieved from 
                            <E T="03">https://www.cms.gov/Medicare/Eligibility-and-Enrollment/MedicarePresDrugEligEnrol/Downloads/CY_2018_PDP_Enrollment_and_Disenrollment_Guidance_6-15-17.pdf.</E>
                             (Last accessed June 24, 2019).
                        </P>
                    </FTNT>
                    <P>
                        Ensuring information on dual eligibility status is accurate and up-to-date by increasing the frequency of federal-state data exchange is an important step in the path to interoperability. As a result, we proposed to update the frequency requirements in 42 CFR 423.910(d) to require that, starting April 1, 2022, all states submit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every 
                        <PRTPAGE P="25573"/>
                        business day, but that if no new transactions are available to transmit, states would not need to submit data on a given business day. We proposed requiring that states begin submitting these data daily to CMS by April 1, 2022 because we believed this applicability date would allow states to phase in any necessary operational changes or bundle them with any new systems implementation. We estimated an updated one-time cost for a state to be $85,000 for this MMA data systems change. For a detailed discussion of the costs associated with these requirements, we refer readers to section XVI. of the CMS Interoperability and Patient Access proposed rule (84 FR 7660 through 7673), as well as section XVI of this final rule. We sought comment on these proposals.
                    </P>
                    <P>We summarize the public comments we received on exchange of state MMA data files and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Almost all those who commented on this provision supported the proposal to require all states to participate in daily submission of MMA file data with CMS by April 1, 2022. Commenters noted that the changes would improve the timeliness and accuracy of eligibility and enrollment data, enhance coordination of benefits, and support greater integration of care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the strong support for the proposed change to the regulation.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter supported the proposed change, but requested CMS consider standardizing which file types and data sets will be acceptable to support standardized daily submissions, for the overall purpose of improving the state and CMS data exchanges.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We understand the suggestion that we standardize which upstream data sets (for example, CMS finder files, state eligibility data) states should use to support daily MMA file submissions. To that end, we will provide technical assistance to states that need to make changes to submit the file daily. As part of that effort, we will work with states that already submit MMA files daily to understand and share information on best practices on the upstream data sets necessary to implement daily MMA file submissions.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter noted that the proposed applicability date of April 1, 2022 will be sufficient for this change, but for overall unity in the rule's proposed changes, encouraged CMS to consider aligning the effective date of this proposal with an overall extended implementation time frame of at least 2 years—and ideally 5 years—for the remainder of the rule's provisions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the value in aligned implementation timelines. However, given that other provisions in this rule for health plans and states are distinct from this requirement, and will be required beginning in 2020, we continue to believe that the April 1, 2022 implementation timeline proposed for daily MMA file submissions is appropriate.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters noted the value of the data in the MMA file to Medicaid managed care organizations (MCO), Medicare dual eligible special needs plans (D-SNPs), Health Information Exchanges, and providers for the purposes of coordinating enrollment, benefits, and/or care for dually eligible individuals. These commenters requested access to the daily MMA file. One commenter noted that some states are sharing Medicare plan enrolment data from these files with their Medicaid MCOs while also providing batch inquiry data sharing mechanisms to D-SNPs on Medicaid plan enrollment. This commenter recommended that CMS encourage or require all states to follow this process at a minimum.
                    </P>
                    <P>Commenters also encouraged CMS to leverage the MMA file to support parties complying with the D-SNP integration standards recently issued in 42 CFR 422.2.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate these suggestions to promote access to data for plans and providers serving dually eligible individuals, and we will explore these ideas further for potential future consideration. However, we decline to modify the regulation as suggested, as the recommended changes are beyond the scope of the proposal, which is limited to the frequency of the file exchange.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters made additional suggestions for streamlining data exchanges. In addition to making the MMA files accessible to plans and providers, some commenters recommended adding Medicaid plan enrollment information to MMA files to create a single source of Medicare-Medicaid enrollment data for dually eligible individuals. Another commenter suggested a potential pathway to streamlining data exchanges would be for CMS to allow state Transformed Medicaid Statistical Information System (T-MSIS) files to serve as the beneficiary data source for third-party applications.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the value of streamlining data exchanges, including access to a consistent data source on eligibility and enrollment. We also acknowledge the overlap of certain data exchanged in the MMA and T-MSIS file, though we note we would need to carefully explore the implications and impacts of merging operational data exchanges such as the MMA file—which result in changes to an individual's Medicare benefit—with informational exchanges such as T-MSIS. We will consider exploring these opportunities further for potential future consideration. However, we decline to modify the regulation as suggested, as the recommended changes are beyond the scope of the proposal, which is limited to the frequency of the file exchange.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters noted significant system changes and cost to update the frequency of exchanging MMA files to daily. One commenter stated that they believe HHS has underestimated the cost to upgrade the MMA system to support daily exchange. The commenter encouraged CMS to provide an updated estimate for the costs to upgrade the system that include additional operational costs. This commenter and others encouraged CMS to consider providing additional funding to state Medicaid programs that will need to upgrade their data systems. One commenter questioned if CMS would consider increasing the FMAP states receive for interoperability activities that support dual eligible plans integrations and in particular, for programmatic or systems changes to come into compliance with D-SNP integration. The commenter noted that this increase could exceed existing enhanced matches, for example allowing the 90 percent match to apply for ongoing systems operations that facilitate care coordination.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the input on the level of effort needed to submit the MMA file daily. As noted elsewhere, we will provide technical assistance and opportunities for shared learning through webinars and training to support states' transition. We also note that federal matching funds of 50 percent for administration will reduce the states' costs. States may also be eligible for enhanced 90 percent federal matching funds for the costs of developing and implementing any necessary system changes required by regulation, and enhanced 75 percent federal matching funds for their system's maintenance and operation costs. These enhanced federal matching funds would be available for their Eligibility and Enrollment systems (and, if necessary, their Medicaid Management Information System (MMIS)). States would request enhanced funding through the Advance Planning Document (APD) process.
                        <PRTPAGE P="25574"/>
                    </P>
                    <P>As commenters did not provide specific information on the costs in excess of our assessment, we find that we have no basis to make a reasonable adjustment. As such, we are maintaining our estimate of the number of hours required, as detailed in sections XII. and XIII. of this final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter opposed increasing states submission of the MMA file from monthly to daily, recommending instead that the frequency be increased to weekly. The commenter stated that determining on a daily basis whether there was any new information to send would be a significant effort, as multiple upstream systems may have to be changed, and further, that there would seldom be new data to send on a daily basis. The commenter requested that if CMS finalized the regulation to require daily exchanges that states be permitted to continue to existing processing cycles that cross business, for example, run overnight between 6:00 p.m. to 6:00 a.m.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We acknowledge the commenter's concerns about resources, but note that other commenters—even those who echoed concerns about resources—uniformly supported the value of daily exchanges in improving the experience of dually eligible individuals and the ability of providers and plans to coordinate eligibility, enrollment, benefits, and/or care for this population. As we note above, we are committed to providing technical assistance and federal matching funds to support needed systems changes at the state. As a result, we decline to make the recommended change.
                    </P>
                    <P>With respect to the point that there would not be updates on a daily basis, we reiterate that no file would be required on business days when there were no updates. We expect that states would be able to automate their systems so that they check daily for changes to data that would need to be submitted to CMS on the MMA file, but also automate a process by which the system only generates an MMA file upon identifying such a change. We appreciate the additional coding required to implement this logic but that that once implemented, no additional interventions would be needed. We will work with states that have implemented these changes to identify and share best practices in identifying data changes to trigger daily submissions.</P>
                    <P>Finally, in response to the concern about states that have an overnight processing cycle to continue so to meet the definition of “daily,” the proposed regulation would permit this.</P>
                    <P>After consideration of the public comments and for the reasons articulated in the CMS Interoperability and Patient Access proposed rule and our responses to comments, we are finalizing 42 CFR 423.910 as proposed.</P>
                    <HD SOURCE="HD2">B. Request for Stakeholder Input</HD>
                    <P>In addition to the proposals discussed above, we sought public comment for consideration in potential future rulemaking on how we can achieve greater interoperability of federal-state data for dually eligible individuals, including in the areas of program integrity and care coordination, coordination of benefits and crossover claims, beneficiary eligibility and enrollment, and their underlying data infrastructure. For more information on our request for comment, see the CMS Interoperability and Patient Access proposed rule (84 FR 7645). We thank commenters for their input. We will consider the information received for potential future rulemaking.</P>
                    <P>
                        <E T="03">Final Action:</E>
                         We will require all states to participate in daily exchange of buy-in data, which includes both sending data to CMS and receiving responses from CMS daily, and require all states submit the required MMA file data to CMS daily by April 1, 2022. These policies are being finalized in 42 CFR 406.26, 407.40, and 423.910, respectively, as proposed. These requirements will improve the experience of dually eligible individuals and the ability of providers and payers to coordinate eligibility, enrollment, benefits, and/or care for this population. Federal matching funds of 50 percent for administration are available to support states' costs. States may also be eligible for enhanced 90 percent federal matching funds for the costs of developing and implementing any necessary system changes required by this regulation, and enhanced 75 percent federal matching funds for their system's maintenance and operation costs. CMS will provide technical assistance to the states that need to make changes to submit their files daily, including best practices on the upstream data sets necessary to implement daily MMA file submissions.
                    </P>
                    <HD SOURCE="HD1">VIII. Information Blocking Background and Public Reporting Provisions, and Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Information Blocking Background</HD>
                    <HD SOURCE="HD3">1. Legislative Background and Policy Considerations</HD>
                    <P>
                        The nature and extent of information blocking has come into focus in recent years. In 2015, at the request of the Congress, ONC submitted a Report on Health Information Blocking 
                        <SU>51</SU>
                        <FTREF/>
                         (hereinafter referred to as the “Information Blocking Congressional Report”), in which ONC commented on the then current state of technology, health IT, and health care markets. Notably, ONC observed that prevailing market conditions create incentives for some individuals and entities to exercise their control over electronic health information in ways that limit its availability and use. Since that time, ONC and other divisions of HHS have continued to receive feedback from patients, clinicians, health care executives, payers, app developers and other technology companies, registries and health information exchanges, professional and trade associations, and many other stakeholders regarding practices which may constitute information blocking. Despite significant public and private sector efforts to improve interoperability and data liquidity, engagement with stakeholders confirms that adverse incentives remain and continue to undermine progress toward a more connected health system.
                    </P>
                    <FTNT>
                        <P>
                            <SU>51</SU>
                             Office of the National Coordinator. (2015, April 9). Report to Congress on Health Information Blocking. Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf.</E>
                        </P>
                    </FTNT>
                    <P>Based on these economic realities and first-hand experience working with the health IT industry and stakeholders, ONC concluded in the Information Blocking Congressional Report that information blocking is a serious problem and recommended that the Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices.</P>
                    <P>
                        MACRA became law in the same month that the Information Blocking Congressional Report was published. Section 106(b)(2)(A) of MACRA amended section 1848(o)(2)(A)(ii) of the Act to require that an eligible professional must demonstrate that he or she has not knowingly and willfully taken action (such as to disable functionality) to limit or restrict the compatibility or interoperability of certified EHR technology, as part of being a meaningful EHR user. Section 106(b)(2)(B) of MACRA made corresponding amendments to section 1886(n)(3)(A)(ii) of the Act for eligible hospitals and, by extension, under section 1814(l)(3) of the Act for CAHs. Sections 106(b)(2)(A) and (B) of MACRA provide that the manner of this demonstration is to be through a process specified by the Secretary, such as the use of an attestation. To implement these provisions, as discussed further 
                        <PRTPAGE P="25575"/>
                        below, we established and codified attestation requirements to support the prevention of information blocking, which consist of three statements containing specific representations about a health care provider's implementation and use of CEHRT. To review our discussion of these requirements, we refer readers to the CY 2017 Quality Payment Program final rule (81 FR 77028 through 77035).
                    </P>
                    <P>Recent empirical and economic research further underscores the complexity of the information blocking problem and its harmful effects. For a full discussion of the research, see the CMS Interoperability and Patient Access proposed rule (84 FR 7645 through 7646).</P>
                    <P>In December 2016, section 4004 of the Cures Act added section 3022 of the PHSA (the “PHSA information blocking provision”), which defines conduct by health care providers, health IT developers, and health information exchanges and networks that constitutes information blocking. The PHSA information blocking provision was enacted in response to ongoing concerns that some individuals and entities are engaging in practices that unreasonably limit the availability and use of electronic health information for authorized and permitted purposes (see the definition of electronic health information proposed by ONC for HHS adoption at 45 CFR 171.102 (84 FR 7588)). These practices undermine public and private sector investments in the nation's health IT infrastructure and frustrate efforts to use modern technologies to improve health care quality and efficiency, accelerate research and innovation, and provide greater value and choice to health care consumers.</P>
                    <P>The information blocking provision defines and creates possible penalties and disincentives for information blocking in broad terms, working to deter the entire spectrum of practices likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information. The PHSA information blocking provision applies to health care providers, health IT developers, exchanges, and networks. The information blocking provision also provides that the “Secretary, through rulemaking, shall identify reasonable and necessary activities that do not constitute information blocking for purposes of the definition at section 3022(a)(1) of the PHSA.” ONC's 21st Century Cures Act proposed rule proposed “exceptions” to the information blocking provision. These exceptions are reasonable and necessary activities that would not constitute information blocking. In addition to the attestation discussed in this section, all health care providers would also be subject to the separate information blocking regulations proposed by ONC for HHS adoption at 45 CFR part 171 (84 FR 7601 through 7605).</P>
                    <HD SOURCE="HD1">B. Public Reporting and Prevention of Information Blocking on Physician Compare</HD>
                    <P>
                        Physician Compare (
                        <E T="03">http://www.medicare.gov/physiciancompare</E>
                        ) draws its operating authority from section 10331(a)(1) of the Affordable Care Act. Consistent with section 10331(a)(2) of the Affordable Care Act, Physician Compare initiated a phased approach to publicly reporting performance scores that provide comparable information on quality and patient experience measures. A complete history of public reporting on Physician Compare is detailed in the CY 2016 Physician Fee Schedule (PFS) final rule with comment period (80 FR 71117 through 71122). More information about Physician Compare, including the history of public reporting and regular updates about what information is currently available, can also be accessed on the Physician Compare Initiative website at 
                        <E T="03">https://www.cms.gov/medicare/quality-initiatives-patient-assessment-instruments/physician-compare-initiative/.</E>
                    </P>
                    <P>As discussed in the CY 2018 Quality Payment Program final rule (82 FR 53820), Physician Compare has continued to pursue a phased approach to public reporting under MACRA in accordance with section 1848(q)(9) of the Act. For a discussion of public reporting on Physician Compare, see the CMS Interoperability and Patient Access proposed rule (84 FR 7646 through 7647).</P>
                    <P>Building upon the continuation of our phased approach to public reporting and understanding the importance of preventing information blocking, promoting interoperability, and the sharing of information, we proposed to make certain data about the attestation statements on the prevention of information blocking referenced in the CMS Interoperability and Patient Access proposed rule (84 FR 7645) available for public reporting on Physician Compare, drawing upon our authority under section 10331(a)(2) of Affordable Care Act, which required us to make publicly available on Physician Compare information on physician performance that provides comparable information for the public on quality and patient experience measures. Section 10331(a)(2) of the Affordable Care Act provided that to the extent scientifically sound measures that are developed consistent with the requirements of section 10331 of the Affordable Care Act are available, such information shall include, to the extent practicable, an assessment of the coordination of care and other information as determined appropriate by the Secretary. We noted our belief that section 10331(a)(2) of the Affordable Care Act provided the statutory authority to publicly report certain data about the prevention of information blocking attestation statements as an assessment of care coordination and as other information determined appropriate by the Secretary. Furthermore, the prevention of information blocking attestation statements are required for a clinician to earn a Promoting Interoperability performance category score, which is then incorporated into the final score for MIPS, and we are required to publicly report both of these scores under section 1848(q)(9)(A) of the Act. Publicly posting this information as an indicator is consistent with our finalized policy to publicly report, either on the profile pages or in the downloadable database, other aspects of the Promoting Interoperability performance category, such as objectives, activities, or measures specified in the CY 2018 Quality Payment Program final rule (82 FR 53826 through 53827). We note that we finalized at 42 CFR 414.1395(b), that, with the exception of data that must be mandatorily reported on Physician Compare, for each program year, we rely on the established public reporting standards to guide the information available for inclusion on Physician Compare. The public reporting standards require data included on Physician Compare to be statistically valid, reliable, and accurate; be comparable across submission mechanisms; and, meet the reliability threshold. To be included on the public facing profile pages, the data must also resonate with website users, as determined by CMS.</P>
                    <P>
                        There are three prevention of information blocking attestation statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C) to which eligible clinicians reporting on the Promoting Interoperability performance category of MIPS must attest. To report successfully on the Promoting Interoperability performance category, in addition to satisfying other requirements, an eligible clinician must submit an attestation response of “yes” for each of these statements. For more information about these statements, we refer readers to the preamble discussion 
                        <PRTPAGE P="25576"/>
                        in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 81 FR 77035).
                    </P>
                    <P>The Promoting Interoperability performance category weight comprises 25 percent of a MIPS eligible clinician's final score for each MIPS payment year, as specified at 42 CFR 414.1375(a). As specified at 42 CFR 414.1405(b)(2), MIPS eligible clinicians with a final score below the performance threshold receive a negative MIPS payment adjustment factor on a linear sliding scale. Certain MIPS eligible clinicians who submit data for the Promoting Interoperability performance category may be eligible for reweighting, as specified under 42 CFR 414.1380(c)(2). As specified at 42 CFR 414.1405(a), (b)(1), and (b)(2), MIPS eligible clinicians may receive a positive, neutral, or negative MIPS payment adjustment factor. As specified at 42 CFR 414.1405(c), the applicable percent for MIPS payment year 2021 is 7 percent. For MIPS payment year 2022, and each subsequent MIPS payment year, it is 9 percent. For more information about the MIPS, we refer readers to the preamble discussion in the CY 2020 Quality Payment Program final rule (84 FR 62946 through 63083).</P>
                    <P>
                        We noted our belief that it would benefit the public to know if eligible clinicians have attested negatively to the statements under 42 CFR 414.1375(b)(3)(ii) as this may assist the patient in selecting a clinician or group who collaborates with other clinicians, groups, or other types of health care providers by sharing information electronically, and does not withhold information that may result in better care. Therefore, we proposed to include an indicator on Physician Compare for the eligible clinicians and groups that submit a “no” response to any of the three statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C). In the event that these statements are left blank, that is, a “yes” or a “no” response is not submitted, the attestations would be considered incomplete, and we would not include an indicator on Physician Compare. We also proposed to post this indicator on Physician Compare, either on the profile pages or the downloadable database, as feasible and appropriate, starting with the 2019 performance period data available for public reporting starting in late 2020. We refer readers to the 2019 Promoting Interoperability Information Blocking Factsheet at 
                        <E T="03">https://qpp-cm-prod-content.s3.amazonaws.com/uploads/282/2019%20PI%20Information%20Blocking%20Fact%20Sheet.pdf</E>
                         for more information about the attestation statements.
                    </P>
                    <P>
                        Under 42 CFR 414.1395(b), these data must meet our established public reporting standards, including that to be included on the public facing profile pages, the data must resonate with website users, as determined by CMS. In previous testing with patients and caregivers, we learned that effective use of CEHRT is important to them when making informed health care decisions. For more information about previous testing with patients and caregivers, we refer readers to the Physician Compare Technical Expert Panel (TEP) Summary Report at 
                        <E T="03">https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/physician-compare-initiative/Downloads/Physician-Compare-TEP-Summary-2018.pdf.</E>
                         To determine how to best display and meaningfully communicate the indicator on the Physician Compare website, the exact wording and, if applicable, profile page indicator would be determined after user testing and shared with stakeholders through the Physician Compare Initiative page, listservs, webinars, and other available communication channels. We noted that the proposal was contingent upon the availability of and technical feasibility to use the data for public reporting.
                    </P>
                    <P>We summarize the public comments we received on this topic and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Most commenters supported our proposal to publicly report an indicator on the Physician Compare website for the eligible clinicians and groups that submit a “no” response to any of the three prevention of information blocking attestation statements, noting that the indicator would discourage clinicians and groups from information blocking and help Medicare patients and caregivers make informed health care decisions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support and agree that publicly reporting an indicator on Physician Compare will discourage clinicians and groups from information blocking and help Medicare patients and caregivers make informed decisions.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters expressed concern for various reasons about publicly reporting an indicator on the Physician Compare website for the eligible clinicians and groups that submit a “no” response to any of the three prevention of information blocking attestation statements. Several of these commenters thought the indicator would be redundant, since there is already an incentive for clinicians to attest to the prevention of information blocking statements in order to earn a MIPS Promoting Interoperability performance category score. Some commenters were concerned that an indicator may not accurately reflect whether a clinician or group is knowingly or willfully information blocking, since they may be confused about the attestation statements' meanings. A few commenters suggested delaying Physician Compare's indicator implementation in order to give clinicians and groups, particularly small and rural practices, time to become more familiar with the attestations. Other commenters expressed concern as to whether Medicare patients and caregivers would find the indicator useful; one of these commenters suggested conducting a pilot study to make such a determination. Finally, several commenters suggested an appeal process or an opportunity for clinicians and groups to review their information prior to public reporting.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We believe publicly reporting an indicator on Physician Compare for the eligible clinicians and groups that submit a “no” response to any of the three prevention of information blocking attestation statements is not redundant, as Medicare patients and caregivers do not currently have access to this type of information, which could aid them in making informed health care decisions.
                    </P>
                    <P>
                        Regarding concerns about clinicians, including small and rural practices, needing time to become familiar with the attestations, we believe there has been sufficient time for clinicians to become familiar with them, since these attestation statements have been a MIPS Promoting Interoperability performance category requirement since the 2017 performance period. We also believe that webinars and educational materials that CMS has made available have provided clinicians and groups an opportunity to become familiar with the information blocking attestation statements. We will also continue to support small and rural practices by offering free and customized resources available within local communities, including direct, one-on-one support from the Small, Underserved, and Rural Support Initiative along with our other no-cost technical assistance (83 FR 59720). Regarding whether an information blocking indicator would be meaningful to patients and caregivers, we note that under 42 CFR 414.1395(b), these data must meet our established public reporting standards, including that to be posted on public facing profile pages, the data must resonate with website users, as determined by CMS. Such user testing to date has shown that 
                        <PRTPAGE P="25577"/>
                        effective CEHRT usage is important to patients when making health care decisions. In addition, as specified at 42 CFR 414.1375(b)(3)(ii), MIPS eligible clinicians must attest to the prevention of information blocking statements. For more information about these statements, we refer readers to the preamble discussion in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 81 FR 77035). In addition, we note that section 4004 of the Cures Act added section 3022 of the PHSA, which directs HHS to identify reasonable and necessary activities conducted by health care providers, health IT developers, and health information exchanges and networks that would not constitute information blocking as defined in section 3022. For more information, see the information blocking discussion in ONC's 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ).
                    </P>
                    <P>While we appreciate the commenter's suggestion to conduct a pilot study, we believe that further user testing will allow us to gain the additional understanding necessary.</P>
                    <P>Regarding the comments requesting an opportunity to review or an appeal process, we note that, under 42 CFR 414.1395(d), for each program year, CMS provides a 30-day preview period for any clinician or group with Quality Payment Program data before the data are publicly reported on Physician Compare. Although at this time we do not preview indicator information, clinicians and groups will be able to preview their Promoting Interoperability performance category information, including their attestation responses to the three statements during the MIPS targeted review process. All performance data publicly reported on Physician Compare will reflect the scores eligible clinicians and groups receive in their MIPS performance feedback, which will be available for review and potential correction during the targeted review process (83 FR 59912).</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters recommended additional actions to prevent information blocking, beyond publicly reporting an indicator on Physician Compare. Some commenters recommended implementing additional penalties for clinicians and groups that attest “no” to the prevention of information blocking attestations, such as corrective action. Other commenters suggested CMS offer more positive incentives. Several commenters suggested having additional indicators, such a positive one for those who attest “yes.” Another commenter recommended treating a blank response to the three attestation statements as a “no” response. A few commenters recommended that the proposed indicator not be used for clinicians and groups that participate in trusted exchange networks.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions and will consider them for potential future rulemaking, to the extent permitted by our authority. To the extent of our authority, we will consider treatment of attestation statements that are left blank, use of a positive indicator on the Physician Compare profile pages or downloadable database, and the use of the proposed indicator for clinicians and groups that participate in trusted exchange networks for potential future rulemaking.
                    </P>
                    <P>Regarding commenters' suggestions for additional penalties, we note that section 4004 of the Cures Act identifies potential penalties and disincentives for information blocking. Health care providers determined by the Inspector General to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable federal law, as the Secretary sets forth through notice and comment rulemaking. In the ONC 21st Century Cures Act proposed rule, a request for information regarding disincentives for health care providers was included (84 FR 7553).</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters requested additional information on the proposed information blocking indicator. A few of these commenters requested additional information on the attestation requirements for clinicians and groups participating in other programs, such as Medicare Advantage. Several commenters requested additional guidance on exceptions to the attestations. Another commenter requested more information on the implications for clinicians and groups who leave the attestation statements blank and do not attest “yes” or “no.” Several commenters questioned how clinicians' responses to the three attestation statements would be verified for accuracy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The three attestation statements are required under the MIPS, which is a Medicare FFS program. We note that 42 CFR 414.1310(b) and (c) provide that Qualifying APM Participants (QPs) and Partial QPs who do not report on applicable measures and activities that are required to be reported under MIPS for any given performance period in a year are excluded from this definition at 42 CFR 414.1305 of a MIPS eligible clinician per the statutory exclusions defined in section 1848(q)(1)(C)(ii) and (v) of the Act. Therefore, the prevention of information blocking indicator would be applicable only to MIPS eligible clinicians and groups under Medicare FFS and not to other programs, such as MA. Under MIPS, the attestation statements are required for all eligible clinicians under the Promoting Interoperability performance category of MIPS, as specified at 42 CFR 414.1375(b)(3)(ii) (81 FR 77035). If the attestation statements are left blank, that is, a “yes” or “no” response is not submitted, the attestations would be considered incomplete and the clinician or group would not receive a Promoting Interoperability performance category score. In this situation, we would not have an affirmative or negative response to the three attestation statements from the clinician or group, and we would not have enough information to determine whether the clinician or group is knowingly and willfully information blocking. Regarding exceptions to the attestation requirements, under 42 CFR 414.1380(c)(2) the Promoting Interoperability performance category may be reweighted to zero percent of the final score for a MIPS eligible clinician in certain circumstances, and clinicians who receive reweighting would not have to submit data for the Promoting Interoperability performance category, including their responses to the attestation statements. Regarding verification of clinicians' attestation statements, we note that we finalized in prior rulemaking that we will perform ongoing monitoring of MIPS eligible clinicians and groups on an ongoing basis for data validation, auditing, program integrity issues, and instances of non-compliance with MIPS requirements. If a MIPS eligible clinician or group is found to have submitted inaccurate data for MIPS, we finalized that we would reopen and revise the determination in accordance with the rules set forth at 42 CFR 405.980 through 405.986 (81 FR 77362).
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our responses to these comments, we are finalizing this policy as proposed. Specifically, we are finalizing to include an indicator on Physician Compare for the eligible clinicians and groups that submit a “no” response to any of the three prevention of information blocking attestation statements for MIPS under 42 CFR 414.1375(b)(3)(ii)(A) through (C), as proposed. In the event that these statements are left blank, that is, a “yes” 
                        <PRTPAGE P="25578"/>
                        or a “no” response is not submitted, the attestations will be considered incomplete, and we will not include an indicator on Physician Compare. We will post this indicator on Physician Compare, either on the profile pages or in the downloadable database, as feasible and appropriate, starting with the 2019 performance period data available for public reporting starting in late 2020.
                    </P>
                    <HD SOURCE="HD2">C. Public Reporting and Prevention of Information Blocking for Eligible Hospitals and Critical Access Hospitals (CAHs)</HD>
                    <P>
                        Section 1886(n)(4)(B) of the Act requires the Secretary to post in an easily understandable format a list of the names and other relevant data, as determined appropriate by the Secretary, of eligible hospitals and CAHs who are meaningful EHR users under the Medicare FFS program, on a CMS website. In addition, that section requires the Secretary to ensure that an eligible hospital or CAH has the opportunity to review the other relevant data that are to be made public with respect to the eligible hospital or CAH prior to such data being made public. We noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7647) that we believed certain information related to the prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ) would constitute other relevant data under section 1886(n)(4)(B) of the Act. Specifically, we referred to the three prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ) to which eligible hospitals and CAHs must attest for purposes of the Promoting Interoperability Program. As part of successfully demonstrating that an eligible hospital or CAH is a meaningful EHR user for purposes of the Promoting Interoperability Program, the eligible hospital or CAH must submit an attestation response of “yes” for each of these statements. For more information about these statements, we referred readers to the preamble discussion in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 77035).
                    </P>
                    <P>
                        We noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7647) that we believed it would be relevant to the public to know if eligible hospitals and CAHs have attested negatively to the statements under 42 CFR 495.40(b)(2)(i)(I)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ) as it could indicate that they are knowingly and unreasonably interfering with the exchange or use of electronic health information in ways that limit its availability and use to improve health care. As we stated in the CY 2017 Quality Payment Program final rule, we believed that addressing issues related to information blocking would require additional and more comprehensive measures (81 FR 77029). In addition, publicly posting this information would reinforce our commitment to focus on increased interoperability and the appropriate exchange of health information. We proposed to post information on a CMS website available to the public indicating that an eligible hospital or CAH attesting under the Medicare FFS Promoting Interoperability Program submitted a “no” response to any of the three statements under 42 CFR 495.40(b)(2)(i)(I)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ). In the event that these statements are left blank, that is, a “yes” or a “no” response is not submitted, we proposed the attestations would be considered incomplete, and we would not post any information related to these attestation statements for that hospital or CAH. We proposed to post this information starting with the attestations for the EHR reporting period in 2019, and we expected the information would be posted in late 2020. In accordance with section 1886(n)(4)(B) of the Act, we proposed to establish a process for each eligible hospital and CAH to review the information related to their specific prevention of information blocking attestation statements before it is publicly posted on a CMS website. Specifically, for each program year, we proposed a 30-day preview period for an eligible hospital or CAH to review this information before it is publicly posted. During the 30-day preview period, we proposed that all of the information that we would publicly post would be available for the eligible hospital or CAH to review, and we would consider making changes to the information on a case-by-case basis (for example, in the event the eligible hospital or CAH identifies an error, and we subsequently determine that the information is not accurate). Additional information on the review process would be provided outside of the rulemaking process through the usual communication channels for the program.
                    </P>
                    <P>We summarize the public comments we received on this topic and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters indicated their strong support for this proposal and suggested that we finalize the proposal, as commenters believe it is necessary in building an interoperable health system. One commenter believes that maintaining accountability and enforcing penalties is critical to maintaining individual health and safety. Another commenter agreed, stating that information blocking is detrimental to the health, safety, and welfare of patients. Many commenters indicated that information blocking should not be tolerated for competitive or financial reasons, further indicating that consumers and stakeholders should be made aware of those who participate in information blocking practices, as this transparency can prevent potential medical errors and improve the overall quality of care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support for the proposal. We agree with the commenters and believe that the proposed policy would be both appropriate and effective in reinforcing our commitment to focus on increasing interoperability and the appropriate exchange of health information. Knowingly or willfully preventing, avoiding, or withholding information limits interoperability and prevents the sharing of important health information.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters indicated support for the promotion of health information exchange and the prevention of information blocking, generally, but expressed several concerns about the implementation of this proposal. A couple of commenters were concerned that there is not enough time to develop the policies and procedures needed to streamline the proposed process, and in response, suggested building in a period of non-enforcement (a practice period without posting any information publicly). Several commenters expressed concern that there will not be an opportunity to dispute information prior to publication, and requested including a guarantee of the proposed 30-day preview period prior to the publication of certain information on a CMS website. Finally, commenters had concerns about how policies related to information blocking and changes to the 2015 Edition of certified health IT proposed in ONC's 21st Century Cures Act proposed rule may impact the prevention of information blocking attestations under the Promoting Interoperability Program.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and suggestions. We are finalizing the proposal to post this information starting with the attestations for the EHR reporting period in 2019, and we are targeting for this information to be posted in late 2020. Although we will not have a period of non-enforcement (postponing posting of information publicly), we are building in a 30-day preview period during which any discrepancies or concerns may be addressed on a case-by-case 
                        <PRTPAGE P="25579"/>
                        basis prior to posting. Additional information on the preview period will be provided outside of the rulemaking process through the usual communication channels for the program. With regard to ONC's 21st Century Cures Act rule, the prevention of information blocking attestation statements under the Promoting Interoperability Program are not affected by ONC's final rule policies and remain unchanged.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A number of commenters supported the prevention of information blocking, but had concerns about the additional burden this proposal may add. One commenter requested reassurance that this process will not increase burden, while a few other commenters shared concerns that this process will increase burden.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. As eligible hospitals and CAHs are already required to respond to these three attestation statements under the Promoting Interoperability Program, we do not believe this proposal would require additional reporting effort, or thereby increase burden. We do not believe the 30-day preview period would increase burden as it will be an opportunity for eligible hospitals and CAHs to ensure the accuracy of the information that will be posted publicly, should they choose to take advantage of this opportunity.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters stated that there should be an audit or spot check process to validate the responses provided to the three attestation statements. Commenters indicated concern that those who knowingly participate in information blocking practices will answer `yes' to the three attestation statements simply to complete the question/answer sequencing in the reporting system. Further, commenters expressed concern regarding how easy it could be for their peers to respond dishonestly, and requested more stringent auditing practices from CMS. A number of commenters requested additional information on how a “blank” response would be treated for purposes of this proposal; one commenter believed that a “blank” should be considered a “no”, and another commenter believed that a “blank” should simply be considered as a “blank.”
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns. We do not have a specific auditing practice in place for these specific attestation statements. Instead, all eligible hospitals and CAHs are required to submit responses to the attestation statements under the Promoting Interoperability Program and must respond accurately, as any eligible hospital or CAH participating in the Promoting Interoperability Program may be subject to an audit. In the event that an eligible hospital or CAH leaves a “blank” response to an attestation statement, where a “yes” or a “no” response is not submitted, the response would be considered incomplete, and no information would be posted related to these attestation statements at this time.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the effort to prevent information blocking, though several believed that posting certain information on a CMS website of those who attest `no' to the prevention of information blocking statements may not strongly impact the issue. Of the reasons given, one commenter remained agnostic on whether such a policy would have tangible success in deterring information blocking, several commenters stated that the information posted on a CMS website will have little meaning to consumers, and others believed that this process would not promote interoperability nor would it improve patient access to information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate all of the commenters' concerns. As discussed in the CY 2017 Quality Payment Program Final Rule (81 FR 77029), the act of information blocking is a systemic problem that Congress has expressed concerns about. Growing evidence has established that there is a strong incentive for health care providers to unreasonably interfere with the exchange of health information. We believe that publicly posting certain information on a CMS website is one valuable tool in our continued effort to deter these information blocking practices.
                    </P>
                    <P>As patients gain access to more data, they become more empowered and more informed decision makers. Knowing if a physician may be information blocking could influence their decision to see that physician. In addition, knowing patients can see this information may deter physicians from engaging in this behavior. For these reasons, we do believe that this effort will have an impact and be meaningful to consumers. We do also believe that this policy will promote interoperability and improve patient access to information. With patients becoming more empowered, this drives health care providers to move toward information sharing rather than information blocking, which directly leads to improved patient access to information.</P>
                    <P>
                        <E T="03">Comment:</E>
                         A couple commenters suggested moving away from posting public information, and instead focusing on creating positive incentive programs, enhancing guidance, providing more education, and fostering change through encouraging the prevention of information blocking. Some commenters agreed with the approach, but believed CMS could develop more concrete measures that would have a stronger justification for posting information on a CMS website versus using the three attestation statements.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Thank you for these comments and suggestions. To the extent that the commenters are requesting that we create positive incentive programs that include incentive payments to eligible hospitals and CAHs, we note that we can only do so to the extent authorized by law. We will take into consideration the suggestions for enhancing prevention of information blocking guidance, providing more education, and fostering change through encouragement in potential future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters were in favor of posting certain information on eligible hospitals and/or CAHs that provide a “no” response to the prevention of information blocking attestation statements, but have requested additional ways to discourage this practice. Commenters requested that those who are knowingly and willfully blocking the transfer of information also be fined, per instance or per patient, as a way of disincentivizing this practice. A couple commenters suggested strengthening this provision by establishing an easy way for stakeholders to report potential information blocking activities.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' suggestions regarding additional ways to discourage information blocking. We refer commenters to section 3022(b)(2)(B) of the PHSA, which provides that any health care provider determined by the Office of the Inspector General (OIG) to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable federal law, as the Secretary sets forth through notice and comment rulemaking. Health care providers would also be subject to the separate information blocking regulations proposed by ONC for HHS adoption at 45 CFR part 171 (84 FR 7601 through 7605). Further, we note that ONC's 21st Century Cures Act proposed rule included a request for information regarding disincentives for health care providers (84 FR 7553).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters, while in agreement with publicly posting certain information related to 
                        <PRTPAGE P="25580"/>
                        information blocking, had concerns that eligible hospitals and CAHs are being held accountable for the practices of health IT vendors. Many commenters were concerned that vendors are restricting the transfer of data by data embargoing, actively blocking, and refusing or prohibiting the transfer of data. Further, there were concerns that vendors are requiring complex programs, the purchase of many costly programs, and requiring excessive fees to conduct data transfer. Last, several commenters requested that vendors be penalized equally, and in the same manner, as eligible hospitals and CAHs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' support for the proposal, and we also appreciate their concerns. We emphasize that the information blocking provision (section 4004 of the Cures Act) applies to health IT developers of certified health IT. Section 3022(a)(1) of the PHSA, in defining information blocking, refers to four classes of individuals and entities that may engage in information blocking and which include: Health care providers, health IT developers of certified health IT, networks, and exchanges. In the ONC 21st Century Cures Act proposed rule, ONC proposed to adopt definitions of these terms to provide clarity regarding the types of individuals and entities to whom the information blocking provision applies (84 FR 7601 through 7602).
                    </P>
                    <P>Regarding penalties, section 4004 of the Cures Act identifies potential penalties and disincentives for information blocking. Health IT developers, health information networks, and health information exchanges that the Inspector General, following an investigation, determines to have committed information blocking shall be subject to a civil monetary penalty determined by the Secretary for all such violations identified through such investigation, which may not exceed $1,000,000 per violation. Such determination shall take into account factors such as the nature and extent of the information blocking and harm resulting from such information blocking, including, where applicable, the number of patients affected, the number of providers affected, and the number of days the information blocking persisted. Health care providers determined by the Inspector General to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable Federal law, as the Secretary sets forth through notice and comment rulemaking.</P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter suggested a collaboration between CMS, ONC, and OIG in order to address information blocking together, to combat information blocking consistently and from all angles.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenter's suggestion, and note that CMS, ONC, and OIG are consistently working together on issues such as information blocking so that our policies are complementary and work together to address the issue.
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing this policy as proposed. We will include information on a CMS website available to the public indicating that an eligible hospital or CAH attesting under the Medicare FFS Promoting Interoperability Program submitted a “no” response to any of the three prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ). We will post this information starting with the attestations for the EHR reporting period in 2019, and expect the information will be posted in late 2020. In the event that an eligible hospital or CAH leaves a “blank” response to an attestation statement, where a “yes” or a “no” response is not submitted, the attestations will be considered incomplete, and no information will be posted related to these attestation statements. We will establish a process for each eligible hospital and CAH to review the information related to their specific prevention of information blocking attestation statements before it is publicly posted on the CMS website. For each program year, we will have a 30-day preview period for an eligible hospital or CAH to review this information before it is publicly posted. During the 30-day preview period, all of the information that we will publicly post will be available for the eligible hospital or CAH to review, and we will consider making changes to the information on a case-by-case basis.
                    </P>
                    <HD SOURCE="HD1">IX. Provider Digital Contact Information Provisions, and Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Background</HD>
                    <P>Congress required the Secretary to create a provider digital contact information index in section 4003 of the Cures Act. This index must include all individual health care providers and health care facilities, or practices, in order to facilitate a comprehensive and open exchange of patient health information. Congress gave the Secretary the authority to use an existing index or to facilitate the creation of a new index. In comments received on the FY 2019 IPPS proposed rule RFI, there was strong support for a single, public directory of provider digital contact information. Commenters noted that digital communication could improve interoperability by facilitating efficient exchange of patient records, eliminating the burden of working with scanned paper documents, and ultimately enhancing care coordination.</P>
                    <P>
                        To ensure the index is accessible to all clinicians and facilities, we updated the National Plan and Provider Enumeration System (NPPES) 
                        <SU>52</SU>
                        <FTREF/>
                         to be able to capture digital contact information for both individuals and facilities. It is important to note that the aforementioned updates to the NPPES entailed the addition of two additional data fields. However, due to an administrative oversight, the data elements which allow for the digital capture of contact information are not OMB approved. CMS acknowledges this violation of the Paperwork Reduction Act of 1995 (PRA) and is currently working to remediate the issue by creating a new PRA package and thereby come into compliance with the PRA. Prior to its submission for OMB approval, the new information collection request will be made available for public review and comment as required by the PRA.
                    </P>
                    <FTNT>
                        <P>
                            <SU>52</SU>
                             The NPPES website at 
                            <E T="03">https://nppes.cms.hhs.gov/.</E>
                        </P>
                    </FTNT>
                    <P>NPPES currently supplies National Provider Identifier (NPI) numbers to health care providers (both individuals and facilities), maintains their NPI record, and publishes the records online. The Secretary adopted the NPI as the HIPAA administrative simplification standard identifier for health care providers (69 FR 3434). HIPAA covered entities, including health care providers, health plans, and health care clearinghouses, must use the NPI in HIPAA transactions. All health care providers that transmit health information in electronic form in connection with a HIPAA transaction must obtain an NPI.</P>
                    <P>
                        Health care providers are required to communicate to the NPPES any information that has changed within 30 days of the change (45 CFR 162.410(a)(4)). We review NPPES to ensure a provider has a valid NPI as part of the Medicare enrollment process, as well as the revalidation process, which occurs every 3 to 5 years depending on the provider or supplier type.
                        <PRTPAGE P="25581"/>
                    </P>
                    <P>Information in NPPES is publicly accessible via both an online search option and a downloadable database option. As a result, adding digital contact information to this existing index is an efficient and effective way to meet the Congressional requirement to establish a digital contact information index and to promote the sharing of information.</P>
                    <P>
                        As of June 2018, NPPES has been updated to include the capability to capture one or more pieces of digital contact information that can be used to facilitate secure sharing of health information. For instance, providers can submit a Direct address, which functions similar to a regular email address, but includes additional security measures to ensure that messages are only accessible to the intended recipient in order to keep the information confidential and secure. “Direct” is a technical standard for exchanging health information. Direct addresses are available from a variety of sources, including EHR vendors, State Health Information Exchange entities, regional and local Health Information Exchange entities, as well as private service providers offering Direct exchange capabilities called Health Information Service Providers (HISPs) (
                        <E T="03">https://www.healthit.gov/sites/default/files/directbasicsforprovidersqa_05092014.pdf</E>
                        ). NPPES can also capture information about a wide range of other types of endpoints that providers can use to facilitate secure exchange of health information, for instance a FHIR server URL or query endpoint associated with a health information exchange. We strongly encourage the inclusion of this FHIR endpoint information in NPPES in support of the Patient Access API policy discussed in section III. of this final rule and the Provider Directory API policy discussed in section IV. of this final rule. Using NPPES as one way to make these endpoints publicly known will significantly support interoperability throughout the health care system.
                    </P>
                    <P>In addition, NPPES can now maintain information about the type of contact information providers and organizations are associated with, along with the preferred uses for each address. Each provider in NPPES can maintain their own unique information or associate themselves with information shared among a group of providers. Finally, in March 2019, NPPES added a public API which can be used to obtain the digital contact information stored in the database. Although NPPES is now better equipped to maintain provider digital contact information, many providers have not submitted this information. In the 2015 final rule, “Medicare and Medicaid Programs; Electronic Health Record Incentive Program-Stage 3 and Modifications to Meaningful Use in 2015 Through 2017” (80 FR 62901), we finalized a policy to collect information in NPPES about the electronic addresses of participants in the EHR Incentive Program (specifically, a Direct address and/or other “electronic service information” as available). However, this policy was not fully implemented at the time, in part due to the limitations of the NPPES system which have since been addressed. As a result, many providers have not yet added their digital contact information to NPPES and digital contact information is frequently out of date.</P>
                    <P>In light of these updates to the NPPES system, all individual health care providers and facilities can take immediate action to update their NPPES record online to add digital contact information. This simple step will significantly improve interoperability by making valuable contact information easily accessible. For those providers who continue to rely on the use of cumbersome, fax-based modes of sharing information, we hope that greater availability of digital contact information will help to reduce barriers to electronic communication with a wider set of providers with whom they share patients. Ubiquitous, public availability of digital contact information for all providers is a crucial step towards eliminating the use of fax machines for the exchange of health information. We urged all providers to take advantage of this resource to implement Congress' requirement that the Secretary establish a digital contact information index.</P>
                    <HD SOURCE="HD2">B. Public Reporting of Missing Digital Contact Information</HD>
                    <P>Entities seeking to engage in electronic health information exchange need accurate information about the electronic addresses (for example, Direct address, FHIR server URL, query endpoint, or other digital contact information) of potential exchange partners. A common directory of the electronic addresses of health care providers and organizations could enhance interoperability and information exchange by providing a resource where users can obtain information about how to securely transmit electronic health information to a provider.</P>
                    <P>We proposed to increase the number of providers with valid and current digital contact information available through NPPES by publicly reporting the names and NPIs of those providers who do not yet have their digital contact information included in the NPPES system. We proposed to begin this public reporting in the second half of 2020, to allow individuals and facilities time to review their records in NPPES and update the system with appropriate digital contact information. We also requested comment from stakeholders on the most appropriate way to pursue this public reporting initiative, including where these names should be posted, with what frequency, and any other information stakeholders believed would be helpful.</P>
                    <P>We noted that we believed this information would be extremely valuable to facilitate interoperability, and we appreciated Congress' leadership in requiring the establishment of this directory. We requested stakeholder comment on additional possible enforcement authorities to ensure that individuals and facilities make their digital contact information publicly available through NPPES. For example, we questioned if Medicare reporting programs, such as MIPS, should require eligible clinicians to update their NPPES data with their digital contact information? Should CMS require this information to be included as part of the Medicare enrollment and revalidation process? How can CMS work with states to promote adding information to the directory through state Medicaid programs and CHIP? Should CMS require providers to submit digital contact information as part of program integrity processes related to prior authorization and submission of medical record documentation? We noted that we would review comments for possible consideration in future rulemaking on these questions.</P>
                    <P>We summarize the public comments we received on this topic and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many stakeholders shared our goal of improving the accuracy and completeness of data in the NPPES.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support and are finalizing this policy as proposed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters, while supporting the ultimate goal of the proposal, noted doubts about whether the proposal would be effective at increasing the accuracy and completeness of digital contact information in NPPES. Commenters believed that a public reporting mechanism would not serve as a meaningful deterrent to providers leaving their information blank. One commenter stated that they believed, even with the implementation of this proposal, high rates of inaccuracies would persist in NPPES, and 
                        <PRTPAGE P="25582"/>
                        stakeholders would continue to rely on internal sources of information. Several commenters stated that, given the likelihood that this proposal would not result in meaningful improvements, this proposal would represent unnecessary administrative burden for providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their feedback on the potential effectiveness of this proposal. While we believe that this proposal is an important initial step toward increasing the accuracy of information in NPPES, we appreciate that this proposal may not be sufficient to fully realize the goal of NPPES serving as a comprehensive index of provider digital contact information. To this end, we requested comment on other programs that CMS could leverage to improve the completeness and accuracy of information in NPPES. The responses to this comment solicitation are discussed in more detail below.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters recommended that, instead of pursuing a policy based on “public shaming,” it would be more effective for CMS to consider incentive-based policies for updating their digital contact information in NPPES.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their recommendations. While we believe the proposed policy is an important step toward increasing the completeness and accuracy of information in NPPES, we believe that other policy initiatives using incentives may be effective as well, such as leveraging opportunities under the MIPS program, and we will consider these approaches for potential inclusion in future rulemaking.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         In the proposed rule, CMS requested comment on additional possible enforcement authorities to ensure that individuals and facilities make their digital contact information publicly available through NPPES. Many commenters supported the use of other authorities to increase the accuracy and completeness of digital contact information in NPPES, stating that they believe these authorities were more likely to be effective than the proposed policy for publicly reporting the names and NPIs of those providers that have not included digital contact information in NPPES.
                    </P>
                    <P>For instance, many commenters believed that including this requirement in the MIPS program would be a more effective strategy for achieving the goals of the policy. Commenters believed this would be more effective due to the incentives available through the MIPS program. Commenters also believed that use of the MIPS program would be more effective since the Promoting Interoperability category of MIPS already includes requirements to electronically exchange health information, and the goal of increasing availability of digital contact information would align with those features of the program. Commenters also believed that tying this policy to the MIPS program would help to ensure annual updates of digital contact information as part of required MIPS data submissions.</P>
                    <P>Several commenters also supported the use of the Medicare enrollment or revalidation process and the use of program integrity processes as ways to promote updating of digital contact information in NPPES.</P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their input on additional enforcement mechanisms. We will take these comments under consideration as we consider potential future rulemaking or operational changes to these programs that are consistent with each program's statutory authority.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters suggested that CMS provide additional education and guidance about the benefits of adding their digital contact information to NPPES. These commenters recommended that CMS engage in public education as a necessary step before proceeding with public reporting in order to build awareness among providers of the importance of updating this information. For instance, one commenter noted that many hospital-based physicians are not aware of their digital contact information, currently relying on their institution's informatics division to manage this data. Others suggested that providers are not aware of the new functionality in NPPES allowing for submission of digital contact information and that education will be needed to familiarize providers with this feature. Commenters recommended that public education initiatives be targeted at those providers least likely to be familiar with the new functionality, and that CMS should work with specialty societies and other provider representatives to ensure education reaches a wide variety of providers. Some commenters also stated that a public education initiative alone would be a more appropriate alternative to public reporting of providers' names and NPIs.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' recommendations around the need for public education. Since updating the functionality in NPPES starting in 2018, we have taken steps to familiarize the provider community with these updates and plan to continue and expand this outreach. We agree that education efforts will be important to ensure that providers are aware of their responsibilities and that they may be at risk of having their names and NPIs publicly reported if they do not update their digital contact information in NPPES in a timely manner. While recognizing the importance of public education, we also believe that more aggressive steps are needed to accelerate the accuracy of completeness of information within NPPES, therefore we are finalizing the policy to publicly report the names and NPIs of providers that do not include digital contact information in NPPES.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         CMS proposed to begin public reporting in the second half of 2020. A number of commenters suggested that CMS delay this timeframe to allow providers more time to be made aware of the policy, review their NPPES record, and add missing information. One commenter believed that this timeline was not consistent with the time that would be required for CMS to reach small providers with information about the new policy, and recommended a delay of at least an additional 12 months before public reporting begins.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns and suggestions regarding the appropriate timeframe for public reporting under this proposal. However, we believe that the proposed timeline allows sufficient time for outreach and education to make providers aware of the requirement. We are therefore finalizing this timeframe as proposed.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters expressed concerns about the accuracy of information in NPPES, stating that inaccurate information imposes a burden on both providers and consumers who may try to collect and use this information only to find out that it is incorrect. These commenters noted inaccurate contact information also poses a problem for providers who are concerned with sending protected health information to the wrong recipient. One commenter stated that these challenges raise questions about whether a public file is appropriate to serve as the basis for increasing interoperability across provider systems.
                    </P>
                    <P>
                        Commenters suggested steps CMS could take to improve the accuracy of information in NPPES. One commenter suggested that CMS establish a requirement that providers update their information within a set time period. Another commenter suggested that NPPES post the date that information associated with a given NPI was last updated so that individuals reviewing the database could assess its accuracy. Several commenters urged CMS to 
                        <PRTPAGE P="25583"/>
                        conduct direct outreach to providers to confirm their information, or to validate provider information with other sources, such as state licensing boards, in order to increase accuracy.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns about the accuracy of provider contact information within NPPES. The “Last Updated” date is posted on the “NPI View” page for records in the public NPPES NPI Registry. It should also be noted that providers are required to update information included in NPPES within 30 days of a change (45 CFR 162.410(a)(4)). However, we understand from commenters that in practice these updates often do not occur, contributing to historical challenges with the accuracy of NPPES data.
                    </P>
                    <P>We appreciate commenters' suggestions for ways to improve the accuracy of data within NPPES, and we will take these suggestions into consideration.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters noted that providers who have not participated in the Promoting Interoperability Program (formerly the EHR Incentive Programs) are more likely to not have digital contact information available than those that have participated and received incentives for adoption of health information. Commenters stated that these providers would be at a disadvantage under the proposed policy, and that identifying these providers as noncompliant through a public reporting mechanism would be unfair. Commenters stated that this group likely includes smaller practices, rural clinicians, hospital-based clinicians, and clinicians employed at a variety of settings which were not eligible for EHR incentives, such as rehabilitation centers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns regarding those clinicians that are less likely to have existing digital contact information. While we understand that it may take more time for these clinicians to obtain and submit digital contact information to NPPES, we believe that the timeframe for implementing this proposal will provide sufficient notice to clinicians. We also believe that obtaining digital contact information, such as a Direct address, is now widely available to clinicians, including those who do not have certified EHR systems. Accordingly, we believe that these providers will be able to obtain digital contact information and add it to their NPPES record with relatively minimal burden.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters suggested that CMS establish a process for offering providers a chance to review their information and correct any issues prior to the implementation of public reporting. Commenters stated that CMS should issue communication to providers informing them of the status of their digital contact information, and that communications should include mechanisms which allow the provider to make corrections. One commenter recommended that CMS institute a 60-day review period prior to public reporting similar to the review period established for data included on the Physician Compare website.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions regarding opportunities for clinicians to review their information prior to the implementation of this public reporting policy. We have already implemented multiple methods for providers to review their information allowing them to correct any issues with their NPPES record. Providers can review their information using the NPPES NPI Registry (
                        <E T="03">https://npiregistry.cms.hhs.gov/</E>
                        ), the NPPES NPI Registry API (
                        <E T="03">https://npiregistry.cms.hhs.gov/registry/help-api</E>
                        ), or the NPPES Data Dissemination file (
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/NationalProvIdentStand/DataDissemination</E>
                        ). Each source currently contains all the information that will allow providers to determine the correctness of their information. As discussed above, we will also engage in continued public education efforts to ensure providers are aware of the benefits of including digital contact information in NPPES, as well as the associated public reporting policy.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters requested additional information about what kind of digital contact information would satisfy this requirement. One commenter recommended that providers should be able to specify other digital endpoints besides a Direct address. Another commenter requested clarity on whether the digital fax numbers would qualify as digital contact information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         As discussed in the proposed rule, NPPES is able to capture a variety of different digital endpoints. A digital fax number is not considered a digital endpoint for the purposes of this proposal. For more information on the digital contact information which can be added to NPPES, see 
                        <E T="03">https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.</E>
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters recommended that CMS partner with other centralized authorities that collect provider information. Commenters stated that relying on providers alone to update their information will not provide the levels of accuracy necessary for other providers to utilize NPPES for routine exchange of electronic health information. Commenters noted that today, directory services that employ appropriate identify proofing processes and other means for ensuring records are up-to-date are much more likely to possess accurate information than NPPES, and CMS should seek to improve the quality of NPPES by working with these partners. Commenters believed that by working with these entities, CMS could greatly reduce provider burden associated with entering information into and updating information in NPPES.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' input regarding other strategies to improve the accuracy of the digital contact information within NPPES.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters requested additional guidance on how the public reporting mechanism would operate. One commenter sought information on where the names would be publicly reported. Another commenter questioned how CMS would address public reporting of providers that have an NPI but do not have active practice locations where they are providing services under Medicare or engaging in communication with patients.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for these questions. Following the publication of the final rule, we will release additional information around the public reporting mechanism including where we intend to publish the names and NPIs of providers that do not have digital contact information in NPPES, as well as information about whether certain providers would be exempt from public reporting.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter questioned how providers would be expected to know their digital contact information as this information may not be visible to providers in many EHR systems.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We encourage providers, especially clinicians, to work with health IT administrators in their organization or directly with their health IT vendor if they are unclear on where their digital contact information can be found. We also note that NPPES now provides for bulk uploading of information to multiple NPI records, and encourage clinicians to work with health IT administrators in their organization to develop streamlined processes for updating this information in a way that imposes minimal burden on clinicians.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters noted the Provider Enrollment, Chain, and Ownership System (PECOS) system 
                        <PRTPAGE P="25584"/>
                        would be the most appropriate location for storing digital contact information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         While we understand the interest in using PECOS as the location for storing digital contact information, we are not considering this as an option at this time. PECOS collects information specific to provider and supplier enrollment in the Medicare program and the system is limited to the fields on the CMS 855 Enrollment forms. Any other data outside of this is optional. There are also many operational and systematic issues that prevent PECOS from being utilized to implement the digital contact information requirement.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters raised questions about what entities would have access to the information in NPPES. One commenter stated that any entity should be able to gain access to NPPES in order to advance interoperability. Another noted that making digital endpoints publicly accessible via an API that may be accessible to third parties could pose a risk to the security of protected health information available through those APIs, and recommended that CMS make this information available to other entities only if the third-party entity requests access from the API owner.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         NPPES already furnishes a public downloadable data dissemination file as well as a public API that provides the public information available in the NPI Registry. Both files are publicly accessible. Please note that this proposal is not related to the Patient Access API discussed in section III. of this final rule that can include patient protected health information.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A number of commenters requested additional information on issues related to NPPES functionality, and sought guidance on how to enter digital contact information. For instance, numerous commenters believed that the NPPES does not allow for a provider to enter information for multiple practice and billing locations. Several commenters sought information about whether a provider could enter multiple digital endpoints, for instance if they employ different endpoints for different types of communication. One commenter requested information on whether a provider could enter digital contact information for his or her employer, rather than individual information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         For more information on how information is captured in NPPES, we encourage commenters to review information available on the NPPES website at 
                        <E T="03">https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.</E>
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested that CMS develop a digital contact information interoperability standard for facilitating efficient exchange of patient records.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions, and note that we continue to collaborate with ONC, other federal partners, and industry stakeholders, to develop more robust provider directory standards that can support exchange of this information. We also direct commenters to the discussion of the Provider Directory API in section IV. of this final rule.
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing to publicly report the names and NPIs of those providers who do not have digital contact information included in the NPPES system beginning in the second half of 2020 as proposed. Additionally, we will engage in continued public education efforts to ensure providers are aware of the benefits of including digital contact information in NPPES, including FHIR API endpoints, and when and where this information will be posted.
                    </P>
                    <HD SOURCE="HD1">X. Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs) Provisions, and Analysis of and Responses to Public Comments</HD>
                    <HD SOURCE="HD2">A. Background</HD>
                    <P>As noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7649 through 7653), we appreciate the pathways Congress has created for action on interoperability and have been working diligently with ONC to implement them. In order to ensure broad stakeholder input to inform the proposals, we published a Request for Information (RFI) on interoperability in several proposed rules, including the FY 2019 IPPS proposed rule (83 FR 20550). Specifically, we published the RFI entitled, “Promoting Interoperability and Electronic Healthcare Information Exchange Through Possible Revisions to the CMS Patient Health and Safety Requirements for Hospitals and Other Medicare- and Medicaid-Participating Providers and Suppliers.” We requested stakeholders' input on how we could use the CMS health and safety standards that are required for providers and suppliers participating in the Medicare and Medicaid programs (that is, the Conditions of Participation (CoPs), Conditions for Coverage (CfCs), and Requirements for long term care facilities) to further advance electronic exchange of information that supports safe, effective transitions of care between hospitals and community providers. Specifically, we requested comment on revisions to the current CMS CoPs for hospitals such as: Requiring that hospitals transferring medically necessary information to another facility upon a patient transfer or discharge do so electronically; requiring that hospitals electronically send required discharge information to a community provider via electronic means if possible and if a community provider can be identified; and requiring that hospitals make certain information available to patients or a specified third-party application (for example, required discharge instructions) via electronic means if requested.</P>
                    <P>The RFI discussed several steps we have taken in recent years to update and modernize the CoPs and other health and safety standards to reflect current best practices for clinical care, especially in the area of care coordination and discharge planning. For a complete discussion of this work, see the proposed rule (84 FR 7649 through 7650).</P>
                    <P>
                        In the September 30, 2019 
                        <E T="04">Federal Register</E>
                        , we published a final rule, “Medicare and Medicaid Programs; Revisions to Requirements for Discharge Planning” (84 FR 51836) (“Discharge Planning final rule”), that revises the discharge planning requirements that hospitals (including psychiatric hospitals, long-term care hospitals, and inpatient rehabilitation facilities), critical access hospitals (CAHs), and home health agencies, must meet to participate in Medicare and Medicaid programs. The rule supports CMS' interoperability efforts by promoting the exchange of patient information between health care settings, and by ensuring that a patient's necessary medical information is transferred with the patient after discharge from a hospital, CAH, or post-acute care services provider. By requiring that all of the patient's necessary medical information, including his or her post-discharge goals of care and treatment preferences, must be documented in the patient's medical record 
                        <E T="03">and</E>
                         transferred along with the patient at the time of discharge to an appropriate receiving health care facility, such as a PAC service provider or agency, and to other outpatient service providers and practitioners responsible for the patient's follow-up or ancillary care, the rule aims to better prepare patients and their caregivers to be active partners and advocates for their health care and community support needs upon 
                        <PRTPAGE P="25585"/>
                        discharge from the hospital or post-acute care setting.
                    </P>
                    <P>While we finalized a broad requirement for sending necessary medical information in accordance with all applicable laws, rather than listing specific data elements (such as those explicitly aligned with the data referenced as part of the Common Clinical Data Set (CCDS) that was finalized in the 2015 final rule, “Medicare and Medicaid Programs; Electronic Health Record Incentive Program—Stage 3 and Modifications to Meaningful Use in 2015 Through 2017” (80 FR 62762), we also ensured that the revisions to the CoPs did not conflict with the CCDS, or future standards proposed for adoption for electronic exchange of health information, specifically the USCDI. The discharge planning CoPs do not bar providers from sending all additional appropriate medical information regarding the patient's current course of illness and treatment, post-discharge goals of care, and treatment preferences in accordance with applicable laws. However, we note here that the Discharge Planning final rule does not require hospitals, CAHs, and HHAs to transfer the necessary patient medical information exclusively by electronic means nor does it require that providers notify the appropriate providers, suppliers, and practitioners receiving the necessary medical information of the patient's discharge as we are now requiring in this final rule.</P>
                    <P>Additionally, the Discharge Planning final rule further supports interoperability and a patient's access to his or her own medical records by updating the hospital Patient Rights CoP to now state that the patient has the right to access his or her medical records in the form and format requested (including in an electronic form or format when such medical records are maintained electronically). Therefore, the hospital CoPs now include an explicit requirement that, as a condition of participation, hospitals must provide patients with access to their medical records in an electronic format upon the patient's request if the hospital has the capacity to do so.</P>
                    <P>In response to the RFI in the FY 2019 IPPS proposed rule, many stakeholders supported our goals of increasing interoperability, and acknowledged the important role that hospital settings play in supporting care coordination. Stakeholders agreed that use of electronic technology was an important factor in ensuring safe transitions. Multiple stakeholders emphasized that electronic data exchange between hospitals and physician offices, as well as with hospices, HHAs, SNFs, and other post-acute care services providers, was especially important during care transitions when maintaining access to patient health information, including medication information, and is extremely relevant to the patient's next phase of care. Additionally, stakeholders noted that giving patients and their caregivers access to important health information (such as discharge information along with accurately reconciled lists of discharge medications) created a more patient-centered health care system, and reduced the risk of errors and hospital readmissions. But many stakeholders also expressed concerns about implementing policy changes within the CoPs that might increase the compliance burden on hospitals. However, several stakeholders also strongly recommended that CMS add details to the CoPs, and require that hospitals share not only medically necessary information with physician offices, HHAs, and SNFs (such as pending tests and discharge summaries), but also notifications of when patients were admitted to the hospital as well as discharged or transferred from the hospital and admitted to the care of applicable PAC services providers and suppliers.</P>
                    <P>Given responses to the RFI, as well as previous rulemaking activities, we sought to further expand CMS requirements for interoperability within the hospital and CAH CoPs as part of the CMS Interoperability and Patient Access proposed rule by focusing on electronic patient event notifications. In addition, we noted that we were committed to taking further steps to ensure that facilities that are electronically capturing information are electronically exchanging that information with providers who have the capacity to accept it.</P>
                    <P>
                        Infrastructure supporting the exchange of electronic health information across settings has matured substantially in recent years. Research studies have increasingly found that health information exchange interventions can affect positive outcomes in health care quality and public health, in addition to more longstanding findings around reductions in utilization and costs. A recent review of how health information exchange interventions can improve cost and quality outcomes identified a growing body of high-quality studies showing that these interventions are associated with beneficial results.
                        <SU>53</SU>
                        <FTREF/>
                         The authors identified a number of studies demonstrating positive effects on outcomes associated with better care coordination, such as reductions in 30-day readmissions,
                        <E T="51">54 55 56</E>
                        <FTREF/>
                         and improved medication reconciliation.
                        <SU>57</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>53</SU>
                             Menachemi, N., Rahurkar, S., Harle, C.A., &amp; Vest, J.R. (2018). The benefits of health information exchange: An updated systematic review. 
                            <E T="03">Journal of the American Medical Informatics Association, 25</E>
                            (9), 1259-1265. doi: 10.1093/jamia/ocy035.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>54</SU>
                             Yeaman, B., Ko, K., del Castillo, R. (2015). Care transitions in long-term care and acute care: Health information exchange and readmission rates. 
                            <E T="03">The Online Journal of Issues in Nursing, 20</E>
                            (3). doi: 10.3912/OJIN.Vol20No03Man05.
                        </P>
                        <P>
                            <SU>55</SU>
                             Vest, J.R., Kern, L.M., Silver, M.D., &amp; Kaushal, R. (2015). The potential for community-based health information exchange systems to reduce hospital readmissions. 
                            <E T="03">Journal of the American Medical Informatics Association, 22</E>
                            (2), 435-442. doi: 10.1136/amiajnl-2014-002760.
                        </P>
                        <P>
                            <SU>56</SU>
                             Unruh, M.A., Jung, H.-Y., Kaushal, R., &amp; Vest, J.R. (2017). Hospitalization event notifications and reductions in readmissions of Medicare fee-for-service beneficiaries in the Bronx, New York. 
                            <E T="03">Journal of the American Medical Informatics Association, 24</E>
                            (e1), e150-e156. doi: 10.1093/jamia/ocw139.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>57</SU>
                             Boockvar, K.S., Ho, W., Pruskowski, J., Dipalo, K.E., Wong, J.J., Patel, J., . . . Hung, W. (2017). Effect of health information exchange on recognition of medication discrepancies is interrupted when data charges are introduced: Results of a cluster-randomized controlled trial. 
                            <E T="03">Journal of the American Medical Informatics Association, 24</E>
                            (6), 1095-1101. doi: 10.1093/jamia/ocx044.
                        </P>
                    </FTNT>
                    <P>
                        Electronic patient event notifications from hospitals, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings, especially for patients at discharge. This approach has been associated with a reduction in readmissions following implementation of such notifications.
                        <SU>58</SU>
                        <FTREF/>
                         We noted that the evidence cited in this section to support the use of innovative health information exchange interventions and approaches, such as the patient event notifications that we proposed to require, can be applied to various types of hospitals, including psychiatric hospitals, as well as to CAHs, as discussed below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>58</SU>
                             Unruh, M.A., Jung, H.-Y., Kaushal, R., &amp; Vest, J.R. (2017). Hospitalization event notifications and reductions in readmissions of Medicare fee-for-service beneficiaries in the Bronx, New York. 
                            <E T="03">Journal of the American Medical Informatics Association, 24</E>
                            (e1), e150-e156. doi: 10.1093/jamia/ocw139.
                        </P>
                    </FTNT>
                    <P>
                        Patient event notifications are automated, electronic communications from the discharging provider to another facility, or to another applicable community provider as identified by the patient (such as a patient's primary care practitioner or practice group, post-acute care services providers and suppliers, and other practitioners and providers that need the notification for post-acute care coordination, treatment, and/or quality improvement purposes), 
                        <PRTPAGE P="25586"/>
                        which alerts the receiving provider that the patient has received care at a different setting. Depending on the implementation, information included with these notifications can range from conveying the patient's name, other basic demographic information, and the sending institution to a richer set of clinical data on the patient. Even with a minimum set of information included, these notifications can help ensure that a receiving provider, facility, or practitioner is aware that the patient has received care elsewhere. The notification triggers a receiving provider, facility, or practitioner to reach out to the patient and deliver appropriate follow-up care in a timely manner. By notifying the individuals and entities that need notification of the patient's status for treatment, care coordination, or quality improvement purposes, the notification can help to improve post-discharge transitions and reduce the likelihood that a patient would face complications from inadequate follow-up care.
                    </P>
                    <P>
                        In addition to their effectiveness in supporting care coordination, virtually all EHR systems generate the basic messages commonly used to support electronic patient event notifications. These notifications are based on admission, discharge, and transfer (ADT) messages, a standard message used within an EHR as the vehicle for communicating information about key changes in a patient's status as they are tracked by the system (more information about the current standard supporting these messages is available at 
                        <E T="03">http://www.hl7.org/implement/standards/product_brief.cfm?product_id=144</E>
                        ). As noted in the Interoperability Standards Advisory (ISA) published by ONC, this messaging standard has been widely adopted across the health care system (see 
                        <E T="03">https://www.healthit.gov/isa/sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers</E>
                        ).
                    </P>
                    <P>ADT messages provide each patient's personal or demographic information (such as the patient's name, insurance, next of kin, and attending physician), when that information has been updated, and also indicate when an ADT status has changed. To create an electronic patient event notification, a system can use the change in ADT status to trigger a message to a receiving provider or to a health information exchange system that can then route the message to the appropriate provider. In addition to the basic demographic information contained in the ADT message, some patient event notification implementations attach more detailed information to the message regarding the patient's clinical status and care received from the sending provider.</P>
                    <HD SOURCE="HD2">B. Provisions for Hospitals (42 CFR 482.24(d))</HD>
                    <P>We proposed to revise the CoPs for Medicare- and Medicaid-participating hospitals at 42 CFR 482.24 by adding a new standard at paragraph (d), “Electronic Notifications,” that would require hospitals to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider or practitioner. We proposed to require hospitals to convey, at a minimum, the patient's basic personal or demographic information, as well as the name of the sending institution (that is, the hospital), and, if not prohibited by other applicable law, the patient's diagnosis. In proposing that patient event notifications sent by a hospital's medical records system include diagnosis, where not prohibited by other applicable law, we requested comment on the technical feasibility of this proposal, noting that we recognize some existing ADT messages might not include diagnosis, as well as the challenges in appropriately segmenting this information in instances where the diagnosis may not be permitted for disclosure under other applicable laws.</P>
                    <P>We also encouraged hospitals, as their systems and those of the receiving providers allowed, to work with patients and their practitioners to offer more robust patient information and clinical data upon request in accordance with applicable law.</P>
                    <P>For a hospital that currently possesses an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event notifications, we proposed that compliance with the proposed standard within the Medical records services CoP (42 CFR 482.24) would be determined by the hospital demonstrating to the surveyor or accrediting organization that its system: (1) Is fully operational and that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends notifications that would have to include the minimum patient health information (which, as noted above, would be the patient's name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the hospital and either immediately prior to or at the time of the patient's discharge and/or transfer from the hospital.</P>
                    <P>
                        We proposed to limit this requirement to only those hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications as discussed below, recognizing that not all Medicare- and Medicaid-participating hospitals have been eligible for past programs promoting adoption of EHR systems. We noted our goal in proposing the requirement was to ensure that hospital EHR systems have a basic capacity to generate messages that can be utilized for notifications by a wide range of receiving providers, enabled by common standards. We believed that a system that utilizes the ADT messaging standard, which is widely used as the basis for implementing these notifications and other similar use cases, would meet this goal by supporting the availability of information that can be used to generate information for patient event notifications. Specifically, we proposed that the system utilize the ADT messaging standard incorporated by reference at 45 CFR 170.205(a)(4)(i).
                        <SU>59</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>59</SU>
                             Health Level Seven Messaging Standard Version 2.5.1 (HL7 2.5.1), an Application Protocol for Electronic Data Exchange in Healthcare Environments, February 21, 2007.
                        </P>
                    </FTNT>
                    <P>We noted that, while there are no criteria under the ONC Health IT Certification Program which certifies health IT to create and send electronic patient event notifications, the ADT standard is referenced by other certification criteria under the program. Specifically, this standard supports certification criteria related to transferring information to immunization registries, as well as transmission of laboratory results to public health agencies as described at 45 CFR 170.315(f) under the 2015 Edition certification criteria, and at 45 CFR 170.314(f) under the 2014 Edition. Thus, we expect systems that include Health IT Modules certified to meet criteria which reference this standard will possess the basic capacity to generate information for notification messages. We further noted that adopting certified health IT that meets these criteria has been required for any hospital seeking to qualify for the Promoting Interoperability Programs (formerly the EHR Incentive Programs).</P>
                    <P>
                        We recognized that there is currently significant variation in how hospitals have utilized the ADT messages to 
                        <PRTPAGE P="25587"/>
                        support implementation of patient event notifications. We also recognized that many hospitals, which have already implemented notifications, may be delivering additional information beyond the basic information included in the ADT message (both automatically when a patient's status changes and then upon request from receiving providers) to receiving practitioners, patient care team members, and post-acute care services providers and suppliers with whom they have established patient care relationships and agreements for patient health information exchange as allowed by law. We believe consensus standards for ADT-based notifications may become more widely adopted in the future (we refer readers to ONC's ISA 
                        <SU>60</SU>
                        <FTREF/>
                         for more information about standards under consideration). However, at this time, we stated that we did not wish to restrict hospitals from pursuing more advanced content as part of patient notifications, nor to create redundant requirements where hospitals already have a suitable notification system in place. Accordingly, while we specified that hospitals subject to the proposal possess a system utilizing this standard, we proposed that hospitals could utilize other standards or features to support their notification systems. We requested comment on the proposal, including whether this requirement would achieve the goal of setting a baseline for hospitals' capacity to generate information for electronic notifications, while still allowing for innovative approaches that would potentially increase the effectiveness of these notifications toward improving patient outcomes and safety during transitions in care.
                    </P>
                    <FTNT>
                        <P>
                            <SU>60</SU>
                             Office of the National Coordinator. (n.d.). Admission, Discharge, and Transfer. Retrieved from 
                            <E T="03">https://www.healthit.gov/isa/admission-discharge-and-transfer.</E>
                        </P>
                    </FTNT>
                    <P>We further proposed that the hospital would need to demonstrate that the system's notification capacity was fully operational, that it operated in accordance with all state and federal statutes and regulations regarding the exchange of patient health information. We intended for these notifications to be required, at minimum, for inpatients admitted to, and discharged and/or transferred from the hospital. However, we also noted that patient event notifications are an effective tool for coordinating care across a wider set of patients that may be cared for by a hospital. For instance, a patient event notification could ensure that a primary care physician was aware that his or her patient had received care at the emergency room, and initiate outreach to the patient to ensure that appropriate follow-up for the emergency visit was pursued. While we encouraged hospitals to extend the coverage of their notification systems to serve additional patients, outside of those admitted and seen as inpatients, we also sought comment on whether we should identify a broader set of patients to whom this requirement would apply, and if so, how we should implement such a requirement in a way that minimizes administrative burden on hospitals.</P>
                    <P>Additionally, we proposed that the hospital would have to demonstrate that its system sends notifications that include the minimum patient health information (specifically, patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis). We proposed that the hospital would also need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of the patient's hospital admission, discharge, or transfer, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) the hospital has reasonable certainty that such notifications are received. We noted that we believed the proposal would allow for a diverse set of strategies that hospitals might use when implementing patient event notifications.</P>
                    <P>Through these provisions, we sought to allow for different ways that a hospital might identify those practitioners, other patient care team members, and PAC services providers and suppliers that are most relevant to both the pre-admission and post-discharge care of a patient. We proposed that hospitals send notifications to those practitioners or providers that had an established care relationship with the patient relevant to his or her care. We recognized that hospitals and their partners may identify appropriate recipients through various methods. For instance, hospitals might identify appropriate practitioners by requesting this information from patients or caregivers upon arrival, or by obtaining information about care team members from the patient's record. We expected hospitals might develop or optimize processes to capture information about established care relationships directly, or work with an intermediary that maintains information about care relationships. In other cases, we noted that hospitals may, directly or through an intermediary, identify appropriate notification recipients through the analysis of care patterns or other attribution methods that seek to determine the provider most likely to be able to effectively coordinate care post-discharge for a specific patient. The hospital or intermediary might also develop processes to allow a provider to specifically request notifications for a given patient for whom they are responsible for care coordination as confirmed through conversations with the patient.</P>
                    <P>Additionally, we expected hospitals, psychiatric hospitals, and CAHs to comply with the HIPAA Rules set out at 45 CFR parts 160 and 164 if these proposed CoP requirements for patient event notifications were finalized. As required at 42 CFR 482.11 for hospitals and psychiatric hospitals and at 42 CFR 485.608 for CAHs, these providers must comply with all pertinent currently existing federal laws, including the HIPAA Privacy and Security Rules. The Privacy Rule permits patient event notifications as disclosures for treatment purposes (the proposed required notifications, when finalized, also may be treated as disclosures required by law (see 45 CFR 164.502(a)).</P>
                    <P>
                        We also recognized that factors outside of the hospital's control might determine whether or not a notification was successfully received and utilized by a practitioner. Accordingly, we proposed that a hospital would only need to send notifications to those practitioners for whom the hospital has reasonable certainty of receipt. While we stated that we expected hospitals would, to the best of their ability, seek to ensure that notification recipients were able to receive notifications (for instance, by obtaining a recipient's Direct address 
                        <SU>61</SU>
                        <FTREF/>
                        ), we understood that technical issues beyond the hospital's control could prevent successful receipt and use of a notification.
                    </P>
                    <FTNT>
                        <P>
                            <SU>61</SU>
                             For more information about obtaining a Direct addresses, see 
                            <E T="03">https://www.healthit.gov/sites/default/files/directbasicsforprovidersqa_05092014.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        Finally, we noted that hospitals have an existing responsibility under the CoPs at 42 CFR 482.43(d) to “transfer or refer patients, along with necessary medical information, to appropriate facilities, agencies, or outpatient services, as needed, for follow-up or ancillary care.” We emphasized that the proposal regarding patient event notifications would be separate from the 
                        <PRTPAGE P="25588"/>
                        requirement regarding necessary medical information at 42 CFR 482.43(d). However, we recognized that processes to implement the proposal, if finalized, could intersect with the hospital's discharge planning process. We noted that nothing in the proposal would affect the hospital's responsibilities under 42 CFR 482.43(d). However, we noted if the proposal was finalized, hospitals might wish to consider ways to fulfill these requirements in ways that reduce redundancy while still remaining compliant with existing requirements. For instance, where appropriate and allowed by law, hospitals might seek to include required necessary medical information within the same message as a patient event notification.
                    </P>
                    <HD SOURCE="HD2">C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f))</HD>
                    <P>Medicare- and Medicaid-participating psychiatric hospitals must comply with all of the hospital CoPs at 42 CFR 482.1 through 482.23 and at 42 CFR 482.25 through 482.57. They also must adhere to special provisions regarding medical records at 42 CFR 482.61 and staffing requirements at 42 CFR 482.62. Since the medical records requirements are different for psychiatric hospitals, and since these hospitals do not have to comply with the regulations at 42 CFR 482.24, we proposed a new electronic notification standard at 42 CFR 482.61(f) within the special provisions for psychiatric hospitals in this section.</P>
                    <P>Similar to the proposal for hospitals at 42 CFR 482.24(d), we proposed a new standard at 42 CFR 482.61(f), “Electronic Notifications,” that would require psychiatric hospitals to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider.</P>
                    <P>As we proposed for hospitals, we proposed to limit this requirement to only those psychiatric hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, defined as systems that utilize the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i). We proposed that that for a psychiatric hospital that currently possessed an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event (ADT) notifications, compliance with the proposed standard within the Special medical records requirements for psychiatric hospitals CoP (42 CFR 482.61) would be determined by the hospital demonstrating that its system: (1) Is fully operational and that it operated in accordance with all state and federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends notifications that would have to include the minimum patient health information (specifically, patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the hospital and either immediately prior to or at the time of the patient's discharge and/or transfer from the hospital. We requested comment on the policy as part of this hospital proposal in section X.B. of the CMS Interoperability and Patient Access proposed rule (84 FR 7650 through 7652).</P>
                    <P>We also proposed that the hospital would need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, and either immediately prior to or at the time of the patient's hospital admission, discharge, or transfer, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) the hospital is reasonably certain will receive such notifications.</P>
                    <P>We referred readers to the extended discussion of the proposals in sections X.A. and B. of the CMS Interoperability and Patient Access proposed rule (84 FR 7649 through 7652). We sought comment on these proposals.</P>
                    <HD SOURCE="HD2">D. Provisions for CAHs (42 CFR 485.638(d))</HD>
                    <P>We believe implementation of patient event notifications are also important for CAHs to support improved care coordination from these facilities to other providers in their communities. Therefore, similar to the proposals for the hospital and psychiatric hospital medical records requirements as discussed in the preceding sections, we proposed to revise 42 CFR 485.638, by adding a new standard to the CAH Clinical records CoP at paragraph (d), “Electronic Notifications.” As discussed, the proposed standard would require CAHs to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider.</P>
                    <P>We proposed to limit this requirement to only those CAHs which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, defined as systems that utilize the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i). We proposed that for a CAH that currently possessed an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event (ADT) notifications, compliance with the proposed standard within the Clinical records services CoP (42 CFR 485.638) would be determined by the CAH demonstrating that its system: (1) Is fully operational and that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends notifications that would have to include the minimum patient health information (specifically, patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the CAH and either immediately prior to or at the time of the patient's discharge and/or transfer from the CAH. We requested comment on the policy as part of the hospital proposal in section X.B. of the CMS Interoperability and Patient Access proposed rule (84 FR 7650 through 7652).</P>
                    <P>
                        Additionally, we proposed that the CAH would need to demonstrate that the system sends notifications directly, or through an intermediary that facilitated exchange of health information, and at or immediately prior to the time of the patient's CAH admission, discharge, or transfer, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) the CAH is reasonably certain will receive such notifications.
                        <PRTPAGE P="25589"/>
                    </P>
                    <HD SOURCE="HD2">E. Comments and Responses on the Provisions of the Proposed Rule; Final Actions and Provisions of the Final Rule for Hospitals (42 CFR 482.24(d)), Psychiatric Hospitals (42 CFR 482.61(f)); and CAHs (42 CFR 485.638(d))</HD>
                    <P>We requested comments on the proposals including stakeholder feedback about how the proposals should be operationalized. Additionally, we sought comment on how CMS should implement these proposals as part of survey and certification guidance in a manner that minimizes compliance burden on hospitals, psychiatric hospitals, and CAHs while ensuring adherence with the standards. We also sought stakeholder input about a reasonable timeframe for implementation of these proposals for hospitals, psychiatric hospitals, and CAHs, respectively.</P>
                    <P>We received more than 600 public comments on this section that were specific to the patient event notification requirements proposed for inclusion in the CoPs, but which generally did not distinguish among the requirements individually proposed for hospitals, psychiatric hospitals, and CAHs at 42 CFR 482.24(d), 482.61(f), and 485.638(d), respectively. We summarize the public comments we received on our proposals related to the Conditions of Participation and provide our responses in this section. This summary of the public comments and our responses apply equally to all three provider types included under this proposed requirement and the specific provisions proposed for each unless otherwise noted. We provide the final actions and the provisions of the final rule at the end of this section.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the proposals to require hospitals (including psychiatric hospitals) and CAHs to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider. Commenters stated that they believed implementing patient event notifications would be a highly effective tool to improve care transitions for patients moving between a hospital and other settings, including returning home. Commenters believed that increasing the sharing of patient event notifications at admission and discharge can lead to improved outcomes, higher quality, and lower cost care. Commenters also pointed to many instances in which these notifications are being utilized today, stating that they believe that patient event notifications had effectively contributed to improved care coordination. For instance, one commenter pointed to the statewide requirement for hospitals in Maryland to transmit notifications, noting that this has been an important policy supporting care coordination in the state. Several commenters noted that the availability of notification information is especially important for the success of value-based payment models, such as ACO initiatives, where participants may be financially at risk for costs associated with poor care transitions.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' support for the proposal and are finalizing our proposal with modifications as discussed below.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         While many commenters agreed that patient event notifications are an important way to improve care coordination, some disagreed that the CoPs were the appropriate vehicle for advancing their use. Many commenters stated that by placing the patient event notification requirements in the CoPs, CMS is putting hospitals' participation in Medicare at risk, which they stated would be an excessive penalty for failure to implement patient event notifications in accordance with the proposed requirements.
                    </P>
                    <P>Commenters also stated that the survey and certification process was not well-suited to determining compliance with the proposed CoP “Electronic notifications” standard. These commenters questioned how surveyors would assess compliance with the requirements, including one commenter who questioned how a hospital would demonstrate that its system sent notifications that improve the coordination of care, and not just show that its system is merely functioning as required. They further stated that a survey team would need clear guidance on how to assess providers for compliance to ensure that hospitals are transmitting patient information to, and receiving it from, other providers.</P>
                    <P>Additionally, one commenter stated that hospital accreditation programs are not the appropriate entities to assess compliance, due to the technical nature of the requirements.</P>
                    <P>Commenters also expressed concern that tying these requirements to the CoPs could lead to hospitals sending more information than is necessary to ensure compliance, further increasing excessive information received by providers.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns regarding use of the CoPs to advance the use of patient notifications; however, we disagree that the CoPs are an inappropriate vehicle for this purpose. We believe that the capability to send patient event notifications should be a fundamental feature of hospital medical record systems to support effective care transitions and promote patient safety during transitions. This belief is consistent with the statutory authority for establishing and appropriately updating the CoPs as that authority is contained in section 1861(e) of the Act, which defines institutions that meet the definition of a hospital for Medicare purposes. Specifically, section 1861(e)(2) of the Act requires that a hospital “maintains clinical records on all patients,” and section 1861(e)(9) of the Act requires that a hospital “meets such other requirements as the Secretary finds necessary in the interest of the health and safety of individuals who are furnished services in the institution.” As discussed in the proposed rule (84 FR 7650), we believe patient event notifications can help to improve care coordination for patients discharged from the hospital and reduce the incidence of events such as hospital readmissions that could have been avoided through more timely follow-up care.
                    </P>
                    <P>Further, including a CoP requirement for patient event notifications at the time of a patient's discharge or transfer as we have proposed and are finalizing in this rule is also consistent with section 1861(ee)(2) of the Act, which states that the Secretary shall develop guidelines and standards for the discharge planning process in order to ensure a timely and smooth transition to the most appropriate type of and setting for post-hospital or rehabilitative care. We believe patient event notifications are an effective tool for ensuring that the settings responsible for follow-up care are made aware that their patients have been discharged in an expeditious manner. We believe that these notifications can be utilized to more effectively trigger care coordination activities that promote timely transitions. We have chosen to include these requirements in the CoPs for medical records services, and not those for discharge planning, because we believe that the medical records CoPs provide a more global approach to the notifications than do the discharge planning CoPs, especially since we are requiring notifications for inpatient admissions as well as ED and outpatient observation admissions or registrations in addition to patient discharges and transfers. Therefore, given this statutory authority, we maintain that the CoPs are an appropriate vehicle for advancing the use of patient event notifications.</P>
                    <P>
                        We also disagree that the CoPs are an inappropriate vehicle for this policy due to what the commenters' characterize as 
                        <PRTPAGE P="25590"/>
                        the disproportionate penalties associated with noncompliance with this CoP. We note that while the CoPs are a significant regulatory mechanism, noncompliance with one subordinate standard under one CoP must be considered relative to a hospital's compliance or noncompliance with the many other CoPs and standards as well as the severity of the noncompliance and the risk it poses to patient health and safety. Under the heading, “Determining the Severity of Deficiencies,” the State Operations Manual (SOM), Appendix A—Survey Protocol, Regulations and Interpretive Guidelines for Hospitals cites the regulations at 42 CFR 488.26 (“The decision as to whether there is compliance with a particular requirement, condition of participation, or condition for coverage, depends upon the manner and degree to which the provider or supplier satisfies the various standards within each condition.”) as the basis for determining the various levels of noncompliance with the CoPs during a survey (
                        <E T="03">https://www.cms.gov/Regulations-andGuidance/Guidance/Manuals/downloads/som107ap_a_hospitals.pdf;</E>
                         p.19).
                    </P>
                    <P>From page 19 of the SOM, Appendix A:</P>
                    <P>“When noncompliance with a condition of participation is noted, the determination of whether a lack of compliance is at the Standard or Condition level depends upon the nature (how severe, how dangerous, how critical, etc.) and extent (how prevalent, how many, how pervasive, how often, etc.) of the lack of compliance. The cited level of the noncompliance is determined by the interrelationship between the nature and extent of the noncompliance.</P>
                    <P>“A deficiency at the Condition level may be due to noncompliance with requirements in a single standard or several standards within the condition, or with requirements of noncompliance with a single part (tag) representing a severe or critical health or safety breach. Even a seemingly small breach in critical actions or at critical times can kill or severely injure a patient, and represents a critical or severe health or safety threat.</P>
                    <P>“A deficiency is at the Standard level when there is noncompliance with any single requirement or several requirements within a particular standard that are not of such character as to substantially limit a facility's capacity to furnish adequate care, or which would not jeopardize or adversely affect the health or safety of patients if the deficient practice recurred.”</P>
                    <P>Regarding the comments questioning how surveyors, either state surveyors or those from one of the hospital accreditation programs, would determine compliance with the notification requirements, we will issue, as we do with all new or revised CoP requirements, new interpretive guidelines, which include survey procedures, for the State Operations Manual, following finalization of this rule and prior to the rule's effective date. We will advise and train state surveyors on the new requirements as is the normal procedure when new and/or revised CoPs and standards are finalized. For example, the current Medical Record Services CoP requirements, contained at 42 CFR 482.24, and in which we are finalizing these new patient event notification requirements, primarily contain provisions for administrative systems or processes where the hospital is responsible for demonstrating that the various components of its medical records system or process are in place and operational in order to comply with the overall requirements of the CoP. Surveyors would then approach these new requirements in a similar fashion and apply similar survey procedures and methods that do not require surveyors to have deep technical knowledge of various systems in order to determine compliance. As with the survey of the hospital's total medical records system, surveyors would utilize basic and effective survey procedures and methods such as:</P>
                    <P>• Review of the organizational structure and policy statements and an interview with the person responsible for the medical records service to first ascertain that the hospital has a system that meets the initial requirements for patient event notifications in order to determine whether or not the hospital is exempt from the specific patient event notification requirements that follow.</P>
                    <P>• Review of a sample of active and closed medical records for completeness and accuracy, including any patient event notifications, in accordance with federal and state laws and regulations and hospital policy.</P>
                    <P>• Interview of medical records and other hospital staff, including physicians and other practitioners, to determine understanding of the patient events notification function of the system.</P>
                    <P>• Conducting observations and interviews with medical records staff and leadership to determine if requirements for patient event notifications are being met.</P>
                    <P>CMS-approved accreditation organizations (AOs) with hospital programs are required, at a minimum, to enforce standards that meet or exceed hospital CoP requirements, so each AO will be responsible for training its survey and accreditation staff on the patient event notification requirements finalized in this rule ahead of the applicable date established by CMS.</P>
                    <P>Finally, the patient event notification requirements that we are finalizing require a hospital to send only a minimal amount of patient information in order to be in compliance with the provisions. These requirements are consistent with our belief that existing patient event notification systems have demonstrated that a minimal set of information can achieve the desired effect of improving care coordination while imposing minimal burden on providers. However, hospitals are not prohibited from sending more detailed information under these requirements and we would expect each hospital is fully aware of its own capacity to send additional patient information, other applicable laws governing this, and the capacities of the intended recipients to receive additional patient information, and would base its decisions to send additional information on these factors as well as on what is best for the patient. Based on our experience with hospitals, we disagree with the commenter that a hospital would unnecessarily send “excessive” amounts of patient information in an attempt to ensure a determination that the hospital was in compliance. To prevent such confusion, we have clearly delineated the patient information requirements in this final rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters stated that the CoPs were not appropriate for advancing goals related to interoperability and the use of health IT. Commenters stated that CMS currently regulates provider use of technology through a variety of other avenues, such as the Promoting Interoperability Programs, and that adding the proposed requirements under the CoPs would add an unnecessary additional mechanism for addressing these issues. Commenters believed this could lead to additional provider burden and confusion, as stakeholders would be required to navigate duplicative requirements around the electronic exchange of information. Several commenters stated that, by shifting focus to compliance with the proposed requirements, and requiring hospitals to engage in duplicative reporting on information exchange, this proposal could divert funding and attention from necessary investments in interoperable health information exchange. Commenters stated that they believed using the CoPs 
                        <PRTPAGE P="25591"/>
                        in this fashion was inconsistent with congressional intent for how HHS should regulate the use of health IT.
                    </P>
                    <P>Commenters also noted that HHS is currently seeking to establish a range of new policies designed to advance the interoperable exchange of health information. Commenters believed these policies could have a significant impact on the sharing of health information, including the sharing of patient event notifications, and that CMS should refrain from rulemaking through the CoPs until these polices have been finalized. One commenter also noted that, at the time the comment period on the CMS Interoperability and Patient Access proposed rule closed, CMS' Discharge Planning rule (80 FR 68125) had not yet been finalized, and that it would be premature to add this requirement in advance of finalizing related revisions to the discharge planning section of the CoPs.</P>
                    <P>Commenters further stated that HHS has a variety of other mechanisms for advancing electronic information exchange and improving the infrastructure for exchange that would be more effective than adding requirements to the CoPs. Several commenters expressed concern that using the CoPs would set static requirements that are ill-suited to an evolving technology environment and the innovation needed to increase adoption of notifications across providers.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' input. As noted above, we disagree with commenters who stated that the CoPs are not an appropriate mechanism for policy related to interoperability or the use of health IT. Existing CoPs address requirements related to medical records systems as well as the transfer of health information, and we believe there is no reason that these regulations should not address technology issues where the use of technology may be relevant to patient health and safety, provided that such references to technology in the CoPs do not lead to “static requirements” as noted by the commenter, and which we believe we have avoided doing in both the proposed and final rules. Furthermore, while a 2017 review of the current available scientific evidence on the impact of different health information technologies on improving patient safety outcomes, warned that health care organizations “need to be selective in which technology to invest in, as literature shows that some technologies have limited evidence in improving patient safety outcomes,” the review also stated that there “should be no doubt that health information technology is an important tool for improving healthcare quality and safety.” 
                        <SU>62</SU>
                        <FTREF/>
                         According to the authors of the review, evidence from a number of studies shows that health IT offers numerous opportunities for improving and transforming health care that includes the potential to reduce human errors, improve clinical outcomes, facilitate care coordination, improve practice efficiencies, and track data over time. Based on this evidence as well as the evidence directly related to patient event notifications that we cited previously, we believe that the requirements for patient event notifications that we have proposed and that we are finalizing in this rule will have a positive impact on many of these same areas, especially regarding the facilitation of care coordination for patients, leading to improved outcomes and enhanced patient health and safety.
                    </P>
                    <FTNT>
                        <P>
                            <SU>62</SU>
                             Alotaibi, Y., &amp; Federico, F. (2017). The impact of health information technology on patient safety. 
                            <E T="03">Saudi Medical Journal, 38</E>
                            (12), 1173-1180. doi: 10.15537/smj.2017.12.20631.
                        </P>
                    </FTNT>
                    <P>While we appreciate the importance of aligning policies across different programs to minimize provider burden, we believe that the proposed requirements are not addressed elsewhere and are appropriate for inclusion in the CoPs. Additionally, we disagree with commenters who stated that the proposed requirements will require hospitals to engage in duplicative reporting on information exchange since the proposed requirements do not require hospitals and CAHs to do any type of reporting to CMS in order to comply with the requirements. We also understand that other proposed or recently finalized policies may be relevant to the proposed requirements in this rule; however, we believe these policies will complement one another and serve to enable the proposed requirements around patient event notifications. As we noted above regarding the final rule published on September 30, 2019, Discharge Planning final rule (84 FR 51836), the revised discharge planning CoPs do not require hospitals, CAHs, and HHAs to transfer necessary patient medical information exclusively by electronic means, nor do they require that providers notify the appropriate providers, suppliers, and practitioners receiving the necessary medical information of the patient's discharge (or admission) as we are now are requiring in this final rule. We believe that the two rules, as written and finalized, do not conflict, but instead complement and support each other in CMS' goal of improving patient care transitions. Therefore, we disagree with the comments stating that the patient event notification requirements are premature or duplicative in relation to the final discharge planning requirements for hospitals, CAHs, and HHAs.</P>
                    <P>Regarding concerns that it will be challenging to update the CoPs to reflect changing technology requirements, our proposal sought to focus primarily on functional requirements that will allow hospitals the flexibility to pursue innovation and adapt their systems over time, similar to other functional requirements under the Medical Records Services CoP. Where we do reference a specific standard, in order to determine whether or not a hospital's system would be subject to the proposed “Electronic notifications” standard, we reference a content exchange standard at 45 CFR 170.205(d)(2) common to many EHRs that we believe is unlikely to undergo changes that would require frequent updates.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters stated that including these requirements under the CoPs would significantly increase the compliance burden for providers. Commenters believed that the proposed policy was contrary to other recent HHS burden reduction initiatives for providers. Commenters also believed that this proposal would add additional layers of regulation to what is a common practice for many hospitals today, further increasing provider burden.
                    </P>
                    <P>Several commenters stated that CMS had underestimated the burden associated with this proposal. They disagreed that implementing patient event notifications would be largely limited to a one-time cost, and stated that there would be substantial work required prior to implementing the proposal and continuous work around receiving notifications from other providers. Commenters suggested that CMS pursue other initiatives to alleviate costs, such as standardizing the data set for patient event notifications. Stakeholders also urged CMS to ensure that providers have cost-effective choices for required technology solutions, and to not create an environment that encourages over-pricing of solutions.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns about additional provider burden. While we understand that this new requirement may impose some additional implementation burden on hospitals, commenters also expressed that there are many ways for hospitals to minimize this burden through the use of existing technologies and services, such as health information exchanges and other service providers which capture notification information from a hospital's EHR and route it to 
                        <PRTPAGE P="25592"/>
                        appropriate recipients. We believe that there is sufficient flexibility in the current proposal to ensure hospitals have a broad range of options for implementation and will be able to comply in a way that aligns with their existing capabilities.
                    </P>
                    <P>
                        We believe that care coordination can have a significant positive impact on the quality of life, consumer experience, and health outcomes for patients. However, we acknowledge that though such activities can have positive impact, they will likely generate some costs. We believe it is difficult to quantify the impact of these changes because EHR implementation across care settings varies in maturity rates, leading to potential variance in cost and impact across such settings. Nonetheless, we have attempted to estimate the burden for those hospitals and CAHs that currently utilize electronic medical records systems or other electronic administrative systems that are conformant with the content exchange standard at 45 CFR 170.205(d)(2), and which generate information to support the basic messages commonly used for electronic patient event notifications, but which are not currently transmitting notifications. The cost of implementing these changes will include a one-time cost related to initial implementation of the notification system. Additionally, we have also estimated recurring maintenance costs for either those hospitals or CAHs that use hospital or CAH IT services staff to perform this recurring maintenance, or for those hospitals and CAHs that contract with third party outside services providers to perform this maintenance. We also stress that the requirements that we are finalizing here do not mandate that a hospital or CAH must purchase and implement a new EHR system. Rather, as finalized here, the provisions require a hospital or a CAH to demonstrate compliance with 
                        <E T="03">all</E>
                         of the provisions contained at 42 CFR 482.24(d), 482.61(f), and 485.638(d) 
                        <E T="03">only if</E>
                         it utilizes an electronic medical records system or other electronic administrative system that is conformant with the content exchange standard at 45 CFR 170.205(d)(2). We note here then that a hospital or a CAH that does not meet the basic requirements denoted in the standard language at paragraphs 42 CFR 482.24(d), 482.61(f), and 485.638(d) is exempt from demonstrating compliance with the requirements that follow and will not be surveyed for those specific provisions once a surveyor determines that the system used by the hospital or CAH is not conformant with the content exchange standard discussed here.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the proposal to limit the application of the proposed requirements to hospitals that possess a system capable of generating information for patient event notifications, while several disagreed with CMS and thought that CMS should not limit these requirements to only certain hospitals. Numerous commenters also sought additional information on how CMS will determine whether a hospital's system is subject to the proposed CoP standard. Commenters stated that the proposed rule did not indicate how surveyors would determine which electronic records systems possess required attributes, and that surveyors would not have the technical expertise required to make this determination.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In the CMS Interoperability and Patient Access proposed rule, we proposed to limit this requirement to only those hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications. We defined a system with this capacity as one that utilizes the ADT messaging standard, Health Level Seven (HL7®) Messaging Standard Version 2.5.1 (HL7 2.5.1)) incorporated by reference at 45 CFR 170.205(a)(4)(i). We noted that this standard is referenced by certification criteria related to transferring information to immunization registries, as well as transmission of laboratory results to public health agencies as described at 45 CFR 170.315(f), and that adoption of certified health IT that meets these criteria has been required for any hospital seeking to qualify for the Promoting Interoperability Program. We believe hospitals and surveyors will be able to determine whether an EHR system possesses the capacity to generate information for electronic patient event notifications, defined for the purposes of the CoP as a system conformant with the specified ADT messaging standard (HL7 2.5.1), based on existing requirements for other programs, such as the Promoting Interoperability Program. In general, we believe that information about whether a system complies with this provision will be easy to obtain from a hospital's health IT developer.
                    </P>
                    <P>As discussed below, we are finalizing a citation to the ADT messaging standard (HL7 2.5.1) at 45 CFR 170.205(d)(2).</P>
                    <P>
                        <E T="03">Comment:</E>
                         A commenter noted that in some instances a hospital's patient event notification system is connected to the hospital's registration system rather than its EHR system, which is used for clinical purposes only.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the comment and the opportunity to note here that the “electronic medical records system” described in the CoPs is not limited to the EHR system used for the management of clinical data. Hospitals would also be permitted to send patient event notifications using their registration system. Based on this comment, we are revising the language at 42 CFR 482.24(d), 482.61(f), and 485.638(d) in this final rule to now state that if the hospital (or psychiatric hospital or CAH), “. . . utilizes an electronic medical records system or other electronic administrative system,” then the hospital (or psychiatric hospital or CAH) would need to demonstrate that its system complies with the provisions that follow in this section.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         In the proposed rule we sought comment on whether we should identify a broader set of patients to whom this requirement would apply, beyond those admitted and treated as inpatients. For instance, we noted that a patient event notification could ensure a primary care physician is aware that their patient has received care at the emergency room, and initiate outreach to the patient to ensure that appropriate follow-up for the emergency visit is pursued (84 FR 7651).
                    </P>
                    <P>Many stakeholders responded to this request for comment by stating that they supported extending this policy to also include patients seen in a hospital's emergency department (ED). Commenters stated that requiring systems to be able to send these notifications would be an important way to support better care coordination and prevent unnecessary repeat visits to the emergency department. Commenters also suggested that this requirement should include patients seen in the hospital for “observational” stays, but who are not admitted as inpatients.</P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with the commenters that ED patients should be included in the patient event notification system, and have revised the regulatory text at 42 CFR 482.24(3)(i) and (4)(i), 482.61(3)(i) and (4)(i), and 485.638(3)(i) and (4)(i) to include these patients. Many patients registered in the ED are eventually discharged home after being treated, while others are either held for observation in a hospital bed as outpatients or admitted as inpatients to the hospital. The revisions we are finalizing here would require a hospital's system to send patient event notifications for patients who are registered in the ED, if applicable, and then also for patients admitted as 
                        <PRTPAGE P="25593"/>
                        inpatients, regardless if the patient was admitted from the ED, from an observation stay, or as a direct admission from home, from their practitioner's office, or as a transfer from some other facility. We agree with the commenters and believe that if we were not to include ED patients in the notification requirements in this final rule, we would miss an important opportunity for positively impacting the care transitions and the continuing care of a significant number of patients seen in the nation's hospital emergency departments. Including ED patients in the patient event notification requirements is consistent with the purpose of the CoPs as a regulatory means of promoting and protecting the overall health and safety of 
                        <E T="03">all</E>
                         hospital patients, regardless of their physical location in the hospital.
                    </P>
                    <P>
                        To illustrate when a patient event notification is, and is not, required, we would like to point out the following scenarios. A hospital's system would be expected to send one notification when a patient is first registered in a hospital's ED or as an observational stay (that is, in both of these cases, the patient would be considered an outpatient and not an inpatient at this point in time), and a second notification if the same patient was then later admitted to a hospital inpatient services unit (for example, medical unit, labor and delivery unit, telemetry unit, neurology unit, surgical unit, intensive care unit (ICU), etc.), or if the same patient was admitted for inpatient services, but was being boarded in the ED while waiting for an inpatient unit bed. In contrast, a second patient event notification would 
                        <E T="03">not</E>
                         be required if an already admitted inpatient was transferred from one inpatient services unit of the hospital to another (for example, if the patient was admitted to the hospital's ICU, but was then later transferred to the hospital's “step-down” or “intermediate care” unit or to a medical unit, in which case, the patient continued to remain an inpatient of the hospital), or if an already admitted patient was being boarded in the ED and then was transferred to an inpatient unit when a bed became available. However, while the requirements do not prohibit a hospital from electing to send a patient event notification when a patient is transferred to one inpatient services unit of the hospital to another, the requirements finalized in this rule are based on a change in the patient's status from outpatient to inpatient, and not necessarily on the physical location of the patient.
                    </P>
                    <P>Finally, in all cases, a patient's discharge or transfer from the hospital, either from the ED or an observational stay or an inpatient services unit, would still require the hospital to send another and separate patient event notification to the applicable entities as required under this rule.</P>
                    <P>
                        <E T="03">Comment:</E>
                         We proposed that hospitals should send notifications to those practitioners or providers that have an established care relationship with the patient relevant to his or her care (84 FR 7652). Many commenters sought additional information about the term “established care relationship” and how hospitals should discern who has an established care relationship with a patient. Commenters noted that the list of providers who have an “established care relationship” with a patient could be very extensive and requested more information on the extent of the specialization of care team members covered by the requirement. One commenter suggested CMS indicate that the term “established care relationship” only applies to one that is current and directly related to the patient's diagnosis for which the notification is sent. Another commenter suggested that CMS define “established care relationship” as the principle physician identified by the patient and any institution that the patient identifies. Several commenters suggested that CMS replace the term “established care relationship” with “active relationship,” and noted that this would also ensure payers received the notifications, as their relationship with a patient may not be included under the definition of a “care” relationship. One commenter suggested that CMS note that hospitals have the latitude to choose the recipient of the notification. Commenters also sought direction on how hospitals should approach a situation in which a patient does not have a primary care provider, or in which a provider who has an established care relationship with the patient cannot be easily identified. Several commenters noted that effective notification systems are often organized around a subscription model, in which receiving providers are responsible for identifying those patients for whom they would like to receive notifications.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' input. We agree that the term “established care relationship” could be subject to an overly broad interpretation that is not consistent with our goal to set a minimum floor for these requirements under the CoPs. Accordingly, we are finalizing a more limited set of recipients to whom a hospital's system must send patient event notifications for the purposes of meeting this CoP. We are finalizing at 42 CFR 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5) requirements that the hospital's system send notifications to the following recipients as applicable: The patient's established primary care practitioner; the patient's established primary care practice group or entity; or other practitioners or practice groups or entities, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. We believe that the use of the modifier “established,” as finalized here in the context of a patient's established primary care practitioner or his or her established primary care practice group or entity, more clearly signifies a care relationship that the patient recognizes as primary or one that is evidenced by documentation of the relationship in the patient's medical record. As an example, if the patient's established primary care practitioner refers the patient to the hospital, this primary care practitioner should receive the event notification. We believe this language improves upon the proposed term “established care relationship,” which commenters correctly noted is too vague in meaning, too broad in scope, and too open to various interpretations, all of which could prove burdensome for hospitals to demonstrate compliance with the requirements here. We note that this final policy does not prevent a hospital from sending patient event notifications to other practitioners, in accordance with all applicable laws, who may be relevant to a patient's post-discharge care and would benefit from receiving patient event notifications, nor would it prevent a hospital from seeking to identify these other practitioners. However, we believe this more limited set of recipients is more appropriate to our goal of setting baseline requirements and will provide hospitals with sufficient specificity to comply with the requirements.
                    </P>
                    <P>
                        In cases where a hospital is not able to identify a primary care practitioner for a patient, the patient has not identified a provider to whom they would like information about their care to be sent, or there is no applicable PAC provider or supplier identified, we would not expect a hospital to send a patient event notification for that patient. We note that under the CoP, a hospital would be required to demonstrate that its system sends notifications to appropriate recipients. We expect that hospitals would demonstrate this capability in variety of ways, for instance, by demonstrating that the hospital has processes and policies in place to identify patients' primary care practitioners and 
                        <PRTPAGE P="25594"/>
                        incorporate this information into the patient event notification system, or through recording information received from patients about their providers.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters stated that obtaining information about providers who have an “established care relationship” with a given patient and maintaining lists of these providers and contact information for delivery of patient event notifications would impose significant burden on hospitals. One commenter noted that patients may not reliably provide information about their providers, and recommended that in those cases the recipient of the patient event notification should identify their relationship with a patient in advance.
                    </P>
                    <P>Several commenters noted that, to the extent hospitals already have operational processes and infrastructure in place to determine destinations for notifications, these processes should be left in place. Several commenters noted that, in order to successfully route messages to the appropriate provider, hospitals would need to be able to overcome challenges associated with patient matching: The ability for a hospital to accurately match records about a patient with the records held by a receiving provider. Commenters stated that challenges with patient matching could inhibit patient event notifications from being received by the correct provider and will lead to frequent pushback from providers about receiving notifications regarding patients they are not affiliated with. Commenters also noted the importance of community-wide directories that map the address of a provider to their electronic endpoint destination, which would allow a hospital to query a directory and find the destination of the patient's choice.</P>
                    <P>
                        <E T="03">Response:</E>
                         As noted, we are finalizing a more limited minimum set of recipients for patient event notifications than originally proposed. This set of recipients is focused on a patient's established primary care practitioner (or established primary care practice group or entity) or any other practitioner (or practice group or entity) identified by the patient as primarily responsible for his or her care. However, we are retaining inclusion in this final rule of PAC providers and suppliers as required recipients of notifications as originally proposed. In order to clarify the PAC services providers and suppliers that are required recipients, we are modifying this proposal to refer to “all applicable PAC services providers and suppliers.” For purposes of this policy, applicable PAC services providers and suppliers would be those PAC services providers and suppliers with whom the patient has an established care relationship prior to admission or to whom the patient is being transferred or referred. Similar to our modification to reference the patient's established primary care practitioner, these PAC services providers and suppliers would be those with an established care relationship immediately preceding the hospital registration or admission (such as a PAC services provider or supplier from which the patient was transferred to the hospital) or those with which a relationship is being established for purposes of treatment and/or care coordination post-discharge from the hospital. The potential recipients of patient event notifications will be limited to only those that need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes. We believe that this final policy will reduce potential operational burden associated with a broader “established care relationship” definition. We believe that increasing numbers of hospitals now commonly seek to identify patients' primary care practitioners and their contact information, including any digital contact information, or partner with intermediaries that identify primary care practitioners, and that many hospitals will be able to continue to use their existing processes to satisfy the CoP. If a hospital has processes in place for identifying patients' primary care practitioners and other applicable providers, but is not able to identify an appropriate recipient for a patient event notification for a specific patient, the hospital would not be expected to send a notification for that patient.
                    </P>
                    <P>
                        Research using CMS data on readmission rates in Medicare-participating hospitals from 2007 to 2015 shows that the readmission rates for targeted conditions (that is, a set of specific diagnoses measured by Medicare) declined from 21.5 percent to 17.8 percent, and rates for non-targeted conditions declined from 15.3 percent to 13.1 percent.
                        <SU>63</SU>
                        <FTREF/>
                         While this decline in readmissions rates is attributable to multiple factors, we believe that one of the significant factors driving down avoidable patient readmissions is identification by the hospital of the patient's established primary care practitioner (or practice group) and his or her contact information prior to discharge and/or transfer. Increased and early identification of the patient's primary care practitioner is more likely to lead to more accurate and timely transfer of patient health information from hospital-based practitioners to community-based primary care practitioners. Additionally, early identification of a patient's primary care practitioner along with the patient event notification to the practitioner that his or her patient is about to be discharged from the hospital is most likely to have a net positive effect on scheduled post-discharge follow-up rates for patients most at risk for avoidable readmissions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>63</SU>
                             Alper, E., O'Malley, T.A., &amp; Greenwald, J. (n.d.). Hospital discharge and readmission. Retrieved from 
                            <E T="03">https://www.uptodate.com/contents/hospital-discharge-and-readmission.</E>
                        </P>
                    </FTNT>
                    <P>
                        We appreciate commenters concerns about patient matching challenges. This is a larger issue beyond the scope of this CoP proposal and this current rule, but we will consider this issue for future revisions and updates to the CoPs. With the continued increase in the use of electronic data in health care organizations and among providers of health care services, there has been a continued need for patient matching, or patient identity management (PIM) processes, in health care organizations, including hospitals. PIM has been defined as the ability to uniquely ascertain the identity of a patient, assign that patient's record an identifier that is unique within the organization, system, or exchange network, and match that patient's record within and between systems using a number of demographic data elements, such as the patient's first name, last name, address, and date of birth. Effective PIM supports patient identity integrity, which the National Association of Healthcare Access Management defines as accurately identifying and matching the right patient with his or her complete medical record, every time, in every provider setting.
                        <SU>64</SU>
                        <FTREF/>
                         Accurate patient identity management is critical to successfully delivering the right care to the correct patients.
                    </P>
                    <FTNT>
                        <P>
                            <SU>64</SU>
                             National Association of Healthcare Access Management. (2016, March 17). NAHAM Public Policy Statement on Patient Identity Integrity. Retrieved from 
                            <E T="03">https://nahamnews.blogspot.com/2016/03/naham-public-policy-statement-on.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        Capturing incorrect or incomplete data can result in critical patient care issues and risk privacy breaches. Health care organizations are more likely to have their EHR system filled with duplicate patient records and inaccurate information about their patients when they are not managing an effective PIM process. Having an ineffective PIM process will most definitely negatively impact a hospital's patient event notification system, which is one of the many reasons why a rigorous PIM process is essential to patient care as health IT moves forward. Additionally, PIM has become crucial in order to (1) 
                        <PRTPAGE P="25595"/>
                        enable health record document consumers to obtain trusted views of their patient subjects; (2) facilitate data exchange projects; (3) abide by the current regulations concerning patient information-related transparency, privacy, disclosure, handling, and documentation; and (4) make the most efficient use of limited health care resources by reducing redundant data collection.
                        <SU>65</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>65</SU>
                             Gliklich, R., Dreyer, N., &amp; Leavy, M. (Eds.). (2014). 
                            <E T="03">Registries for Evaluating Patient Outcomes: A User's Guide</E>
                             (3rd ed.). Rockville, MD: AHRQ Publication. Retrieved from 
                            <E T="03">https://www.ncbi.nlm.nih.gov/books/NBK208616/.</E>
                        </P>
                    </FTNT>
                    <P>Nationally recognized practices and standards for ensuring patient identity integrity have been identified by organizations such as the National Association of Healthcare Access Management, American Health Information Management Association, the Agency for Healthcare Research and Quality, and ONC. These standards include standardizing demographic data fields and internally evaluating the accuracy of patient matching within health care organizations.</P>
                    <P>We believe this presents an opportunity for the health IT industry to lead the way in developing innovative solutions to patient matching, or PIM, that can benefit all facets of the health care industry. However, appreciating the importance of accurate patient matching, CMS will continue to evaluate ways to support improved patient matching solutions.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested additional provider types that should receive patient event notifications. For instance, commenters suggested health plans should be included on the list of recipients for patient event notifications, noting that this information would be valuable to plans responsible for coordinating services for beneficiaries and reducing readmissions. One commenter also recommended sending notifications to public health departments. Several commenters also requested that specific health care professionals be identified as recipients. Commenters also suggested that other caregivers such as relatives be included on the list of recipients.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions about adding additional recipients for patient event notifications. While there may be other entities that could benefit from receiving patient event notifications, we believe it is more appropriate for the purposes of the CoP requirements to focus on a minimal set of recipients for notifications. This approach would not preclude hospitals from sending notifications to other entities, including health plans, provided hospitals comply with applicable laws and regulations regarding sharing of patient data.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters suggested that CMS should consider approaches that aim to incentivize providers to implement patient event notifications, rather than requiring hospitals to do so through the CoPs. Commenters stated that adding this requirement would result in unnecessary and burdensome duplication of requirements that hospitals are already subject to as part of existing programs focused on advancing health information exchange. Specifically, many commenters recommended that CMS seek to advance these goals through the Promoting Interoperability Program. Commenters suggested CMS consider adding a measure to the program based on patient event notifications, noting that such a measure could mirror the “active engagement” concept currently used for public health measures under the program or be assessed through an attestation similar to current attestations related to information blocking. Several commenters also noted our discussion of potentially establishing a set of “health IT activities” under the Promoting Interoperability Program (84 FR 7618) that would not be linked to performance measures, noting that such a concept would be well-suited to advancing patient event notifications. One commenter noted that the Promoting Interoperability Program, with its annual performance assessment, is more appropriate to supporting progress on technology goals than the CoPs, and that a measure reported annually could better assess the degree to which providers are improving their usage of patient event notifications.
                    </P>
                    <P>Commenters also recommended other alternative strategies that CMS could engage in to incentivize use of patient event notifications, such as models established under Innovation Center authority. Commenters believed that highlighting the use of patient event notifications in connection with alternative payment models could help to strengthen the business case for this intervention. Another commenter recommended that the use of patient event notifications could be incentivized through an offset or bonus in a hospital-focused quality program, or through offering regulatory flexibility (for instance around telehealth) to hospitals that choose to implement a system for notifications.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions to encourage the use of patient event notifications through the Promoting Interoperability Program. In order for an action to serve as the basis for a measure under the Promoting Interoperability Program, the action must require the use of certified health IT. As discussed in the CMS Interoperability and Patient Access proposed rule, at this time there is no certification criterion included in ONC's certification program for the creation and transmission of patient event notifications (84 FR 7651). As discussed elsewhere in this final rule, ONC does not believe there is a widely adopted consensus standard for patient event notifications at this time. ONC will continue to monitor adoption of standards for this use case and consider whether it would be appropriate to develop a certification criterion for this functionality. Accordingly, we believe it would not be feasible to add a measure related to patient event notifications to the Promoting Interoperability Program at this time.
                    </P>
                    <P>We appreciate commenters input about other programs that could advance the use of patient event notifications, such as models established under Innovation Center authority, and will take these under consideration.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters addressed the use of the ADT standard for patient event notifications. One commenter noted that the ADT messaging standard is very broad and that implementations are subject to significant variability and customization. Commenters highlighted the fact that there is significant variation in the implementation of the ADT standard, limiting interoperability across interfaces using this standard, and suggested that CMS clarify specific content and triggering events for ADT data exchange. Another commenter noted that the lack of an implementation guide for the use of ADT messages for notifications is challenging, as this guidance is essential for understanding what information must be sent and how. Commenters who believed that the reference to the ADT standard would require the establishment of new interfaces for exchanging ADT messages stated that recipient providers would not be able to receive ADT messages if they do not have an inbound ADT interface in place. Many commenters believed that specifying the HL7 2.5.1 ADT message standard would be overly restrictive and recommended that CMS not specify a specific standard for these transactions at this time. Commenters urged CMS to focus on creating functional requirements rather than identifying specific mechanisms or standards for 
                        <PRTPAGE P="25596"/>
                        the data. Other commenters stated that any standard should be required as a floor, rather than a ceiling. One stakeholder recommended that CMS compile stakeholder feedback to better understand which standard would be preferred by the industry.
                    </P>
                    <P>Several commenters supported adoption of the ADT message standard (HL7 2.5.1), stating that it is the most frequently used standard for the transmission of patient event notifications. One commenter urged CMS to avoid policies that allow a hospital to deviate from a required standard, and to align with standards proposed by ONC to ensure consistency across different types of data exchange.</P>
                    <P>One commenter suggested that CMS explore moving to later versions of the HL7 2.5.1 standard, which provide additional message types, segments, and codes while others noted that additional work will be needed by standards setting bodies such as HL7 to develop a more robust standard in the future.</P>
                    <P>Other commenters supported the flexibility discussed in the CMS Interoperability and Patient Access proposed rule with respect to using other standards and features to support sending patient event notifications. One commenter supported the flexibility provided in the proposed rule, but believed that this flexibility may introduce challenges for those providers receiving and incorporating information provided by a hospital.</P>
                    <P>Several commenters urged CMS to not require the use of certified EHR technology (CEHRT) to send ADT messages, noting that hospitals currently use a variety of solutions to send patient event notifications. One commenter noted that the HL7 protocol cannot be sent using Direct messaging or other exchanges used for continuity of care documents. One commenter noted that ADT information is not available in real time, and that an open API for both the hospital and receiving provider would be needed to enable real-time notifications. Commenters recommended that CMS instead focus on the use of standards-based feeds from the hospital's technology of choice.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' feedback. We recognized in the CMS Interoperability and Patient Access proposed rule that there is currently significant variation in how hospitals have utilized ADT messages to support implementation of patient event notifications (84 FR 7651). In recognition of this current state, we proposed to require that a hospital would be subject to this CoP if its system complied with the ADT messaging standard, but we did not propose to require that hospitals use a specific standard to format or deliver patient event notifications. We believe this flexibility is necessary due to significant variation in how HL7 2.5.1 messages have been used to support notifications, and allows providers to use other standards for structuring and delivering this information that they may be currently using to implement patient event notifications, or may prefer to use for other reasons.
                    </P>
                    <P>As noted, our intent is to allow flexibility; therefore, we have refrained from specifying a standard for delivery of patient event notifications that could be overly limiting for hospitals. We are finalizing revised regulation text at 42 CFR 482.24(d), 482.61(f), and 485.638(d) that specifies that a hospital system's conformance with the ADT standard will be used solely to determine whether a hospital is subject to the CoP. Requirements regarding the content and format of the patient event notifications, which a hospital's system must send to satisfy the CoP, are limited to the minimal information elements described elsewhere in this final rule. We are not specifying a standard for the content, format, or delivery of these notifications.</P>
                    <P>We also note that we did not specify that hospitals must use a specific technology to send patient event notifications; for instance, we did not specify that a hospital must use the capabilities of certified health IT to send notifications, nor that hospitals must send notifications via an interface adhering to the HL7 messaging standard. We hope that this response addresses commenters' concerns, and clarifies that the reference to the HL7 messaging standard in these requirements does not preclude use of other standards for transporting patient event notifications. In addition, we note that our understanding is that many successful patient event notification implementations have used the content of HL7 messages in conjunction with other forms of transport, such as Direct messages.</P>
                    <P>While we agree with commenters that common usage of a single, strictly defined standard would increase interoperability for these transactions, we do not believe that this is possible at this time. At the same time, we strongly encourage hospitals, and any intermediaries a hospital may partner with, to adopt standards-based approaches to the structure and transmission of patient event notifications, including the many standards-based solutions described by commenters. We acknowledge that, at this time, the use of different standards may result in decreased ability for certain providers to receive notifications from sending hospitals, depending on the attributes of their respective systems. We will consider whether there are additional ways we can encourage hospitals to move towards increased interoperability for these transactions in the future.</P>
                    <P>We also wish to address and clarify a discrepancy in the way we referenced the ADT messaging standard in the proposed rule. Specifically, in the preamble of the proposed rule we cited 45 CFR 170.299(f)(2), where the HL7 2.5.1 messaging standard is listed for incorporation by reference. However, in the regulation text of the proposed rule, we erroneously cited to 45 CFR 170.205(a)(4)(i), which contains the C-CDA standard instead of HL7 2.5.1. The C-CDA standard is referenced in certification criteria related to summary of care records (84 FR 7678). As discussed above, we are finalizing our policy that a hospital will be subject to the requirements in this section if it uses a system conformant with the HL7 2.5.1 content exchange standard, which indicates a system has the basic capacity to generate information for patient event notifications. In this final rule, we are revising the regulation text and finalizing a citation to the HL7 2.5.1 content exchange standard where it is currently referenced at 45 CFR 170.205(d)(2). We believe that this citation is the most appropriate way to reference the HL7 2.5.1 standard.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters requested that CMS indicate whether it would be acceptable to transmit information using other standards than the ADT message, specifically delivering messages using the C-CDA standard, which providers must use to satisfy the requirements of the transitions of care measures under the Promoting Interoperability Programs. Several commenters stated that they would prefer to format messages using this standard, which they already use for the Promoting Interoperability Program, and that a requirement to deliver messages according to the HL7 ADT messaging standard would result in duplicative work. Others questioned whether transmitting notifications via a FHIR®-based API would be permissible.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In the proposed rule, we stated that a hospital's medical records system is a compliant system if it utilizes the ADT messaging standard. However, we did not propose a specific format or standard for the patient event notification that a hospital would be required to send under the proposed CoP. Thus, hospitals would be allowed to transmit patient event notifications 
                        <PRTPAGE P="25597"/>
                        using other standards, such as the C-CDA or via a FHIR-based API.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the inclusion of diagnosis in patient event notifications where permitted by law, stating that this information is helpful for supporting care coordination between a hospital and other providers. One commenter noted that this information can be included by leveraging certain segments of the HL7 ADT feed, and that this segment can also be filtered for sensitive diagnoses that are prohibited for transmission under certain state or federal laws.
                    </P>
                    <P>A number of commenters expressed concerns about requiring the inclusion of diagnosis, noting that hospitals may not have this information at the time of admission, when only the presenting symptom may be available, or immediately at discharge. Other commenters noted that while this is important information for improving care coordination, diagnosis is not included in the most basic versions of the HL7 ADT messaging standard. Other commenters noted that clinical data is more appropriate for transfer through other standards for sharing clinical data, such as the C-CDA standard, which is specified to support the exchange of clinical summaries using certified health IT. These commenters noted that rather than requiring the inclusion of diagnosis in the patient event notification, it would make more sense to allow hospitals to transfer this information by attaching a clinical summary to the notification, or by providing this information upon request from a receiving provider.</P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters that diagnosis is an important data element to share during care transitions. However, our intention for this proposal has been to set a minimal floor for patient event notifications, allowing for significant flexibility, in recognition of the wide variety of ways that providers are currently implementing patient event notifications. We are concerned that the proposed requirement to include diagnosis could introduce unnecessary burden for hospitals that will be seeking to satisfy this requirement utilizing the most basic information available in an ADT message to support patient event notifications. As a result, we are not finalizing a requirement that diagnosis must be included in patient event notifications at 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2). We wish to reiterate that this final policy in no way precludes hospitals from including additional information, such as diagnosis, in a patient event notification. We also note that hospitals are required to send other necessary medical information to receiving providers under the hospital CoP on Discharge Planning at 42 CFR 482.43. In addition, certain clinical information such as diagnosis is included in the summary of care record which hospitals must be capable of transferring electronically in order to meet the health information exchange measures under the Promoting Interoperability Program.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested CMS require hospitals to include additional informational elements in patient event notifications, such as: Discharge disposition; chief complaint; medication profile; insurance policy coverage information; additional information about the hospital, such as address and tax ID; contact information for a variety of resources such as social services agencies and legal assistance providers; and other information that can be used for patient matching. Commenters believe that additional information would have a positive impact on care coordination. Other commenters supported the proposal to require only a limited data set. One commenter recommended that CMS impose additional parameters on the information included as part of patient event notifications, including a requirement that data must be recent and relevant to patient care.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' suggestions, and agree that this additional information can have a positive impact on care coordination, patient matching, and other requirements. However, we do not believe that this information should be required within the CoPs for patient event notifications. We have heard from many stakeholders that even patient event notifications with extremely limited information can have a positive effect on care coordination when they are delivered in a timely manner. In addition, we understand that hospitals are currently delivering patient event notifications with widely varying sets of information. Finally, we note that hospitals are required to send other necessary medical information to receiving providers under the hospital CoP on Discharge Planning at 42 CFR 482.43. While we decline to require additional data at this time, to ensure that hospitals are able to satisfy the requirement with minimal effort, we encourage hospitals to consider other information that can be added to patient event notifications to support care coordination.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters suggested that CMS work with ONC to add a certification criterion or a condition of certification related to the transmission of patient event notifications under ONC's certification program. Many commenters stated that hospitals should not be required to comply with the proposed requirements until they have had an opportunity to adopt certified technology supporting these requirements. Commenters believed this would assure hospitals that their systems are compliant with the proposed requirements. Moreover, commenters expressed concern that without complementary regulation directed toward health IT developers, the burden for ensuring these technical capabilities would rest on hospital providers alone. Some commenters suggested that ONC should also include data elements related to patient event notifications in the USCDI, or seek to standardize notification data elements in another way, to ensure that notifications can be received by other EHR systems. Commenters also pointed to a variety of emerging initiatives which focus on barriers to information exchange, such as TEFCA, policies to address information blocking, and updates to API technology under the ONC certification program. Commenters urged CMS to leverage these initiatives to advance the use of patient event notifications, for instance, by incorporating patient event notification functionality through the networks established as part of TEFCA.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' input. As we noted in the CMS Interoperability and Patient Access proposed rule, there is currently no certification criterion specific to creating and sending electronic patient event notifications included in ONC's certification program (84 FR 7651). While ONC monitors the development of consensus standards for patient event notifications as part of its ISA (
                        <E T="03">https://www.healthit.gov/isa/admission-discharge-and-transfer</E>
                        ), ONC has not yet proposed to develop a certification criterion based on any of these standards. Instead of focusing on the use of a specific certification criterion, we have sought to allow hospitals flexibility in how they satisfy the proposed CoP. We believe this is consistent with current practices around patient event notifications that have been implemented in a wide variety of ways across hospitals. We appreciate that many other policy initiatives may intersect with how hospitals implement patient event notification requirements. While we believe that providers will be 
                        <PRTPAGE P="25598"/>
                        able to implement patient event notifications based on existing systems and infrastructure, we believe that many of the initiatives commenters mentioned will help to enable and enhance notification capabilities as they are introduced.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A number of commenters stated that the proposal would disproportionately burden rural and critical access hospitals. Commenters noted that providers in these settings may not have an EHR system, or may be unable to upgrade to the newest edition of certified technology. For small and rural providers that do have an EHR system, commenters expressed concern about the implementation costs providers would need to incur as they work with their EHR vendors to deploy new functionality. Commenters noted that, while working with an intermediary could substantially reduce the burden associated with this proposal, many small and rural hospitals are operating in geographic areas that are not yet served by entities such as health information exchanges that could serve as intermediaries, requiring these hospitals to dedicate significant resources to developing a compliant solution. This lack of access to appropriate infrastructure would put small and rural hospitals at disproportionate risk of noncompliance with the CoP standard, despite the significant effects penalties for noncompliance may have on underserved communities. Several commenters raised concerns about these providers' ability to shoulder compliance costs with the proposed requirements, and suggested CMS provide funding opportunities to these hospitals to mitigate the potential burden associated with the proposal.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns about the impact of this proposal on small, rural, and critical access hospitals (CAHs). We note that those hospitals without an EHR system with the technical capacity to generate information for electronic patient event notifications, defined as a system conformant with the ADT messaging standard (HL7 2.5.1), will not be subject to this final rule. Furthermore, we believe that changes finalized in this rule will ease some of the potential compliance burden associated with the rule, and make it easier for these hospitals to comply successfully with the CoP standard. For example, our final policy extends the applicable date for the requirements as well as defining a more limited set of a recipients to whom hospitals must send notifications for the purposes of compliance with the CoP.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters noted that patient event notifications are most effective when they take into account receiving providers' preferences. Commenters noted that recipients need flexibility to determine the information that they want to be notified about, the frequency of notification delivery, and how they would like notifications delivered; otherwise providers may experience “signal fatigue” due to receiving an excessive number of messages that do not contain information the provider finds useful. Commenters expressed concern that, under the proposed requirements, hospitals would not have flexibility to take into account receiving providers' preferences for receiving patient event notifications. They further believed that the proposed requirements would result in hospitals sending information to all providers regardless of their interest in receiving notifications, while implementation experience has shown that notifications are more successful when receiving providers can request the information they would like to receive.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns about the importance of incorporating provider recipients' preferences when implementing patient notification systems. We understand from stakeholders that a key feature of successful patient event notification implementations is flexibility with respect to the manner in which notifications are delivered, to allow for better alignment with individual providers' workflows. Without such flexibility, providers are more likely not to find notification systems useful, reducing their effectiveness to improve care coordination.
                    </P>
                    <P>We note that under the proposed requirement, hospital systems must send patient notifications in accordance with the proposed requirements. However, this would not preclude hospitals, working either directly with providers or through an intermediary, from tailoring the delivery of patient notifications in a manner consistent with individual provider preferences. For instance, while a hospital's system must be able to send notifications at both admission and discharge, as well as at the time of registration in the emergency department, if a specific provider prefers only to receive notifications upon discharge, nothing would prevent the hospital from limiting the notifications sent to that provider accordingly.</P>
                    <P>We note that our revised regulation text states that hospitals must send notifications to those recipients that “need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes.” We believe that this standard will allow hospitals the discretion to determine which recipients need to receive notifications, for instance, by declining to send certain notifications where a practitioner has stated that such notifications are not necessary or effective for supporting care coordination. In cases where the hospital has partnered with an intermediary to deliver notifications, the intermediary may exercise this discretion on behalf of a hospital.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the proposal to allow use of an intermediary to deliver patient event notifications. Commenters stated that use of an intermediary could reduce operational burden on hospitals by maintaining recipient information, supporting more effective patient matching, and delivering notifications in accordance with receiving providers' preferences. Commenters pointed to numerous examples of how intermediaries, such as health information exchanges, are successfully facilitating the delivery of more complete and accurate patient event notifications from today.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their support and agree that the use of intermediaries to deliver patient notifications can reduce burden on hospitals and support effective notification systems.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters sought additional information on our proposals with respect to the use of an intermediary, and whether exclusive use of an intermediary, provided other requirements are met, would satisfy the CoP. Commenters stated that they believe hospitals should be able to exclusively make use of an intermediary. Other commenters suggested that CMS should “deem” a hospital compliant with the CoP if they demonstrate that they are using an intermediary to deliver notifications, as long as the intermediary has not been found to violate information blocking rules.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In the CMS Interoperability and Patient Access proposed rule, we stated that, if finalized, hospitals would be required to send notifications “directly or through an intermediary that facilitates exchange of health information.” We believe this would allow exclusive use of either method, or a combination of these methods, provided other requirements of the CoP are met. For instance, if a hospital makes exclusive use of an intermediary to satisfy the CoP, the hospital would still be subject to the requirement that 
                        <PRTPAGE P="25599"/>
                        notifications must be sent to the set of recipients we are finalizing in this rule, specifically all applicable post-acute care services providers and suppliers as well as a patients' primary care practitioners or practice groups and entities primarily responsible for a patient's care, as well as practitioners identified by the patient. Given this requirement, exclusive use of an intermediary with a limited ability to deliver notifications to the specified set of recipients, for instance an intermediary which restricts its delivery to only those providers within a specific integrated health care system, would not satisfy the CoP. Alternatively, if a hospital demonstrates that an intermediary connects to a wide range of recipients and does not impose restrictions on which recipients are able to receive notifications through the intermediary, exclusive use of such an intermediary would satisfy the CoP.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters sought additional information on whether it would be permissible for a hospital to delegate responsibility for making a determination about the existence of a patient's care relationships to an intermediary that facilitates delivery of a patient notification.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         In the CMS Interoperability and Patient Access proposed rule we discussed a variety of methods through which hospitals can identify recipients for patient notifications, including through partnering with intermediaries such as health information exchanges (84 FR 7652). We reiterate that we believe this is one way that hospitals are currently identifying recipients for notifications, and that using an intermediary to do so may reduce operational burden for hospitals. Thus, hospitals would be permitted to delegate this authority.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters requested additional information on whether ACOs would be entitled to receive patient event notifications. Commenters stated that ACOs represent groups of providers and suppliers and work directly on their behalf. Therefore, it was unclear whether they would be considered intermediaries or providers and suppliers for the purposes of the proposed CoP. Commenters stated that patient event notifications are used by many ACOs today, and that ACOs both receive notifications directly from hospitals and through other intermediaries such as health information exchanges.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We note that the proposed CoP does not create an entitlement for any specific provider or intermediary to receive patient event notifications. Rather, it requires hospitals to demonstrate that their medical records system sends patient event notifications in a manner compliant with the proposed requirements. We believe there is nothing in the proposed requirements that would prevent ACOs that have business associate relationships with the intended primary care practitioner or practice group or entity from receiving patient event notifications on behalf of that practitioner, group, or entity so long as their business associate agreement allows them to fulfill that role.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested that CMS should develop a mechanism for allowing community providers to report that they have not received notifications from a given hospital, or that the notifications received are incomplete or unreasonably delayed. Commenters believe that such a mechanism would ensure patient event notification systems are functional and help to establish delivery parameters across a community.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' input, but are unclear here as to whether the commenters are requesting that we develop a regulatory mechanism within the CoP provisions to allow for a community provider to report to a hospital any issues it may be experiencing with the hospital's notification system or if the request is for CMS to develop some other type of mechanism to accomplish this, such as an incentive-based payment mechanism as a means of encouraging a hospital to include this reporting function as part of its notification system. If it is the latter type of request, then such a mechanism would be outside the scope of the CoPs and this section of the rule. However, if it is the former type of request, we will consider these ideas as we evaluate future updates and revisions to the CoPs with regard to patient event notifications.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         We proposed that a hospital would only need to send notifications to those practitioners for whom the hospital has reasonable certainty of receipt (84 FR 7652). We further explained that we expected hospitals would, to the best of their ability, seek to ensure that notification recipients were able to receive notifications, but that we recognized that factors outside of the hospital's control may determine whether or not a notification was successfully received and utilized by a practitioner.
                    </P>
                    <P>Many commenters stated that a standard of “reasonable certainty” would hold hospitals responsible for factors outside of their control that prevent delivery of notifications, and that hospitals should only be held accountable for transmission of information, not receipt. Commenters stated that it would be very difficult for hospitals to obtain reasonable certainty given the limitations of the infrastructure that is currently available for sharing health information. Several commenters believed that the phrase “reasonable certainty” would impose a new affirmative duty to validate receipt of notifications, which would result in significant additional administrative burden for hospitals. Several commenters suggested that CMS replace the term “reasonable certainty” with alternatives such as “reasonable effort” or “reasonable confidence.” They believed these alternative standards would better reflect actions within the hospital's control.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' feedback. In proposing that hospitals send notifications to those practitioners for whom the hospital has reasonable certainty of receipt, we sought to adapt a similar standard currently identified in guidance for the Promoting Interoperability Program (see 
                        <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/MedicareEH_2019_Obj2-.pdf</E>
                        ) regarding the expectations of participants in that program when they transfer a summary of care record to another provider. However, we concur with commenters that a standard of “reasonable certainty,” while appropriate for the Promoting Interoperability Program, in which participants are required to use certified technology for the transmission and receipt of summary of care documents, may not be appropriate in the context of this proposal, which permits flexibility in both the technology used to send and receive patient event notifications and the format of the notification itself. We agree that a standard that better reflects actions within the hospital's control would be much more appropriate in this circumstance. Accordingly, we are revising our final policy (at 42 CFR 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5)) to now require that a hospital (or a CAH) must demonstrate that it “has made a reasonable effort to ensure that” the system sends the notifications to any of the following that need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes to all applicable post-acute care services providers and suppliers and: (1) The patient's established primary care practitioner; (2) the patient's established primary care practice group or entity; or (3) other 
                        <PRTPAGE P="25600"/>
                        practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care.
                    </P>
                    <P>We believe that this modified standard will provide hospitals and CAHs with appropriate flexibility and can account for the constraints of providers' existing systems. We also believe that this modified standard takes into account the fact that some recipients may not be able to receive patient event notifications, or may not be able to receive notifications in a manner consistent with a hospital system's capabilities, and the fact that hospitals and CAHs may not be able to identify provider recipients for some patients. We expect that surveyors will evaluate whether a hospital is making a reasonable effort to send patient event notifications while working within the constraints of its existing technology infrastructure.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters offered their assessments of readiness across hospitals to implement patient event notifications. One commenter pointed to hospitals' high levels of engagement in some form of health information exchange as an indication that hospitals are well-positioned to distribute patient event notifications, and stated that establishing ADT-based notification feeds did not impose significant burdens on hospitals. Another commenter agreed that the technical capabilities to implement notifications exists today, and stated that the primary challenge for hospitals would be in updating business and operational practices to comply.
                    </P>
                    <P>Other commenters stated that functionality to use ADT message information for patient event notifications is not part of certified electronic health record technology and that not all EHRs are capable of generating notifications. They stated that EHRs are not able to automatically send and receive notifications and cautioned CMS against oversimplifying the development burden associated with implementation. One commenter suggested that CMS should provide supplemental funding to support hospitals' costs, workflow changes, and technical expertise associated with implementation.</P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their insights. We share the assessment of commenters who stated that most hospitals will be able to implement patient event notifications with minimal burden due to the widespread adoption of technology systems that can be utilized to support generating and sending these notifications. Patient event notifications have been widely recognized as an important way to support patient safety, by enabling providers and suppliers responsible for the post-discharge care of a patient to quickly initiate care coordination protocols that can mitigate the risk of deterioration of a patient's condition following a hospital stay. We understand some commenters' concerns that the ability to send patient event notifications has not been included as a capability certified under the ONC certification program, and that there is no widely adopted, uniform approach to sending patient event notifications at this time. However, as noted by many commenters, we believe there are a wide variety of available, low-cost solutions that providers can adopt to fulfill the minimal requirements described in this final rule. Accordingly, we have provided significant flexibility for providers to meet these requirements by not including additional technical specifications about how patient event notifications must be formatted and shared. We believe that this approach allows flexibility for hospitals to establish patient event notifications that meet the requirements in ways that minimize implementation burden; however, we recognize that the lack of a uniform approach may lead to instances where a provider is unable to receive notifications sent by a hospital in a seamless, interoperable fashion.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Commenters stated that national infrastructure for health information exchange was not yet mature enough to support the widespread implementation of patient event notifications and that successful implementation of notifications requires the ability to acquire data feeds and a rules engine to support alerting routing and delivery, as well as a patient index function to create and verify patient panels. While many commenters believed that this infrastructure might be available in the future, for instance, through establishment of the TEFCA, they stated that it is not ubiquitous today. Without this infrastructure, commenters noted that providers would be required to support a large number of point-to-point interfaces with other providers that lack scalability, and will be highly costly, inefficient, and burdensome to develop and maintain. One commenter recommended that CMS establish that, for compliance purposes, a hospital would only be required to demonstrate a notification has been sent for a single patient. This would allow surveyors to confirm that the system is functional while allowing for variation across hospitals depending on their capabilities to send notifications under different circumstances. One commenter suggested that CMS should focus on incentivizing providers to participate in existing scalable networks that support health information exchange, including patient event notifications.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters that the national health information exchange infrastructure to support patient event notifications is not yet ubiquitous. However, we believe that the health information infrastructure that exists today will be sufficient to provide substantial support for the requirements we are finalizing in this rule. As other commenters noted, organizations such as health information exchanges are supporting the sharing of patient event notifications in many areas today. While we understand there is variation in availability of this infrastructure, we believe there are options increasingly available for hospitals to implement basic patient event notifications that will allow hospitals to demonstrate they have made a “reasonable effort” to ensure their system sends the required notifications, as per the policy finalized in this final rule.
                    </P>
                    <P>We appreciate the suggestion that the CoP should specify a hospital could achieve compliance through demonstrating that a notification has been sent for a single patient, and that this would ease compliance concerns expressed by stakeholders. However, we believe that these concerns are addressed through the more limited standard in our final policy that requires a hospital (or CAH) to make a “reasonable effort” to ensure that its system sends these notifications. In addition, and as previously noted, survey and certification interpretive guidelines utilize a variety of approaches to evaluate whether a hospital has satisfied the CoP, and in this final rule we decline to employ overly prescriptive regulatory language that might significantly limit options for surveyors as they assess compliance.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters identified challenges related to the proposal that a hospital demonstrate that its system sends notifications to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers meeting certain conditions (84 FR 7651). Commenters stated that the proposal seemed to require a hospital to be able to send a notification to any other health care provider and assumed that the receiving provider would have the technological capabilities to receive this information. Commenters stated that this is not realistic given the current 
                        <PRTPAGE P="25601"/>
                        state of technology adoption among receiving providers, and that recipients would need to develop capabilities to receive, incorporate, and use these notifications for the proposal to be effective.
                    </P>
                    <P>Commenters stated that, today, notifications would only be likely to reach recipients only a percentage of the time citing many factors related to the limitations of EHR technology that prevent providers and clinicians from incorporating electronic information into their EHRs. For instance, commenters noted that EHRs must be able to confidentially match transferred data to a patient, incorporate the notification into the EHR, and ensure that it is reviewed and stored in a clinically appropriate way to ensure it is effectively used. Commenters stated that CMS should consider complementary requirements and/or supports for ambulatory and other facilities to ensure they are able to receive patient event notifications provided by hospitals. Commenters requested additional information on the expectations for receiving providers to successfully receive and incorporate patient event notifications, and noted they may face significant burden associated with technical development if expected to be able to receive these notifications.</P>
                    <P>Moreover, commenters expressed concerns about the capacity of specific providers, including small and rural physician practices and post-acute care providers and suppliers, to receive patient event notifications. Commenters specifically noted that post-acute care providers were not provided financial incentives under the HITECH, and therefore many post-acute care providers are not using EHRs or are using EHRs that are not able to exchange information with hospital EHRs. Several commenters recommended that CMS not hold hospitals accountable for delivering patient event notifications to post-acute care suppliers, given the difficulties these suppliers would have in receiving these notifications. Others stated that the inability of these providers to receive notifications would limit the effectiveness of the proposed requirements.</P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters input on this issue. In the CMS Interoperability and Patient Access proposed rule, we stated that a hospital subject to the proposed requirements must demonstrate that its system sends notifications to certain recipients. We do not expect that a hospital would “demonstrate” that its system meets these requirements through meeting a comprehensive measure of performance. Likewise, we would not expect a hospital's system to be capable of electronically communicating with every possible provider, facility, or practitioner system, or of satisfying every possible preference for delivery of patient event notifications that a provider, facility, or practitioner might attempt to impose on the hospital. As noted above, we are modifying our proposal to require that a hospital makes a “reasonable effort” to ensure that its system sends patient event notifications to the specified recipients.
                    </P>
                    <P>Under the survey and certification process we would expect a hospital to demonstrate its system's compliance with the CoP in a variety of ways, subject to the system's capabilities. For instance, if a given system sends notifications via Direct messaging, we might expect surveyors to review whether the hospital has a process in place for capturing Direct addresses of patients' primary care practitioners to enable the system to send patient event notifications to these recipients.</P>
                    <P>
                        Finally, with regard to comments about PAC services providers and suppliers that were not eligible for incentives for EHR adoption under the EHR Incentive Programs established by the HITECH Act, we again note that the requirements in this final rule are limited to only those hospitals and CAHs that possess and utilize EHR or other administrative systems with the technical capacity to generate information for electronic patient event notifications. Moreover, a hospital or CAH with such a system must only demonstrate that it has made a “reasonable effort” to ensure that its system sends notifications to any of the specified recipients, including all 
                        <E T="03">applicable</E>
                         post-acute care services providers and suppliers (that is, to those PAC services providers and suppliers to whom the patient is being transferred or referred).
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         In the CMS Interoperability and Patient Access proposed rule, we did not explicitly address the effective implementation date for the proposed revisions to the CoPs. However, we note that revisions to the CoPs are generally applicable 60 days from the publication of a final rule.
                    </P>
                    <P>Many commenters recommended CMS allow additional time for implementation beyond the usual applicable date of these revisions. Commenters stated that additional time was required to allow providers to complete technical upgrades and train staff on new workflows. One commenter suggested that CMS finalize different timeframes based on whether hospitals are in an area with existing infrastructure for transmitting patient event notifications. Another commenter suggested that CMS develop working groups to determine appropriate timelines for implementation.</P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with commenters that additional time would be appropriate for hospitals and CAHs to implement the proposed requirements. Therefore, we are finalizing that the requirements will be applicable 12 months after the publication date of this final rule.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Multiple commenters addressed privacy implications of the proposed requirements. Commenters sought clarity on whether patient consent would be required to send a patient event notification, or whether hospitals would be able to honor a patient's request to opt-out of sharing information with providers in the form of a patient event notification. Commenters urged CMS to issue further guidance about privacy and security challenges associated with sending patient event notifications, for instance, how hospitals should address cases where they cannot confirm the identity of a provider, and/or where transmission could risk improper disclosure of protected health information. Several commenters suggested that concerns about noncompliance could lead some hospitals to be overly hasty in sending patient event notifications without considering the privacy impact of the transmission, potentially leading to inappropriate disclosures of information.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' concerns about preserving patient privacy. Nothing in this proposed rule should be construed to supersede hospitals' compliance with HIPAA or other state or federal laws and regulations related to the privacy of patient information. We note that hospitals would not be required to obtain patient consent for sending a patient event notification for treatment, care coordination, or quality improvement purposes as described in this final policy. However, we also recognize that it is important for hospitals to be able to honor patient preferences to not share their information. While the CoP would require hospitals to demonstrate that their systems can send patient event notifications, we do not intend to prevent a hospital from recording a patient's request to not share their information with another provider, and, where consistent with other law, restrict the delivery of notifications as requested by the patient and consistent with the individual right to request restriction of uses and disclosures established in the 
                        <PRTPAGE P="25602"/>
                        HIPAA Privacy Rule. Similarly, if a hospital is working with an intermediary to deliver patient event notifications, the intermediary may record information about a patient's preferences for how their information is shared, and, where consistent with other law, restrict the delivery of notifications accordingly. Based on commenters' concerns regarding a patient's ability to request that his or her medical information (in the form of a patient event notification) is not shared with other settings, we are revising and finalizing a requirement in this rule that a hospital (or CAH) must demonstrate that its notification system sends notifications, “to the extent permissible under applicable federal and state law and regulations and not inconsistent with the patient's expressed privacy preferences.”
                    </P>
                    <P>Regarding improper disclosure of health information where a hospital cannot confirm the identity of a receiving provider, we note that under this policy a hospital would not be under any obligation to send a patient event notification in this case. Under our final policy, hospitals would be required to make a “reasonable effort” to ensure their systems send notifications to the specified recipients. We believe this standard will account for instances in which a hospital (or its intermediary) cannot identify an appropriate recipient for a patient event notification despite establishing processes for identifying recipients, and thus is unable to send a notification for a given patient.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters raised concerns about how hospitals would be able to implement the proposed patient event notifications while complying with state and federal laws and regulations around the transmission of sensitive data. Commenters noted these issues are particularly relevant for psychiatric hospitals included in the proposal. Commenters noted that some states have more stringent privacy and consent requirements that apply to individuals treated in mental health facilities which may impact the sending of patient event notifications. One commenter noted that hospitals with behavioral health units do not disclose patient event information as part of their primary system data feed due to requirements that disclosure of this information must be accompanied by written consent. Commenters also noted that appropriately segregating this data is expensive and time consuming.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Nothing in this requirement should be construed as conflicting with hospitals' ability to comply with laws and regulations restricting the sharing of sensitive information. While hospitals subject to the CoP would need to demonstrate their system sends notifications to appropriate recipients, hospitals would not be expected to share patient information through a notification unless they have obtained any consents necessary to comply with existing laws and regulations.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Many commenters supported the proposal to require a hospital's system demonstrate that it sends patient event notifications at the time of admission, and at, or just prior to, the time of discharge. Commenters emphasized that it is important for notification information to be timely in order for it to be effective in improving care coordination. One commenter stated that some providers find that notifications triggered by an ADT message are triggered too early, prior to the availability of a discharge summary, and sought additional information about whether hospitals may use other triggers for a patient event notification.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate commenters' support for the proposal. We believe patient event notifications are most useful when tied to admission (or registration, as is the term generally used for patients seen in the ED) and discharge events, as receiving near-real time information about a patient's hospitalization can ensure receiving providers, facilities, and practitioners are able to act quickly to ensure successful care coordination. While we agree that sending available clinical information along with a patient event notification can be helpful, we believe that delaying notifications until all of the information about a patient's hospitalization is available would likely decrease the value of the notification.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters suggested that the requirements should be limited to external providers and not include providers that may share the same EHR as the hospital as part of an integrated delivery system. Commenters noted that organizations may have other ways to notify these providers about a discharge, and that hospitals should be exempt from sending notifications to these providers.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         Under the proposed requirements, we are not specifying a format or transport method for patient event notifications. Accordingly, hospitals could use a mix of approaches to deliver patient event notifications, for instance, by partnering with an intermediary to deliver notifications to external providers, while using features internal to a shared EHR system to transmit information to providers that are part of the same organization.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         Several commenters sought clarity on how the patient event notifications would relate to information blocking policy, and urged CMS to ensure that any new CoP requirements are aligned with other policies around information blocking. Several commenters suggested that, as an alternative to the proposed requirements, CMS should establish a standard under the CoPs that states hospitals will not engage in information blocking, to be aligned with policies established by ONC in the 21st Century Cures Act final rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We note that there are currently three prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ) to which eligible hospitals and CAHs must attest for purposes of the Promoting Interoperability Program. As part of successfully demonstrating that an eligible hospital or CAH is a meaningful EHR user for purposes of the Promoting Interoperability Program, the eligible hospital or CAH must submit an attestation response of “yes” for each of these statements. These attestations are discussed further in section VIII. of this final rule. We also refer commenters to section 3022(b)(2)(B) of the Public Health Service Act (PHSA), which provides that any health care provider determined by the OIG to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable federal law, as set forth by the Secretary through notice and comment rulemaking. Further, we refer commenters to the ONC 21st Century Cures Act proposed rule for additional discussion on disincentives (84 FR 7553).
                    </P>
                    <P>
                        <E T="03">Final Action:</E>
                         After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing these proposals with some modifications and reorganization of the provisions. These policies are being finalized at 42 CFR 482.24(d), 482.61(f), and 485.638(d) for Conditions of Participation for hospitals, psychiatric hospitals, and specialized providers (CAHs).
                    </P>
                    <P>
                        Based on public comments, and to further advance electronic exchange of information that supports effective transitions of care for patients between hospitals and CAHs and their community PAC services providers and suppliers as well as their primary care practitioners, the following requirements at 42 CFR 482.24(d), 
                        <PRTPAGE P="25603"/>
                        482.61(f), and 485.638(d) are being finalized here with modifications and reorganization from the proposed requirements (84 FR 7678):
                    </P>
                    <P>• We are revising 42 CFR 482.24(d) by deleting the reference to “paragraph (d)(2) of this section”;</P>
                    <P>• We are revising 42 CFR 482.61(f) by deleting the reference to “paragraph (d)(2) of this section”;</P>
                    <P>• We are revising 42 CFR 485.638(d) by deleting the reference to “paragraph (d)(2) of this section”;</P>
                    <P>• We are revising 42 CFR 482.24(d) by adding new language to the regulatory text so that it now includes “or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2),”;</P>
                    <P>• We are revising 42 CFR 482.61(f) by adding new language to the regulatory text so that it now includes “or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2),”;</P>
                    <P>• We are revising 42 CFR 485.638(d) by adding new language to the regulatory text so that it now includes “or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2),”;</P>
                    <P>• We are deleting all of the regulatory text proposed at 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2), including the inaccurate references to “45 CFR 170.205(a)(4)(i);”</P>
                    <P>• We are redesignating 42 CFR 482.24(d)(3), 482.61(f)(3), and 485.638(d)(3) as 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2), respectively, and also revising the regulatory text to now state that the system sends notifications that must include at least patient name, treating practitioner name, and sending institution name;</P>
                    <P>
                        • We are redesignating 42 CFR 482.24(d)(4), 482.61(f)(4), and 485.638(d)(4) as 42 CFR 482.24(d)(3), 482.61(f)(3), and 485.638(d)(3), respectively, and also revising the regulatory text to now state that, “
                        <E T="03">to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences,</E>
                         the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of: 
                        <E T="03">the patient's registration in the hospital's [or CAH's] emergency department (if applicable); or the patient's admission to the hospital's [or CAH's] inpatient services (if applicable).”</E>
                    </P>
                    <P>
                        • We are redesignating 42 CFR 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5) as 42 CFR 482.24(d)(4), 482.61(f)(4), and 485.638(d)(4), respectively, and also revising the regulatory text to state that, “
                        <E T="03">to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences,</E>
                         the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of: 
                        <E T="03">the patient's discharge or transfer from the hospital's [or CAH's] emergency department (if applicable): or the patient's discharge or transfer from the hospital's [or CAH's] inpatient services (if applicable).”</E>
                    </P>
                    <P>
                        • We are deleting the regulatory text proposed at 42 CFR 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5) and adding new regulatory text to state that, “
                        <E T="03">the hospital [or CAH] has made a reasonable effort to ensure that the system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes: the patient's established primary care practitioner; the patient's established primary care practice group or entity; or other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care</E>
                        .”
                    </P>
                    <P>Finally, recognizing that hospitals, including psychiatric hospitals and CAHs, are on the front lines of the COVID-19 public health emergency, and in response to the number of comments received regarding concerns with the applicability date for this rule, we are establishing an applicability date of 12 months after finalization of this rule for hospitals, including psychiatric hospitals, and CAHs to allow for adequate and additional time for these institutions, especially small and/or rural hospitals as well as CAHs, to come into compliance with the new requirements.</P>
                    <HD SOURCE="HD1">XI. Provisions of the Final Regulations</HD>
                    <P>Generally, this final rule incorporates the provisions of the CMS Interoperability and Patient Access proposed rule as proposed. The following provisions of this final rule differ from the proposed rule.</P>
                    <P>We are finalizing four proposals with modifications.</P>
                    <P>
                        1. We are requiring MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content and vocabulary standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.213 (currently version 1 of the USCDI), via a payer-to-payer data exchanged as outlined in this section V. of this final rule. Specifically, we are finalizing as proposed that impacted payers incorporate the data they receive into the enrollee's record. We are finalizing that with the approval and at the direction of a current or former enrollee, a payer must send the defined information set to any other payer. In addition, we specify that a payer is only obligated to send data received from another payer under this policy in the electronic form and format it was received.
                    </P>
                    <P>Starting January 1, 2022, and for QHP issuers on the FFEs starting with plan years beginning on or after January 1, 2022, the finalized regulation requires these payers to make data available with a date of service on or after January 1, 2016 that meets the requirements of this section and which the payer maintains. In this way, payers only have to prepare an initial historical set of data for sharing via this payer-to-payer data exchange policy that is consistent with the data set to be available through the Patient Access API, as finalized in section III. of this final rule.</P>
                    <P>
                        2. Regarding the Patient Access API, we are finalizing requirements for MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to implement and maintain a standards-based Patient Access API that meets the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215, that include the data elements specified in this final rule, and that permit third-party applications to retrieve, with the approval and at the direction of a current enrollee, data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221. Specifically, we are finalizing that the Patient Access API must, at a minimum, make available adjudicated claims; encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where maintained by the impacted payer). We are not finalizing a requirement to include Provider Directory information as part of the 
                        <PRTPAGE P="25604"/>
                        Patient Access API. Instead, to limit burden, we are only requiring provider and, in the case of MA-PD plans, pharmacy directory information, be included in the Provider Directory API discussed in section IV. of this final rule. Data via the Patient Access API must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received by the impacted payer. We are finalizing that MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP state agencies, and CHIP managed care entities must make available the date they maintain with a date of service on or after January 1, 2016 beginning January 1, 2021, and for QHP issuers on the FFEs beginning with plan years beginning on or after January 1, 2021.
                    </P>
                    <P>
                        3. We are finalizing a Provider Directory API for MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP state agencies, and CHIP managed care entities making standardized information about their provider networks available via a FHIR-based API conformant with the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.215 (which include HL7 FHIR Release 4.0.1), excluding the security protocols related to user authentication and authorization, or any other protocols that restrict the availability of this information to anyone wishing to access it. At a minimum, these payers must make available via the Provider Directory API provider names, addresses, phone numbers, and specialties. For MA organizations that offer MA-PD plans, they must also make available, at a minimum, pharmacy directory data, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”). This Provider Directory API must be fully implemented by January 1, 2021 for all payers subject to this new requirement. Under this final rule, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must make the Provider Directory API accessible via a public-facing digital endpoint on their website to ensure public discovery and access.
                    </P>
                    <P>Modifications being finalized for the timelines for these policies will provide impacted payers ample time to build and test the required standards-based APIs to meet the new API requirements. In addition, providing more time for payer-to-payer data exchange between impacted payers will ensure successful implementation, and better enable plans to use a standards-based API to meet this requirement if they so choose. We are not finalizing the Care Coordination through Trusted Exchange Networks proposal. Although some commenters did show support for the proposal, others raised strong concerns. Given the concerns commenters raised specifically regarding the need for a mature TEFCA to be in place first, and appreciating the ongoing work on the TEFCA being done at this time, we are not finalizing this trusted exchange proposal in this rule.</P>
                    <P>4. We are finalizing the Revisions to the Conditions of Participation for Hospitals and Critical Access Hospitals proposal with modifications that are based on public comments. Additionally, and based on strong support from commenters, we are including patient event notification requirements for any patient who accesses services in a hospital (or CAH) emergency department. In response to the number of comments received regarding concerns with the applicable date for this policy, we are finalizing an applicability date of 12 months after publication of this rule for hospitals, including psychiatric hospitals, and CAHs to allow for adequate time for these institutions, especially small and/or rural hospitals as well as CAHs, to come into compliance with the new requirements.</P>
                    <P>All other policies are being substantially finalized as proposed.</P>
                    <HD SOURCE="HD1">XII. Collection of Information Requirements</HD>
                    <P>
                        Under the Paperwork Reduction Act of 1995, we are required to provide 30-day notice in the 
                        <E T="04">Federal Register</E>
                         and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995 requires that we solicit comment on the following issues:
                    </P>
                    <P>• The need for the information collection and its usefulness in carrying out the proper functions of our agency.</P>
                    <P>• The accuracy of our estimate of the information collection burden.</P>
                    <P>• The quality, utility, and clarity of the information to be collected.</P>
                    <P>• Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.</P>
                    <P>We solicited public comment on each of these issues for the following sections of this document that contain information collection requirements (ICRs):</P>
                    <HD SOURCE="HD2">A. Background</HD>
                    <P>Payers should have the ability to exchange data instantly with other payers for care and payment coordination or transitions, and with providers to facilitate more efficient care. Payers are in a unique position to provide patients a complete picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. To advance our commitment to interoperability, we are finalizing our proposals for the Patient Access API, the Provider Directory API, and the payer-to-payer data exchange as discussed above.</P>
                    <P>We noted that these proposals were designed to empower patients by making sure that they have access to health information about themselves in a usable digital format and can make decisions about how, with whom, and for what uses they will share it. By making claims data readily available and portable to the enrollee, these initiatives supported efforts to reduce burden and cost and improve patient care by reducing duplication of services, adding efficiency to patient visits to providers; and, facilitating identification of fraud, waste, and abuse.</P>
                    <HD SOURCE="HD2">B. Wage Estimates</HD>
                    <P>
                        To derive average costs, we used data from the U.S. Bureau of Labor Statistics' (BLS) May 2018 National Occupational Employment and Wage Estimates (
                        <E T="03">https://www.bls.gov/oes/current/oes_nat.htm</E>
                        ). Table 1 presents the mean hourly wage, the cost of fringe benefits (calculated at 100 percent of salary), and the adjusted hourly wage. In the CMS Interoperability and Patient Access proposed rule, Table 1 was based on the latest 2017 wage data (84 FR 7658). In this final rule, we have updated Table 1 to reflect 2018 wage data, which is now the latest available data.
                        <PRTPAGE P="25605"/>
                    </P>
                    <GPOTABLE COLS="05" OPTS="L2,i1" CDEF="s50,12,12,12,12">
                        <TTITLE>Table 1—Occupation Titles and Wage Rates</TTITLE>
                        <BOXHD>
                            <CHED H="1">Occupation title</CHED>
                            <CHED H="1">
                                Occupation 
                                <LI>code</LI>
                            </CHED>
                            <CHED H="1">
                                Mean 
                                <LI>hourly </LI>
                                <LI>wage </LI>
                                <LI>($/hr)</LI>
                            </CHED>
                            <CHED H="1">
                                Fringe 
                                <LI>benefit </LI>
                                <LI>($/hr)</LI>
                            </CHED>
                            <CHED H="1">
                                Adjusted 
                                <LI>hourly </LI>
                                <LI>wage </LI>
                                <LI>($/hr)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Administrators and Network Architects</ENT>
                            <ENT>15-1140</ENT>
                            <ENT>$45.09</ENT>
                            <ENT>$45.09</ENT>
                            <ENT>$90.18</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Security Engineer</ENT>
                            <ENT>17-2199</ENT>
                            <ENT>47.80</ENT>
                            <ENT>47.80</ENT>
                            <ENT>95.60</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Computer and Information Analysts</ENT>
                            <ENT>15-1120</ENT>
                            <ENT>45.67</ENT>
                            <ENT>45.67</ENT>
                            <ENT>91.34</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">General Operations Manager</ENT>
                            <ENT>11-1021</ENT>
                            <ENT>59.56</ENT>
                            <ENT>59.56</ENT>
                            <ENT>119.12</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Operations Research Analysts</ENT>
                            <ENT>15-2031</ENT>
                            <ENT>42.48</ENT>
                            <ENT>42.48</ENT>
                            <ENT>84.96</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Software Developers, Applications</ENT>
                            <ENT>15-1132</ENT>
                            <ENT>51.96</ENT>
                            <ENT>51.96</ENT>
                            <ENT>103.92</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Computer and Information Systems Managers</ENT>
                            <ENT>11-3021</ENT>
                            <ENT>73.49</ENT>
                            <ENT>73.49</ENT>
                            <ENT>146.98</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Designers</ENT>
                            <ENT>27-1020</ENT>
                            <ENT>24.05</ENT>
                            <ENT>24.05</ENT>
                            <ENT>48.10</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Technical Writer</ENT>
                            <ENT>27-3042</ENT>
                            <ENT>36.30</ENT>
                            <ENT>36.30</ENT>
                            <ENT>72.60</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Computer Systems Analysts</ENT>
                            <ENT>15-1121</ENT>
                            <ENT>45.01</ENT>
                            <ENT>45.01</ENT>
                            <ENT>90.02</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Network and Computer Systems Administrators</ENT>
                            <ENT>15-1142</ENT>
                            <ENT>41.86</ENT>
                            <ENT>41.86</ENT>
                            <ENT>83.72</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Medical Records and Health Information Technician</ENT>
                            <ENT>29-2071</ENT>
                            <ENT>21.16</ENT>
                            <ENT>21.16</ENT>
                            <ENT>42.32</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Medical and Health Service Managers</ENT>
                            <ENT>11-9111</ENT>
                            <ENT>54.68</ENT>
                            <ENT>54.68</ENT>
                            <ENT>109.36</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>As indicated, we are adjusting the employee hourly wage estimates by a factor of 100 percent. This is necessarily a rough adjustment, both because fringe benefits and overhead costs vary significantly from employer to employer, and because methods of estimating these costs vary widely from study to study. Nonetheless, there is no practical alternative and we believe that doubling the hourly wage to estimate total cost is a reasonable accurate estimation method.</P>
                    <HD SOURCE="HD2">C. Information Collection Requirements (ICRs)</HD>
                    <HD SOURCE="HD3">1. ICRs Regarding MMA File Requirements (42 CFR 423.910)</HD>
                    <P>States transmit system generated data files, at least monthly, to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The file is called the MMA file, but is occasionally referred to as the “State Phasedown file.” Section 423.910(d) requires states to transmit at least one MMA file each month. However, states have the option to transmit multiple MMA files throughout the month (up to one per day). Most states transmit at least weekly. This information collection activity is currently approved under OMB control number 0938-0958.</P>
                    <P>Ensuring information on dual eligibility status is accurate and up-to-date by increasing the frequency of federal-state data exchange is an important step toward interoperability. As a result, we proposed to update the frequency requirements in 42 CFR 423.910(d) to require that starting April 1, 2022, all states transmit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every business day, but if no new transactions are available to transmit, data would not need to be transmitted on a given business day. We estimate it would take a computer systems analyst about 6 months (approximately 960 hours) to complete the systems updates necessary to process and transmit the MMA data daily. After completion of system updates, these system generated reports would be set to run and transmitted to CMS on an automated production schedule.</P>
                    <P>As a result of updated information, we are revising the number of states currently transmitting MMA daily data from 13 states, as stated in the CMS Interoperability and Patient Access proposed rule, to 15 states. Consequently, we estimate a one-time aggregate burden for 36 entities (51 total entities (50 states and the District of Columbia) minus the 15 states currently transmitting MMA daily data) to comply with the requirement of transmission of daily MMA data at an aggregate burden of $3,111,091 (36 entities * 960 hours * $90.02 per hour for a computer system analyst to perform the updates). We have only estimated the cost of system updates since the system transfers are done automatically and this has no additional cost. We will be revising the information collection request currently approved under 0938-0958 to include the requirements discussed in this section.</P>
                    <HD SOURCE="HD3">2. ICRs Regarding API Proposals (42 CFR 422.119, 422.120, 431.60, 431.70, 438.242, 457.730, 457.760, 457.1233, and 45 CFR 156.221)</HD>
                    <P>
                        To promote our commitment to interoperability, we are finalizing new requirements for a Patient Access API for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, CHIP FFS at 42 CFR 457.730, Medicaid managed care at 42 CFR 438.242(b)(5), CHIP managed care at 42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221. Additionally, we are finalizing a publicly available Provider Directory API for MA organizations at 42 CFR 422.120, at 42 CFR 431.70 for Medicaid FFS, at 42 CFR 438.242(b)(6) for Medicaid managed care, at 42 CFR 457.760 for CHIP FFS, and at 42 CFR 457.1233(d)(3) for CHIP managed care. We proposed to require these entities to establish standards-based APIs that permit third-party applications to retrieve standardized data for adjudicated claims, encounters with capitated providers, provider remittances, beneficiary cost-sharing, reports of lab test results, provider directories (and pharmacy directories for MA-PDs), and preferred drug lists, where applicable. We finalized the requirement for a Patient Access API and a Provider Directory API; this final rule requires generally the same information as proposed to be available through APIs but we are finalizing the requirement for two APIs. Additionally, we proposed and are finalizing at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213 (currently version 1 of the USCDI). To implement the new requirements for APIs and payer to payer data exchange, we estimate that plans and states will conduct three major work phases: Initial design, development and testing, and long-term support and maintenance. In the proposed rule, we provided detailed 
                        <PRTPAGE P="25606"/>
                        estimations of the required labor categories and number of hours required to implement the API provisions (84 FR 7659). We originally estimated a one-time burden of $789,356.00 per organization or state per implementation, with an ongoing maintenance cost $158,359.00 per organization or state (84 FR 7659). We noted that, in the initial design phase, we believed tasks would include: Determining available resources (personnel, hardware, cloud space, etc.); assessing whether to use in-house resources to facilitate an API connection or contract the work to a third party; convening a team to scope, build, test, and maintain the API; performing a data availability scan to determine any gaps between internal data models and the data required for the necessary FHIR resources; and, mitigating any gaps discovered in the available data.
                    </P>
                    <P>
                        During the development and testing phase, we noted that plans and states would need to conduct the following: Map existing data to HL7 
                        <SU>66</SU>
                        <FTREF/>
                         FHIR standards, which would constitute the bulk of the work required for implementation; allocate hardware for the necessary environments (development, testing, production); build a new FHIR server or leverage existing FHIR servers; determine the frequency and method by which internal data are populated on the FHIR server; build connections between the databases and FHIR server; perform capability and security testing; and vet third-party applications, which includes potentially asking third-party applications to attest to certain privacy provisions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>66</SU>
                             Health Level Seven International (HL7®) is a not-for-profit, ANSI-accredited standards development organization (SDO) focused on developing consensus standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. Learn more at “About HL7” web page, last accessed June 27, 2018.
                        </P>
                    </FTNT>
                    <P>After the completion of the API development, plans and states would need to conduct the following throughout each year: Allocate resources to maintain the FHIR server, which includes the cost of maintaining the necessary patient data, and perform capability and security testing.</P>
                    <P>In the proposed rule, we proposed a new requirement for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process to coordinate care between plans by exchanging, at a minimum, the USCDI at the enrollee's request (84 FR 7640). Originally, we noted that we would allow multiple methods for electronic exchange of the information, including use of the APIs. Although we considered requiring the use of the FHIR-based API, we understood that some geographic areas might have a regional health information exchange that could coordinate such transactions. We also noted other ways to exchange this data, such as: Direct plan-to-plan exchange; leveraging connections to HIEs, or beneficiary-facing third-party applications. Since the requirements for the payer-to-payer data exchange and the API provisions share a content and vocabulary standard and because plans will be investing in the development of the APIs in this final rule, we believe that plans would overwhelmingly use these APIs to meet the payer to payer data exchange requirements. As we had no reliable way to determine which plans would utilize any of the available methods to meet the payer-to-payer data exchange requirement or how to determine the cost of each of these methods, given that each plan could be at a different technology maturity level, we accounted for costs for all impacted payers assuming the use of a newly developed API to implement the payer-to-payer data exchange requirements, as this would account for a higher effort options, and included this in our original estimates for the API provisions.</P>
                    <P>We summarize the public comments we received on concerns raised regarding our proposed cost of implementing and maintaining the APIs and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters expressed concern that CMS underestimated the complexity of implementing the API requirements and did not agree with the agency's estimation that the API implementation is a one-time cost. These commenters noted that additional costs include: The costs to contract with third-party applications, the costs of ongoing education, and the cost of answering questions from members about data and errors. Commenters argued that the proposed API requirements significantly add to overhead costs and will increase costs for providers and payers, rather than facilitate information exchange and better care for patients. One commenter estimated a range of between $1 million and $1.5 million to implement the API requirements, with an additional $200,000 to maintain the API. Another commenter argued that the costs of implementation could be as high as four times the estimates CMS provided.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We thank commenters for their input and understand their concerns associated with the cost required to implement the requirements of this final rule. We understand that our estimates regarding the implementation of the API provisions may vary depending on a number of factors, including, but not limited to a payer's current knowledge of and experience with implementing FHIR-based APIs, and whether an impacted payer will develop this technology in-house or seek a third party contractor to support this effort.
                    </P>
                    <P>To further develop our cost estimates, we reviewed the cost estimates associated with updating Blue Button from Blue Button 1.0 to 2.0 to include a standards-based API, similar to the requirements of this final rule. This update was estimated at $2 million. However, we believe that the estimates associated with updating the existing Blue Button 1.0 to a standards-based API for Blue Button 2.0 do not accurately represent the costs for payers impacted by this final rule. Blue Button 1.0 was developed across several federal agencies, including the Departments of Defense, Health and Human Services, and Veterans Affairs, with a capability to allow beneficiaries online access to their own personal health records, such as the ability to download PDF documents. Unlike the standards-based APIs required under this final rule, Blue Button 1.0 was not originally developed with a prescribed set of standards that allow for third-party apps to connect and retrieve data via an API. The estimates for Blue Button account for upgrading an existing technology platform that was not originally developed to allow third-party app access via an API, which we believe adds additional cost that may not impact all payers under this final rule. Additionally, we note that costs related to federal procurement and the need to engage multiple contractors to implement the updates to Blue Button, while at the same time maintaining access to the original system, caused the cost of implementing standards-based APIs for Blue Button 2.0 to be higher than those costs for payers impacted by this final rule. Therefore, we believe that the estimates for upgrading Blue Button from 1.0 to 2.0 are not truly representative of the cost to implement the standards-based API required by this final rule, but nonetheless are valuable in further informing our cost estimates.</P>
                    <P>
                        As noted above, we did receive one comment that suggested a cost range between $1 million and $1.5 million to implement the API requirements of this final rule, with another commenter indicating a four-fold increase in costs relative to the estimates included in the proposed rule. While disagreeing with 
                        <PRTPAGE P="25607"/>
                        our bottom line, these commenters did not provide where in our detailed analysis we underestimated costs. For example, it is unclear if the commenters were including voluntary provider costs, or other costs when calculating the dollar amounts for compliance. Therefore, without specific examples of additional costs that need to be accounted for in this impact analysis, we believe that our estimates are reasonable. To address commenters' concerns regarding ongoing costs, we remind readers that we specifically are accounting for a cost of $157,656 per organization, for costs throughout the year to include: Allocating resources to maintain the FHIR server, which includes the cost of maintaining the necessary patient data, and perform capability and security testing.
                    </P>
                    <P>However, in an effort to take into account the additional information that commenters presented regarding our costs estimates, and understanding there are many factors that may influence the cost of implementing these policies, as noted above, we are adjusting our cost estimates to reflect a range instead of a point estimate. We believe that our cost projections for an initial one-time cost to implement the API requirements of this final rule of $718,414 per organization, reflecting 6 months of work by a team of ten professionals, can now serve as a minimum estimate; in other words, we do not believe it is technically feasible to implement the requirements of this final rule in less than 6 months. For a primary estimate, we have increased our cost estimates by a factor of 2 to account for cost variation. We note that using this factor of 2, the cost per organization is consistent with the commenter stating a $1 million to $1.5 million per organization cost. For a high estimate we have increased our cost estimates by a factor of 3. Although, one commenter noted a factor of 4 should be included, all other information available to us, including the commenter who noted a range between $1 million and $1.5 million, and our estimates for upgrading Blue Button, a factor of 4 does not appear to be reflective of the costs for implementation and represents more of an outlier for cost estimating purposes. As shown in section XIII. of this final rule, we have revised down our estimate of affected individual market enrollees from 76 million (all commercial market enrollees) to 17.5 million (those individual market enrollees directly affected by this final rule). This reduction by a factor of 4 (76 million former estimate/17.5 million revised estimate) raises the cost per individual market enrollee per year by a factor of 4 consistent with the commenter's suggested factor of 4. This factor of 4, however, only affects cost per enrollee per year; it does not affect total costs as calculated in Table 2.</P>
                    <P>Additionally, we note that as part of our original estimated costs associated with the annual burden of the requirements of this final rule, we accounted for additional capability testing and long-term support of the APIs, increased data storage needs, such as additional servers, or cloud storage to store any additional patient health information, and allocation of resources to maintain the FHIR server, and perform capability and security testing. Therefore, our estimates related to the annual burden account for the ongoing cost, and we are not providing additional estimates for maintenance as this is already factored in.</P>
                    <P>The burden estimate related to the new requirements for implementing and maintaining the APIs reflects the time and effort needed to collect the information described above and disclose this information. We now estimate:</P>
                    <P>• An initial set one-time costs associated with the implementing the API requirements.</P>
                    <P>• An ongoing maintenance cost after the system is set up, and the costs associated with additional data storage, system testing, and maintenance.</P>
                    <P>Consistent with our discussion above, we now regard this as a low or minimum estimate, the argument being that a complex system cannot be designed in less than 6 months. Our high estimate now reflects 18 months of work (4,320 hours) for administrators and network architects. This is obtained by using a factor of 3 (4,320 hours (high estimate) = 3*1440 hours, the original estimate). For a primary estimate, we estimate 12 months of work or 2,880 hours (1,440 hours * 2) for administrators and network architects. The use of a factor of 2 is consistent with a $2 million cost per entity and consistent with the commenter who estimated an implementation cost of $1 million to $1.5 million. We note that, in terms of actual implementation, this assumption is focused on the 2,880 hours of work that could be conducted in less than 12 months through necessary personnel or third-party contractor allocation, if needed. As a result, the “12-month” assumption is also consistent with the implementation of the new API requirements, which must be implemented by January 1, 2021.</P>
                    <P>As can be seen from the bottom rows of Table 2:</P>
                    <P>• For a low estimate, first year implementation will require a total of 8,400 hours per organization at a cost of $718,414.40 per organization (this number is obtained by adding the products of hourly wages and hours required in each row, for example 1440*$90.18 + 960*$95.60, etc.).</P>
                    <P>• For a high estimate, first year implementation will require a total of 25,200 hours per organization at a cost of $2,365,243 per organization (this number is obtained by adding the products of hourly wages and hours required in each row).</P>
                    <P>• For a primary estimate, first year implementation will require a total of 16,800 hours of work per organization at a cost of $1,576,829 per organization.</P>
                    <P>
                        • Therefore, the aggregate burden of the first year implementation across 345 parent organizations 
                        <SU>67</SU>
                        <FTREF/>
                         is 2,898,000 hours (8400 * 345) at a cost of $272 million ($718,414 * 345) for the low estimate. Similar calculations show that the primary estimate is 5,796,000 hours at an aggregate cost of $544,005,936 million, and the high estimate is 8,694,000 hours at a cost of $816,008,904.
                    </P>
                    <FTNT>
                        <P>
                            <SU>67</SU>
                             We provide a detailed rationale for how we determined the number of parent organizations in section XIII.C.1. of this final rule. In that analysis we determined that 288 issuers and 56 states, territories, and U.S. commonwealths, which operate FFS programs, will be subject to the API provisions for Medicare, Medicaid, and the commercial market. To this we added the one state that operates its CHIP and Medicaid separately. Thus, we have a total of 345 parent entities (288+56+1).
                        </P>
                    </FTNT>
                    <P>• Similarly, ongoing maintenance after the first year will require a total of 1,710 hours per organization at a cost of $157,656.60 per organization.</P>
                    <P>• Therefore, the aggregate burden of ongoing implementation across 345 parent organizations is $54.4 million ($157,656.60 * 345).</P>
                    <P>
                        We explicitly note that a low and high estimate were only provided for the first year, but not for subsequent years.
                        <PRTPAGE P="25608"/>
                    </P>
                    <GPOTABLE COLS="9" OPTS="L2,i1" CDEF="s25,9,9,9,9,12,12,12,12">
                        <TTITLE>Table 2—First Year and Maintenance Cost of the API Provisions</TTITLE>
                        <BOXHD>
                            <CHED H="1">Occupation title</CHED>
                            <CHED H="1">
                                Occupation 
                                <LI>code</LI>
                            </CHED>
                            <CHED H="1">
                                Mean 
                                <LI>hourly </LI>
                                <LI>wage </LI>
                                <LI>($/hr)</LI>
                            </CHED>
                            <CHED H="1">
                                Fringe 
                                <LI>benefit </LI>
                                <LI>($/hr)</LI>
                            </CHED>
                            <CHED H="1">
                                Adjusted 
                                <LI>hourly wage </LI>
                                <LI>($/hr)</LI>
                            </CHED>
                            <CHED H="1">
                                First year 
                                <LI>hours </LI>
                                <LI>(low estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                First year 
                                <LI>hours </LI>
                                <LI>(primary</LI>
                                <LI>estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                First year 
                                <LI>hours </LI>
                                <LI>(high estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                Maintenance 
                                <LI>hours</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Administrators and Network Architects</ENT>
                            <ENT>15-1140</ENT>
                            <ENT>$45.09</ENT>
                            <ENT>$45.09</ENT>
                            <ENT>$90.18</ENT>
                            <ENT>1440</ENT>
                            <ENT>2880</ENT>
                            <ENT>4320</ENT>
                            <ENT>180</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Security Engineer</ENT>
                            <ENT>17-2199</ENT>
                            <ENT>47.80</ENT>
                            <ENT>47.80</ENT>
                            <ENT>95.60</ENT>
                            <ENT>960</ENT>
                            <ENT>1920</ENT>
                            <ENT>2880</ENT>
                            <ENT>240</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Computer and Information Analysts</ENT>
                            <ENT>15-1120</ENT>
                            <ENT>45.67</ENT>
                            <ENT>45.67</ENT>
                            <ENT>91.34</ENT>
                            <ENT>480</ENT>
                            <ENT>960</ENT>
                            <ENT>1440</ENT>
                            <ENT>60</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">General Operations Manager</ENT>
                            <ENT>11-1021</ENT>
                            <ENT>59.56</ENT>
                            <ENT>59.56</ENT>
                            <ENT>119.12</ENT>
                            <ENT>720</ENT>
                            <ENT>1440</ENT>
                            <ENT>2160</ENT>
                            <ENT>90</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Operations Research Analysts</ENT>
                            <ENT>15-2031</ENT>
                            <ENT>42.48</ENT>
                            <ENT>42.48</ENT>
                            <ENT>84.96</ENT>
                            <ENT>960</ENT>
                            <ENT>1920</ENT>
                            <ENT>2880</ENT>
                            <ENT>120</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Software Developers, Applications</ENT>
                            <ENT>15-1132</ENT>
                            <ENT>51.96</ENT>
                            <ENT>51.96</ENT>
                            <ENT>103.92</ENT>
                            <ENT>960</ENT>
                            <ENT>1920</ENT>
                            <ENT>2880</ENT>
                            <ENT>240</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Computer and Information Systems Managers</ENT>
                            <ENT>11-3021</ENT>
                            <ENT>73.49</ENT>
                            <ENT>73.49</ENT>
                            <ENT>146.98</ENT>
                            <ENT>720</ENT>
                            <ENT>1440</ENT>
                            <ENT>2160</ENT>
                            <ENT>90</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Designers</ENT>
                            <ENT>27-1020</ENT>
                            <ENT>24.05</ENT>
                            <ENT>24.05</ENT>
                            <ENT>48.10</ENT>
                            <ENT>960</ENT>
                            <ENT>1920</ENT>
                            <ENT>2880</ENT>
                            <ENT>120</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Technical Writer</ENT>
                            <ENT>27-3042</ENT>
                            <ENT>36.30</ENT>
                            <ENT>36.30</ENT>
                            <ENT>72.60</ENT>
                            <ENT>240</ENT>
                            <ENT>480</ENT>
                            <ENT>720</ENT>
                            <ENT>30</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Computer Systems Analysts</ENT>
                            <ENT>15-1121</ENT>
                            <ENT>45.01</ENT>
                            <ENT>45.01</ENT>
                            <ENT>90.02</ENT>
                            <ENT>960</ENT>
                            <ENT>1920</ENT>
                            <ENT>2880</ENT>
                            <ENT>120</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Network and Computer Systems Administrators</ENT>
                            <ENT>15-1142</ENT>
                            <ENT>41.86</ENT>
                            <ENT>41.86</ENT>
                            <ENT>83.72</ENT>
                            <ENT/>
                            <ENT>0</ENT>
                            <ENT>0</ENT>
                            <ENT>420</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Hours per System</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>8,400</ENT>
                            <ENT>16,800</ENT>
                            <ENT>25,200</ENT>
                            <ENT>1,710</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost per system (Dollars) (millions)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>788,414</ENT>
                            <ENT>1,576,829</ENT>
                            <ENT>2,365,243</ENT>
                            <ENT>157,657</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total hours for 345 Organizations (hours)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>2,898,000</ENT>
                            <ENT>5,796,000</ENT>
                            <ENT>8,694,000</ENT>
                            <ENT>589,950</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost for 345 Organizations (millions $)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>272,002,968</ENT>
                            <ENT>544,005,936</ENT>
                            <ENT>816,008,904</ENT>
                            <ENT>54,391,527</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">3. ICRs Regarding Conditions of Participation for Hospitals and Critical Access Hospitals (42 CFR 482.24(d), 482.61(f), 485.638(d))</HD>
                    <P>We are expanding our requirements for interoperability within the hospital and CAH CoPs by focusing on electronic patient event notifications. We are implementing new requirements in section X. of this final rule for hospitals at 42 CFR 482.24(d), for psychiatric hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d). Specifically, for hospitals, psychiatric hospitals, and CAHs, we are finalizing similar requirements to revise the CoPs for Medicare- and Medicaid-participating hospitals, psychiatric hospitals, and CAHs by adding a new standard, “Electronic Notifications,” that will require hospitals, psychiatric hospitals, and CAHs to make electronic patient event notifications available to applicable post-acute care services providers and suppliers, and to community practitioners such as the patient's established primary care practitioner, established primary care practice group or entity, or other practitioner or practice group or entity identified by the patient as primarily responsible for his or her care. We are limiting this requirement to only those hospitals, psychiatric hospitals, and CAHs that utilize electronic medical records systems, or other electronic administrative systems, which are conformant with the content exchange standard at 45 CFR 170.205(d)(2), recognizing that not all Medicare- and Medicaid-participating hospitals have been eligible for past programs promoting adoption of EHR systems. If the hospital's (or CAH's) system conforms to the content exchange standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then demonstrate that its system's notification capacity is fully operational and that the hospital (or CAH) uses it in accordance with all state and federal statutes and regulations applicable to the hospital's (or CAH's) exchange of patient health information, and that its system (to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences) sends the notifications either directly, or through an intermediary that facilitates exchange of health information. It must also demonstrate that the notifications include at least patient name, treating practitioner name, and sending institution name.</P>
                    <P>
                        Upon the patient's registration in the emergency department or admission to inpatient services, and also either immediately prior to, or at the time of, the patient's discharge or transfer (from the emergency department or inpatient services), the hospital (or CAH) must also demonstrate that it has made a reasonable effort to ensure that its system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes: (1) The patient's established primary care practitioner; (2) the patient's established primary care practice group or entity; or (3) other practitioner, or other practice group or entity, identified by the patient as the 
                        <PRTPAGE P="25609"/>
                        practitioner, or practice group or entity, primarily responsible for his or her care.
                    </P>
                    <P>These requirements will help support coordination of a patient's care between settings or with services received through different care settings. Electronic patient event notifications from these care settings, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings. These notifications are typically automated, electronic communications from the admitting or discharging provider to applicable post-acute care services providers and suppliers, and also to community practitioners identified by the patient, that alert the receiving providers or community practitioners that a patient is receiving, or has received, care at a different setting.</P>
                    <P>
                        These notifications are frequently based on “admission, discharge, and transfer (ADT)” messages, a standard message used within an EHR as the vehicle for communicating information about key changes in a patient's status as they are tracked by the system (more information about the current standard supporting these messages is available at 
                        <E T="03">http://www.hl7.org/implement/standards/product_brief.cfm?product_id=144</E>
                        ). As noted in the ISA published by ONC, this messaging standard has been widely adopted across the health care system (see 
                        <E T="03">https://www.healthit.gov/isa/sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers</E>
                        ).
                    </P>
                    <P>We continue to believe that care coordination can have a significant positive impact on the quality of life, consumer experience, and health outcomes for patients. As we have noted in the preamble to this rule, virtually all EHR systems (as well as older legacy electronic administrative systems, such as electronic patient registrations systems, and which we are including in this final rule) generate information to support the basic messages commonly used for electronic patient event notifications. While we acknowledge that some level of implementation cost would be realized for those providers not already transmitting notifications, we also note there is substantial agreement that implementation of these basic messaging and notification functions within such existing systems constitutes a relatively low cost burden for providers, particularly when such costs are considered alongside the innovative and beneficial patient care transition solutions and models for best practices they provide.</P>
                    <P>
                        Although we do not have current data on how many facilities are already transmitting electronic patient event notifications, 59 percent of hospitals were found to be routinely electronically notifying a patient's primary care provider upon his or her entry to the hospital's emergency department in 2015, which is an over 50 percent increase since 2012.
                        <SU>68</SU>
                        <FTREF/>
                         By using this historical data to plot a power trend line (R-Squared: 0.9928), we estimate that approximately 71 percent of hospitals may have been routinely transmitting patient event notifications by 2018; therefore, we assume that 29 percent of hospitals, or approximately 1,392, will incur costs associated with updating or configuring their respective EHR systems for electronic patient event notifications. While we do not have parallel data for CAHs, we assume that a similar percentage, or approximately 394 CAHs, will incur this burden. We note that this upwards trend of patient event notification adoption may continue to some unknown extent absent this final rule; however, we are limiting our projection of hospitals that are most affected by these requirements to 2018 due to the amount of uncertainty involved in quantifying this burden.
                    </P>
                    <FTNT>
                        <P>
                            <SU>68</SU>
                             Office of the National Coordinator. (n.d.). Hospital Routine Electronic Notification: Percent of U.S. Hospitals that Routinely Electronically Notify Patient's Primary Care Provider upon Emergency Room Entry, 2015. Retrieved from 
                            <E T="03">https://dashboard.healthit.gov/quickstats/pages/FIG-Hospital-Routine-Electronic-Notification.php</E>
                            .
                        </P>
                    </FTNT>
                    <P>We assume that this process will primarily require the services of two medical records and health information technicians at approximately $42.32/hour for 16 hours each, and 3 hours of time from a medical and health services manager at approximately $109.36/hour, including the costs of overhead and fringe benefits. Thus, the total burden per facility is anticipated to be 35 hours, or approximately $1,682.32 ((16 hours * $42.32/hour * 2 health information technicians) + (3 hours * $109.36/hour * 1 manager)). We assume that the ongoing burden associated with maintenance of these systems would be approximately one quarter of these amounts for the 2 medical records and health information technicians, or 4 hours each, for a total of 8 hours and $338.56 per facility (4 hours * $42.32/hour * 2 health information technicians).</P>
                    <P>In this lower-bound scenario, we estimate that the total first-year burden for hospitals and psychiatric hospitals is approximately 48,720 hours (35 hours * 1,392 hospitals) or $2,341,789 ($1,682.32 * 1,392 hospitals). In subsequent years, we estimate the burden is approximately 11,136 hours (8 hours * 1,392 hospitals) or $471,276 ($338.56 * 1,392 hospitals).</P>
                    <P>For CAHs we estimate that the total first-year burden is approximately 13,790 hours (35 hours * 394 CAHs) or $662,834 ($1,682.32 * 394 CAHs). In subsequent years, we estimate the burden for CAHs is approximately 3,152 hours (8 hours * 394 CAHs) or $133,393 ($338.56 * 394 CAHs).</P>
                    <P>Due to the amount of uncertainty involved in these estimates, we are also presenting estimates for a scenario in which the number of hospitals that routinely electronically notify primary care providers both inside and outside of the hospital's system is assumed to have remained static at the 2015 rate of 29 percent. This upper-bound scenario would indicate that in 2018 approximately 3,407 hospitals and 964 CAHs did not routinely utilize patient event notification, and therefore several thousand additional providers would incur the previously estimated burden per facility.</P>
                    <P>
                        For the purposes of the PRA, we are assuming the midpoint of this range of effects. In this scenario 2,400 hospitals and psychiatric hospitals, and 679 CAHs would incur the estimated burden. The burden estimates associated with the revised CoPs are detailed in Table 3. This information collection will be submitted to OMB under OMB Control Number 0938-New.
                        <PRTPAGE P="25610"/>
                    </P>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,r50,14,14,14,14">
                        <TTITLE>Table 3—Summary of Hour and Dollar Burden by Number of Affected Providers</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="2"> </CHED>
                            <CHED H="1"> </CHED>
                            <CHED H="2"> </CHED>
                            <CHED H="1">Hospitals and psychiatric hospitals</CHED>
                            <CHED H="2">Year 1</CHED>
                            <CHED H="2">Subsequent years</CHED>
                            <CHED H="1">CAHs</CHED>
                            <CHED H="2">Year 1</CHED>
                            <CHED H="2">Subsequent years</CHED>
                        </BOXHD>
                        <ROW RUL="n,s">
                            <ENT I="01">Lower Bound</ENT>
                            <ENT>Affected Providers</ENT>
                            <ENT A="01">1,392</ENT>
                            <ENT A="01">394</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>Total Burden (hours)</ENT>
                            <ENT>48,720</ENT>
                            <ENT>11,136</ENT>
                            <ENT>13,790</ENT>
                            <ENT>3,152</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="22"> </ENT>
                            <ENT>Total Cost</ENT>
                            <ENT>$2,341,789.44</ENT>
                            <ENT>$471,275.52</ENT>
                            <ENT>$662,834.08</ENT>
                            <ENT>$133,392.64</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Primary Estimate</ENT>
                            <ENT>Affected Providers</ENT>
                            <ENT A="01">2,400</ENT>
                            <ENT A="01">679</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>Total Burden (hours)</ENT>
                            <ENT>84,000</ENT>
                            <ENT>19,200</ENT>
                            <ENT>23,765</ENT>
                            <ENT>5,432</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="22"> </ENT>
                            <ENT>Total Cost</ENT>
                            <ENT>$4,037,568.00</ENT>
                            <ENT>$812,544.00</ENT>
                            <ENT>$1,142,295.28</ENT>
                            <ENT>$229,882.24</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Upper Bound</ENT>
                            <ENT>Affected Providers</ENT>
                            <ENT A="01">3,407</ENT>
                            <ENT A="01">964</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>Total Burden (hours)</ENT>
                            <ENT>119,245</ENT>
                            <ENT>27,256</ENT>
                            <ENT>33,740</ENT>
                            <ENT>7,712</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>Total Cost</ENT>
                            <ENT>$5,731,664.24</ENT>
                            <ENT>$1,153,473.92</ENT>
                            <ENT>$1,621,756.48</ENT>
                            <ENT>$326,371.84</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">4. Summary of Information Collection Burdens</HD>
                    <GPOTABLE COLS="9" OPTS="L2,i1" CDEF="s50,r50,10,10,10,10,10,10,10">
                        <TTITLE>Table 4—Summary of Primary Information Collection Burdens</TTITLE>
                        <BOXHD>
                            <CHED H="1">
                                Regulation 
                                <LI>section(s)</LI>
                            </CHED>
                            <CHED H="1">OMB control No.</CHED>
                            <CHED H="1">
                                Number of 
                                <LI>respondents</LI>
                            </CHED>
                            <CHED H="1">
                                Number of 
                                <LI>responses</LI>
                            </CHED>
                            <CHED H="1">
                                Burden per 
                                <LI>response </LI>
                                <LI>(hours)</LI>
                            </CHED>
                            <CHED H="1">
                                Total annual 
                                <LI>burden </LI>
                                <LI>(hours)</LI>
                            </CHED>
                            <CHED H="1">
                                Hourly labor cost of 
                                <LI>reporting </LI>
                                <LI>($)</LI>
                            </CHED>
                            <CHED H="1">
                                Total labor cost 1st year
                                <LI>($)</LI>
                            </CHED>
                            <CHED H="1">
                                Total labor
                                <LI>cost</LI>
                                <LI>subsequent years</LI>
                                <LI>($)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">§ 423.910</ENT>
                            <ENT>0938-0958 *</ENT>
                            <ENT>36</ENT>
                            <ENT>36</ENT>
                            <ENT>960</ENT>
                            <ENT>34,560</ENT>
                            <ENT>$90.02</ENT>
                            <ENT>3,111,091</ENT>
                            <ENT>3,111,091</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 422.119, § 431.60, § 457.730, § 438.242, § 457.1233 and § 156.221</ENT>
                            <ENT>0938-New</ENT>
                            <ENT>345</ENT>
                            <ENT>345</ENT>
                            <ENT>16,800</ENT>
                            <ENT>5,796,000</ENT>
                            <ENT>Varies</ENT>
                            <ENT>544,005,936</ENT>
                            <ENT>0</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 422.119, § 431.60, § 457.730, § 438.242, § 457.1233, and § 156.221</ENT>
                            <ENT>0938-New</ENT>
                            <ENT>345</ENT>
                            <ENT>345</ENT>
                            <ENT>1,710</ENT>
                            <ENT>589,950</ENT>
                            <ENT>Varies</ENT>
                            <ENT/>
                            <ENT>54,391,527</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 482.24(d) and § 482.61(f)</ENT>
                            <ENT>0938-New</ENT>
                            <ENT>2,400</ENT>
                            <ENT>2,400</ENT>
                            <ENT>35</ENT>
                            <ENT>84,000</ENT>
                            <ENT>Varies</ENT>
                            <ENT>4,037,568</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 482.24(d) and § 482.61(f)</ENT>
                            <ENT>0938-New</ENT>
                            <ENT>2,400</ENT>
                            <ENT>2,400</ENT>
                            <ENT>8</ENT>
                            <ENT>19,200</ENT>
                            <ENT>Varies</ENT>
                            <ENT/>
                            <ENT>812,544</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 485.638(d)</ENT>
                            <ENT>0938-New</ENT>
                            <ENT>679</ENT>
                            <ENT>679</ENT>
                            <ENT>35</ENT>
                            <ENT>23,765</ENT>
                            <ENT>Varies</ENT>
                            <ENT>1,142,295</ENT>
                            <ENT/>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">§ 485.638(d)</ENT>
                            <ENT>0938-New</ENT>
                            <ENT>679</ENT>
                            <ENT>679</ENT>
                            <ENT>8</ENT>
                            <ENT>5,432</ENT>
                            <ENT>Varies</ENT>
                            <ENT/>
                            <ENT>229,882.24</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>6,884</ENT>
                            <ENT>Varies</ENT>
                            <ENT>6,552,907</ENT>
                            <ENT>Varies</ENT>
                            <ENT>552,296,890</ENT>
                            <ENT>58,545,044</ENT>
                        </ROW>
                        <TNOTE>* This currently approved ICR will be revised to include the burden discussed in this rule.</TNOTE>
                    </GPOTABLE>
                    <HD SOURCE="HD1">XIII. Regulatory Impact Analysis</HD>
                    <HD SOURCE="HD2">A. Statement of Need</HD>
                    <P>As described in detail in section III. of this rule, the changes to 42 CFR parts 422, 431, 438, 457, and 45 CFR part 156 are part of the agency's broader efforts to empower patients by ensuring that they have full access to their own health care data, through common technologies and without special effort, while keeping that information safe and secure. Interoperability and the capability for health information systems and software applications to communicate, exchange, and interpret data in a usable and readable format, such as PDF or text, is vital, but allowing access to health care data through PDF and text format also limits the utility and sharing of data. Moving to a system in which patients have access to their health care data will help empower them to make informed decisions about their health care, as well as share their data with providers who can assist these patients with their health care. The policies are designed to move Medicare, MA, Medicaid, CHIP, and QHP issuers on the FFEs further to that ultimate goal of empowering their enrollees. As technology has advanced, we have encouraged states, payers, and providers to adopt various forms of technology to improve the accurate and timely exchange of standardized health care information. The policies in this final rule enable patients to be active partners in the exchange of electronic health care data by easily monitoring or sharing their data.</P>
                    <P>
                        States and CMS routinely exchange data on who is enrolled in Medicare, and which parties are liable for paying that beneficiary's Parts A and B 
                        <PRTPAGE P="25611"/>
                        premiums. These “buy-in” data exchanges support state, CMS, and SSA premium accounting, collections, and enrollment functions. We have become increasingly concerned about the limitations of monthly buy-in data exchanges with states. The relatively long lag in updating buy-in data means that the state is not able to terminate or activate buy-in coverage sooner, so the state or beneficiary may be paying premiums for longer than appropriate. We note that once the data catch up, states and CMS reconcile the premiums by recouping and re-billing, so premiums collected are ultimately accurate, but only with an administratively burdensome process involving debits and payments between the beneficiary, state, CMS, SSA, and potentially providers. Daily buy-in data exchange will reduce this administrative burden.
                    </P>
                    <P>States submit data on files at least monthly to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The MMA file was originally developed to meet the need to timely identify dually eligible beneficiaries for the then-new Medicare Part D prescription drug benefit. Over time, we use these files' data on dual eligibility status to support Part C capitation risk-adjustment, and most recently, feeding dual eligibility status to Part A and B eligibility and claims processing systems so providers, suppliers, and beneficiaries have accurate information on beneficiary cost-sharing obligations. As CMS now utilizes MMA data on dual eligibility status in systems supporting all four parts of the Medicare program, it is becoming even more essential that dual eligibility status is accurate and up-to-date. Dual eligibility status can change at any time in a month. Waiting up to a month for status updates can negatively impact access to the correct level of benefit at the correct level of payment. As described in detail in section VII. of this rule, the changes to 42 CFR parts 406, 407, and 423 establish frequency requirements that necessitate all states to participate in daily exchange of buy-in data, and updates frequency requirements to require all states to participate in daily exchange of MMA file data, with CMS by April 1, 2022.</P>
                    <HD SOURCE="HD2">B. Overall Impact</HD>
                    <P>We have examined the impacts of this final rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), section 1102(b) of the Social Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995; Pub. L. 104-4), Executive Order 13132 on Federalism (August 4, 1999), the Congressional Review Act (5 U.S.C. 804(2)), and Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs (January 30, 2017).</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). Section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule: (1) Having an annual effect on the economy of $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local or tribal governments or communities (also referred to as “economically significant”); (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raising novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles set forth in the Executive Order.</P>
                    <P>A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). We estimate that this rulemaking is “economically significant” as measured by the $100 million threshold, and hence also a major rule under the Congressional Review Act. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of the rulemaking. Table 5 summarizes the estimated costs presented in section XII. of this final rule.</P>
                    <P>In the proposed rule, we provided detailed estimations of the required labor categories and number of hours required to implement standards-based APIs (84 FR 7659). We originally estimated a one-time burden of $789,356 per organization or state, per implementation, with an ongoing maintenance cost $158,359.80 per organization or state (84 FR 7659). As we detailed in section XII., to account for additional information commenters presented regarding our costs estimates, we are adjusting our original cost estimates to reflect a range, instead of a point estimate. Our original estimate for the initial one-time cost to implement the API requirements of this final rule of $788,414 per organization will now serve as a minimum estimate. We have increased our primary cost estimate by a factor of 2 to an initial one-time cost of $1,576,829 per organization or state. Additionally, we are increasing our original cost estimate by a factor of 3 for an initial one-time cost of $2,365,243 per organization or state to serve as a high estimate (detailed cost estimates are located in Table 5).</P>
                    <P>Table 5 reflects updated wages for 2018, the latest available from the Bureau of Labor Statistics (BLS) website; the CMS Interoperability and Patient Access proposed rule used 2017 wage estimates. Nevertheless, the change in total impact was small. We note that estimates below do not account for enrollment growth or higher costs associated with medical care. This is because the cost of requirements to implement patient access through APIs and for states to comply with data exchange requirements are not impacted by enrollment growth or higher costs associated with medical care. Per OMB guidelines, the projected estimates are expressed in constant-year dollars (in this case, using 2018 prices and wages).</P>
                    <P>
                        Table 5 forms the basis for allocating costs by year and program to the federal government, state Medicaid agencies, and parent organizations.
                        <PRTPAGE P="25612"/>
                    </P>
                    <GPOTABLE COLS="10" OPTS="L2,i1" CDEF="s20,10,10,10,10,10,10,10,10,10">
                        <TTITLE>Table 5—Estimated Costs (millions) of Final Rule by Provision</TTITLE>
                        <BOXHD>
                            <CHED H="1">Provision</CHED>
                            <CHED H="2">Regulatory text</CHED>
                            <CHED H="1">
                                Dual eligible
                                <LI>care</LI>
                                <LI>coordination</LI>
                            </CHED>
                            <CHED H="2">§ 406.26, § 407.40, § 423.910</CHED>
                            <CHED H="1">
                                Patient
                                <LI>access API (low</LI>
                                <LI>estimate)</LI>
                            </CHED>
                            <CHED H="2">§ 422.119, § 431.60, § 438.242, § 457.730, § 457.123, § 156.221</CHED>
                            <CHED H="1">
                                Patient
                                <LI>access API (primary </LI>
                                <LI>estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                Patient
                                <LI>access API (high</LI>
                                <LI>estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                Total cost (low
                                <LI>estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                Total cost (primary
                                <LI>estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                Total cost (high
                                <LI>estimate)</LI>
                            </CHED>
                            <CHED H="1">
                                Months in year for compliance for dual
                                <LI>eligible</LI>
                                <LI>provisions</LI>
                            </CHED>
                            <CHED H="1">
                                Percent of 25 month window for compliance with dual
                                <LI>eligible</LI>
                                <LI>provisions</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2020</ENT>
                            <ENT>2.8</ENT>
                            <ENT>272.0</ENT>
                            <ENT>544.0</ENT>
                            <ENT>816.0</ENT>
                            <ENT>274.8</ENT>
                            <ENT>546.8</ENT>
                            <ENT>818.8</ENT>
                            <ENT>10</ENT>
                            <ENT>40</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021</ENT>
                            <ENT>3.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>57.8</ENT>
                            <ENT>57.8</ENT>
                            <ENT>57.8</ENT>
                            <ENT>12</ENT>
                            <ENT>48</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2022</ENT>
                            <ENT>0.8</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>55.2</ENT>
                            <ENT>55.2</ENT>
                            <ENT>55.2</ENT>
                            <ENT>3</ENT>
                            <ENT>12</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2023</ENT>
                            <ENT>0.0</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">2024</ENT>
                            <ENT>0</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">2025</ENT>
                            <ENT>0.0</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">2026</ENT>
                            <ENT>0.0</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">2027</ENT>
                            <ENT>0.0</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">2028</ENT>
                            <ENT>0.0</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">2029</ENT>
                            <ENT>0.0</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT>54.4</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total</ENT>
                            <ENT>7.0</ENT>
                            <ENT>761.5</ENT>
                            <ENT>1033.5</ENT>
                            <ENT>1305.5</ENT>
                            <ENT>768.5</ENT>
                            <ENT>1040.5</ENT>
                            <ENT>1312.5</ENT>
                            <ENT>25.0</ENT>
                            <ENT>100</ENT>
                        </ROW>
                        <TNOTE>
                            <E T="02">Note:</E>
                             Totals may not equal sum of parts due to rounding.
                        </TNOTE>
                    </GPOTABLE>
                    <P>
                        <E T="03">Allocation of Cost Impact by Payer:</E>
                         As stated in section XII. of this final rule, cost estimates have been aggregated at the parent organization level because we believe that an organization that offers QHPs on the FFEs, Medicare, Medicaid, and CHIP products would create one system that would be used by all “plans” to whom it offers access to data via APIs. We note that due to the implementation of APIs across multiple business lines, there is no straightforward method to immediately estimate parent organization expenditures on how much of the cost is born by each payer. Although this section provides such estimates it is important to understand how they are arrived at. A summary by Table in this section is provided in Table 6. As shown in Table 6:
                    </P>
                    <P>• We first ascertain total costs of implementing this final rule by provision in (Table 5);</P>
                    <P>• As indicated earlier, we have no straightforward way of ascertaining total costs by payer since we do not have internal data for each parent organization on how it allocates costs by program;</P>
                    <P>• Therefore, to approximate costs we developed approximated proportions of total cost of each parent organization by payer (Medicare, Medicaid, CHIP, and Individual market, including individual market plans sold on and off the Exchanges, as we expect that, among parent organizations of issuers that offer QHPs on the FFEs, costs will be passed on through all plans the issuers offer in the individual market. Since this rule does not apply to QHP issuers offering QHPs only on Federally-facilitated Small Business Health Options Program Exchanges (FF-SHOPs) they were not included in our analysis.</P>
                    <P>• Our use of available data includes many approximations due to data limitations discussed in detail below (Table 7);</P>
                    <P>• Table 7 then allows us to obtain proportions of total costs for this final rule by payer (Table 8);</P>
                    <P>• Since we know the way federal payments for both Medicare and Medicaid are calculated, we can then obtain total costs by payer incurred by the federal government (Table 9);</P>
                    <P>• We next subtracted federal payments by payer (Table 9) from total costs by payer (Table 8) to obtain the non-federal costs of this final rule by payer (Table 10);</P>
                    <P>• Table 11 presents the same data as Table 10; Table 10 presents total non-federal costs per payer, while Table 11 presents average non-federal costs per enrollee per payer;</P>
                    <P>• Table 12 presents the same data as Table 9; while Table 9 presents total costs to the federal government by payer, Table 12 presents average federal costs per enrollee by payer; and</P>
                    <P>• Table 13 lists potential means for payers to deal with new costs.</P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,r100,r100">
                        <TTITLE>Table 6—Outline of the Flow of Logic by Table for This Impact Analysis</TTITLE>
                        <BOXHD>
                            <CHED H="1">Table</CHED>
                            <CHED H="1">Content of table</CHED>
                            <CHED H="1">Comments on table</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">5</ENT>
                            <ENT>Total costs by provision (API, Dual)</ENT>
                            <ENT>Costs are fully developed in the Collection of Information section of this final rule (section XII. of this final rule).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">7</ENT>
                            <ENT>Proportion of premiums by program (2016-2018) used, in later tables, as a proxy for proportion of cost by program</ENT>
                            <ENT>There is no straightforward way to directly assess parent organization cost by payer. Therefore, for each payer we develop approximate percentages of cost per payer.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">8</ENT>
                            <ENT>API costs total cost by year and Program (Medicare, Medicaid, Individual market plans, and CHIP). This total cost is divided by cost to the federal government (Table 9) and non-federal costs to plans and enrollees (Table 10)</ENT>
                            <ENT>We obtain the total API costs for this final rule per program by multiplying the API costs (for all programs) of this final rule (Table 5) by the proportion of premiums presented in Table 7.</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25613"/>
                            <ENT I="01">9</ENT>
                            <ENT>Total costs incurred by the federal government by program and year</ENT>
                            <ENT>Based on how federal payments are calculated in Medicare and Medicaid, we have projected federal proportions of the total cost and these are applied to Table 8 to obtain Table 9.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">10</ENT>
                            <ENT>Non-federal total costs for API by program by year</ENT>
                            <ENT>Table 9 = Table 8-Table 10—non-federal costs are obtained by subtracting federal costs (Table 9) from total costs (Table 8).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">11</ENT>
                            <ENT>Average non-federal cost per enrollee per year by program for plans</ENT>
                            <ENT>Tables 11 and 10 present the same data in different forms. Table 10 presents total non-federal cost by program for states and plans, while Table 11 presents average non-federal costs per enrollee per year for states and plans.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">12</ENT>
                            <ENT>Average federal cost per enrollee per year by program for the federal government</ENT>
                            <ENT>Tables 12 and 9 present the same data in different forms. Table 9 presents total cost to the federal government (due to matching programs), while Table 12 presents average cost per enrollee to the federal government.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">13</ENT>
                            <ENT>How payers would defray the remaining costs</ENT>
                            <ENT>This table lists potential means for a plan to deal with extra costs. We have no way of predicting what will actually happen.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>
                        <E T="03">Preliminary Estimates:</E>
                         This section provides several detailed estimates of cost by payer (Table 7); we also account for federal matching for Medicaid and payments by the Trust Fund for Medicare Advantage organizations (Table 9); we indicate remaining burden on plans (Tables 10, 11) and how they might account for it (Table 12). However, these estimates are approximate as explained in detail below.
                    </P>
                    <P>
                        Data Sources for Cost by Payer: To obtain allocation of cost by payer we used the CMS public use files for MLR data, for 2016.
                        <SU>69</SU>
                        <FTREF/>
                         The MLR data sets are for private insurance plans but the issuers of that private insurance in many cases also have contracts to provide MA, Medicaid, and CHIP managed care plans and report revenue, expense, and enrollment data for these plans on the private insurance MLR reporting form.
                    </P>
                    <FTNT>
                        <P>
                            <SU>69</SU>
                             Center for Consumer Information and Insurance Oversight. (n.d.). Medical Loss Ratio Data and System Resources. Retrieved from 
                            <E T="03">https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html.</E>
                        </P>
                    </FTNT>
                    <P>Thus, these MLR data sets omit organizations that only have Medicare or Medicaid. The data from the CMS MLR files also omit: (1) The CHIP program; and (2) state Medicaid agencies. We now discuss these omissions to assess the accuracy of using these MLR files.</P>
                    <P>
                        <E T="03">CHIP:</E>
                         Eighty-five percent of the 194 CHIP managed care plans also offer Medicaid and hence are covered by the parent entity. We believe it reasonable that the remaining CHIP plans also have commercial offerings since it would be inefficient to operate a CHIP-only plan, as the total national CHIP enrollment is currently only about 7 million. Similarly, except for one state, CHIP programs are run through the state Medicaid agency; again, there would be one interoperability cost for the one state agency since the resulting software and systems would be used both for Medicaid and CHIP. Thus, while we are leaving out CHIP programs in this analysis since they are not in the CMS MLR files, we do not believe this materially alters the overall picture.
                    </P>
                    <P>
                        <E T="03">Medicare Advantage:</E>
                         We compared the CMS MLR files with the CMS Trustee Report.
                        <SU>70</SU>
                        <FTREF/>
                         According to the Trustee Report (Table IV.C2), total MA revenue for 2016 was $189.1 billion. Thus, the reported amount in the CMS MLR files of $157 billion for MA represents 83 percent (157/189.1) of all MA activity reflected in the Trustee Report. Therefore, we believe the proportions obtained from these MLR files are accurate.
                    </P>
                    <FTNT>
                        <P>
                            <SU>70</SU>
                             See Table IV.C2 in, Boards of Trustees (Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds). (2018, June 5). The 2018 Annual Report of The Boards of Trustees of the Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds. Retrieved from 
                            <E T="03">https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Medicaid:</E>
                         For the year for which these MLR files provide data (2016), about 70 percent of Medicaid enrollees were enrolled in Medicaid managed care.
                        <SU>71</SU>
                        <FTREF/>
                         Thus, although the MLR files omit state agencies, we believe that the 70 percent of Medicaid enrollees enrolled in Medicaid managed care provides a good approximation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>71</SU>
                             Centers for Medicare and Medicaid Services. (2018, November 8). CMS Proposes Changes to Streamline and Strengthen Medicaid and CHIP Managed Care Regulations. Retrieved from 
                            <E T="03">https://www.cms.gov/newsroom/press-releases/cms-proposes-changes-streamline-and-strengthen-medicaid-and-chip-managed-care-regulations.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Individual and small group market plans:</E>
                         The MLR files contain data on all commercial parent organizations whether these organizations have other lines of business, such as Medicare Advantage or Medicaid, or not. In discussing commercial plans, we account for: (A) Large group market plans; (B) small group market plans, including SHOP plans; (C) individual market Exchange plans; and (D) individual market off-Exchange plans.
                    </P>
                    <P>• We have carved out the large employer plans since the provisions of this final rule do not apply to them, and we do not believe that parent organizations would pass on costs for individual and small group market plans to large group employer-sponsored plans.</P>
                    <P>• We have noted that the provisions of this final rule do not apply to QHP issuers offering QHPs only on FF-SHOPs, so we are not including small group market plans in this analysis.</P>
                    <P>• We believe it is reasonable, that even though the provisions of this final rule do not apply to off-Exchange individual market plans, issuers subject to this rule offering QHPs on the FFEs will spread the cost to all plans issuers offer in the individual market. They will also likely offer the benefits of the APIs to all covered lives, as they can be marketed as a value add service, and it is logistically more challenging to offer a service to only a limited number of enrollees.</P>
                    <P>
                        • We estimate that off-Exchange plans offered by issuers who offer no QHPs on 
                        <PRTPAGE P="25614"/>
                        FFEs are about 7 percent of total individual market enrollment. Therefore, to the extent that we are including off-Exchange plans, the calculations below will be an approximation, but given this low proportion of off-Exchange-only issuers, we do not believe including them in this approximation will have a major impact.
                    </P>
                    <P>
                        <E T="03">Best Estimates of Impact per Program and Payer:</E>
                         We present two methods to obtain an estimate of cost by program and payer, both for purposes of assessing impact on: (1) Small entities; (2) the federal government; (3) payers (states and plans); and (4) enrollees. We could assume costs proportional to current enrollment, or alternatively, we could assume costs proportional to total premium. For purposes of analyzing impact on small entities and impacts of the provision on the federal government, payers, plans, and enrollees we are using the method of assuming costs proportional to total premium (the method of assuming costs proportional to current enrollment will be used below to assess impact on transfers to enrollees).
                    </P>
                    <P>The CMS Interoperability and Patient Access proposed rule used 2016 CMS MLR files (84 FR 7662). Since its publication, 2017 and 2018 data have become available. However, we are only using these data to obtain proportions and, as Table 7 shows, the proportions for premiums have not changed significantly (only one quarter to one third percent for Medicare and Medicaid). Therefore, we retain and continue to use the 2016 proportions for purposes of this analysis with a note that they generally have remained constant. These proportions of premiums are being used as a proxy to approximate total cost.</P>
                    <P>In the proposed rule we used the full $370 billion in commercial premium in determining our proportions (84 FR 7662). As discussed above, we are revising the estimates because upon further consideration, we have concluded that issuers in the commercial group markets are unlikely to spread the costs through increasing premium rates on those types of plans because issuers are not required to implement and maintain the API requirements of this final rule in the group markets and there are no indications that employer groups in these markets would be willing to pay for this provision through increased premium rates. Consequently, the $370 billion commercial premium is being reduced to $77 billion and the 76 million enrollees are being reduced to 17.5 million.</P>
                    <P>As discussed above, the $370 billion (and 76 million enrollees) represented both individual and small group and large group market plans; the $77 billion and 17.5 million enrollees represent all individual market plans whether they are sold on and/or off-Exchange. We note that this reduction from our original estimate is due to the fact that most plans are large employer plans, and the individual market is only 20 to 23 percent of the full health insurance market. This refinement better aligns with the proportion of the market impacted by this final rule.</P>
                    <P>Among issuers with products in both the individual market and MA or the individual market and Medicaid, the 2016 CMS MLR files show $77 billion reported in premium for individual market plans, $157 billion reported for MA, and $113 billion reported for Medicaid. Consequently, the proportion of interoperability cost for each of the programs is 22.19 percent (77/(77+157+113)), 45.24 percent (157/(77+157+113)), and 32.56 percent (113/(77+157+113)) for individual market plans, MA, and Medicaid respectively. Table 7 shows similar proportions for 2017 and 2018.</P>
                    <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s50,12,12,12,12">
                        <TTITLE>Table 7—Proportion of Premiums (in Billions) for Medicare, Medicaid, and Individual Market Plans</TTITLE>
                        <BOXHD>
                            <CHED H="1">Year</CHED>
                            <CHED H="1">Medicaid</CHED>
                            <CHED H="1">
                                Medicare
                                <LI>Advantage</LI>
                            </CHED>
                            <CHED H="1">
                                Individual
                                <LI>market</LI>
                                <LI>plans</LI>
                            </CHED>
                            <CHED H="1">Totals</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2016 Premium (billions)</ENT>
                            <ENT>113</ENT>
                            <ENT>157</ENT>
                            <ENT>77</ENT>
                            <ENT>347</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2017 Premium (billions)</ENT>
                            <ENT>119.5</ENT>
                            <ENT>170.3</ENT>
                            <ENT>86</ENT>
                            <ENT>376</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2018 Premium (billions)</ENT>
                            <ENT>127</ENT>
                            <ENT>184</ENT>
                            <ENT>91</ENT>
                            <ENT>402</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2016 Percentage (used in this RIA in all estimates) of total costs by program</ENT>
                            <ENT>32.56%</ENT>
                            <ENT>45.24%</ENT>
                            <ENT>22.19%</ENT>
                            <ENT>100.00%</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2017 Percentage</ENT>
                            <ENT>31.78%</ENT>
                            <ENT>45.29%</ENT>
                            <ENT>22.93%</ENT>
                            <ENT>100.00%</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2018 Percentage</ENT>
                            <ENT>31.62%</ENT>
                            <ENT>45.81%</ENT>
                            <ENT>22.56%</ENT>
                            <ENT>100.00%</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>As indicated earlier, since cost allocation at the parent organization level and the allocations of each parent organization may differ by program (Medicare, Medicaid, CHIP, and Individual market plans) and is an internal business decision, we cannot directly assess per-payer costs. However, using the MLR tables, we can assess the proportions of cost by program. We can then multiply these proportions (as presented in Table 7) by the total costs of this final rule as presented in Table 5 to obtain Table 8, which breaks out the total column in Table 5, the total cost by year of implementing and maintaining the API, to offer API costs by year and program.</P>
                    <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s50,14,14,14,14">
                        <TTITLE>Table 8—API Costs (in Millions) by Year and Program</TTITLE>
                        <BOXHD>
                            <CHED H="1">Year</CHED>
                            <CHED H="1">
                                Full
                                <LI>implementation and maintenance</LI>
                                <LI>costs (millions)</LI>
                                <LI>(from Table 5) for API</LI>
                                <LI>provision</LI>
                            </CHED>
                            <CHED H="1">
                                Individual
                                <LI>market plans</LI>
                                <LI>(22.19%)</LI>
                            </CHED>
                            <CHED H="1">
                                Medicaid and CHIP
                                <LI>(32.56%)</LI>
                            </CHED>
                            <CHED H="1">
                                Medicare 
                                <LI>Advantage</LI>
                                <LI>(45.24%)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2020 (Low estimate)</ENT>
                            <ENT>272.0</ENT>
                            <ENT>60.4</ENT>
                            <ENT>88.6</ENT>
                            <ENT>123.1</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (Primary estimate)</ENT>
                            <ENT>544.0</ENT>
                            <ENT>120.7</ENT>
                            <ENT>177.2</ENT>
                            <ENT>246.1</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (High Estimate)</ENT>
                            <ENT>816.0</ENT>
                            <ENT>181.1</ENT>
                            <ENT>265.7</ENT>
                            <ENT>369.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2022</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25615"/>
                            <ENT I="01">2023</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2024</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2025</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2026</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2027</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2028</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">2029</ENT>
                            <ENT>54.4</ENT>
                            <ENT>12.1</ENT>
                            <ENT>17.7</ENT>
                            <ENT>24.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (Low Estimate)</ENT>
                            <ENT>761.5</ENT>
                            <ENT>169.0</ENT>
                            <ENT>248.0</ENT>
                            <ENT>344.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (Primary Estimate)</ENT>
                            <ENT>1033.5</ENT>
                            <ENT>229.3</ENT>
                            <ENT>336.6</ENT>
                            <ENT>467.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (High Estimate)</ENT>
                            <ENT>1305.5</ENT>
                            <ENT>289.7</ENT>
                            <ENT>425.1</ENT>
                            <ENT>590.7</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD2">Methods of Bearing Cost by Payer</HD>
                    <P>
                        <E T="03">QHPs on the FFEs:</E>
                         Individual market plans have the option to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market plans on the FFEs, there would be federal premium tax credit (PTC) impacts. The purpose of the PTC is to assist enrollees in paying premium costs. Since PTCs are only available if an individual purchases an individual market plan on an Exchange, the PTC estimates apply only to Exchange plans. In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and non-Exchange plans, and some issuers have only non-Exchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate.
                    </P>
                    <P>
                        <E T="03">Medicare Advantage:</E>
                         MA organizations may increase bids to reflect the costs of this final rule. Some of these expected increased bid costs may increase Medicare Trust Fund payments. For those (most) MA organizations whose bid amount is below the benchmark, the Trust Fund provides total expenditures to the MA organizations consisting of: (1) Full payment of the bid amount; and (2) the rebate, a portion of the difference between the benchmark and the bid amount. Since MA organizations are increasing their bid amounts to reflect the costs of this final rule, it follows that the rebate, equaling the difference between the benchmark and bid, is decreased, resulting in less rebates paid to the MA organizations. Based on our past experience and projections for the future, the rebate is estimated as 34 percent of the difference between benchmark and bid. Thus, although the Trust Fund pays the bid in full, nevertheless, 66 percent of the increased bid costs arising from this final rule, are reduced from the rebates. The MA organizations in its submitted bid, can address this reduction of rebates by either: (1) Temporarily, for marketing purposes, absorbing the loss by reducing its profit margin; (2) reducing the supplemental benefits it provides the enrollee paid for by the rebate; or (3) raising enrollee premiums in order to provide supplemental benefits for which premiums are not paid by the rebate. The decision of what approach to use is an internal business decision in part motivated by unforeseen forces of marketing; we therefore have no way of predicting what will happen.
                    </P>
                    <P>
                        <E T="03">Medicaid:</E>
                         State Medicaid agencies may be allowed to allocate the costs of state information retrieval systems between the costs attributable to design, development, installation, or enhancement of the system—at a 90 percent federal match—and for ongoing operations of the system—at a 75 percent federal match.
                    </P>
                    <P>For Medicaid managed care entities, we assume an MCO, PIHP, and PAHP cost for implementing the standards-based API provisions would be built into the capitation rates and paid for by the state Medicaid agency, with the state Medicaid agency being reimbursed at the state's medical assistance match rate. For purposes of these estimates we use the weighted FMAP, 58.44, which is based on our past experience with this program.</P>
                    <P>
                        Medicaid managed care costs constitute 52 percent of the Medicaid program costs.
                        <SU>72</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>72</SU>
                             Allen, K. (2019, April 18). Medicaid Managed Care Spending in 2018. Retrieved from 
                            <E T="03">https://www.healthmanagement.com/blog/medicaid-managed-care-spending-in-2018/.</E>
                        </P>
                    </FTNT>
                    <P>Consequently, for the first year (implementation year), the federal matching is (0.48*0.90+0.52*0.5844) of the total program costs, reflecting the 90 percent first year implementation matching for state agencies which comprise 48 percent of the program cost plus 58.44 percent matching for the Medicaid managed care plans which comprise 52 percent of the program costs. Similarly, for years after the first the federal costs are (0.48*0.75+0.52*0.5844) of total program costs.</P>
                    <P>
                        <E T="03">CHIP:</E>
                         Most states operate Medicaid and CHIP from the same state agency. One state is a notable exception in that it has a separate Medicaid and CHIP agency. The federal government pays an enhanced federal medical assistance percentage (EFMAP) to states for all costs associated with CHIP, including systems costs (this is unlike Medicaid where there are different FMAPs for different types of costs). For federal FY 2019, the EFMAPs will range from 88 to 100 percent. For federal FY 2020, the EFMAPs will range from approximately 76.5 to 93 percent. After federal FY 2020, the EFMAPs will range from approximately 65 to 81.5 percent. Since the CHIP program federal rebate ranges include the 90 percent and 75 percent federal matching proportions of the Medicaid program, we are applying the 90 percent and 75 percent from Medicaid to the CHIP programs. Since the CHIP program is small relative to the Medicaid program, we believe this approach reasonable.
                    </P>
                    <P>
                        Table 9 uses these proportions to estimate the impact of the API on the federal government. For example, the $65.2 million cost to the federal government for Medicaid/CHIP for 2020 
                        <PRTPAGE P="25616"/>
                        (low estimate), the implementation year of the API, is obtained by multiplying the total $88.6 million (low estimate) cost listed in Table 8 by (0.48*0.90+0.52*0.5844) the ratio indicated in the previous paragraphs.
                    </P>
                    <P>These assumptions on all first-year federal expenses are reflected in Table 9 which includes PTC payments as well as federal matching in Medicaid and Medicare. For PTC and Medicare we have assumed Federal payment in 2021. We note that we are not discussing at this point how parent organizations will bear these costs. This will be discussed below. However, the basis for the discussion is the calculation of non-federal cost born by enrollees and plans which is obtained by subtracting federal costs from total costs.</P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                        <TTITLE>Table 9—Costs Incurred by Federal Government Program and Year</TTITLE>
                        <TDESC>[In Millions]</TDESC>
                        <BOXHD>
                            <CHED H="1">Year</CHED>
                            <CHED H="1">
                                For individual
                                <LI>market plans</LI>
                            </CHED>
                            <CHED H="1">For Medicaid CHIP</CHED>
                            <CHED H="1">
                                For Medicare
                                <LI>Advantage</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2020 (Low estimate)</ENT>
                            <ENT>0.0</ENT>
                            <ENT>65.2</ENT>
                            <ENT>0.0</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (Primary estimate)</ENT>
                            <ENT>0.0</ENT>
                            <ENT>130.4</ENT>
                            <ENT>0.0</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (High Estimate)</ENT>
                            <ENT>0.0</ENT>
                            <ENT>195.5</ENT>
                            <ENT>0.0</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (Low estimate)</ENT>
                            <ENT>6.1</ENT>
                            <ENT>11.8</ENT>
                            <ENT>50.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (Primary Estimate)</ENT>
                            <ENT>6.1</ENT>
                            <ENT>11.8</ENT>
                            <ENT>92.1</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2022 (High Estimate)</ENT>
                            <ENT>6.1</ENT>
                            <ENT>11.8</ENT>
                            <ENT>133.9</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2022</ENT>
                            <ENT>6.2</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2023</ENT>
                            <ENT>6.2</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2024</ENT>
                            <ENT>6.3</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2025</ENT>
                            <ENT>6.3</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2026</ENT>
                            <ENT>6.3</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2027</ENT>
                            <ENT>6.3</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2028</ENT>
                            <ENT>6.3</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">2029</ENT>
                            <ENT>6.4</ENT>
                            <ENT>11.8</ENT>
                            <ENT>8.4</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Low Estimate)</ENT>
                            <ENT>56.4</ENT>
                            <ENT>171.0</ENT>
                            <ENT>117.1</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Primary Estimate)</ENT>
                            <ENT>56.4</ENT>
                            <ENT>236.2</ENT>
                            <ENT>159.0</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (High Estimate)</ENT>
                            <ENT>56.4</ENT>
                            <ENT>301.4</ENT>
                            <ENT>200.8</ENT>
                        </ROW>
                        <TNOTE>
                            <E T="02">Note:</E>
                             The following percentages were applied to Table 8 to obtain Table 9: 0 percent for individual market plans, 34 percent for Medicare advantage plans and 0.48*0.90+0.52*0.5844 (1st year) and 0.48*0.75+0.52*0.5844 (later years) for Medicaid. Furthermore, as discussed above, federal payments to Medicare Advantage for implementation occurs fully in 2021.
                        </TNOTE>
                    </GPOTABLE>
                    <P>By taking the difference between the respective cells in Tables 8 (total costs by program) and 9 (total matching by the federal government), we obtain the remaining costs for the API for Medicare Advantage plans and for state Medicaid agencies. To this amount (which only deals with the API provisions) must be added the coordination cost for the dual eligible (column 3 of Table 5) multiplied by the proportion of costs presented in Table 7. This remaining cost born by Medicare Advantage plans and state Medicaid agencies is presented in Table 10. Since the federal government does not match QHP costs, the total cost for QHPs on the FFEs is born in its entirety by the plans. This also is listed in Table 10; however, in subtracting Table 9 from Table 8, we exclude PTC costs. These are federal costs, but unlike Medicare Advantage and Medicaid, the QHPs on the FFEs must account for the full cost of implementation. These PTC costs are not used to defray API costs.</P>
                    <P>For example, Table 10 lists for 2020 (low estimate), Medicaid/CHIP a remaining cost to states of $24.3 million ($88.6 million total (low estimate) cost for 2020 (Table 8)−$65.2 million matched by the federal government (Table 9) + ($2.8 million total cost for coordination of dual eligibles (Table 5) * 32.56 percent (proportion of total costs incurred by Medicaid/CHIP (Table 7)). (There are minor differences due to rounding.)</P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                        <TTITLE>Table 10—Remaining Costs by Program for API by Year</TTITLE>
                        <TDESC>[In millions]</TDESC>
                        <BOXHD>
                            <CHED H="1">Year</CHED>
                            <CHED H="1">
                                For individual
                                <LI>market plans</LI>
                            </CHED>
                            <CHED H="1">
                                For Medicaid/
                                <LI>CHIP</LI>
                            </CHED>
                            <CHED H="1">
                                For Medicare
                                <LI>Advantage</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2020 (Low estimate)</ENT>
                            <ENT>61.0</ENT>
                            <ENT>24.3</ENT>
                            <ENT>124.3</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (Primary estimate)</ENT>
                            <ENT>121.3</ENT>
                            <ENT>47.7</ENT>
                            <ENT>247.4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (High Estimate)</ENT>
                            <ENT>181.7</ENT>
                            <ENT>71.1</ENT>
                            <ENT>370.1</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (Low estimate)</ENT>
                            <ENT>12.8</ENT>
                            <ENT>7.0</ENT>
                            <ENT>-24.1</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021(Primary Estimate)</ENT>
                            <ENT>12.8</ENT>
                            <ENT>7.0</ENT>
                            <ENT>-65.9</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (High Estimate)</ENT>
                            <ENT>12.8</ENT>
                            <ENT>7.0</ENT>
                            <ENT>-107.8</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2022</ENT>
                            <ENT>12.3</ENT>
                            <ENT>6.2</ENT>
                            <ENT>16.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2023</ENT>
                            <ENT>12.1</ENT>
                            <ENT>6.0</ENT>
                            <ENT>16.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2024</ENT>
                            <ENT>12.1</ENT>
                            <ENT>6.0</ENT>
                            <ENT>16.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2025</ENT>
                            <ENT>12.1</ENT>
                            <ENT>6.0</ENT>
                            <ENT>16.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2026</ENT>
                            <ENT>12.1</ENT>
                            <ENT>6.0</ENT>
                            <ENT>16.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2027</ENT>
                            <ENT>12.1</ENT>
                            <ENT>6.0</ENT>
                            <ENT>16.2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2028</ENT>
                            <ENT>12.1</ENT>
                            <ENT>6.0</ENT>
                            <ENT>16.2</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <PRTPAGE P="25617"/>
                            <ENT I="01">2029</ENT>
                            <ENT>12.1</ENT>
                            <ENT>6.0</ENT>
                            <ENT>16.2</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Low Estimate)</ENT>
                            <ENT>170.5</ENT>
                            <ENT>79.3</ENT>
                            <ENT>230.6</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Primary Estimate)</ENT>
                            <ENT>230.9</ENT>
                            <ENT>102.6</ENT>
                            <ENT>311.8</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (High Estimate)</ENT>
                            <ENT>291.3</ENT>
                            <ENT>126.0</ENT>
                            <ENT>392.7</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>We next discuss in Tables 11 through 13 how payers and the federal government will deal with these extra costs. We also discuss whether the costs are excessive for existing plans as well as how new plans might deal with these costs.</P>
                    <P>The further discussion of bearing these costs is illustrated by reformulating the costs in terms of costs per enrollee (per year), which is obtained by dividing the total cost to the payer for all programs in which it participates (Medicare, Medicaid, CHIP, and Individual market plans) by its total enrollment. As an example, if a payer hypothetically spent $1 billion in a year for 100,000 enrollees then the cost per enrollee per year is $10,000 ($1 billion/100,000).</P>
                    <P>As can be seen from this example, the cost per enrollee metric facilitates comparison of costs. Since program expenditures for both Medicaid and MA are typically hundreds of millions (or billions) of dollars, concepts like burden and negligibility may not have intuitive meaning, as opposed to the costs per enrollee, which are more manageable and understandable.</P>
                    <P>
                        To provide background, the 2018 Medicare Trust Fund Report 
                        <SU>73</SU>
                        <FTREF/>
                         states that costs per enrollee are projected to be roughly $12,000—$14,000 for contract years 2020—2023 (Table IV.C3). The costs per enrollee for the Medicaid program are similarly several thousand dollars. The estimates in the 2019 Medicare Trust Fund Report are identical.
                        <SU>74</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>73</SU>
                             Boards of Trustees (Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds). (2018, June 5). The 2018 Annual Report of The Boards of Trustees of the Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds. Retrieved from 
                            <E T="03">https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>74</SU>
                             See page 154 in, Boards of Trustees (Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds). (2019, April 22). The 2019 Annual Report of The Boards of Trustees of the Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds. Retrieved from 
                            <E T="03">https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2019.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        For purposes of indicating the cost per enrollee, we estimate 110.5 million enrollees will be affected by these provisions since currently there are 17.5, 66,
                        <SU>75</SU>
                        <FTREF/>
                         20,
                        <SU>76</SU>
                        <FTREF/>
                         and 7 
                        <SU>77</SU>
                        <FTREF/>
                         million enrollees covered by payers in the individual market, Medicaid, MA, and separate CHIP programs, respectively. Table 11 presents costs per enrollee by program for payers after reducing total costs by federal matching, while Table 12 presents costs per enrollee by program for the federal government.
                    </P>
                    <FTNT>
                        <P>
                            <SU>75</SU>
                             Centers for Medicare and Medicaid Services. (n.d.). October 2019 Medicaid &amp; CHIP Enrollment Data Highlights. Retrieved from 
                            <E T="03">https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/index.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>76</SU>
                             Centers for Medicare and Medicaid Services. (n.d.). Monthly Contract Summary Report—August 2018. Retrieved from 
                            <E T="03">https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/MCRAdvPartDEnrolData/Monthly-Contract-and-Enrollment-Summary-Report-Items/Contract-Summary-2018-08.html?DLPage=1&amp;DLEntries=10&amp;DLSort=1&amp;DLSortDir=descending.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>77</SU>
                             Centers for Medicare and Medicaid Services. (n.d.). October 2019 Medicaid &amp; CHIP Enrollment Data Highlights. Retrieved from 
                            <E T="03">https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/index.html.</E>
                        </P>
                    </FTNT>
                    <P>For example, the 2020 (low estimate) cost per enrollee for commercial individual market plans is $3.48 (Table 11), which is obtained by dividing the total, 2020, low-estimate, non-federal, individual market plan cost of $61 million (Table 10) by 17.5 million enrollees. (This is based on the low estimate of cost for API; the high estimate of cost would be $10.38 = $181.7 million/17.5 million).</P>
                    <P>The 2022 cost per enrollee for state Medicaid agencies after federal matching is 9 cents per enrollee (Table 11), which is obtained by dividing the total non-federal cost per program after federal matching, $6.2 million (Table 10) by 73 million enrollees (66 million in Medicaid + 7 million in CHIP). Each of these three calculations restates total spending per program per stakeholder (government, state Medicaid agencies, or Medicare Advantage plans) in terms of cost per enrollee.</P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                        <TTITLE>Table 11—Average Cost per Enrollee per Year (Dollars and Cents) by Program for Payers</TTITLE>
                        <BOXHD>
                            <CHED H="1">Current enrollment by payer (millions)</CHED>
                            <CHED H="1">
                                Individual
                                <LI>market plans (17.5)</LI>
                            </CHED>
                            <CHED H="1">
                                Medicaid
                                <LI>plans (73)</LI>
                            </CHED>
                            <CHED H="1">
                                Medicare
                                <LI>Advantage</LI>
                                <LI>plans (20)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2020 (Low estimate)</ENT>
                            <ENT>3.48</ENT>
                            <ENT>0.33</ENT>
                            <ENT>6.22</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (Primary estimate)</ENT>
                            <ENT>6.93</ENT>
                            <ENT>0.65</ENT>
                            <ENT>12.37</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (High Estimate)</ENT>
                            <ENT>10.38</ENT>
                            <ENT>0.97</ENT>
                            <ENT>18.51</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (Low estimate)</ENT>
                            <ENT>0.73</ENT>
                            <ENT>0.10</ENT>
                            <ENT>-1.20</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021(Primary Estimate)</ENT>
                            <ENT>0.73</ENT>
                            <ENT>0.10</ENT>
                            <ENT>-3.30</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (High Estimate)</ENT>
                            <ENT>0.73</ENT>
                            <ENT>0.10</ENT>
                            <ENT>-5.39</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2022</ENT>
                            <ENT>0.70</ENT>
                            <ENT>0.09</ENT>
                            <ENT>0.83</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2023</ENT>
                            <ENT>0.69</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.81</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2024</ENT>
                            <ENT>0.69</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.81</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2025</ENT>
                            <ENT>0.69</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.81</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25618"/>
                            <ENT I="01">2026</ENT>
                            <ENT>0.69</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.81</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2027</ENT>
                            <ENT>0.69</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.81</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2028</ENT>
                            <ENT>0.69</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.81</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">2029</ENT>
                            <ENT>0.69</ENT>
                            <ENT>0.08</ENT>
                            <ENT>0.81</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Low Estimate)</ENT>
                            <ENT>9.7</ENT>
                            <ENT>1.1</ENT>
                            <ENT>11.5</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Primary Estimate)</ENT>
                            <ENT>13.2</ENT>
                            <ENT>1.4</ENT>
                            <ENT>15.6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (High Estimate)</ENT>
                            <ENT>16.6</ENT>
                            <ENT>1.7</ENT>
                            <ENT>19.6</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                        <TTITLE>Table 12—Average Cost per Enrollee per Year (Dollars and Cents) by Program for Federal Government</TTITLE>
                        <BOXHD>
                            <CHED H="1">Current enrollment by payer (millions)</CHED>
                            <CHED H="1">
                                Individual
                                <LI>market plans (17.5)</LI>
                            </CHED>
                            <CHED H="1">
                                Medicaid
                                <LI>plans (73)</LI>
                            </CHED>
                            <CHED H="1">
                                Medicare
                                <LI>Advantage</LI>
                                <LI>plans (20)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2020 (Low estimate)</ENT>
                            <ENT>0.00</ENT>
                            <ENT>0.89</ENT>
                            <ENT>0.00</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (Primary estimate)</ENT>
                            <ENT>0.00</ENT>
                            <ENT>1.79</ENT>
                            <ENT>0.00</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2020 (High Estimate)</ENT>
                            <ENT>0.00</ENT>
                            <ENT>2.68</ENT>
                            <ENT>0.00</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (Low estimate)</ENT>
                            <ENT>0.35</ENT>
                            <ENT>0.16</ENT>
                            <ENT>2.51</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021(Primary Estimate)</ENT>
                            <ENT>0.35</ENT>
                            <ENT>0.16</ENT>
                            <ENT>4.60</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2021 (High Estimate)</ENT>
                            <ENT>0.35</ENT>
                            <ENT>0.16</ENT>
                            <ENT>6.69</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2022</ENT>
                            <ENT>0.35</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2023</ENT>
                            <ENT>0.35</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2024</ENT>
                            <ENT>0.36</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2025</ENT>
                            <ENT>0.36</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2026</ENT>
                            <ENT>0.36</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2027</ENT>
                            <ENT>0.36</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2028</ENT>
                            <ENT>0.36</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">2029</ENT>
                            <ENT>0.37</ENT>
                            <ENT>0.16</ENT>
                            <ENT>0.42</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Low Estimate)</ENT>
                            <ENT>3.2</ENT>
                            <ENT>2.3</ENT>
                            <ENT>5.9</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">Total (Primary Estimate)</ENT>
                            <ENT>3.2</ENT>
                            <ENT>3.2</ENT>
                            <ENT>7.9</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (High Estimate)</ENT>
                            <ENT>3.2</ENT>
                            <ENT>4.1</ENT>
                            <ENT>10.0</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>In Table 13, we explain possible ways payers may deal with these extra costs. We emphasize that Table 13 lists potential legal possibilities. What actually happens will depend on market dynamics and internal business decisions, and we have no straightforward way of predicting what these actual behaviors and responses will be.</P>
                    <P>
                        <E T="03">Individual Market Plans:</E>
                         As noted above, individual market plans have the option of absorbing costs or passing costs to enrollees either in the form of higher premiums or reduced benefits that are non-essential health benefits (EHBs). The average estimated cost per enrollee in 2021 through 2028 is under a dollar, which we assume issuers would pass on to enrollees. However, for purposes of market competitiveness, it is possible that some of the 2020 average estimated cost of $3.48 per enrollee (low estimate) or $10.38 per enrollee per year (high estimate) would be absorbed by each QHP issuer on an FFE.
                    </P>
                    <P>
                        <E T="03">Medicaid:</E>
                         State Medicaid agencies and CHIP are adding a cost under 10 cents per enrollee for 2021 through 2029. Total costs per enrollee for the Medicaid program are several thousand dollars. We note, the federal government is incurring costs capped at $2.68 per enrollee per year in 2020 and at 16 cents per enrollee per year in 2021 through 2029.
                    </P>
                    <P>
                        <E T="03">Medicare Advantage:</E>
                         In their bids (submitted the June prior to the beginning of the coverage year), Medicare Advantage plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: (1) Temporarily absorbing costs by reducing profit margins; (2) reducing the supplemental benefits paid for by the rebates; or (3) raising enrollee cost sharing or premiums (however, we believe many plans for competitive reasons would chose to remain zero premium and either absorb losses for one year or reduce rebate-funded supplemental benefits in the amount per enrollee shown in Table 9). Table 13 summarizes these methods of bearing the remaining costs.
                        <PRTPAGE P="25619"/>
                    </P>
                    <GPOTABLE COLS="02" OPTS="L2,p1,8/9,i1" CDEF="s75,r150">
                        <TTITLE>Table 13—How Payers Would Defray Remaining Costs</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1"> </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Individual Market Plans</ENT>
                            <ENT>Individual market plans generally have the option of absorbing costs (for example, for reasons of market competitiveness), increasing premiums to enrollees, or modifying cost-sharing or non-EHB covered benefits. Cost would be spread over all parent organization enrollees in a specified state and the individual market in FFE states. Small commercial individual market issuers seeking certification of plans as QHPs on the FFEs may request an exception to the API provisions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Medicaid/CHIP</ENT>
                            <ENT>State Medicaid agencies would bear the cost (under 10 cents per enrollee). Medicaid plans are fully capitated but may have to defer first year costs.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Medicare Advantage (MA)</ENT>
                            <ENT>MA plans in their June-submitted bids would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: (1) Temporarily absorbing costs by reducing profit margins; (2) reducing additional benefits paid for by the rebates; or (3) raising enrollee cost sharing (however, many plans for competitive reasons would chose to remain zero premium and either absorb losses for one year or reduce additional, rebate-funded benefits in the amount per enrollee shown in Table 9). Tax deferment and amortization as applicable ameliorates cost. Capital costs are spread over entire parent organization enrollees. New plans are allowed to enter with initial negative margins with the expectation that they will stabilize over the first few years.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>
                        <E T="03">PTC Impact:</E>
                         First, we note that there will be no impact on the expected 2020 PTC payment because 2020 premium rates were finalized last year, so even if issuers incur expenses that they did not anticipate when setting rates, they will not be able to reflect those expenses in the premium rates, and therefore, the expected PTC payments for 2020 will not change.
                    </P>
                    <P>Table 10 shows that for 2021 through 2029 the estimated impact to QHPs on the FFEs is a $12 million expense. This estimated $12 million expense burden represents an increase to annual FFE premium of approximately 0.03 percent.</P>
                    <P>Within the FFE states, the estimated expense burden will impact premium rates in the individual market, and is spread across both Exchange and non-Exchange QHPs. PTCs are only paid for QHPs offered through Exchanges, and are calculated as a function of the second lowest cost silver plan. Because of the wide variability of Exchange plans we make the simplifying assumption that the industry would increase the second-lowest-cost silver plan premium rate in the same amount as the overall premium rate increase as a result of the RIA expense estimate. We can then apply the overall rate increase to the projected PTC payments in the FFE states to estimate the impact to PTC payments.</P>
                    <P>Therefore, we estimate that impact to PTCs in the FFE states will be approximately $6 million per year starting in 2021, which is about 0.02 percent of the total 2021 expected PTC payment in FFE states. Again, the calculated PTC impacts in 2021 through 2029 are included with all federal impacts in Table 9.</P>
                    <P>We next summarize the public comments we received on our estimated impacts and provide our responses.</P>
                    <P>
                        <E T="03">Comment:</E>
                         Some commenters requested that the government share more in the associated costs of the open, standards-based API implementation for both MA and Medicaid plans. These commenters noted that additional financial sharing by the federal government would help remedy offsets potentially being absorbed by the health plan that may result in decreased benefits and/or increase premiums.
                    </P>
                    <P>
                        <E T="03">Medicare Advantage:</E>
                         Some commenters requested that the costs be included in MA bids. Other commenters recommended that if CMS is going to make specific technological requirements around implementation of the CMS Interoperability and Patient Access proposed rule then health plans should be allowed to include a percentage of these costs in their MA bids. One commenter recommended that CMS could consider adding a fixed dollar amount to MA bids if health plans complied with the requirements of the proposed rule, or CMS could add it into the bid tool.
                    </P>
                    <P>
                        <E T="03">Medicaid:</E>
                         Similar comments were made for Medicaid plans. One commenter recommended that CMS provide states with a 100 percent federal matching to facilitate implementation and that state Medicaid agencies be required to include plan implementation costs into capitation rates. Another commenter requested that CMS require state Medicaid agencies to include a fixed amount of dollars or a percentage of implementation costs into plan administrative costs to remedy the cost impact of implementation.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We appreciate the commenters' concerns and suggestions. As noted previously in this RIA, we have assumed traditional federal sharing of costs for both the MA and Medicaid programs. The results have been presented in Tables 9 through 12 with Table 13 indicating how payers and the federal government would defray costs. In Tables 11 and 12 the average estimated costs per enrollee (under $15) is compared with overall costs per enrollee (several thousand dollars). Additionally, we have been careful in our analysis to distinguish between federal matching to state Medicaid entities in the first year, federal matching to state Medicaid entities in later years, and federal matching of state payment of capitation rates to state Medicaid agencies. We take note that the commenter's concerns for specific federal matching for the provisions of this final rule would require legislative action. Consequently, when writing the CMS Interoperability and Patient Access proposed rule, we did not believe it was necessary to propose additional federal spending beyond the already existing federal reimbursement to MA, Medicaid plans, and state agencies.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters expressed concern that the CMS Interoperability and Patient Access proposed rule was not clear with regard to whether or not state Medicaid agencies would be allowed to allocate the costs of this implementation—at a 90 percent federal match—and for ongoing operations of the system—at a 75 percent federal match. Commenters requested that CMS provide clarity around the use of such language and exactness of “pay fors” since this is vital for state Medicaid agencies' cost estimates in implementing the requirements of this rule.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         We agree with the commenters. We therefore have revised the calculations to Table 10 to reflect the following more precise accounting of costs: (1) 90 percent of state Medicaid costs are paid or matched by the federal government in the first year of implementing new systems; (2) 75 percent of Medicaid costs are matched for maintenance costs; and (3) on average, state Medicaid agencies are 
                        <PRTPAGE P="25620"/>
                        matched 58.44 percent. We believe this heightened level of detail should satisfy commenter concerns. The revised numbers are reflected in Tables 10 and Table 11.
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         One commenter noted that the developers of APIs may want additional fees to implement or provide access to their APIs. The commenter noted that these fees severely limit innovation in the marketplace for health IT solutions for storing and utilizing patient data, both on the patient and provider side of the equation.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         The data that must be shared via the API under this policy are data that the payers have and must currently make available to patients. We also anticipate that many payers will develop the APIs in-house. If this commenter is more referencing the vendors creating apps, versus APIs for payers, we also do not believe it is appropriate to charge a fee, as discussed in section III. of this final rule. If fees are charged for certain apps, it is not the data that are generating the fee, it is the product or services; indeed, there is a logical connection between the potential benefits of this rule (facilitated by new or enhanced services) and non-quantified potential costs (possibly including those associated with the development or improvement of such services). Currently there are vendors that collect the publicly available directory data, clean these data, supplement these data, and offer this enhanced data product back to payers and providers. It is not the data the vendors are charging for as much as it is the service of cleaning and enhancing these data. Vendors may generate revenue from their third-party apps, but a major component of this is the service they are providing—building the app, making the data the patient directs to them most usable and valuable—that generates the revenue. Payers must already make these data available to patients. These data alone may also drive revenue, but it is the patient's prerogative to provide their data to a third party in order to get a service in exchange
                    </P>
                    <P>
                        <E T="03">Comment:</E>
                         A few commenters noted that RIA does not contain any costs for provider EHR connectivity. One commenter noted that EHR developers' contracts with providers and health systems do not include the cost of system updates that will be required to comply with this proposal. Another commenter was concerned that EHR developers will charge providers significant fees to perform the updates required to comply with CMS' proposals, and providers will likely need to make additional investments to learn how to use standards-based APIs and other new technologies. Another commenter believes that for the clinical data to be available in any API, the CEHRT used by providers needs to be connected to a trusted exchange network. For many clinicians, the commenter noted the costs for connecting their CEHRT to a trusted network continues to remain a barrier.
                    </P>
                    <P>
                        <E T="03">Response:</E>
                         To address commenters' concerns with API connectivity to an EHR, we note that there is no requirement for a payer to link the Patient Access API to an EHR in this final rule, and there are associated challenges, as discussed elsewhere in this RIA, with attributing impacts to various interacting regulatory and other policies. Indeed, we do note that if a provider does elect to connect an EHR to the APIs finalized in this rule, they would be required to meet all the requirements of ONC's Health IT Certification Program.
                        <SU>78</SU>
                        <FTREF/>
                         As part of that program, the 2015 CEHRT includes, for example, “application access” certification criteria that requires health IT to demonstrate it can provide application access to the Common Clinical Data Set (CCDS) via an API.
                        <SU>79</SU>
                        <FTREF/>
                         Furthermore, nearly a third of EHR vendors are also using the FHIR standard to meet 2015 CEHRT requirements.
                        <SU>80</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>78</SU>
                             Office of the National Coordinator. (2019, March 27). About the ONC Health IT Certification Program. Retrieved from 
                            <E T="03">https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>79</SU>
                             Centers for Medicare and Medicaid Services. (n.d.). 2019 Promoting Interoperability Programs: 2015 Edition Certified EHR Technology Fact Sheet. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/CEHRT2015Ed_FactSheet-.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>80</SU>
                             Posnack, S. &amp; Baker, W. (2018, October 1). Heat Wave: The U.S. is Poised to Catch FHIR in 2019. Retrieved from 
                            <E T="03">https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">C. Anticipated Effects</HD>
                    <P>The RFA, as amended, 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. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions.</P>
                    <P>
                        The API requirements in this final rule affect: 1) QHP issuers on the FFEs, 2) MA organizations, including those that are also Part D sponsors of MA-PD plans, as well as 3) Medicaid MCOs with a minimum threshold for small business size of $41.5 million (
                        <E T="03">https://www.sba.gov/federal-contracting/contracting-guide/size-standards</E>
                        ).
                    </P>
                    <P>Assessment of impact is complicated by the fact that costs have been aggregated at the parent organization level. A typical parent organization might have products with QHP issuers on the FFEs, MA, or Medicaid/CHIP programs. We have no way of directly assessing the size of parent organizations. Therefore, as a proxy, we analyze each payer separately.</P>
                    <P>
                        <E T="03">Medicare Advantage:</E>
                         We first assess the impact on MA plans. To clarify the flow of payments between these entities and the federal government, we note that MA organizations submit proposed plan designs and estimates of the amount of revenue necessary to cover the cost of those plan designs (called bids) by the first Monday in June of the year preceding the coverage year. Regulations governing this process are in 42 CFR part 422, subpart F. These bids must be broken down in the following:
                    </P>
                    <P>(1) The revenue requirements for providing Medicare Part A and Part B benefits with actuarially equivalent cost sharing (this is the “basic benefit bid”);</P>
                    <P>(2) The revenue requirements for providing supplemental benefits;</P>
                    <P>(3) The revenue requirements for Non-Benefit Expenses such as Sales &amp; Marketing, Direct and Indirect Administration, Net Cost of Reinsurance, and Insurance Fees; and</P>
                    <P>(4) For MA-PD plans, a Part D bid consistent with Part D regulations in 42 CFR part 423.</P>
                    <P>
                        These bids project payments to hospitals, providers and staff for covered benefits, as well as the cost of plan administration and profits. Because the API requirements finalized in this rule will apply to every MA plan and each MA plan must furnish at least the Medicare Part A and Part B benefits, the cost of the API will be built into the administrative component of the basic benefit bid. These bids in turn determine one component of the payments of the Medicare Trust Fund to the MA organizations who reimburse providers and subcontractors for their services. A second component of the Trust Fund payment to MA organizations are the rebates, which are a portion of the difference between the basic benefit bid compared to an administratively-set benchmark for the MA plan's service area (currently, based on our past and projected experience, rebates vary by plan and are approximately 66 percent). Benchmarks are based on a formula using an estimate of the Medicare FFS per capita cost for the geographic area, which are adjusted to reflect the per capita cost of each county in the U.S. and its territories and adjusted for the enrollees' health status 
                        <PRTPAGE P="25621"/>
                        which is also known as the risk score. Payments from the Medicare Trust Funds for monthly capitation rates (for basic benefits) are capped at the benchmark; for basic benefit bids under the benchmark, a portion, currently approximately 66 percent, of the difference between the bid and benchmark is made available to the MA organization to either: (1) Pay for additional supplemental benefits; (2) include reductions in cost sharing in the plan design; or (3) provide buy-downs of Part B or Part D premiums. Basic benefit bids that are at or above the benchmark receive payment from the Trust Funds of the benchmark amount, with any excess charged to the enrollee as a premium.
                    </P>
                    <P>MA organizations are made aware of the benchmark through the annual CMS publication, “Announcement of Calendar Year [X] Medicare Advantage Capitation Rates and Medicare Advantage and Part D Payment Policies,” which, consistent with section 1853 of the Act, is released prior to MA organizations submission of bids. This publication of the benchmark when coupled with plan awareness that they will receive rebates if their plan bids fall below the benchmark facilitates that bids of most MA organizations are below the benchmark and consequently most MA organizations receive from the Trust Fund a total expenditure equaling payment for the bid plus the rebate.</P>
                    <P>Because of these API provisions, we assume that MA organizations will be raising the June-submitted bid amount to reflect additional administrative costs. While the Trust Fund pays these bid amounts in full, the rebate goes down as the bid increases: That is, since the bid amount goes up, the rebate, equaling the difference between the benchmark and bid, decreases and results in less rebate payment to the MA organization. The MA organization has several options of dealing with these increased bid costs and reduced rebates: The MA organization might decide to: (1) Temporarily absorb the loss by reducing its profit margin (so as to reduce the bid amount and thereby increase the rebates); (2) reduce additional benefits paid to the enrollee from the rebates; or (3) raise enrollee premiums so as to compensate for the reduction of enrollee premium that would have happened if the bid had not been increased (note: for marketing purposes, many plans operate at zero premium, and we do not consider this third option a likely possibility). In this RIA, we have referred to options (2) and (3) (reduction of additional benefits and raising of enrollee premiums) as “passing the costs to the enrollee” so that the “effect” of reduced rebates is fewer supplemental benefits or higher enrollee premiums than would have happened had the cost of the complying with the API provisions of this final rule not been imposed.</P>
                    <P>There are various types of Medicare health plans, including MA HMOs, POS plans, and PPOs; Demonstration plans; Cost Plans; Prescription Drug Plans (PDP); and Programs of All-Inclusive Care for the Elderly (PACE) organization plans. This final rule affects MA HMOs, MA POS plans, and MA PPOs including those that are MA-PDs, but does not affect Cost Plans, stand-alone Prescription Drug Plans, nor PACE organizations.</P>
                    <P>There are a variety of ways to assess whether MA organizations meet the $41.5 million threshold for small businesses. The assessment can be done by examining net worth, net income, cash flow from operations and projected claims as indicated in their bids. Using projected monetary requirements and projected enrollment for 2018 from submitted bids, approximately 30 percent of the MA organizations fell below the $41.5 million threshold for small businesses. Additionally, an analysis of 2016 data, the most recent year for which we have actual data on MA organization net worth, shows that approximately 30 percent of all MA organizations fall below the minimum threshold for small businesses.</P>
                    <P>
                        <E T="03">Medicaid:</E>
                         We next assess the impact on Medicaid managed care plans. Since Medicaid managed care plans receive 100 percent capitation from the state, we generally expect that the costs associated with the API provisions of this final rule, will be included in their capitation rates and may be reasonable, appropriate, and attainable costs whether they are a small business or not.
                    </P>
                    <P>
                        <E T="03">QHP issuers on the FFEs:</E>
                         Based on the 2016 CMS MLR data, approximately 85 out of 494, or 17 percent of companies (that either had only individual market business, or had individual market plus Medicare and/or Medicaid business) had total premium revenue of less than $41,500,000. In other words, for MA, Medicaid, and QHP issuers on the FFEs, a significant number of small plans are affected. The RFA requires us to assess whether the rule has a significant impact on the plans, which we do next.
                    </P>
                    <P>If a rule has a substantial impact on a substantial number of small entities, the rule must discuss steps taken, including alternatives, to minimize burden on small entities. While a significant number (more than 5 percent) of not-for-profit organizations and small businesses are affected by this final rule, the impact is not significant. To assess impact, we use the data in Table 5, which shows that the total raw (not discounted) net effect of this final rule over 10 years is $714 million.</P>
                    <P>
                        <E T="03">Medicare Advantage:</E>
                         We first assess impact on MA plans. Comparing the $714 million number to the total monetary amounts projected to be needed just for 2018, the most recent year on which we have finalized plan submitted bid data (and which is expected to be less than the need in future years including 2019), we find that that the impact of this final rule is significantly below the 3 percent-5 percent threshold for significant impact for MA plans.
                    </P>
                    <P>
                        <E T="03">Medicaid:</E>
                         We next assess impact on Medicaid managed care plans. The total projected capitation payment and premiums for 2019 is projected to be $337.6 billion.
                        <SU>81</SU>
                        <FTREF/>
                         Hence, the total cost of this final rule over 10 years, $714 million, is significantly below the 3 percent-5 percent threshold for significant impact to Medicaid managed care plans.
                    </P>
                    <FTNT>
                        <P>
                            <SU>81</SU>
                             See “Capitation payments &amp; premiums” in Table 17 of Appendix D in, Office of the Actuary (Centers for Medicare and Medicaid Services). (2016). 2016 Actuarial Report on the Financial Outlook for Medicaid. Retrieved from 
                            <E T="03">https://www.medicaid.gov/medicaid/finance/downloads/medicaid-actuarial-report-2016.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">QHP issuers on the FFEs:</E>
                         As discussed prior to Table 6 based on data in the public CMS MLR files, commercial health insurance issuers had premium revenue of $77 billion for individual market plan coverage in 2016. Therefore, the aggregate raw cost of this final rule over 10 years, $762 million (low estimate) and $1.3 billion (high estimate), is significantly below the 3 percent to 5 percent threshold for significant impact to commercial plans. We believe, that although a significant number of small plans under each program are affected by this rule, on average this impact is not significant. Additionally, we note that for those small entities that do find the cost of the provisions of this final rule burdensome, an exception process has been described in section III.C. of this final rule. Specifically, we note that we may provide an exceptions process through which the FFEs may certify health plans that do not provide patient access through a standards-based API, but otherwise meet the requirements for QHP certification. This process could apply for small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the FFEs who demonstrate that deploying standards-
                        <PRTPAGE P="25622"/>
                        based API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to consumers, and not certifying the issuer's QHP or QHPs would result in consumers having few or no plan options in certain areas.
                    </P>
                    <P>Consequently, the Secretary has determined that this final rule will not have a significant economic impact on a substantial number of small entities and the requirements of the RFA have been met. Please see our detailed analysis of apportionment of costs per payer in Tables 6 through 13 and section XIII.H. of this final rule for further details.</P>
                    <P>In addition, section 1102(b) of the Act requires CMS to prepare an RIA if a rule may have a significant impact on the operations of a substantial number of small rural hospitals. This analysis must conform to the provisions of section 604 of the RFA. For purposes of section 1102(b) of the Act, we define a small rural hospital as a hospital that is located outside a Metropolitan Statistical Area and has fewer than 100 beds. We are not preparing an analysis for section 1102(b) of the Act because we have determined, and the Secretary certifies, that this final rule would not have a significant impact on the operations of a substantial number of small rural hospitals.</P>
                    <P>Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (Pub. L. 104-04, enacted March 22, 1995) also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates, except those that are conditions of federal program participation, require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2020, that is approximately $156 million. This rule does not impose any such unfunded mandates.</P>
                    <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. This final rule will not have a substantial direct effect on state or local governments, preempt state law, or otherwise have a federalism implication. Therefore, the requirements of Executive Order 13132 are not applicable.</P>
                    <P>If regulations impose administrative costs, such as the time needed to read and interpret this final rule, we should estimate the cost associated with regulatory review. There are currently 288 organizations and 56 states and territories. We assume each organization will have one designated staff member who will read the entire rule.</P>
                    <P>
                        Using the wage information from the BLS for medical and health service managers (Code 11-9111), we estimate that the cost of reviewing this rule is $139.14 per hour, including overhead and fringe benefits (
                        <E T="03">https://www.bls.gov/oes/current/naics5_524114.htm</E>
                        ). Assuming an average reading speed, we estimate that it would take approximately 6 hours for each person to review this final rule. For each payer that reviews the rule, the estimated cost is $834.84 (6 hours × $139.14). Therefore, we estimate that the total cost of reviewing this regulation is $288,020 ($834.84 × 345 reviewers).
                    </P>
                    <HD SOURCE="HD3">1. Requirements for Patient Access Through APIs</HD>
                    <P>To promote our commitment to interoperability, we are implementing new requirements in section III. of this final rule for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, Medicaid managed care at 42 CFR 438.242, CHIP FFS at 42 CFR 457.730, CHIP managed care at 42 CFR 457.1233, and QHP issuers on the FFEs, excluding QHP issuers offering only SADPs or only FF-SHOP plans, at 45 CFR 156.221 to implement standards-based APIs for making certain data available to current enrollees. The Patient Access API will permit third-party applications to retrieve data concerning adjudicated claims, encounters with capitated providers, provider remittances, patient cost-sharing, a subset of clinical data including lab test results, if maintained by the payer, and, preferred drug lists, and for MA-PD plans only, formulary data that includes covered Part D drugs, and any tiered formulary structure or utilization management procedure, which pertains to those drugs for MA-PD plans.</P>
                    <P>At 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for state Medicaid agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities, we are finalizing the Provider Directory API. We believe that these policies are designed to empower patients by requiring that impacted payers take steps—by implementing the two required APIs—to enable enrollees to have access to their data in a usable digital format and have (potentially) easier means to share that data. By making these data readily available and portable to the patient, these initiatives may help patients have the ability to move from payer to payer, provider to provider, and have both their clinical and administrative information travel with them throughout their health care journey. Payers are in a unique position to provide enrollees with a comprehensive picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. This information can contribute to better informed decision making, helping to inform the patient's choice of coverage options and care providers to more effectively manage their own health, care, and costs. By encouraging them to take charge of and better manage their health and having access to their health information, patients will have the ability to share this information with their other providers, which may reduce duplication of services, add efficiency to provider visits, and facilitate identification of fraud, waste, and abuse.</P>
                    <P>
                        To estimate the number of impacted payers, we reviewed parent organizations of health plans across MA organizations, Medicaid MCOs, and QHP issuers on the FFEs to remove organizations that would not be subject to the policy, such as issuers that offer only SADPs; transportation plans, and brokers such as non-emergency medical transportation (NEMTs) brokers; PACE; visiting nurse and home health care organizations; senior organizations such as Area Agencies on Aging; and other organizations such as community action programs. After removing these organizations, we then reviewed the remaining names of parent organizations and health plans in the National Association of Insurance Commissioners (NAIC) Consumer Information Support (CIS) system to determine the legal name of the entity and whether the entity was registered with the NAIC. We also used the 2018 NAIC Listing of Companies to determine whether various health plans had associated parent organizations using the NAIC's Group coding and numbering system. If the health plan or parent organization did not appear in the NAIC CIS or in the 2018 NAIC Listing of Companies, we then reviewed the name of the entity in the Securities and Exchange online Edgar system to locate the entity's Form 10-K filing, which includes an Exhibit (Exhibit 21) that requires the entity to list its subsidiaries. If the health plan or organization did not appear in these online systems or listings, an online internet search using Google search 
                        <PRTPAGE P="25623"/>
                        engine was conducted. After review, we have determined that 288 issuers and 56 states, territories, and U.S. commonwealths, which operate FFS programs, will be subject to the API provisions for Medicare, Medicaid, and QHP issuers on the FFEs. To this we add the one state that operates its CHIP and Medicaid separately. Thus, we have a total of 345 parent organizations (288+56+1). We note that although 42 states have some lower-income children in an expansion of Medicaid, and some higher-income children or pregnant women in a separate CHIP, all but one of these programs are operated out of the same agency. Although the CHIP programs may be distinct, we believe they will use the same infrastructure built for Medicaid. Thus, the addition of 1 parent organization for CHIP is reasonable and plausible.
                    </P>
                    <P>As noted in section XII.C.3. of this final rule, to implement the Patient Access API together with the payer-to-payer data exchange policies to facilitate a payer maintaining a cumulative health record for their current enrollees, we estimated that organizations and states would conduct three major work phases: Initial design; development and testing; and long-term support of the APIs, including increased data storage, such as additional servers, or cloud storage to store patient health information and maintain it, and allocation of resources to maintain the FHIR server, and perform capability and security testing. (For a detailed description of these phases, see section XII.C.3. of this final rule.)</P>
                    <P>
                        As part of our research into the regulatory impact, we reviewed a sample of health plan organizations offering MA plans to determine whether any currently offer patient portal functionality with the MA plan. If yes, we reviewed whether they offered the opportunity to connect to Medicare's Blue Button 2.0. Health plan organizations offering MA plans were identified from June 2018 data and statistics compiled at 
                        <E T="03">https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/MCRAdvPartDEnrolData/index.html.</E>
                         We initially reviewed the functionality offered by three organizations, which together enroll over half of MA members through review of publicly-available information such as press releases and website informational materials. We found from this review that these organizations not only offered patient portals primarily focused on claims and user-entered data on their website, but that all three also offered enrollees the opportunity to connect to Blue Button. We then identified a selection of other health plan organizations at random and conducted the same evaluation. Results indicate that the majority of the health plan organizations we reviewed offer patients a way to access claims data and other information via their websites and sometimes via applications.
                    </P>
                    <P>We also cross-referenced health plan organizations offering MA plans with health plan organizations that offer plans in the Federal Employees Health Benefits (FEHB) Program because a percentage of those organizations offer plans with patient portal access and Blue Button functionality. The FEHB Program, administered by the Office of Personnel Management (OPM), reported in 2014 that 90 percent of its participating plans offered enrollees access to a personal health record on the organization's website. In addition, OPM reported that over half of the FEHB participating plans expected to offer Blue Button functionality by January 1, 2016. We sought to learn whether there was any overlap between these two lists of organizations to gauge whether additional organizations may already have the capability to offer either patient portals or Blue Button, albeit in a different business arm, as having internal capability may assuage some of the cost of building out a new API to support patient access to claims data. While we found significant overlap between UnitedHealthcare and the Blue Cross Blue Shield Affiliates, we also were able to identify other organizations that offer both MA plans and plans included in the FEHB. While not definitive, this data allows us to draw the conclusion that a number of health plan organizations have the technology in place to offer patient portals to MA enrollees and, further, also have the ability to offer MA enrollees Blue Button functionality.</P>
                    <P>As detailed in section XII. of this final rule and summarized in Table 5, given the current state of interoperability, we estimate the burden related to the new requirements for APIs to have an initial set one-time costs of $788,414 per implementation or an aggregate cost of $272 million ($788,414 × 345 parent organizations) minimum estimate; an initial one-time cost of $1,576,829 per organization or state or an aggregate cost of $544 million ($1,576,829 × 345 parent organizations) primary estimate; and, an initial one-time cost of $2,365,243 per organization or organization or an aggregate $816 million ($2,365,243 × 345 parent organizations) high estimate. For a detailed discussion of the one-time costs associated with implementing the API requirements we refer readers to section XII.C.3. of this final rule. Once the API is established, we believe that there will be an annual cost for performing necessary capability and security testing, performing necessary upgrades, vetting of third-party applications, and maintaining patient health information. We estimate the burden related to the requirements for APIs to have an annual cost of $157,657 per implementation or an aggregate cost of $54 million (345 parent organizations × $157,657). For a detailed discussion of the annual costs associated with implementing the API requirements, we refer readers to section XII.C.3. of this final rule.</P>
                    <P>We are committed to fulfilling our role in promoting interoperability, putting patients first and ensuring they have access to their health care data. We recognize that there are significant opportunities to modernize access to patient data and its ability to share across the health ecosystem. We realize the importance of interoperability and the capability for health information systems and software applications to communicate, exchange, and interpret data in a usable and readable format. Although allowing access to health care data through pdf and text format is vital, it limits the utility of the data, and its ability to be easily accessed and shared. Additionally, we realize that moving to a system in which patients have access to their health care data will ultimately empower them to make informed decisions about their health care. Our policies here do not go as far as our goals for how patients will be ultimately empowered, but take steps in that direction.</P>
                    <P>
                        We note that the federal government has spent over $35 billion under the EHR Incentive Programs 
                        <SU>82</SU>
                        <FTREF/>
                         to incentivize the adoption of EHR systems; however, despite the fact that 78 percent of physicians and 96 percent of hospitals now use an EHR system,
                        <SU>83</SU>
                        <FTREF/>
                         progress on system-wide data sharing has been limited. Previous attempts to advance interoperability have made incremental progress but have failed to align the necessary stakeholders to drive momentum in a single direction. In 2018, the Administration launched the 
                        <PRTPAGE P="25624"/>
                        MyHealthEData initiative.
                        <SU>84</SU>
                        <FTREF/>
                         This government-wide initiative aims to empower patients by ensuring that they have access to their own health care data and the ability to decide how their data will be used, while keeping that information safe and secure. MyHealthEData aims to break down the barriers that prevent patients from gaining electronic access to their health care data and allow them to access that data from the device or application of their choice that will connect to a plan's API, empowering patients and taking a critical step toward interoperability and patient data exchange.
                    </P>
                    <FTNT>
                        <P>
                            <SU>82</SU>
                             Centers for Medicare and Medicaid Services. (2018, May). EHR Incentive Program, Payment Summary Report. Retrieved from 
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/May2018_SummaryReport.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>83</SU>
                             Office of the National Coordinator. (2015). Health IT Dashboard—Office-based Physician Health IT Adoption: State rates of physician EHR adoption, health information exchange &amp; interoperability, and patient engagement. Retrieved from 
                            <E T="03">https://dashboard.healthit.gov/apps/physician-health-it-adoption.php</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>84</SU>
                             Centers for Medicare and Medicaid Services. (2018, May 6). Trump Administration Announces MyHealthEData Initiative to Put Patients at the Center of the US Healthcare System. Retrieved from 
                            <E T="03">https://www.cms.gov/Newsroom/MediaReleaseDatabase/Press-releases/2018-Press-releases-items/2018-03-06.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>Payers should have the ability to exchange data instantly with other payers for care coordination or transitions, and with providers to facilitate more efficient care. Payers are in a unique position to provide enrollees a complete picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. We are committed to solving the issue of interoperability and achieving complete patient access in the U.S. health care system and are taking an active approach using all available policy levers and authorities available to move all participants in the health care market toward interoperability and the secure exchange of health care data. The modern internet app economy thrives on a standards-based API software environment. Part of the health care API evolution is incorporating many of the current protocols from leading standards development organizations with the newer FHIR web developer-friendly way of representing clinical data.</P>
                    <HD SOURCE="HD3">2. Increasing the Frequency of Federal-State Data Exchanges for Dually Eligible Individuals</HD>
                    <P>We routinely exchange data with states on who is enrolled in Medicare, and which parties are liable for paying that beneficiary's Part A and B premiums. These buy-in data exchanges support state, CMS, and SSA premium accounting, collections, and enrollment functions. CMS subregulatory guidance, specifically Chapter 3 of the State Buy-in Manual, specifies that states should exchange buy-in data with CMS at least monthly, but provides the option for states to exchange buy-in data with CMS daily or weekly. Likewise, states can choose to receive the CMS response data on a file daily or monthly.</P>
                    <P>We are establishing the frequency requirements in the regulation itself to require all states to participate in daily exchange of buy-in data to CMS, with “daily” meaning every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. States will be required to begin participating in daily exchange of buy-in data with CMS by April 1, 2022.</P>
                    <P>To estimate impact, we first note that there are a total of 51 entities, consisting of the 50 states and the District of Columbia that can be affected by buy-in. Currently, 25 entities (24 states and the District of Columbia) now submit buy-in data files to CMS daily and 32 entities (31 states and the District of Columbia) receive buy-in data files from CMS daily. Consequently, we expect a one-time burden for 26 states (51 total entities minus 25 entities currently submitting daily buy-in data) to comply with the daily buy-in data submissions, and a similar one-time burden for 19 states (51 total entities minus 32 entities currently receiving buy-in data) to comply with the receipt of daily buy-in data.</P>
                    <P>These numbers changed from those in the CMS Interoperability and Patient Access proposed rule to reflect the most current data available to CMS as of July 1, 2019. Between July 1 and publication of the final rule it is likely that the numbers may change more. However, as can be seen from Table 5, this aspect of the rule has minor impact (only a few million dollars) compared with the overall impact of the rule (several hundred million). Consequently, we are using these July 1 numbers in the final rule.</P>
                    <P>We estimate that each required change, whether to submit buy-in data or receive buy-in data, would take 6 months of work (approximately 960 hours) by a programmer working at an hourly rate of $90.02 per hour. Since there are 45 required changes (19 states that need to comply with receiving data plus 26 states that need to comply with submitting data) we estimate an aggregate burden of $3,888,864 (45 changes * 960 hours of programming work * $90.02/hour).</P>
                    <P>The cost per state per change is approximately $85,000 (960 * $90.02 = $86,419 exactly) and the costs for both changes (to both send and receive buy-in data daily would be approximately $170,000 (2 * $85,000).</P>
                    <P>We did not estimate any savings related to exchanging buy-in data with greater frequency, as data lags only delay when states are billed for premium costs; delays do not impact the applicability date and total costs. While we did not estimate premium savings (since premium collection is ultimately correct), we anticipate that states may experience longer term reduction in administrative burden of making those corrections.</P>
                    <P>As noted in section XII.C. of this final rule, we are updating the frequency requirements in 42 CFR 423.910(d) to require that starting April 1, 2022, all states submit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. As noted in section XII.C. of this final rule, the estimated burden across impacted states is $3,111,091.</P>
                    <P>Thus, the total burden to comply with increased frequency of submission of MMA files and increased frequency of submission and receipt of daily buy-in data files is $7 million ($3,888,864 total cost for the buy-in provision plus $3,111,091 total cost for the MMA file requirements).</P>
                    <P>We estimate a 25-month implementation period for these system updates, from March 2020 to and including March 2022. In the CMS Interoperability and Patient Access proposed rule, we assumed a 3-year implementation period reflecting a May 1st start date and an April 1, 2022 applicability date. The revised 25-month implementation period reflects an expected publication of this final rule in March 2020, with implementation beginning March 2020, and with the applicability date of April 1, 2022 unchanged. Although the implementation period is shorter (25 months versus 36 months) the purpose of the 25-month window is to give organizations flexibility in finding a 6-month period to perform updates as indicated in section XII. of this final rule. Although the flexibility window for this 6-month period is shortened (plans have less choice of which 6 months to work in), data are lacking with which to refine the cost estimates to reflect the shortened compliance period.</P>
                    <P>
                        States will have the ability to choose, in consultation with CMS, when in the 25-month implementation period they want to make this change, with numerous factors impacting in which year they would do so. For the purposes of this impact analysis, we estimated a uniform distribution beginning in March 2020 and ending in April 2022 as calculated in Table 5.
                        <PRTPAGE P="25625"/>
                    </P>
                    <P>Therefore, since, as noted above, the total cost impact over 25 months is $7 million, when apportioned uniformly over the 25 months, the resulting impacts $2.8, $3.4, and $0.8 million for 2020, 2021, and 2022 respectively corresponding to 10 months, 12 months, and 3 months in 2020, 2021 and 2022 respectively. These calculations are transparently presented in Table 5.</P>
                    <HD SOURCE="HD3">3. Revisions to the Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs)</HD>
                    <P>We are expanding CMS' requirements for interoperability within the hospital and CAH CoPs by focusing on electronic patient event notifications. We are implementing new requirements in section X. of this final rule for hospitals at 42 CFR 482.24(d), for psychiatric hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d). Specifically, for hospitals, psychiatric hospitals, and CAHs, we are finalizing similar requirements to revise the CoPs for Medicare- and Medicaid-participating hospitals, psychiatric hospitals, and CAHs by adding a new standard, “Electronic Notifications,” that will require hospitals, psychiatric hospitals, and CAHs to make electronic patient event notifications available to applicable post-acute care services providers and suppliers, and to community practitioners, such as the patient's established primary care practitioner, established primary care practice group or entity, or other practitioner or practice group or entity identified by the patient as primarily responsible for his or her care. We are limiting this requirement to only those hospitals, psychiatric hospitals, and CAHs that utilize electronic medical records systems, or other electronic administrative systems, which are conformant with the content exchange standard at 45 CFR 170.205(d)(2), recognizing that not all Medicare- and Medicaid-participating hospitals have been eligible for past programs promoting adoption of EHR systems. If the hospital's (or CAH's) system conforms to the content exchange standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then demonstrate that its system's notification capacity is fully operational and that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information, and that its system, to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences, sends the notifications either directly, or through an intermediary that facilitates exchange of health information. It must also demonstrate that the notifications include at least patient name, treating practitioner name, and sending institution name.</P>
                    <P>Upon the patient's registration in the emergency department or admission to inpatient services, and also either immediately prior to, or at the time of, the patient's discharge or transfer (from the emergency department or inpatient services), the hospital (or CAH) must also demonstrate that it has made a reasonable effort to ensure that its system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes: (1) The patient's established primary care practitioner; (2) the patient's established primary care practice group or entity; or (3) other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care.</P>
                    <P>
                        As we noted, infrastructure supporting the exchange of electronic health information across settings has matured substantially in recent years. Research studies have increasingly found that health information exchange interventions can effectuate positive outcomes in health care quality and public health outcomes, in addition to more longstanding findings around reductions in utilization and costs. Electronic patient event notifications from hospitals, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings, especially for patients at discharge. This approach has been identified with a reduction in readmissions following implementation.
                        <SU>85</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>85</SU>
                             Unruh, M. A., Jung, H., Kaushal, R., &amp; Vest, J. R. (2017). Hospitalization event notifications and reductions in readmissions of Medicare fee-for-service beneficiaries in the Bronx, New York. Journal of the American Medical Informatics Association, 24(e1), e150-e156. doi: 10.1093/jamia/ocw139.
                        </P>
                    </FTNT>
                    <P>
                        In addition, the CMS Innovation Center has been partnering with states through the State Innovation Models Initiative to advance multi-payer health care payment and delivery system reform models. Through this initiative 34 states have been awarded over $900 million to implement their respective State Health Care Innovation Plans, many of which included enhancements in HIT and HIE. While these models are ongoing, evaluation reports thus far are reporting that many states are experiencing favorable outcomes on ED visit rates and other quality measures.
                        <SU>86</SU>
                        <FTREF/>
                         Although patient event notifications are only a small piece of these models, we want to continue the momentum towards nationwide adoption.
                    </P>
                    <FTNT>
                        <P>
                            <SU>86</SU>
                             Centers for Medicare and Medicaid Services. (2019, December 6). State Innovation Models Initiative: General Information. Retrieved from 
                            <E T="03">https://innovation.cms.gov/initiatives/State-Innovations/</E>
                            .
                        </P>
                    </FTNT>
                    <P>These notifications are automated, electronic communications from the provider to applicable post-acute care services providers and suppliers, and also to community practitioners identified by the patient. These automated communications alert the receiving provider or practitioner that the patient has received care at a different setting. Information included with these notifications can range from simply conveying the patient's name, basic demographic information, and the sending institution, to a richer set of clinical data depending upon the level of technical implementation. Even with a minimum set of information included, these notifications can help ensure that a receiving provider or community practitioner is aware that the patient has received care elsewhere. The notification triggers a receiving provider or practitioner to reach out to the patient to deliver appropriate follow-up care in a timely manner. By providing timely notifications, the alert may improve post-discharge transitions and reduce the likelihood of complications resulting from inadequate follow-up care.</P>
                    <P>
                        We believe that care coordination can have a significant positive impact on the quality of life, consumer experience, and health outcomes for patients. As we have noted in the preamble to this rule, virtually all EHR systems (as well as older legacy electronic administrative systems, such as electronic patient registrations systems, and which we are including in this final rule) generate the basic messages commonly used to support electronic patient event notifications. In addition, while we acknowledge that some level of implementation cost would be realized for those providers not already sending notifications, we also note there is also substantial agreement that implementation of these basic messaging and notification functions within such existing systems constitutes a relatively low cost burden for providers, particularly when such costs are considered alongside the innovative and beneficial patient care transition 
                        <PRTPAGE P="25626"/>
                        solutions and models for best practices they provide.
                    </P>
                    <P>As detailed in section XI., we estimate that the total cost imposed on hospitals, psychiatric hospitals, and CAHs by these provisions to be approximately $5,179,863 in the first year and $1,042,426 in subsequent years.</P>
                    <HD SOURCE="HD3">4. Effects of Other Policy Changes</HD>
                    <P>In addition to those policy changes discussed previously that we are able to model, we are finalizing various other changes in this final rule. Generally, we have limited or no specific data available with which to estimate the impacts of the policy changes. Our estimates of the likely impacts associated with these other changes are discussed in this section.</P>
                    <HD SOURCE="HD3">a. Care Coordination Across Payers</HD>
                    <P>
                        The majority of the 64 million people on Medicare are covered by FFS, however, about 34 percent are covered in MA plans. Since 2003, the number of beneficiaries enrolled in MA plans has increased fivefold from 4.6 million in 2010 to 22 million in 2019.
                        <SU>87</SU>
                        <FTREF/>
                         Given the growth in MA enrollment and the ability for MA beneficiaries to change plans, we believe it is important to supporting efficient care coordination by requiring the sharing of key patient health information when an enrollee requests it. Therefore, we are requiring MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ) at 45 CFR 170.213 (currently version 1 of the USCDI), via a payer-to-payer data exchanged as outlined in this section V. of this final rule. Furthermore, we are finalizing as proposed a regulatory requirement at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to incorporate the data they receive into the payer's record about the enrollee. We are also finalizing that with the approval and at the direction of an enrollee, a payer must send the defined information set to any other payer. We specify that a payer is only obligated to send data received from another payer under this policy in the electronic form and format it was received. However, we have noted that such transactions will need to be made in compliance with any other applicable laws.
                    </P>
                    <FTNT>
                        <P>
                            <SU>87</SU>
                             Medicare Payment Advisory Commission. (2019, July 19). A Data Book: Health Care Spending and the Medicare Program—June 2019. Retrieved from 
                            <E T="03">http://www.medpac.gov/docs/default-source/data-book/jun19_databook_entirereport_sec.pdf?sfvrsn=0</E>
                            .
                        </P>
                    </FTNT>
                    <P>We believe that sending and receiving these data will help both plan enrollees and health care providers in coordinating care and reducing administrative burden. We believe that this entails utilizing all tools available to us to ensure that plans provide coordinated high-quality care in an efficient and cost-effective way that protects program integrity. Leveraging interoperability to facilitate care coordination among plans can, with thoughtful execution, significantly reduce unnecessary care, as well as ensure that health care providers are able to spend their time providing care rather than performing unnecessary administrative tasks. For instance, effective information exchange between plans could improve care coordination by reducing the need for health care providers to write unneeded letters of medical necessity; by reducing instances of inappropriate step therapy; and by reducing repeated utilization reviews, risk screenings, and assessments.</P>
                    <P>We believe that this policy will impose minimal additional costs on plans. We note that we are not specifying a transport standard and anticipate that plans may opt to use APIs, such as the Patient Access API that this final rule also requires. We also anticipate that plans may choose to utilize a regional health information exchange. We believe it is difficult to quantify the impact of this change because plans will likely implement different transport methods, and we cannot predict the selected method plans will choose.</P>
                    <HD SOURCE="HD3">b. Care Coordination Through Trusted Exchange Networks</HD>
                    <P>In section VI. of the CMS Interoperability and Patient Access proposed rule, we proposed requiring MA organization, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in trust networks in order to improve interoperability. We also listed the requirements for participation in a trusted exchange network.</P>
                    <P>As a result of comments and re-examination of our desired policies, we have decided not to finalize this provision. However, as pointed out in the proposed rule, had this provision been finalized, it would impose minimal additional costs on plans. Consequently, not finalizing this policy does not impact this RIA.</P>
                    <HD SOURCE="HD3">5. Non-Mandatory Effects and Regulatory Interaction</HD>
                    <P>
                        We note in this RIA when we had difficulty quantifying costs due to lack of applicable research or data. More specifically, the establishment of a health care information ecosystem could only be achieved with new actions that are conducted widely throughout the health care field—including by entities, especially non-hospital providers, for whom costs have not been estimated in either this RIA or the RIA for the accompanying ONC 21st Century Cures Act final rule (published elsewhere in this issue of the 
                        <E T="04">Federal Register</E>
                        ). Although data limitations have prevented the quantification of these costs, the benefits of the two rules—some of which have been quantified in the ONC RIA—and the rules' potential transfer impacts—including reductions in fraudulent payments, as discussed by Parente et al. (2008) 
                        <SU>88</SU>
                        <FTREF/>
                        —are largely contingent upon such costs being incurred. Additionally, there are ongoing regulatory and policy activities outside of this final rule that might influence the rule's impact in an unquantifiable manner. When possible, we acknowledge these complexities as well.
                    </P>
                    <FTNT>
                        <P>
                            <SU>88</SU>
                             Parente, Stephen T., Karen Mandelbaum, Susan P. Hanson, Bonnie S. Cassidy and Donald W. Simborg. “Crime and Punishment: Can the NHIN Reduce the Cost of Healthcare Fraud?” 
                            <E T="03">Journal of Healthcare Information Management</E>
                             22(3): 42-51. June 2008.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">D. Alternatives Considered</HD>
                    <P>
                        In March 2018, the White House Office of American Innovation and the CMS Administrator announced the launch of MyHealthEData, and CMS's direct, hands-on role in improving patient access and advancing interoperability. As part of the MyHealthEData initiative, we are taking a patient-centered approach to health information access and moving to a system in which patients have immediate access to their electronic health information and can be assured that their health information will follow them as they move throughout the health care system from provider to provider, payer to payer. This final rule contains a range of policies. It provides descriptions of the statutory provisions that are addressed, identifies the policies, and presents rationales for our decisions and, where relevant, alternatives that were considered. We carefully considered alternatives to the policies we are adopting in this final rule but concluded that none of the 
                        <PRTPAGE P="25627"/>
                        alternatives would adequately and immediately begin to address the critical issues of the lack of patient access and interoperability, or the difficulty exchanging health care data within the health care system.
                    </P>
                    <P>As we noted in the CMS Interoperability and Patient Access proposed rule, we believe the following three attributes of standards-based APIs are particularly important to achieving the goal of offering individuals convenient access, through applications they choose, to available and relevant electronic health and health-related information: the API technologies themselves, not just the data accessible through them, are standardized; the APIs are technically transparent; and the APIs are implemented in a pro-competitive manner (84 FR 7620). The API requirements proposed and finalized in this rule were developed to ensure these goals are met.</P>
                    <P>
                        Some of the reasons that we selected the FHIR standard were due to the flexibility it provides and the wide industry adoption that it offers. The open and extensible nature of FHIR allows for health care integration to be transparent and accessible. FHIR is open source, and as such, it has garnered a community that includes developers and vendors. For example, large consumer brands are becoming a driving force behind the adoption of FHIR. Apple is implementing FHIR in Apple Health as part of iOS 11.3, and serves as a member of the Argonaut Project and CARIN Alliance—two HL7 FHIR Accelerators; 
                        <SU>89</SU>
                        <FTREF/>
                         Google supports FHIR by partnering with HL7, as well as through its membership in the CARIN Alliance; and Microsoft published an Azure API for FHIR to create and deploy FHIR service health data solutions.
                        <SU>90</SU>
                        <FTREF/>
                         Furthermore, according to an ONC report, nearly 51 percent of health IT developers appear to be using a version of FHIR combined with OAuth 2.0 to respond to requests for patient data. Additionally, of the hospitals and Merit-based Incentive Payment System (MIPS) eligible clinicians that use certified products, almost 87 percent of hospitals and 69 percent of MIPS eligible clinicians are served by health IT developers with product(s) certified to any FHIR version.
                        <SU>91</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>89</SU>
                             The HL7 FHIR Accelerator Program is designed to assist communities and collaborative groups across the global health care spectrum in the creation and adoption of high quality FHIR Implementation Guides or other standard artifacts to move toward the realization of global health data interoperability. For further details, see 
                            <E T="03">https://www.hl7.org/about/fhir-accelerator/</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>90</SU>
                             Shrestha, R., Mohan, S., &amp; Grieve, G. (2018, February 14). State of the Healthcare API Economy (An Innovation Forum Session: Session 217). Retrieved from 
                            <E T="03">https://365.himss.org/sites/himss365/files/365/handouts/552739129/handout-219_FINAL.pdf</E>
                            . 
                            <E T="03">See also https://azure.microsoft.com/en-us/services/azure-api-for-fhir/</E>
                             and 
                            <E T="03">https://www.apple.com/healthcare/health-records/</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>91</SU>
                             Posnack, S. &amp; Baker, W. (2018, October 1). Heat Wave: The U.S. is Poised to Catch FHIR in 2019. Retrieved from 
                            <E T="03">https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        For additional ways to allow consumers access to their health data, we note that we did receive comments that CMS could consider allowing payers and providers to upload patient data directly to a patient portal that is owned and managed by the patient. One option would allow for HIEs and HINs to serve as a central source for patients to obtain aggregated data in a single location. While HIEs and HINs can provide patients with valuable information via a portal, research has indicated that portals have not gained widespread use by patients. According to ONC, as of 2017, 52 percent of individuals have been offered online access to their medical records by a health provider or payer. Of the 52 percent that were offered access, only half of those viewed their record.
                        <SU>92</SU>
                        <FTREF/>
                         Additionally, we believe that there would be additional burden associated with using portals because providers and patients would need to access multiple portals and websites to access patient data, instead of a single app. Unlike portals that would require developers to link systems or ensure system-level compatibility, FHIR-based APIs have the ability to make data available without the need to link multiple systems or portals and would provide a patient a single-point of access to their data. Having APIs that can be accessed by third-party apps permits the patient to choose how they want to access their data, and it promotes innovation in industry to find ways to best help patients interact with their data in a way that is most meaningful and helpful to them. Additionally, we believe it would be very difficult to evaluate the cost impacts of making individual portals available via an HIE or HIN because business models and process are varied, and there is a lack of standardization in the way the information is stored and transmitted across HIEs and HINs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>92</SU>
                             Patel, V. &amp; Johnson, C. (2018, April). Individuals' Use of Online Medical Records and Technology for Health Needs (ONC Data Brief No. 40). Retrieved from 
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2018-03/HINTS-2017-Consumer-Data-Brief-3.21.18.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>Other alternatives that we considered were how broadly or narrowly to apply the policies and requirements. For example, we could have required health plans to provide more data elements via a standards-based API then just data for adjudicated claims, encounters with capitated providers, provider remittances, beneficiary cost-sharing, clinical data including laboratory results, provider directories (and pharmacy directories for MA-PDs), and preferred drug lists, where applicable. In the CMS Interoperability proposed rule, we originally required MA organizations, state Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities to make available provider directory data through the Patient Access API (84 FR 7633) and publicly available to current and prospective enrollees (84 FR 7639). After consideration of public comments, we have removed the requirements that these impacted payers make provider directory information available through the Patient Access API. MA organizations, state Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities will only need to make provider directory information available via a publicly accessible Provider Directory API. We note the Provider Directory API does not need to conform to the security protocols finalized by HHS at 45 CFR 170.215(a)(3) and (b) that are specific to authenticating users and confirming individuals' authorization or request to disclose their personal information to a specific application through an API, namely the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0. By only requiring the Provider Directory API make these otherwise publicly accessible data available, we are seeking to avoid duplicative effort and additional burden.</P>
                    <P>
                        Additionally, several commenters suggested additional information be added to the requirement for provider directory information to be available through an API, such as NPIs for individual and group providers, practice group name, health system name, as well as the specific plan(s) and tiers a provider participates in “provider demographics;” whether the provider is accepting new patients; and information about which providers are in-network for a plan by geography and/or specialty. While we agreed with commenters that this information would be helpful to patients, we did not modify the proposed requirements for the information that is required to be made available by the Provider Directory API because we believe additional data would be a cost driver. By not adding additional required 
                        <PRTPAGE P="25628"/>
                        information we are seeking to minimize the burden for the regulated payers that must comply with this policy. Instead we are identifying a minimum set of provider directory information that aligns with existing requirements applicable to MA organizations (including MA organizations that offer MA-PD plans), state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities that beneficiaries can currently access.
                    </P>
                    <P>We also looked at policy alternatives related to specific aspects of the API requirements. For instance, we considered whether to modify the requirement to make claims and encounter data, as well as clinical data, available through the Patient Access API no later than one (1) business day after a payer receives it. We reviewed several suggested alternatives such as increasing the timeframe to three (3) or five (5) business days to account for vendor-adjudicated claims. While we considered these alternatives, we ultimately decided not to adjust the proposed requirements because having access to this information within one (1) business day could empower patients to have the information they need, when they need it to inform care coordination. Patients have a right to see the full lifecycle of their claims and encounter information as soon as it is available, even if the payment amounts may change due to appeal. Additionally, as we noted in section XII. of this final rule, the burden related to API requirements is in the initial implementation of the system to make this information available in one (1) business day once received. This requirement is being implemented in the design and build phase and the system update cost for electronic availability would be the same regardless of the number of days the system is set up to accommodate. There is also no data on whether providing three (3) or five (5) days, versus one (1) day, will provide patients with more complete or accurate data.</P>
                    <P>As an alternative, we considered requiring all QHP issuers on all Exchanges to meet the new API requirements as part of QHP certification. Consistent with some other QHP certification requirements, we opted not to require SBEs to include this as part of their certification requirements, but we strongly urge them to do so to ensure equitable treatment of issuers nationally and to allow consumers to access their health information through a third-party application no matter where they are insured across the country. States are the most knowledgeable about their consumers and insurance markets and are responsible for issuer compliance activities. While we believe that these API requirements have the potential to provide great benefit to consumers, complying with them will be mainly operational and SBE states would be required to assess QHP issuer compliance. Therefore, we believe that SBE states should be given the flexibility to determine whether or not these requirements are required of their QHP issuers.</P>
                    <P>An additional alternative that we considered was based off one commenter's suggestion to incentivize plans who meet the required implementation dates through higher Healthcare Effectiveness Data and Information Set (HEDIS) scores. Although the commenter was not clear regarding a specific recommendation as to how to implement changes to the HEDIS score, we evaluated options such as adding a new measure specific to data exchange using HL7 FHIR-based APIs between payers and third-parties on the behalf of patients, or adding bonus points to the total score or some appropriate measure set for implementing the FHIR-based APIs required. However, after further evaluation, we believe that this is not a viable alternative at this time. CMS cannot give a higher HEDIS score for using a digital specification because it would not be an accurate measure of plan performance. To consider adding a bonus to the highest rating if the plan meets certain standards would necessitate requiring a new adjustment to the star rating methodology. This would be a significant change to how the current star ratings are calculated and would have to be proposed through notice and comment rulemaking. Given the implementation date for the API provisions for MA organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities is January 1, 2021, and for QHP issuers on the FFEs beginning with plan years beginning on or after January 1, 2021, implementing changes to the star ratings would not be achievable within the available timeframe to incentivize implementation as the commenter suggested.</P>
                    <P>As we recognize that advancing interoperability is no small or simple matter, we continue to explore alternatives and potential future policies. In the CMS Interoperability and Patient Access proposed rule, we requested comment for consideration in future rulemaking or subregulatory guidance on a number of alternatives related to whether additional policies or requirements, beyond those proposed, should be imposed to promote interoperability. For example, the CMS Innovation Center sought comment on general principles around promoting interoperability as part of the design and testing of innovative payment and service delivery models. Additionally, we sought comment on how we may leverage our program authority to provide support to those working on improving patient matching. For example, we requested comment on whether CMS should require impacted payers use a particular patient matching software solution with a proven success rate of a certain percentage validated by HHS or a third party. We also noted that we will continue to consider feedback received from RFIs issued in various rules over the course of the past 2 years and incorporate those suggestions into our strategy. We thank commenters for their input on these RFIs. We will consider the comments received for potential future rulemaking.</P>
                    <HD SOURCE="HD2">E. Accounting Statement and Table</HD>
                    <P>
                        In accordance with OMB Circular A- 4, Table 14 depicts an accounting statement summarizing the assessment of the benefits, costs, and transfers associated with this regulatory action.
                        <PRTPAGE P="25629"/>
                    </P>
                    <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s50,12,12,12,12">
                        <TTITLE>Table 14—Accounting Statement</TTITLE>
                        <BOXHD>
                            <CHED H="1">Category</CHED>
                            <CHED H="1">
                                Primary 
                                <LI>estimate</LI>
                            </CHED>
                            <CHED H="1">Units</CHED>
                            <CHED H="2">Year dollars</CHED>
                            <CHED H="2">
                                Discount rate 
                                <LI>(percent)</LI>
                            </CHED>
                            <CHED H="2">
                                Period 
                                <LI>covered</LI>
                            </CHED>
                        </BOXHD>
                        <ROW EXPSTB="04" RUL="s">
                            <ENT I="21">
                                <E T="02">Benefits</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">Qualitative</ENT>
                            <ENT A="03">
                                • API requirements will alleviative the burden for patients to go through separate processes to obtain access to each system, and the need to manually aggregate information that is delivered in various, often non-standardized, formats (not necessarily additional to the benefits assessed in the RIA for the accompanying ONC 21st Century Cures Act final rule, (published elsewhere in this issue of the 
                                <E T="02">Federal Register</E>
                                )).
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT A="03">• API requirement allows for the administration of a more efficient and effective Medicaid program by taking advantage of commonly used methods of information sharing and data standardization.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT A="03">• API requirements would help to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, providing potential benefits (not necessarily additional to the benefits assessed in the RIA for the accompanying ONC final rule), and helping them live better, healthier lives.</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="22"> </ENT>
                            <ENT A="03">• Privacy and security policies are being implemented that permit payers to request third-party apps to attest to privacy and security provisions prior to providing the app access to the payer's API.</ENT>
                        </ROW>
                        <ROW EXPSTB="04" RUL="s">
                            <ENT I="21">
                                <E T="02">Costs</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">Annualized Monetized $ millions/year (low estimate)</ENT>
                            <ENT>
                                85.2
                                <LI>80.8</LI>
                            </ENT>
                            <ENT>
                                2019
                                <LI>2019</LI>
                            </ENT>
                            <ENT>
                                7
                                <LI>3</LI>
                            </ENT>
                            <ENT>
                                2020-2029
                                <LI>2020-2029</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annualized Monetized $ millions/year (primary estimate)</ENT>
                            <ENT>
                                122.0
                                <LI>112.4</LI>
                            </ENT>
                            <ENT>
                                2019
                                <LI>2019</LI>
                            </ENT>
                            <ENT>
                                7
                                <LI>3</LI>
                            </ENT>
                            <ENT>
                                2020-2029
                                <LI>2020-2029</LI>
                            </ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Annualized Monetized $ millions/year (high estimate)</ENT>
                            <ENT>
                                158.8
                                <LI>144.0</LI>
                            </ENT>
                            <ENT>
                                2019
                                <LI>2019</LI>
                            </ENT>
                            <ENT>
                                7
                                <LI>3</LI>
                            </ENT>
                            <ENT>
                                2020-2029
                                <LI>2020-2029</LI>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="04" RUL="s">
                            <ENT I="22">
                                <E T="03">Non-Quantified Costs:</E>
                                 Non-hospital provider costs associated with development of a broad health care information ecosystem (regulatory benefits and fraud reduction are largely contingent upon these non-mandatory costs being incurred).
                            </ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="21">
                                <E T="02">Transfers from the Federal Government to Enrollees of Commercial Plans (PTC)</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">Annualized Monetized $ millions</ENT>
                            <ENT>5.4</ENT>
                            <ENT>2019</ENT>
                            <ENT>7</ENT>
                            <ENT>2020-2029</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Annualized Monetized $ millions</ENT>
                            <ENT>5.5</ENT>
                            <ENT>2018</ENT>
                            <ENT>3</ENT>
                            <ENT>2020-2029</ENT>
                        </ROW>
                        <ROW EXPSTB="04">
                            <ENT I="22">
                                <E T="03">Non-Quantified Transfers:</E>
                                 Reduced fraudulent payments to providers from the federal government and other payers.
                            </ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>The preceding discussion was an actual cost impact (not a transfer) since goods and computer services are being paid for. Plans have the option of transferring their expenses to enrollees. In practice, because of market competitive forces a plan may decide to operate at a (partial) loss and not transfer the entire cost. It is important to estimate the maximum the transfer could be. Some costs are transferred to the states (for Medicaid and CHIP) and ultimately to the federal government (for Medicare, Medicaid, and CHIP, and potentially for QHP issuers on the FFEs in the form of higher PTCs)), mitigating the amount transferred to enrollees. One approach to estimate impact on enrollees was made in section XII.B. of this RIA. However, this analysis did not take into account transfers.</P>
                    <P>We now re-estimate the potential full transfer. As noted in Tables 5 through 10, we have in 2021 through 2029 under a dollar increase in premiums as the worst-case scenario, and we used actual costs per year. In this alternate analysis, we use actual amounts for each of 2021 through 2029 with the initial 1-year cost amortized over 9 years. In other words, we assume an aggregate annual cost of $84.6 million ($272 million/9 + $54.4 million), this is based on the low estimate 1st year cost of $272 million. If we use the high estimate cost $816 million we obtain $145 million average ($816 million/9 + $54.4 million).</P>
                    <P>
                        We note that this premium increase could be counterbalanced by projected savings arising from the provisions in this final rule. More specifically, we expect the availability of portable electronic transfer of medical data proposed by this rule will help patients have the ability to move from payer to payer, provider to provider, and have both their clinical and administrative information travel with them throughout their health care journey. Allowing patients to piece together their own information that might otherwise be lost in disparate systems could help make better informed patients and may lead to increase prevention of future medical illnesses due to improvements in care coordination due to better data accessibility. The savings from avoiding one illness or one cheaper procedure would offset the under one-dollar impact. However, we have no way, at this point, of estimating this aspect of the future savings of the rule.
                        <PRTPAGE P="25630"/>
                    </P>
                    <P>We present two estimates. First, we estimate using the enrollment figures used in Table 9 of this RIA. Table 9 shows that we have 110.5 million enrollees (17.5+73+20) in programs that will be spending about $84.6 million per year. Ignoring federal subsidies, and assuming that all costs will be passed on to enrollees (which is contrary to our experience), the 110.5 million enrollees would each incur an extra 77 cents per enrollee ($84.6 million/110.5 million) a year to achieve the $84.6 million goal. This is the low estimate cost. The corresponding high estimate cost would be $1.31 per enrollee per year ($145 million/110.5 million). We next estimate using premium versus enrollment as was done in section XII.B. of this RIA.</P>
                    <P>Prior to discussing potential transfers to enrollees, we discuss how this final rule may affect patients not covered by plans subject to this rule. It is both possible and likely that an organization offering a plan subject to this rule may also offer plans not subject to this rule, and comply with the requirements of this rule for all of its plans, including those not subject to this rule. Consequently, it is possible that to cover the cost of complying with this rule for plans that are subject to this rule and plans that are not subject to this rule, organizations may raise premiums for their plans that are subject to this rule and their plans that are not subject to this rule. It is possible (and we contend likely) that this final rule will affect enrollees in individual market plans other than QHPs on the FFEs, even though there is no requirement for such coverage to comply with this rule. Therefore, we calculate the cost impact per enrollee should organizations offering plans not subject to this rule choose to comply with this rule with regard to those plans. The rest of the discussion below explores this possibility.</P>
                    <P>
                        <E T="03">QHP issuers on the FFEs:</E>
                         Rebates are required under section 2718(b)(1)(A) of the PHSA and the implementing regulations at 45 CFR part 158 when an issuer does not meet the applicable threshold. The commercial market MLR is generally calculated as the percent of each dollar of after-tax premium revenue spent by the issuer on reimbursement for clinical services, and activities that improve the quality of health care. If the issuer's MLR for a state market is below the applicable threshold, then the issuer must return the difference to policyholders. It follows, that if costs of complying with this rule raise plan costs, and if additionally, the issuers pass on the full cost in the form of premium and/or are able to treat these costs as QIAs, then premiums and rebates will change. The following two highly simplified examples are illustrative.
                    </P>
                    <P>Suppose the MLR threshold is 80 percent (in practice it can vary by state market), but the issuer's MLR is below the threshold at 70 percent. Then, the issuer would have to return the 10 percent as a rebate. If the costs of complying with this rule for an issuer are on average 6 percent of premium and the issuer treats these expenses as QIA, the issuer will now have to rebate only 4 percent instead of 10 percent (that is, the issuer's MLR would be 76 percent rather than 70 percent). Similarly, if both the applicable threshold and issuer MLR are 80 percent, then the issuer would not owe a rebate.</P>
                    <P>There are two effects of recognizing these costs as QIA: (1) For issuers subject to this rule who are below the applicable MLR threshold, the rebate from issuers to policyholders would go down by some amount between $0 and the cost of complying with this rule; and (2) for issuers subject to this rule who are at or above the MLR standards, the premium transfers from enrollees to issuers will go up by some amount between $0 and the cost of complying with this rule. We note that both MLR and rebates are calculated by combining all of an issuer's business (on- and off-Exchange) within a state and market.</P>
                    <P>To estimate these amounts, we used the public use 2016 MLR files on the CMS website that were used for Tables 6 through 9 of this RIA. The total reported 2016 premium revenue on the commercial side for individual market plans was approximately $77 billion (See Table 7). Of the $77 billion, the total reported 2016 premium revenue of issuers that were below the commercial MLR standard (80 or 85 percent, depending on the market) was approximately $4 billion.</P>
                    <P>As mentioned earlier, to proceed further we use the estimates of the costs of complying with this rule, which are $84.6 million per year. This cost is for all parent organizations with each parent organization possibly dealing with up to four lines of business subject to MLR requirements and the requirements of this rule: MA (including Part D sponsors); Medicaid; CHIP; and QHP issuers on the FFEs. Thus, of the $84.6 million level annual cost of complying with this rule, we estimate $18.8 million (22.19 percent commercial proportion * $84.6 million level annual cost complying with this rule) to be the cost for individual market plans.</P>
                    <P>In estimating the transfers to policyholders in individual market plans, we must distinguish between the $4 billion of premium revenues of issuers whose MLR was below the applicable threshold and the $73 billion of premium revenues ($77 billion total revenue for individual market plans- $4 billion) of individual market issuers whose MLR was at or above the applicable threshold. We can now calculate the estimated aggregate transfer in the commercial health insurance market from individual market policyholders to issuers whether through premium or rebates as follows:</P>
                    <P>• Percentage cost of complying with this rule = 0.0244 percent of revenue premium ($18.8 million cost/$77 billion total revenue).</P>
                    <P>• Reduced MLR rebates = $1 million (0.0244 percent × $4 billion premium from issuers below the applicable MLR threshold).</P>
                    <P>• Increased premiums = Up to $17.8 million (0.0244 percent × ($77 billion total revenue−$4 billion premium from issuers below the applicable MLR threshold)).</P>
                    <P>• Total transfer from enrollees = Up to $418.8 million ($17.8 million increased premium + $1 million reduced rebate).</P>
                    <P>• Transfer per enrollee = $1.07 ($418.8 million/17.5 million commercial health insurance enrollees).</P>
                    <P>We note that the $1.07 (under a dollar per enrollee) is consistent with the results obtained in Tables 6 through 10 (with exact raw amounts by year without amortization of a large first year expense). These calculations are summarized in Table 15. The $1.07 is the low estimate of first year costs. The high estimate $1.85 per enrollee per year is obtained by replacing the low estimate cost of $272 million with $816 million.</P>
                    <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="xs54,r100,12,r50,xs54">
                        <TTITLE>Table 15—Transfers to Enrollee Resulting From the Final Rule</TTITLE>
                        <BOXHD>
                            <CHED H="1">Label</CHED>
                            <CHED H="1">Item</CHED>
                            <CHED H="1">Amount</CHED>
                            <CHED H="1">Source</CHED>
                            <CHED H="1">Comments</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">(A)</ENT>
                            <ENT>First year cost of interoperability (Low estimate)</ENT>
                            <ENT>272.0</ENT>
                            <ENT>Estimated in this proposed rule</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25631"/>
                            <ENT I="01">(B)</ENT>
                            <ENT>First year cost amortized over 9 years</ENT>
                            <ENT>30.2</ENT>
                            <ENT>(A) / 9</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(C)</ENT>
                            <ENT>Continuation year cost of interoperability</ENT>
                            <ENT>54.4</ENT>
                            <ENT>Estimated in this proposed rule</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">(D)</ENT>
                            <ENT>Level interoperability cost per year</ENT>
                            <ENT>84.6</ENT>
                            <ENT>(B) + (C)</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW EXPSTB="04" RUL="s">
                            <ENT I="21">
                                <E T="02">Commercial Percent of Premium Revenues</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">(E)</ENT>
                            <ENT>Total premium revenues in Individual market, Medicaid and Medicare</ENT>
                            <ENT>347</ENT>
                            <ENT>Table 7</ENT>
                            <ENT>In billions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(F)</ENT>
                            <ENT>Individual market plans premium revenues (dollar amount and percent)</ENT>
                            <ENT>77</ENT>
                            <ENT>22.19%</ENT>
                            <ENT>Table 7.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(G)</ENT>
                            <ENT>Medicare Advantage premium revenues (Dollar amount and percent)</ENT>
                            <ENT>157</ENT>
                            <ENT>45.24%</ENT>
                            <ENT>Table 7.</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">(H)</ENT>
                            <ENT>Medicaid premium revenues (Dollar amount and percent)</ENT>
                            <ENT>113</ENT>
                            <ENT>32.56%</ENT>
                            <ENT>Table 7.</ENT>
                        </ROW>
                        <ROW EXPSTB="04" RUL="s">
                            <ENT I="21">
                                <E T="02">Annual interoperability cost as a percent of commercial individual market health insurance premium revenues</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">(I)</ENT>
                            <ENT>Annual Level interoperability cost</ENT>
                            <ENT>84.6</ENT>
                            <ENT>(D)</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(J)</ENT>
                            <ENT>Percent of total individual market plans revenues</ENT>
                            <ENT>22.19%</ENT>
                            <ENT>(F)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(K)</ENT>
                            <ENT>Interoperability cost for individual market plans</ENT>
                            <ENT>18.8</ENT>
                            <ENT>(I) × (J)</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(L)</ENT>
                            <ENT>Commercial premium revenues for individual market plans</ENT>
                            <ENT>77,000</ENT>
                            <ENT>(E)</ENT>
                            <ENT>2016 data in millions.</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">(M)</ENT>
                            <ENT>Interoperability cost as a percent of total commercial revenue for individual market plans</ENT>
                            <ENT>0.0244%</ENT>
                            <ENT>(K) / (L)</ENT>
                        </ROW>
                        <ROW EXPSTB="04" RUL="s">
                            <ENT I="21">
                                <E T="02">Individual market plans revenue broken out by whether above or below MLR threshold (requiring rebate)</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">(N)</ENT>
                            <ENT>Total individual market plan revenue</ENT>
                            <ENT>77,000</ENT>
                            <ENT>(E)</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(O)</ENT>
                            <ENT>Revenues of individual market health plans whose MLR is below regulatory threshold</ENT>
                            <ENT>4,037</ENT>
                            <ENT>2016 CMS MLR Data in millions</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">(P)</ENT>
                            <ENT>Revenues of individual market plans whose MLR is below regulatory threshold</ENT>
                            <ENT>72,963</ENT>
                            <ENT>(N)−(O)</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW EXPSTB="04" RUL="s">
                            <ENT I="21">
                                <E T="02">Transfer to enrollee per enrollee from decreased rebates and increased premium</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="01">(Q)</ENT>
                            <ENT>Reduction in rebates from interoperability in those plans paying rebates</ENT>
                            <ENT>1.0</ENT>
                            <ENT>(N) × (O)</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(R)</ENT>
                            <ENT>Premium increase from interoperability in those plans not paying rebates</ENT>
                            <ENT>17.8</ENT>
                            <ENT>(N) × (P)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(S)</ENT>
                            <ENT>Total increase to commercial individual market plans enrollees from interoperability</ENT>
                            <ENT>18.8</ENT>
                            <ENT>(Q) + (R)</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(T)</ENT>
                            <ENT>Number commercial enrollees in individual market plans</ENT>
                            <ENT>17.5</ENT>
                            <ENT>From 2016 MLR files, in millions</ENT>
                            <ENT>In millions.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(U)</ENT>
                            <ENT>Dollar increase in premium per enrollee (Low estimate)</ENT>
                            <ENT>$1.07</ENT>
                            <ENT>(S) / (T)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(V)</ENT>
                            <ENT>Dollar increase in premium per enrollee (Medium Estimate)</ENT>
                            <ENT>$1.46</ENT>
                            <ENT>Obtained by replacing 272 million in row (A) with $544 million</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">(W)</ENT>
                            <ENT>Dollar increase in premium per enrollee (High Estimate)</ENT>
                            <ENT>$1.84</ENT>
                            <ENT>Obtained by replacing 272 million in row (A) with $816 million</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD2">F. Regulatory Reform Analysis Under E.O. 13771</HD>
                    <P>Executive Order 13771, titled Reducing Regulation and Controlling Regulatory Costs, was issued on January 30, 2017 and requires that the costs associated with significant new regulations “shall, to the extent permitted by law, be offset by the elimination of existing costs associated with at least two prior regulations.” This final rule is considered an E.O. 13771 regulatory action. We estimate that this rule generates $77.8 million in annualized costs, discounted at 7 percent relative to year 2016, over an infinite time horizon estimate. Details on the estimated costs of this final rule can be found in the preceding analysis.</P>
                    <HD SOURCE="HD2">G. Conclusion</HD>
                    <P>The analysis above, together with the preceding preamble, provides an RIA.</P>
                    <P>In accordance with the provisions of Executive Order 12866, this regulation was reviewed by the Office of Management and Budget.</P>
                    <LSTSUB>
                        <HD SOURCE="HED">List of Subjects</HD>
                        <CFR>42 CFR Part 406</CFR>
                        <P>Health facilities, Diseases, Medicare.</P>
                        <CFR>42 CFR Part 407</CFR>
                        <P>Medicare.</P>
                        <CFR>42 CFR Part 422</CFR>
                        <P>Administrative practice and procedure, Health facilities, Health maintenance organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements.</P>
                        <CFR>42 CFR Part 423</CFR>
                        <P>
                            Administrative practice and procedure, Emergency medical services, Health facilities, Health maintenance organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements.
                            <PRTPAGE P="25632"/>
                        </P>
                        <CFR>42 CFR Part 431</CFR>
                        <P>Grant programs—health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping requirements.</P>
                        <CFR>42 CFR Part 438</CFR>
                        <P>Grant programs—health, Medicaid, Reporting and recordkeeping requirements.</P>
                        <CFR>42 CFR Part 457</CFR>
                        <P>Administrative practice and procedure, Grant programs—health, Health insurance, Reporting and recordkeeping requirements.</P>
                        <CFR>42 CFR Part 482</CFR>
                        <P>Grant programs—health, Hospitals, Medicaid, Medicare, Reporting and recordkeeping requirements.</P>
                        <CFR>42 CFR Part 485</CFR>
                        <P>Grant programs—health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping requirements.</P>
                        <CFR>45 CFR Part 156</CFR>
                        <P>Administrative practice and procedure, Advertising, Advisory committees, Brokers, Conflict of interests, Consumer protection, Grant programs—health, Grants administration, Health care, Health insurance, Health maintenance organization (HMO), Health records, Hospitals, Indians, Individuals with disabilities, Loan programs—health, Medicaid, Organization and functions (Government agencies), Public assistance programs, Reporting and recordkeeping requirements, State and local governments, Sunshine Act, Technical assistance, Women, Youth.</P>
                    </LSTSUB>
                    <P>For the reasons set forth in the preamble, the Centers for Medicare &amp; Medicaid Services (CMS) amends 42 CFR chapter IV and the Office of the Secretary (HHS) amends 45 CFR subtitle A, subchapter B, as set forth below:</P>
                    <HD SOURCE="HD1">TITLE 42—PUBLIC HEALTH</HD>
                    <CHAPTER>
                        <HD SOURCE="HED">CHAPTER IV—CENTERS FOR MEDICARE &amp; MEDICAID SERVICES, DEPARTMENT OF HEALTH AND HUMAN SERVICES</HD>
                        <PART>
                            <HD SOURCE="HED">PART 406—HOSPITAL INSURANCE ELIGIBLIITY AND ENTITLEMENT</HD>
                        </PART>
                    </CHAPTER>
                    <REGTEXT TITLE="42" PART="406">
                        <AMDPAR>1. The authority citation for part 406 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C 1302 and 1395hh. </P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="406">
                        <AMDPAR>2. Section 406.26 is amended by adding paragraph (a)(1)(i) and adding and reserving paragraph (a)(1)(ii) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 406.26 </SECTNO>
                            <SUBJECT>Enrollment under State buy-in.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>(1) * * *</P>
                            <P>(i) Any State that has a buy-in agreement in effect must participate in daily exchanges of enrollment data with CMS.</P>
                            <P>(ii) [Reserved]</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 407—SUPPLEMENTARY MEDICAL INSURANCE (SMI) ENROLLMENT AND ENTITLEMENT</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="407">
                        <AMDPAR>3. The authority citation for part 407 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C 1302 and 1395hh. </P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="407">
                        <AMDPAR>4. Section 407.40 is amended by adding paragraph (c)(4) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 407.40 </SECTNO>
                            <SUBJECT>Enrollment under a State buy-in agreement.</SUBJECT>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>(4) Any State that has a buy-in agreement in effect must participate in daily exchanges of enrollment data with CMS. </P>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 422—MEDICARE ADVANTAGE PROGRAM</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>5. The authority citation for part 422 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P> 42 U.S.C 1302 and 1395hh. </P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>6. Section 422.119 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 422.119 </SECTNO>
                            <SUBJECT>Access to and exchange of health data and plan information.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Application Programming Interface to support MA enrollees.</E>
                                 A Medicare Advantage (MA) organization must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a current individual MA enrollee or the enrollee's personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the enrollee.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Accessible content.</E>
                                 (1) An MA organization must make the following information accessible to its current enrollees or the enrollee's personal representative through the API described in paragraph (a) of this section:
                            </P>
                            <P>(i) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;</P>
                            <P>(ii) Encounter data from capitated providers, no later than one (1) business day after data concerning the encounter is received by the MA organization; and</P>
                            <P>(iii) Clinical data, including laboratory results, if the MA organization maintains any such data, no later than one (1) business day after the data is received by the MA organization.</P>
                            <P>(2) In addition to the information specified in paragraph (b)(1) of this section, an MA organization that offers an MA-PD plan must make the following information accessible to its enrollees through the API described in paragraph (a) of this section:</P>
                            <P>(i) Data concerning adjudicated claims for covered Part D drugs, including remittances and enrollee cost-sharing, no later than one (1) business day after a claim is adjudicated; and,</P>
                            <P>(ii) Formulary data that includes covered Part D drugs, and any tiered formulary structure or utilization management procedure which pertains to those drugs.</P>
                            <P>
                                (c) 
                                <E T="03">Technical requirements.</E>
                                 An MA organization implementing an API under paragraph (a) of this section:
                            </P>
                            <P>(1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;</P>
                            <P>(2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data;</P>
                            <P>(3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law:</P>
                            <P>(i) Content and vocabulary standards at 45 CFR 170.213 where such standards are applicable to the data type or element, as appropriate; and</P>
                            <P>(ii) Content and vocabulary standards at 45 CFR part 162 and § 423.160 of this chapter where required by law or where such standards are applicable to the data type or element, as appropriate.</P>
                            <P>(4) May use an updated version of any standard or all standards required under paragraph (c)(1) or (3) of this section, where:</P>
                            <P>
                                (i) Use of the updated version of the standard is required by other applicable law; or
                                <PRTPAGE P="25633"/>
                            </P>
                            <P>(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:</P>
                            <P>(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170;</P>
                            <P>(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and</P>
                            <P>(C) Use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.</P>
                            <P>
                                (d) 
                                <E T="03">Documentation requirements for APIs.</E>
                                 For each API implemented in accordance with paragraph (a) of this section, an MA organization must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, “publicly accessible” means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available;
                            </P>
                            <P>(1) 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>(2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and</P>
                            <P>(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.</P>
                            <P>
                                (e) 
                                <E T="03">Denial or discontinuation of access to the API.</E>
                                 An MA organization may deny or discontinue any third party application's connection to the API required under paragraph (a) of this section if the MA organization:
                            </P>
                            <P>(1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the MA organization's systems; and</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which enrollees seek to access their electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.</P>
                            <P>
                                (f) 
                                <E T="03">Coordination among payers.</E>
                                 (1) An MA organization must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213. Such information received by an MA organization must be incorporated into the MA organization's records about the current enrollee. With the approval and at the direction of a current or former enrollee or the enrollee's personal representative, the MA organization must:
                            </P>
                            <P>(i) Receive all such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years;</P>
                            <P>(ii) At any time an enrollee is currently enrolled in the MA plan and up to 5 years after disenrollment, send all such data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee's personal representative specifically requests receive the data; and</P>
                            <P>(iii) Send data received from another payer under this paragraph (f) in the electronic form and format it was received.</P>
                            <P>(2) [Reserved]</P>
                            <P>
                                (g) 
                                <E T="03">Enrollee resources regarding privacy and security.</E>
                                 An MA organization must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former enrollees seeking to access their health information held by the MA organization, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:
                            </P>
                            <P>(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and</P>
                            <P>(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to:</P>
                            <P>(i) The HHS Office for Civil Rights (OCR); and</P>
                            <P>(ii) The Federal Trade Commission (FTC).</P>
                            <P>
                                (h) 
                                <E T="03">Applicability.</E>
                                 (1) An MA organization must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f) beginning January 1, 2022 with regard to data:
                            </P>
                            <P>(i) With a date of service on or after January 1, 2016; and</P>
                            <P>(ii) That are maintained by the MA organization.</P>
                            <P>(2) [Reserved] </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <AMDPAR>7. Section 422.120 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 422.120 </SECTNO>
                            <SUBJECT>Access to published provider directory information.</SUBJECT>
                            <P>(a) An MA organization must implement and maintain a publicly accessible, standards-based Application Programming Interface (API) that is conformant with the technical requirements at § 422.119(c), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations, the documentation requirements at § 422.119(d), and is accessible via a public-facing digital endpoint on the MA organization's website.</P>
                            <P>(b) The API must provide a complete and accurate directory of—</P>
                            <P>(1) The MA plan's network of contracted providers, including names, addresses, phone numbers, and specialties, updated no later than 30 calendar days after the MA organizations receives provider directory information or updates to provider directory information; and</P>
                            <P>(2) For an MA organization that offers an MA-PD plan, the MA-PD's pharmacy directory, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”) updated no later than 30 calendar days after the MA organization receives pharmacy directory information or updates to pharmacy directory information.</P>
                            <P>(c) This section is applicable beginning January 1, 2021. </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="422">
                        <PRTPAGE P="25634"/>
                        <AMDPAR>8. Section 422.504 is amended by adding paragraph (a)(18) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 422.504 </SECTNO>
                            <SUBJECT>Contract provisions.</SUBJECT>
                            <STARS/>
                            <P>(a) * * *</P>
                            <P>(18) To comply with the requirements for access to health data and plan information under §§ 422.119 and 422.120 of this chapter.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 423—VOLUNTARY MEDICARE PERSCRIPTION DRUG BENEFIT</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="423">
                        <AMDPAR>9. The authority citation for part 423 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P> 42 U.S.C. 1302, 1306, 1395w-101 through 1395w-152, and 1395hh. </P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="423">
                        <AMDPAR>10. Section 423.910 is amended—</AMDPAR>
                        <AMDPAR>a. In paragraph (b)(1) introductory text by removing the phrase “monthly reporting requirement for the monthly enrollment reporting” and adding in its place the phrase “state enrollment reporting requirement described in paragraph (d) of this section”;</AMDPAR>
                        <AMDPAR>b. In paragraph (d) by revising the paragraph heading and by redesignating the text of paragraph (d) introductory text as paragraph (d)(1).</AMDPAR>
                        <AMDPAR>c. In newly redesignated paragraph (d)(1), by removing the phrase “Effective June 2005, and each subsequent month, States must submit an electronic file, in a manner specified by CMS” and by adding the following phrase “States must submit an electronic file as specified in paragraph (d)(2) of this section,”; and</AMDPAR>
                        <AMDPAR>d. By adding paragraph (d)(2).</AMDPAR>
                        <P>The revision and addition read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 423.910 </SECTNO>
                            <SUBJECT>Requirements.</SUBJECT>
                            <STARS/>
                            <P>(d) * * *</P>
                            <P>(2)(i) For the period prior to April 1, 2022, States must submit the file at least monthly and may submit updates to that file on a more frequent basis.</P>
                            <P>(ii) For the period beginning April 1, 2022, States must submit the file at least monthly and must submit updates to that file on a daily basis.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>11. The authority citation for part 431 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>12. Section 431.60 is added to subpart B to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 431.60 </SECTNO>
                            <SUBJECT>Beneficiary access to and exchange of data.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Application Programming Interface to support Medicaid beneficiaries.</E>
                                 A State must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a current beneficiary or the beneficiary's personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the beneficiary.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Accessible content.</E>
                                 A State must make the following information accessible to its current beneficiaries or the beneficiary's personal representative through the API described in paragraph (a) of this section:
                            </P>
                            <P>(1) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and beneficiary cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;</P>
                            <P>(2) Encounter data no later than one (1) business day after receiving the data from providers, other than MCOs, PIHPs, and PAHPs, compensated on the basis of capitation payments;</P>
                            <P>(3) Clinical data, including laboratory results, if the State maintains any such data, no later than one (1) business day after the data is received by the State; and</P>
                            <P>(4) Information about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of any such information or updates to such information.</P>
                            <P>
                                (c) 
                                <E T="03">Technical requirements.</E>
                                 A State implementing an API under paragraph (a) of this section:
                            </P>
                            <P>(1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;</P>
                            <P>(2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data;</P>
                            <P>(3) Must comply with the content and vocabulary standards requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law:</P>
                            <P>(i) Content and vocabulary standards at 45 CFR 170.213 where such standards are applicable to the data type or element, as appropriate; and</P>
                            <P>(ii) Content and vocabulary standards at 45 CFR part 162 and § 423.160 of this chapter where required by law, or where such standards are applicable to the data type or element, as appropriate.</P>
                            <P>(4) May use an updated version of any standard or all standards required under paragraph (c)(1) or (3) of this section, where:</P>
                            <P>(i) Use of the updated version of the standard is required by other applicable law, or</P>
                            <P>(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:</P>
                            <P>(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170;</P>
                            <P>(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and</P>
                            <P>(C) Use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.</P>
                            <P>
                                (d) 
                                <E T="03">Documentation requirements for APIs.</E>
                                 For each API implemented in accordance with paragraph (a) of this section, a State must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, “publicly accessible” means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available;
                            </P>
                            <P>
                                (1) API syntax, function names, required and optional parameters supported and their data types, return 
                                <PRTPAGE P="25635"/>
                                variables and their types/structures, exceptions and exception handling methods and their returns;
                            </P>
                            <P>(2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and</P>
                            <P>(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.</P>
                            <P>
                                (e) 
                                <E T="03">Denial or discontinuation of access to the API.</E>
                                 A State may deny or discontinue any third-party application's connection to the API required under paragraph (a) of this section if the State:
                            </P>
                            <P>(1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the State's systems; and</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which beneficiaries seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.</P>
                            <P>
                                (f) 
                                <E T="03">Beneficiary resources regarding privacy and security.</E>
                                 The State must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former beneficiaries seeking to access their health information held by the State Medicaid agency, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:
                            </P>
                            <P>(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and</P>
                            <P>(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to:</P>
                            <P>(i) The HHS Office for Civil Rights (OCR); and</P>
                            <P>(ii) The Federal Trade Commission (FTC).</P>
                            <P>
                                (g) 
                                <E T="03">Data availability.</E>
                                 (1) The State must comply with the requirements in paragraph (a) through (f) of this section beginning January 1, 2021 with regard to data:
                            </P>
                            <P>(i) With a date of service on or after January 1, 2016; and</P>
                            <P>(ii) That are maintained by the State.</P>
                            <P>(2) [Reserved]</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="431">
                        <AMDPAR>13. Section 431.70 is added to subpart B to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 431.70 </SECTNO>
                            <SUBJECT>Access to published provider directory information.</SUBJECT>
                            <P>(a) The State must implement and maintain a publicly accessible, standards-based Application Programming Interface (API) that is conformant with the technical requirements at § 431.60(c), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations, the documentation requirements at § 431.60(d), and is accessible via a public-facing digital endpoint on the State's website.</P>
                            <P>(b) The API must provide a complete and accurate directory of—</P>
                            <P>(1) The State's provider directory information specified in section 1902(a)(83) of the Act, updated no later than 30 calendar days after the State receives provider directory information or updates to provider directory information.</P>
                            <P>(2) [Reserved]</P>
                            <P>(c) This section is applicable beginning January 1, 2021.</P>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 438—MANAGED CARE</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>14. The authority citation for part 438 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>15. Section 438.62 is amended by adding paragraphs (b)(1)(vi) and (vii) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 438.62 </SECTNO>
                            <SUBJECT>Continued services to enrollees.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(1) * * *</P>
                            <P>(vi) A process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213. Such information received by the MCO, PIHP, or PAHP must be incorporated into the MCO's, PIHP's, or PAHP's records about the current enrollee. With the approval and at the direction of a current or former enrollee or the enrollee's personal representative, the MCO, PIHP, or PAHP must:</P>
                            <P>(A) Receive all such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years;</P>
                            <P>(B) At any time the enrollee is currently enrolled in the MCO, PIHP, or PAHP and up to 5 years after disenrollment, send all such data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee's personal representative specifically requests receive the data; and</P>
                            <P>(C) Send data received from another payer under this paragraph in the electronic form and format it was received.</P>
                            <P>(vii) Applicability.</P>
                            <P>(A) The MCO, PIHP, or PAHP must comply with the requirements in paragraph (b)(1)(vi) of this section beginning January 1, 2022 with regard to data:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) With a date of service on or after January 1, 2016; and
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) That are maintained by the MCO, PIHP, or PAHP.
                            </P>
                            <P>(B) [Reserved]</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="438">
                        <AMDPAR>16. Section 438.242 is amended by adding paragraphs (b)(5) and (6) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 438.242 </SECTNO>
                            <SUBJECT>Health information systems.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(5) Implement an Application Programming Interface (API) as specified in § 431.60 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP and include—</P>
                            <P>(i) All encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating on the basis of capitation payments and adjudicated claims and encounter data from any subcontractors.</P>
                            <P>(ii) [Reserved]</P>
                            <P>(6) Implement, by January 1, 2021, and maintain a publicly accessible standards-based API described in § 431.70, which must include all information specified in § 438.10(h)(1) and (2) of this chapter.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 457—ALLOTMENTS AND GRANTS TO STATES</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>17. The authority citation for part 457 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 1302.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>18. Section 457.700 is amended by—</AMDPAR>
                        <AMDPAR>a. Redesignating paragraphs (a)(1) and (2) as paragraphs (a)(2) and (3), respectively;</AMDPAR>
                        <AMDPAR>b. Adding paragraph (a)(1); and</AMDPAR>
                        <AMDPAR>c. Revising paragraph (c).</AMDPAR>
                        <P>The addition and revision reads as follows:</P>
                        <SECTION>
                            <PRTPAGE P="25636"/>
                            <SECTNO>§ 457.700 </SECTNO>
                            <SUBJECT> Basis, scope, and applicability.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">* * *</E>
                            </P>
                            <P>(1) Section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to States to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage;</P>
                            <STARS/>
                            <P>
                                (c) 
                                <E T="03">Applicability.</E>
                                 The requirements of this subpart apply to separate child health programs and Medicaid expansion programs, except that § 457.730 does not apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care organizations may meet the requirements of § 457.730 by requiring the managed care organizations to meet the requirements of § 457.1233(d)(2).
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>19. Section 457.730 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.730 </SECTNO>
                            <SUBJECT>Beneficiary access to and exchange of data.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Application Programming Interface to support CHIP beneficiaries.</E>
                                 A State must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of the current individual beneficiary or the beneficiary's personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the beneficiary.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Accessible content.</E>
                                 A State must make the following information accessible to its current beneficiaries or the beneficiary's personal representative through the API described in paragraph (a) of this section:
                            </P>
                            <P>(1) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and beneficiary cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;</P>
                            <P>(2) Encounter data no later than 1 business day after receiving the data from providers, other than MCOs, PIHPs, or PAHPs, compensated on the basis of capitation payments;</P>
                            <P>(3) Clinical data, including laboratory results, if a State maintains any such data, no later than one (1) business day after the data is received by the State; and</P>
                            <P>(4) Information, about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of the information or updates to such information.</P>
                            <P>
                                (c) 
                                <E T="03">Technical requirements.</E>
                                 A State implementing an API under paragraph (a) of this section:
                            </P>
                            <P>(1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;</P>
                            <P>(2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify that the API technology is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data;</P>
                            <P>(3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law:</P>
                            <P>(i) Content and vocabulary standards at 45 CFR 170.213 where such standards are applicable to the data type or element, as appropriate; and</P>
                            <P>(ii) Content and vocabulary standards at 45 CFR part 162 and § 423.160 of this chapter where required by law, or where such standards are applicable to the data type or element, as appropriate.</P>
                            <P>(4) May use an updated version of any standard or all standards required under paragraphs (c)(1) or (3) of this section, where:</P>
                            <P>(i) Use of the updated version of the standard is required by other applicable law, or</P>
                            <P>(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:</P>
                            <P>(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170;</P>
                            <P>(B) For standards at 45 CFR 170.213 and 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and</P>
                            <P>(C) Use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.</P>
                            <P>
                                (d) 
                                <E T="03">Documentation requirements for APIs.</E>
                                 For each API implemented in accordance with paragraph (a) of this section, a State must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, “publicly accessible” means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available;
                            </P>
                            <P>(1) 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>(2) The software components and configurations that an application must use in order to successfully interact with the API and process its response(s); and</P>
                            <P>(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.</P>
                            <P>
                                (e) 
                                <E T="03">Denial or discontinuation of access to the API.</E>
                                 A State may deny or discontinue any third-party application's connection to the API required under paragraph (a) of this section if the State:
                            </P>
                            <P>(1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the State's systems; and</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which beneficiaries seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.</P>
                            <P>
                                (f) 
                                <E T="03">Beneficiary resources regarding privacy and security.</E>
                                 A State must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former beneficiaries seeking to 
                                <PRTPAGE P="25637"/>
                                access their health information held by the State CHIP agency, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:
                            </P>
                            <P>(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and</P>
                            <P>(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of OCR and FTC, and how to submit a complaint to:</P>
                            <P>(i) The HHS Office for Civil Rights (OCR); and</P>
                            <P>(ii) The Federal Trade Commission (FTC).</P>
                            <P>
                                (g) 
                                <E T="03">Data availability.</E>
                                 (1) The State must comply with the requirements in paragraphs (a) through (f) of this section beginning January 1, 2021 with regard to data:
                            </P>
                            <P>(i) With a date of service on or after January 1, 2016; and</P>
                            <P>(ii) That are maintained by the State.</P>
                            <P>(2) [Reserved]</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>20. Section 457.760 is added to subpart G to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.760 </SECTNO>
                            <SUBJECT>Access to published provider directory information.</SUBJECT>
                            <P>(a) The State must implement and maintain a publicly accessible, standards-based Application Programming Interface (API) that is conformant with the technical requirements at § 457.730(c), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations, the documentation requirements at § 457.730(d), and is accessible via a public-facing digital endpoint on the State's website.</P>
                            <P>(b) The API must provide a complete and accurate directory of—</P>
                            <P>(1) The State's provider directory information including provider names, addresses, phone numbers, and specialties, updated no later than 30 calendar days after the State receives provider directory information or updates to provider directory information.</P>
                            <P>(2) [Reserved]</P>
                            <P>(c) This section is applicable beginning January 1, 2021.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="457">
                        <AMDPAR>21. Section 457.1233 is amended by revising paragraph (d) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 457.1233 </SECTNO>
                            <SUBJECT>Structure and operations standards.</SUBJECT>
                            <STARS/>
                            <P>
                                (d) 
                                <E T="03">Health information systems.</E>
                                 (1) The State must ensure, through its contracts, that each MCO, PIHP, and PAHP complies with the health information systems requirements as provided in § 438.242(a), (b)(1) through (4), (c), (d), and (e) of this chapter.
                            </P>
                            <P>(2) Each MCO, PIHP, and PAHP must implement an Application Programming Interface (API) as specified in § 457.730 as if such requirements applied directly to the MCO, PIHP, or PAHP, and include—</P>
                            <P>(i) All encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating on the basis of capitation payments and adjudicated claims and encounter data from any subcontractors.</P>
                            <P>(ii) [Reserved]</P>
                            <P>(3) Implement, by January 1, 2021, and maintain a publicly accessible standards-based API described in § 457.760, which must include all information specified in § 438.10(h)(1) and (2) of this chapter.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 482—CONDITIONS OF PARTICIPATION: HOSPITALS</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="482">
                        <AMDPAR>22. The authority citation for part 482 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P> 42 U.S.C. 1302, 1395hh, and 1395rr, unless otherwise noted.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="482">
                        <AMDPAR>23. Section 482.24 is amended by adding paragraph (d) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 482.24 </SECTNO>
                            <SUBJECT>Conditions of participation: Medical record services.</SUBJECT>
                            <STARS/>
                            <P>
                                (d) 
                                <E T="03">Standard: Electronic notifications.</E>
                                 If the hospital utilizes an electronic medical records system or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2), then the hospital must demonstrate that—
                            </P>
                            <P>(1) The system's notification capacity is fully operational and the hospital uses it in accordance with all State and Federal statutes and regulations applicable to the hospital's exchange of patient health information.</P>
                            <P>(2) The system sends notifications that must include at least patient name, treating practitioner name, and sending institution name.</P>
                            <P>(3) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of:</P>
                            <P>(i) The patient's registration in the hospital's emergency department (if applicable).</P>
                            <P>(ii) The patient's admission to the hospital's inpatient services (if applicable).</P>
                            <P>(4) To the extent permissible under applicable federal and state law and regulations and not inconsistent with the patient's expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of:</P>
                            <P>(i) The patient's discharge or transfer from the hospital's emergency department (if applicable).</P>
                            <P>(ii) The patient's discharge or transfer from the hospital's inpatient services (if applicable).</P>
                            <P>(5) The hospital has made a reasonable effort to ensure that the system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes:</P>
                            <P>(i) The patient's established primary care practitioner;</P>
                            <P>(ii) The patient's established primary care practice group or entity; or</P>
                            <P>(iii) Other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="482">
                        <AMDPAR>24. Section 482.61 is amended by adding paragraph (f) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 482.61 </SECTNO>
                            <SUBJECT>Condition of participation: Special medical record requirements for psychiatric hospitals.</SUBJECT>
                            <STARS/>
                            <P>
                                (f) 
                                <E T="03">Standard: Electronic notifications.</E>
                                 If the hospital utilizes an electronic medical records system or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2), then the hospital must demonstrate that—
                            </P>
                            <P>(1) The system's notification capacity is fully operational and the hospital uses it in accordance with all State and Federal statutes and regulations applicable to the hospital's exchange of patient health information.</P>
                            <P>
                                (2) The system sends notifications that must include at least patient name, treating practitioner name, and sending institution name.
                                <PRTPAGE P="25638"/>
                            </P>
                            <P>(3) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of:</P>
                            <P>(i) The patient's registration in the hospital's emergency department (if applicable).</P>
                            <P>(ii) The patient's admission to the hospital's inpatient services (if applicable).</P>
                            <P>(4) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of:</P>
                            <P>(i) The patient's discharge or transfer from the hospital's emergency department (if applicable).</P>
                            <P>(ii) The patient's discharge or transfer from the hospital's inpatient services (if applicable).</P>
                            <P>(5) The hospital has made a reasonable effort to ensure that the system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes:</P>
                            <P>(i) The patient's established primary care practitioner;</P>
                            <P>(ii) The patient's established primary care practice group or entity; or</P>
                            <P>(iii) Other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. </P>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 485—CONDITIONS OF PARTICIPATION: SPECIALIZED PROVIDERS</HD>
                    </PART>
                    <REGTEXT TITLE="42" PART="485">
                        <AMDPAR>25. The authority citation for part 485 is revised to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P> 42 U.S.C. 1302 and 1395hh.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="42" PART="485">
                        <AMDPAR>26. Section 485.638 is amended by adding paragraph (d) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 485.638 </SECTNO>
                            <SUBJECT>Conditions of participation: Clinical records.</SUBJECT>
                            <STARS/>
                            <P>
                                (d) 
                                <E T="03">Standard: Electronic notifications.</E>
                                 If the CAH utilizes an electronic medical records system or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2), then the CAH must demonstrate that—
                            </P>
                            <P>(1) The system's notification capacity is fully operational and the CAH uses it in accordance with all State and Federal statutes and regulations applicable to the CAH's exchange of patient health information.</P>
                            <P>(2) The system sends notifications that must include at least patient name, treating practitioner name, and sending institution name.</P>
                            <P>(3) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of:</P>
                            <P>(i) The patient's registration in the CAH's emergency department (if applicable).</P>
                            <P>(ii) The patient's admission to the CAH's inpatient services (if applicable).</P>
                            <P>(4) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient's expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of:</P>
                            <P>(i) The patient's discharge or transfer from the CAH's emergency department (if applicable).</P>
                            <P>(ii) The patient's discharge or transfer from the CAH's inpatient services (if applicable).</P>
                            <P>(5) The CAH has made a reasonable effort to ensure that the system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient's status for treatment, care coordination, or quality improvement purposes:</P>
                            <P>(i) The patient's established primary care practitioner;</P>
                            <P>(ii) The patient's established primary care practice group or entity; or</P>
                            <P>(iii) Other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care.</P>
                        </SECTION>
                    </REGTEXT>
                    <HD SOURCE="HD1">TITLE 45—PUBLIC WELFARE</HD>
                    <HD SOURCE="HD1">SUBTITLE A—DEPARTMENT OF HEALTH AND HUMAN SERVICES</HD>
                    <PART>
                        <HD SOURCE="HED">PART 156—HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES</HD>
                    </PART>
                    <REGTEXT TITLE="45" PART="485">
                        <AMDPAR>27. The authority citation for part 156 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>42 U.S.C. 18021-18024, 18031-18032, 18041-18042, 18044, 18054, 18061, 18063, 18071, 18082, 26 U.S.C. 36B, and 31 U.S.C. 9701.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="485">
                        <AMDPAR>28. Section 156.221 is added to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 156.221 </SECTNO>
                            <SUBJECT>Access to and exchange of health data and plan information.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Application Programming Interface to support enrollees.</E>
                                 Subject to paragraph (h) of this section, a QHP issuer on a Federally-Facilitated Exchange must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a current individual enrollee or the enrollee's personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the enrollee.
                            </P>
                            <P>
                                (b) 
                                <E T="03">Accessible content.</E>
                                 (1) A QHP issuer on a Federally-facilitate Exchange must make the following information accessible to its current enrollees or the enrollee's personal representative through the API described in paragraph (a) of this section:
                            </P>
                            <P>(i) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;</P>
                            <P>(ii) Encounter data from capitated providers, no later than one (1) business day after data concerning the encounter is received by the QHP issuer; and</P>
                            <P>(iii) Clinical data, including laboratory results, if the QHP issuer maintains any such data, no later than one (1) business day after data is received by the issuer.</P>
                            <P>(2) [Reserved]</P>
                            <P>
                                (c) 
                                <E T="03">Technical requirements.</E>
                                 A QHP issuer on a Federally-facilitated Exchange implementing an API under paragraph (a) of this section:
                            </P>
                            <P>
                                (1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;
                                <PRTPAGE P="25639"/>
                            </P>
                            <P>(2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify the API is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable data;</P>
                            <P>(3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable, to the data type or data element, unless alternate standards are required by other applicable law:</P>
                            <P>(i) Content and vocabulary standards at 45 CFR 170.213 where such are applicable to the data type or element, as appropriate; and</P>
                            <P>(ii) Content and vocabulary standards at part 162 of this subchapter and 42 CFR 423.160 where required by law, or where such standards are applicable to the data type or element, as appropriate.</P>
                            <P>(4) May use an updated version of any standard or all standards required under paragraphs (c)(1) or (3) of this section, where:</P>
                            <P>(i) Use of the updated version of the standard is required by other applicable law, or</P>
                            <P>(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:</P>
                            <P>(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or part 170 of this subchapter;</P>
                            <P>(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and</P>
                            <P>(C) Use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.</P>
                            <P>
                                (d) 
                                <E T="03">Documentation requirements for APIs.</E>
                                 For each API implemented in accordance with paragraph (a) of this section, a QHP issuer on a Federally-Facilitated Exchange must make publicly accessible, by posting directly on its website and/or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, “publicly accessible” means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available;
                            </P>
                            <P>(1) 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>(2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and</P>
                            <P>(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.</P>
                            <P>
                                (e) 
                                <E T="03">Denial or discontinuation of access to the API.</E>
                                 A QHP issuer on a Federally-Facilitated Exchange may deny or discontinue any third party application's connection to the API required under paragraph (a) of this section if the QHP issuer:
                            </P>
                            <P>(1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of personally identifiable information, including protected health information, on the QHP issuer's systems; and</P>
                            <P>(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which enrollees seek to access their electronic health information as defined at § 171.102 of this subchapter, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.</P>
                            <P>
                                (f) 
                                <E T="03">Coordination among payers.</E>
                                 (1) A QHP issuer on a Federally-facilitated Exchange must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213. Such information received by a QHP issuer on a Federally-facilitated Exchange must be incorporated into the QHP issuer's records about the current enrollee. With the approval and at the direction of a current or former enrollee or the enrollee's personal representative, a QHP issuer on a Federally-facilitated Exchange must:
                            </P>
                            <P>(i) Receive all such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years;</P>
                            <P>(ii) At any time the enrollee is currently enrolled in the plan and up to 5 years after disenrollment, send all such data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee's personal representative specifically requests receive the data; and</P>
                            <P>(iii) Send data received from another payer under this paragraph (f) in the electronic form and format it was received.</P>
                            <P>(2) [Reserved]</P>
                            <P>
                                (g) 
                                <E T="03">Enrollee resources regarding privacy and security.</E>
                                 A QHP issuer on a Federally-facilitated Exchange must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former enrollees seeking to access their health information held by the QHP issuer, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:
                            </P>
                            <P>(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and</P>
                            <P>(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to:</P>
                            <P>(i) The HHS Office for Civil Rights (OCR); and</P>
                            <P>(ii) The Federal Trade Commission (FTC).</P>
                            <P>
                                (h) 
                                <E T="03">Exception.</E>
                                 (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraphs (a) through (g) of this section, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section.
                                <PRTPAGE P="25640"/>
                            </P>
                            <P>(2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (a) through (g) of this section if the Exchange determines that making such health plan available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates.</P>
                            <P>
                                (i) 
                                <E T="03">Applicability.</E>
                                 A QHP issuer on an individual market Federally-facilitated Exchange, not including QHP issuers offering only stand-alone dental plans, must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning with plan years beginning on or after January 1, 2021, and with the requirements in paragraph (f) of this section beginning with plan years beginning on or after January 1, 2022 with regard to data:
                            </P>
                            <P>(1) With a date of service on or after January 1, 2016; and</P>
                            <P>(2) That are maintained by the QHP issuer for enrollees in QHPs.</P>
                        </SECTION>
                    </REGTEXT>
                    <SIG>
                        <DATED>Dated: January 21, 2020.</DATED>
                        <NAME>Seema Verma,</NAME>
                        <TITLE>Administrator, Centers for Medicare &amp; Medicaid Services.</TITLE>
                        <DATED>Dated:  March 5, 2020.</DATED>
                        <NAME>Alex M. Azar II,</NAME>
                        <TITLE>Secretary, Department of Health and Human Services.</TITLE>
                    </SIG>
                </SUPLINF>
                <FRDOC>[FR Doc. 2020-05050 Filed 4-21-20; 4:15 pm]</FRDOC>
                <BILCOD> BILLING CODE P</BILCOD>
            </RULE>
        </RULES>
    </NEWPART>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <NEWPART>
        <NEWBOOKT>
            <PRTPAGE P="25641"/>
            <PARTNO>Part III</PARTNO>
            <BOOK>Book 2 of 2 Books</BOOK>
            <PGS>Pages 25641-26318</PGS>
            <AGENCY TYPE="P">Department of Health and Human Services</AGENCY>
            <CFR>45 CFR Parts 170 and 171</CFR>
            <TITLE>21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program; Final Rule</TITLE>
        </NEWBOOKT>
        <RULES>
            <RULE>
                <PREAMB>
                    <PRTPAGE P="25642"/>
                    <AGENCY TYPE="S">DEPARTMENT OF HEALTH AND HUMAN SERVICES</AGENCY>
                    <SUBAGY>Office of the Secretary</SUBAGY>
                    <CFR>45 CFR Parts 170 and 171</CFR>
                    <RIN>RIN 0955-AA01</RIN>
                    <SUBJECT>21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program</SUBJECT>
                    <AGY>
                        <HD SOURCE="HED">AGENCY:</HD>
                        <P>Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services (HHS).</P>
                    </AGY>
                    <ACT>
                        <HD SOURCE="HED">ACTION:</HD>
                        <P>Final rule.</P>
                    </ACT>
                    <SUM>
                        <HD SOURCE="HED">SUMMARY:</HD>
                        <P>This final rule implements certain provisions of the 21st Century Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) developers under the ONC Health IT Certification Program (Program), the voluntary certification of health IT for use by pediatric health care providers, and reasonable and necessary activities that do not constitute information blocking. The implementation of these provisions will advance interoperability and support the access, exchange, and use of electronic health information. The rule also finalizes certain modifications to the 2015 Edition health IT certification criteria and Program in additional ways to advance interoperability, enhance health IT certification, and reduce burden and costs.</P>
                    </SUM>
                    <EFFDATE>
                        <HD SOURCE="HED">DATES:</HD>
                        <P/>
                        <P>
                            <E T="03">Effective date:</E>
                             This final rule is effective on June 30, 2020.
                        </P>
                        <P>
                            <E T="03">Incorporation by reference:</E>
                             The incorporation by reference of certain publications listed in the rule was approved by the Director of the Federal Register as of June 30, 2020.
                        </P>
                        <P>
                            <E T="03">Compliance date:</E>
                             Compliance with 45 CFR 170.401, 170.402(a)(1), and 45 CFR part 171 is required by November 2, 2020.
                        </P>
                    </EFFDATE>
                    <FURINF>
                        <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                        <P>Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202-690-7151.</P>
                    </FURINF>
                </PREAMB>
                <SUPLINF>
                    <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                    <P/>
                    <HD SOURCE="HD1">Table of Contents</HD>
                    <EXTRACT>
                        <FP SOURCE="FP-2">I. Executive Summary</FP>
                        <FP SOURCE="FP1-2">A. Purpose of Regulatory Action</FP>
                        <FP SOURCE="FP1-2">B. Summary of Major Provisions and Clarifications</FP>
                        <FP SOURCE="FP1-2">1. Deregulatory Actions for Previous Rulemakings</FP>
                        <FP SOURCE="FP1-2">2. Updates to the 2015 Edition Certification Criteria</FP>
                        <FP SOURCE="FP1-2">a. Adoption of the United States Core Data for Interoperability (USCDI) as a Standard</FP>
                        <FP SOURCE="FP1-2">b. Electronic Prescribing</FP>
                        <FP SOURCE="FP1-2">c. Clinical Quality Measures—Report</FP>
                        <FP SOURCE="FP1-2">d. Electronic Health Information (EHI) Export</FP>
                        <FP SOURCE="FP1-2">e. Application Programming Interfaces</FP>
                        <FP SOURCE="FP1-2">f. Privacy and Security Transparency Attestations</FP>
                        <FP SOURCE="FP1-2">g. Security Tags and Consent Management</FP>
                        <FP SOURCE="FP1-2">3. Modifications To the ONC Health IT Certification Program</FP>
                        <FP SOURCE="FP1-2">4. Health IT for the Care Continuum</FP>
                        <FP SOURCE="FP1-2">5. Conditions and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">6. Information Blocking</FP>
                        <FP SOURCE="FP1-2">C. Costs and Benefits</FP>
                        <FP SOURCE="FP-2">II. Background</FP>
                        <FP SOURCE="FP1-2">A. Statutory Basis</FP>
                        <FP SOURCE="FP1-2">1. Standards, Implementation Specifications, and Certification Criteria</FP>
                        <FP SOURCE="FP1-2">2. Health IT Certification Program(s)</FP>
                        <FP SOURCE="FP1-2">B. Regulatory History</FP>
                        <FP SOURCE="FP1-2">C. General Comments on the Proposed Rule</FP>
                        <FP SOURCE="FP-2">III. Deregulatory Actions for Previous Rulemakings</FP>
                        <FP SOURCE="FP1-2">A. Background</FP>
                        <FP SOURCE="FP1-2">1. History of Burden Reduction and Regulatory Flexibility</FP>
                        <FP SOURCE="FP1-2">2. Executive Orders 13771 and 13777</FP>
                        <FP SOURCE="FP1-2">B. Deregulatory Actions</FP>
                        <FP SOURCE="FP1-2">1. Removal of Randomized Surveillance Requirements</FP>
                        <FP SOURCE="FP1-2">2. Removal of the 2014 Edition From the Code of Federal Regulations</FP>
                        <FP SOURCE="FP1-2">3. Removal of the ONC-Approved Accreditor From the Program</FP>
                        <FP SOURCE="FP1-2">4. Removal of Certain 2015 Edition Certification Criteria and Standards</FP>
                        <FP SOURCE="FP1-2">a. 2015 Edition Base EHR Definition Certification Criteria</FP>
                        <FP SOURCE="FP1-2">b. Drug-Formulary and Preferred Drug Lists</FP>
                        <FP SOURCE="FP1-2">c. Patient-Specific Education Resources</FP>
                        <FP SOURCE="FP1-2">d. Common Clinical Data Set Summary Record—Create; and Common Clinical Data Set Summary Record—Receive</FP>
                        <FP SOURCE="FP1-2">e. Secure Messaging</FP>
                        <FP SOURCE="FP1-2">5. Removal of Certain ONC Health IT Certification Program Requirements</FP>
                        <FP SOURCE="FP1-2">a. Limitations Disclosures</FP>
                        <FP SOURCE="FP1-2">b. Transparency and Mandatory Disclosures Requirements</FP>
                        <FP SOURCE="FP1-2">6. Recognition of Food and Drug Administration Processes</FP>
                        <FP SOURCE="FP1-2">a. FDA Software Precertification Pilot Program</FP>
                        <FP SOURCE="FP1-2">b. Development of Similar Independent Program Processes—Request for Information</FP>
                        <FP SOURCE="FP-2">IV. Updates To the 2015 Edition Certification Criteria</FP>
                        <FP SOURCE="FP1-2">A. Standards and Implementation Specifications</FP>
                        <FP SOURCE="FP1-2">1. National Technology Transfer and Advancement Act</FP>
                        <FP SOURCE="FP1-2">2. Compliance With Adopted Standards and Implementation Specifications</FP>
                        <FP SOURCE="FP1-2">3. “Reasonably Available” to Interested Parties</FP>
                        <FP SOURCE="FP1-2">B. Revised and New 2015 Edition Criteria</FP>
                        <FP SOURCE="FP1-2">1. The United States Core Data for Interoperability Standard (USCDI)</FP>
                        <FP SOURCE="FP1-2">a. USCDI 2015 Edition Certification Criteria</FP>
                        <FP SOURCE="FP1-2">b. USCDI Standard—Data Classes Included</FP>
                        <FP SOURCE="FP1-2">c. USCDI Standard—Relationship to Content Exchange Standards and Implementation Specifications</FP>
                        <FP SOURCE="FP1-2">2. Clinical Notes C-CDA Implementation Specification</FP>
                        <FP SOURCE="FP1-2">3. Unique Device Identifier(s) for a Patient's Implantable Device(s) C-CDA Implementation Specification</FP>
                        <FP SOURCE="FP1-2">4. Electronic Prescribing Criterion</FP>
                        <FP SOURCE="FP1-2">a. Electronic Prescribing Standard and Certification Criterion</FP>
                        <FP SOURCE="FP1-2">b. Electronic Prescribing Transactions</FP>
                        <FP SOURCE="FP1-2">5. Clinical Quality Measures—Report Criterion</FP>
                        <FP SOURCE="FP1-2">6. Electronic Health Information (EHI) Export Criterion</FP>
                        <FP SOURCE="FP1-2">a. Single Patient Export To Support Patient Access</FP>
                        <FP SOURCE="FP1-2">b. Patient Population Export to Support Transitions Between Health IT Systems</FP>
                        <FP SOURCE="FP1-2">c. Scope of Data Export</FP>
                        <FP SOURCE="FP1-2">d. Export Format</FP>
                        <FP SOURCE="FP1-2">e. Initial Step Towards Real-Time Access</FP>
                        <FP SOURCE="FP1-2">f. Timeframes</FP>
                        <FP SOURCE="FP1-2">g. 2015 Edition “Data Export” Criterion in § 170.315(b)(6)</FP>
                        <FP SOURCE="FP1-2">7. Standardized API for Patient and Population Services Criterion</FP>
                        <FP SOURCE="FP1-2">8. Privacy and Security Transparency Attestations Criteria</FP>
                        <FP SOURCE="FP1-2">a. Encrypt Authentication Credentials</FP>
                        <FP SOURCE="FP1-2">b. Multi-Factor Authentication</FP>
                        <FP SOURCE="FP1-2">9. Security Tags and Consent Management Criteria</FP>
                        <FP SOURCE="FP1-2">a. Implementation With the Consolidated CDA Release 2.1</FP>
                        <FP SOURCE="FP1-2">b. Implementation With the Fast Healthcare Interoperability Resources (FHIRr) Standard</FP>
                        <FP SOURCE="FP1-2">10. Auditable Events and Tamper-Resistance, Audit Reports, and Auditing Actions on Health Information</FP>
                        <FP SOURCE="FP1-2">C. Unchanged 2015 Edition Criteria—Promoting Interoperability Programs Reference Alignment</FP>
                        <FP SOURCE="FP-2">V. Modifications To the ONC Health IT Certification Program</FP>
                        <FP SOURCE="FP1-2">A. Corrections</FP>
                        <FP SOURCE="FP1-2">1. Auditable Events and Tamper Resistance</FP>
                        <FP SOURCE="FP1-2">2. Amendments</FP>
                        <FP SOURCE="FP1-2">3. View, Download, and Transmit to 3rd Party</FP>
                        <FP SOURCE="FP1-2">4. Integrating Revised and New Certification Criteria Into the 2015 Edition Privacy and Security Certification Framework</FP>
                        <FP SOURCE="FP1-2">B. Principles of Proper Conduct for ONC-ACBs</FP>
                        <FP SOURCE="FP1-2">1. Records Retention</FP>
                        <FP SOURCE="FP1-2">2. Conformance Methods for Certification Criteria</FP>
                        <FP SOURCE="FP1-2">3. ONC-ACBs To Accept Test Results From Any ONC-ATL in Good Standing</FP>
                        <FP SOURCE="FP1-2">4. Mandatory Disclosures and Certifications</FP>
                        <FP SOURCE="FP1-2">C. Principles of Proper Conduct for ONC-ATLs—Records Retention</FP>
                        <FP SOURCE="FP-2">VI. Health IT for the Care Continuum</FP>
                        <FP SOURCE="FP1-2">A. Health IT for Pediatric Setting</FP>
                        <FP SOURCE="FP1-2">1. Background and Stakeholder Convening</FP>
                        <FP SOURCE="FP1-2">2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care</FP>
                        <FP SOURCE="FP1-2">a. 2015 Edition Certification Criteria</FP>
                        <FP SOURCE="FP1-2">
                            b. New or Revised Certification Criteria
                            <PRTPAGE P="25643"/>
                        </FP>
                        <FP SOURCE="FP1-2">B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information</FP>
                        <FP SOURCE="FP-2">VII. Conditions and Maintenance of Certification Requirements for Health IT Developers</FP>
                        <FP SOURCE="FP1-2">A. Implementation</FP>
                        <FP SOURCE="FP1-2">B. Provisions</FP>
                        <FP SOURCE="FP1-2">1. Information Blocking</FP>
                        <FP SOURCE="FP1-2">2. Assurances</FP>
                        <FP SOURCE="FP1-2">a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities</FP>
                        <FP SOURCE="FP1-2">b. Certification to the “Electronic Health Information Export” Criterion</FP>
                        <FP SOURCE="FP1-2">c. Records and Information Retention</FP>
                        <FP SOURCE="FP1-2">d. Trusted Exchange Framework and the Common Agreement—Request for Information</FP>
                        <FP SOURCE="FP1-2">3. Communications</FP>
                        <FP SOURCE="FP1-2">a. Background and Purpose</FP>
                        <FP SOURCE="FP1-2">b. Condition of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">c. Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">4. Application Programming Interfaces</FP>
                        <FP SOURCE="FP1-2">a. Statutory Interpretation and API Policy Principles</FP>
                        <FP SOURCE="FP1-2">b. API Standards and Implementation Specifications</FP>
                        <FP SOURCE="FP1-2">c. Standardized API for Patient and Population Services</FP>
                        <FP SOURCE="FP1-2">d. API Condition of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">e. API Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">5. Real World Testing</FP>
                        <FP SOURCE="FP1-2">a. Unit of Analysis at which Testing Requirements Apply</FP>
                        <FP SOURCE="FP1-2">b. Applicability of Real World Testing Condition and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">c. Testing Plans, Methods, and Results Reporting</FP>
                        <FP SOURCE="FP1-2">d. Submission Dates</FP>
                        <FP SOURCE="FP1-2">e. Real World Testing Pilot Year</FP>
                        <FP SOURCE="FP1-2">f. Health IT Modules Certified But Not Yet Deployed</FP>
                        <FP SOURCE="FP1-2">g. Standards Version Advancement Process (SVAP)</FP>
                        <FP SOURCE="FP1-2">h. Updating Already Certified Health IT Leveraging SVAP Flexibility</FP>
                        <FP SOURCE="FP1-2">i. Health IT Modules Presented for Certification Leveraging SVAP Flexibility</FP>
                        <FP SOURCE="FP1-2">j. Requirements Associated With All Health IT Modules Certified Leveraging SVAP Flexibility</FP>
                        <FP SOURCE="FP1-2">k. Advanced Version Approval for SVAP</FP>
                        <FP SOURCE="FP1-2">l. Real World Testing Principles of Proper Conduct for ONC-ACBs</FP>
                        <FP SOURCE="FP1-2">m. Health IT Module Certification &amp; Certification to Newer Versions of Certain Standards</FP>
                        <FP SOURCE="FP1-2">6. Attestations</FP>
                        <FP SOURCE="FP1-2">7. EHR Reporting Criteria Submission</FP>
                        <FP SOURCE="FP1-2">C. Compliance</FP>
                        <FP SOURCE="FP1-2">D. Enforcement</FP>
                        <FP SOURCE="FP1-2">1. ONC Direct Review of the Conditions and Maintenance of Certification Requirements</FP>
                        <FP SOURCE="FP1-2">2. Review and Enforcement Only by ONC</FP>
                        <FP SOURCE="FP1-2">3. Review Processes</FP>
                        <FP SOURCE="FP1-2">a. Initiating Review and Health IT Developer Notice</FP>
                        <FP SOURCE="FP1-2">b. Relationship With ONC-ACBs and ONC-ATLs</FP>
                        <FP SOURCE="FP1-2">c. Records Access</FP>
                        <FP SOURCE="FP1-2">d. Corrective Action</FP>
                        <FP SOURCE="FP1-2">e. Certification Ban and Termination</FP>
                        <FP SOURCE="FP1-2">f. Appeal</FP>
                        <FP SOURCE="FP1-2">g. Suspension</FP>
                        <FP SOURCE="FP1-2">h. Proposed Termination</FP>
                        <FP SOURCE="FP1-2">4. Public Listing of Certification Ban and Terminations</FP>
                        <FP SOURCE="FP1-2">5. Effect on Existing Program Requirements and Processes</FP>
                        <FP SOURCE="FP1-2">6. Coordination With the Office of Inspector General</FP>
                        <FP SOURCE="FP1-2">7. Applicability of Conditions and Maintenance of Certification Requirements for Self-Developers</FP>
                        <FP SOURCE="FP-2">VIII. Information Blocking</FP>
                        <FP SOURCE="FP1-2">A. Statutory Basis</FP>
                        <FP SOURCE="FP1-2">B. Legislative Background and Policy Considerations</FP>
                        <FP SOURCE="FP1-2">1. Purpose of the Information Blocking Provision</FP>
                        <FP SOURCE="FP1-2">2. Policy Considerations and Approach to Information Blocking</FP>
                        <FP SOURCE="FP1-2">3. General Comments Regarding Information Blocking Exceptions</FP>
                        <FP SOURCE="FP1-2">C. Relevant Statutory Terms and Provisions</FP>
                        <FP SOURCE="FP1-2">1. “Required by Law”</FP>
                        <FP SOURCE="FP1-2">2. Health Care Providers, Health IT Developers, Exchanges, and Networks</FP>
                        <FP SOURCE="FP1-2">a. Health Care Providers</FP>
                        <FP SOURCE="FP1-2">b. Health IT Developers of Certified Health IT</FP>
                        <FP SOURCE="FP1-2">c. Health Information Networks and Health Information Exchanges</FP>
                        <FP SOURCE="FP1-2">3. Electronic Health Information</FP>
                        <FP SOURCE="FP1-2">4. Price Information—Request for Information</FP>
                        <FP SOURCE="FP1-2">5. Interests Promoted by the Information Blocking Provision</FP>
                        <FP SOURCE="FP1-2">a. Access, Exchange, and Use of EHI</FP>
                        <FP SOURCE="FP1-2">b. Interoperability Elements</FP>
                        <FP SOURCE="FP1-2">6. Practices That May Implicate the Information Blocking Provision</FP>
                        <FP SOURCE="FP1-2">a. Prevention, Material Discouragement, and Other Interference</FP>
                        <FP SOURCE="FP1-2">b. Likelihood of Interference</FP>
                        <FP SOURCE="FP1-2">c. Examples of Practices Likely to Interfere With Access, Exchange, or Use of EHI</FP>
                        <FP SOURCE="FP1-2">7. Applicability of Exceptions</FP>
                        <FP SOURCE="FP1-2">a. Reasonable and Necessary Activities</FP>
                        <FP SOURCE="FP1-2">b. Treatment of Different Types of Actors</FP>
                        <FP SOURCE="FP1-2">c. Establishing That Activities and Practices Meet the Conditions of an Exception</FP>
                        <FP SOURCE="FP1-2">D. Exceptions to the Information Blocking Definition</FP>
                        <FP SOURCE="FP1-2">1. Exceptions That Involve not Fulfilling Requests To Access, Exchange, or Use EHI</FP>
                        <FP SOURCE="FP1-2">a. Preventing Harm Exception—When will an actor's practice that is likely to interfere with the access, exchange, or use of EHI in order to prevent harm not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">b. Privacy Exception—When will an actor's practice of not fulfilling a request to access, exchange, or use EHI in order to protect an individual's privacy not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">c. Security Exception—When will an actor's practice that is likely to interfere with the access, exchange, or use of EHI in order to protect the security of EHI not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">d. Infeasibility Exception—When will an actor's practice of not fulfilling a request to access, exchange, or use EHI due to the infeasibility of the request not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">e. Health IT Performance Exception—When will an actor's practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of EHI not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">2. Exceptions That Involve Procedures for Fulfilling Requests To Access, Exchange, or Use EHI</FP>
                        <FP SOURCE="FP1-2">a. Content and Manner Exception—When will an actor's practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use EHI not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">b. Fees Exception—When will an actor's practice of charging fees for accessing, exchanging, or using EHI not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">c. Licensing Exception—When will an actor's practice to license interoperability elements in order for EHI to be accessed, exchanged, or used not be considered information blocking?</FP>
                        <FP SOURCE="FP1-2">E. Additional Exceptions—Request for Information</FP>
                        <FP SOURCE="FP1-2">1. Exception for Complying With Common Agreement for Trusted Exchange</FP>
                        <FP SOURCE="FP1-2">2. New Exceptions</FP>
                        <FP SOURCE="FP1-2">F. Complaint Process</FP>
                        <FP SOURCE="FP1-2">G. Disincentives for Health Care Providers—Request for Information</FP>
                        <FP SOURCE="FP-2">IX. Registries Request for Information</FP>
                        <FP SOURCE="FP-2">X. Patient Matching Request for Information</FP>
                        <FP SOURCE="FP-2">XI. Incorporation by Reference</FP>
                        <FP SOURCE="FP-2">XII. Collection of Information Requirements</FP>
                        <FP SOURCE="FP1-2">A. ONC-ACBs</FP>
                        <FP SOURCE="FP1-2">B. Health IT Developers</FP>
                        <FP SOURCE="FP-2">XIII. Regulatory Impact Analysis</FP>
                        <FP SOURCE="FP1-2">A. Statement of Need</FP>
                        <FP SOURCE="FP1-2">B. Alternatives Considered</FP>
                        <FP SOURCE="FP1-2">C. Overall Impact</FP>
                        <FP SOURCE="FP1-2">1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis</FP>
                        <FP SOURCE="FP1-2">2. Executive Order 13771—Reducing Regulation and Controlling Regulatory Costs</FP>
                        <FP SOURCE="FP1-2">a. Costs and Benefits</FP>
                        <FP SOURCE="FP1-2">b. Accounting Statement and Table</FP>
                        <FP SOURCE="FP1-2">3. Regulatory Flexibility Act</FP>
                        <FP SOURCE="FP1-2">4. Executive Order 13132—Federalism</FP>
                        <FP SOURCE="FP1-2">5. Unfunded Mandates Reform Act of 1995</FP>
                        <FP SOURCE="FP-2">Regulation Text</FP>
                    </EXTRACT>
                    <HD SOURCE="HD1">I. Executive Summary</HD>
                    <HD SOURCE="HD2">A. Purpose of Regulatory Action</HD>
                    <P>
                        ONC is responsible for the implementation of key provisions in Title IV of the 21st Century Cures Act (Cures Act) that are designed to advance interoperability; support the access, exchange, and use of electronic health information (EHI); and address occurrences of information blocking. This final rule implements certain provisions of the Cures Act, including Conditions and Maintenance of Certification requirements for health information technology (health IT) 
                        <PRTPAGE P="25644"/>
                        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 implements parts of section 4006(a) of the Cures Act to support patients' access to their EHI in a form convenient for patients, such as making a patient's EHI more electronically accessible through the adoption of standards and certification criteria and the implementation of information blocking policies that support patient electronic access to their health information at no cost. Additionally, the final rule modifies the 2015 Edition health IT certification criteria and ONC Health IT Certification Program (Program) in other ways to advance interoperability, enhance health IT certification, and reduce burden and costs.
                    </P>
                    <P>In addition to fulfilling the Cures Act's requirements, the final rule contributes to fulfilling Executive Order (E.O.) 13813. The President issued E.O. 13813 on October 12, 2017, to promote health care choice and competition across the United States. Section 1(c) of the E.O., in relevant part, states that government rules affecting the United States health care system should re-inject competition into health care markets by lowering barriers to entry and preventing abuses of market power. Section 1(c) also states that government rules should improve access to and the quality of information that Americans need to make informed health care decisions. For example, as mentioned above, the final rule establishes application programming interface (API) requirements, including for patients' access to their health information without special effort. The API approach also supports health care providers' independence to choose the “provider-facing” third-party services they want to use to interact with the certified API technology they have acquired. In addition, the final rule provides the Secretary of Health and Human Services' (Secretary) interpretation of the information blocking definition as established in the Cures Act and the application of the information blocking provision by identifying reasonable and necessary activities that would not constitute information blocking. Many of these activities focus on improving patient and health care provider access to EHI and promoting competition.</P>
                    <HD SOURCE="HD2">B. Summary of Major Provisions and Clarifications</HD>
                    <HD SOURCE="HD3">1. Deregulatory Actions for Previous Rulemakings</HD>
                    <P>Since the inception of the Program, we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Throughout the years, we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both developers and providers, and support innovation. This approach has been consistent with the principles of E.O. 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to “periodically review its existing significant regulations and determine whether any such regulations should be modified, streamlined, expanded, or repealed so as to make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives.” To that end, we have historically, where feasible and appropriate, taken measures to reduce burden within the Program and make the Program more effective, flexible, and streamlined.</P>
                    <P>We reviewed and evaluated existing regulations and identified ways to administratively reduce burden and implement deregulatory actions through guidance. In this final rule, we have finalized new deregulatory actions that will reduce burden for health IT developers, providers, and other stakeholders. We have finalized five deregulatory actions in section III.B: (1) Removal of a requirement to conduct randomized surveillance on a set percentage of certified products, allowing ONC-Authorized Certification Bodies (ONC-ACBs) more flexibility to identify the right approach for surveillance actions; (2) removal of the 2014 Edition from the Code of Federal Regulations (CFR); (3) removal of the ONC-Approved Accreditor (ONC-AA) from the Program; (4) removal of certain 2015 Edition certification criteria; and (5) removal of certain Program requirements. We have not finalized a sixth deregulatory action we proposed, related to recognition of the Food and Drug Administration (FDA) Software Precertification Program, as comments and the early stage of development of the FDA program indicate finalization would be premature at this time.</P>
                    <HD SOURCE="HD3">2. Updates to the 2015 Edition Certification Criteria</HD>
                    <P>This final rule updates the 2015 Edition to remove several certification criteria. It also updates some certification criteria to reflect standard and implementation specification updates. In consideration of public comments, the final rule adds only two new technical certification criteria and two new attestation-structured privacy and security certification criteria.</P>
                    <HD SOURCE="HD3">a. Adoption of the United States Core Data for Interoperability (USCDI) as a Standard</HD>
                    <P>
                        We noted in the Proposed Rule that, as part of continued efforts to ensure the availability of a minimum baseline of data classes that could be commonly available for interoperable exchange, ONC adopted the 2015 Edition “Common Clinical Data Set” (CCDS) definition and used the CCDS shorthand in several certification criteria. However, the CCDS definition also began to be used colloquially for many different purposes. As the CCDS definition's relevance grew outside of its regulatory context, it was often viewed as a ceiling to the industry's collective data set for access, exchange, and use. In addition, we noted in the NPRM that as we continue to move toward value-based care, the inclusion of additional data classes beyond the CCDS would be necessary. In order to advance interoperability, we proposed to remove the CCDS definition and its references from the 2015 Edition and replace it with the “United States Core Data for Interoperability 
                        <SU>1</SU>
                        <FTREF/>
                        ” (USCDI). We proposed to adopt the USCDI as a standard, naming USCDI Version 1 (USCDI v1) in § 170.213 and incorporating it by reference in § 170.299. The USCDI standard would establish a set of data classes and constituent data elements required to support interoperability nationwide. To achieve the goals set forth in the Cures Act, we indicated that we intended to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI's expansion. We also noted that once the USCDI is adopted by the Secretary in regulation, health IT developers would be allowed to take advantage of a new proposed flexibility we called the “Standards Version Advancement Process” (SVAP) (see 84 FR 7497 through 7500, see also section VII.B.5 of this final rule). In order to advance interoperability, we have finalized the adoption of the USCDI standard. Because the USCDI is adopted as a standard and the SVAP is finalized, the SVAP will allow a developer to voluntarily have their products certified to newer, National Coordinator approved versions of the 
                        <PRTPAGE P="25645"/>
                        USCDI in the future without waiting for rulemaking to update the version of the USCDI listed in the regulations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1</SU>
                             
                            <E T="03">https://www.healthit.gov/uscdi.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Electronic Prescribing</HD>
                    <P>We have finalized an update to the electronic prescribing National Council for Prescription Drug Programs (NCPDP) SCRIPT standard in 45 CFR 170.205(b) from NCPDP SCRIPT standard version 10.6 to NCPDP SCRIPT standard version 2017071 for the electronic prescribing certification criterion (§ 170.315(b)(3)). ONC and the Centers for Medicare &amp; Medicaid Services (CMS) have historically maintained aligned e-Rx and medication history (MH) standards to ensure that the current standard for certification to the electronic prescribing criterion supports use of the current Part D e-Rx and MH standards. This helps advance alignment with CMS' program standards.</P>
                    <P>In a final rule published April 16, 2018, CMS finalized its update of its Part D standards to NCPDP SCRIPT standard version 2017071 for e-Rx and MH, effective January 1, 2020 (83 FR 16440). In addition to continuing to reference the transactions previously included in § 170.315(b)(3), and in keeping with CMS' final rule, we have adopted all of the additional NCPDP SCRIPT standard version 2017071 transactions that CMS adopted in 42 CFR 423.160(b)(2)(iv). Furthermore, we have adopted the same electronic Prior Authorization (ePA) request and response transactions supported by NCPDP SCRIPT standard 2017071 proposed by CMS in the Medicare Program; Secure Electronic Prior Authorization for Medicare Part D proposed rule (84 FR 28450). Some adopted transactions are required to demonstrate conformance to the updated § 170.315(b)(3) criterion, while other transactions are optional.</P>
                    <HD SOURCE="HD3">c. Clinical Quality Measures—Report</HD>
                    <P>
                        In this final rule, we have removed the Health Level 7 (HL7®) Quality Reporting Document Architecture (QRDA) standard requirements in the 2015 Edition “Clinical Quality Measures—report” criterion in § 170.315(c)(3) and, in their place, required Health IT Modules to support the CMS QRDA Implementation Guide (IGs).
                        <SU>2</SU>
                        <FTREF/>
                         This will help reduce the burden for health IT developers and remove certification requirements that do not support quality reporting for CMS programs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>2</SU>
                             
                            <E T="03">https://ecqi.healthit.gov/qrda-quality-reporting-document-architecture.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Electronic Health Information (EHI) Export</HD>
                    <P>We proposed to adopt a new 2015 Edition certification criterion, referred to as “EHI export” in § 170.315(b)(10) in the Proposed Rule. The criterion's proposed conformance requirements were intended to provide a means to export the entire EHI a certified health IT product produced and electronically managed to support two contexts: (1) Single patient EHI export and (2) for patient EHI export when a health care provider is switching health IT systems. The proposals did not require the exported data to be in a specific standardized format. Rather, we proposed to require that such an export be in a computable, electronic format made available via a publicly accessible hyperlink. We noted that this transparency would facilitate the subsequent interpretation and use of the exported information.</P>
                    <P>We have finalized the criterion with modifications in response to public comment. We have refined the scope of data a Health IT Module certified to § 170.315(b)(10) must export, and aligned the criterion to the definition of EHI we finalized in § 170.102 and § 171.102. The finalized criterion requires a certified Health IT Module to electronically export all of the EHI, as defined in § 171.102, that can be stored at the time of certification by the product, of which the Health IT Module is a part. We finalized the 2015 Edition Cures Update “EHI export” criterion in § 170.315(b)(10) but did not finalize its inclusion in the 2015 Edition Base Electronic Health Record (EHR) definition, as proposed. Our intention with this criterion, in combination with other criteria set forth in this final rule, is to advance the interoperability of health IT as defined in section 4003 the Cures Act, including the “complete access, exchange, and use of all electronically accessible health information.”</P>
                    <HD SOURCE="HD3">e. Application Programming Interfaces (APIs)</HD>
                    <P>We have adopted a new API certification criterion in §  170.315(g)(10) to replace the “application access—data category request” certification criterion (§  170.315(g)(8)), and added it to the updated 2015 Edition Base EHR definition. This new “standardized API for patient and population services” certification criterion focuses on supporting two types of API-enabled services: (1) Services for which a single patient's data is the focus and (2) services for which multiple patients' data are the focus. The API certification criterion requires the use of the Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standard Release 4 and references several standards and implementation specifications adopted in §  170.213 and §  170.215 to support standardization and interoperability. This certification criterion will align industry efforts around FHIR Release 4 and advance interoperability of API-enabled “read” services for single and multiple patients.</P>
                    <HD SOURCE="HD3">f. Privacy and Security Transparency Attestations</HD>
                    <P>We have adopted two new privacy and security certification criteria requiring transparency attestations from developers of certified health IT as part of the updated 2015 Edition privacy and security certification framework. The attestations will serve to identify whether or not certified health IT supports encrypting authentication credentials and/or multi-factor authentication (MFA). While these criteria provide increased transparency, they do not require new development or implementation to take place. As part of ONC's ongoing commitment to advance transparency about certified health IT products, ONC will list the developers' attestation responses on the Certified Health IT Product List (CHPL).</P>
                    <HD SOURCE="HD3">g. Security Tags and Consent Management</HD>
                    <P>In the 2015 Edition final rule (80 FR 62646, Oct. 16, 2015), we adopted two “data segmentation for privacy” (DS4P) certification criteria, one for creating a summary record according to the DS4P standard (§ 170.315(b)(7)) and one for receiving a summary record according to the DS4P standard (§ 170.315(b)(8)). Certification to these 2015 Edition DS4P criteria only required security tagging of Consolidated-Clinical Document Architecture (C-CDA) documents at the document level. As noted in the 2015 Edition final rule (80 FR 62646), certification to these criteria is not linked to meeting the Certified EHR Technology definition (CEHRT) used in CMS programs.</P>
                    <P>
                        Since the 2015 Edition final rule, the health care industry has engaged in additional field testing and implementation of the DS4P standard. Stakeholders also shared with ONC—through public forums, listening sessions, and correspondence—that only 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. Based on public comment, in this final rule, we 
                        <PRTPAGE P="25646"/>
                        have changed the names of the two current 2015 Edition DS4P criteria to Security tags—Summary of Care (send) and Security tags—Summary of Care (receive). We also updated the requirements for these criteria to support security tagging at the document, section, and entry levels. This change better reflects the purpose of these criteria and enables adopters to support a more granular approach to security tagging clinical documents for exchange.
                    </P>
                    <P>In finalizing this more granular approach for security tagging Consolidated Clinical Document Architecture (C-CDA) documents, we note that we do not specify rules or requirements for the disposition of tagged data or any requirements on health care providers related to data segmentation for privacy. The use cases for which health IT certified to these criteria might be implemented would be driven by other applicable Federal, State, local, or tribal law and are outside the scope of the certification criteria. We recognize that the tagging of documents is not a fully automated segmentation of the record but rather a first, technological step or tool to support health IT developers implementing technology solutions for health care providers to replace burdensome manual processes for tagging sensitive information.</P>
                    <P>We also proposed to adopt a new 2015 Edition certification criterion, “consent management for APIs” in § 170.315(g)(11), to support data segmentation and consent management through an API in accordance with the Consent Implementation Guide (IG). However, in response to comments, we have chosen not to finalize our proposal for this criterion at this time.</P>
                    <HD SOURCE="HD3">3. Modifications to the ONC Health IT Certification Program</HD>
                    <P>In this final rule, we have finalized corrections to the 2015 Edition privacy and security certification framework (80 FR 62705) and relevant regulatory provisions. We also have finalized corrections to the relevant current Certification Companion Guides (CCGs). We have adopted new and revised Principles of Proper Conduct (PoPC) for ONC-ACBs. We have finalized clarification that the records retention provision includes the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules. We also have finalized revisions to the PoPC in § 170.523(h) to clarify the basis for certification, including to permit a certification decision to be based on an evaluation conducted by the ONC-ACB for Health IT Modules' compliance with certification criteria by use of conformity methods approved by the National Coordinator for Health Information Technology (National Coordinator). We also have finalized the addition of § 170.523(r) to require ONC-ACBs to accept test results from any ONC-Authorized Testing Laboratory (ONC-ATL) in good standing under the Program and compliant with the ISO/IEC 17025 accreditation requirements consistent with the requirements set forth in §§ 170.520(b)(3) and 170.524(a). We believe these new and revised PoPC provide necessary clarifications for ONC-ACBs and promote stability among the ONC-ACBs. We also have finalized the update of § 170.523(k) to broaden the requirements beyond just the Medicare and Medicaid EHR Incentive Programs (now renamed the Promoting Interoperability (PI) Programs and referenced as such hereafter) and provided other necessary clarifications.</P>
                    <P>We have finalized a revised PoPC for ONC-ATLs. The finalized revision clarifies that the records retention provision includes the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules.</P>
                    <HD SOURCE="HD3">4. Health IT for the Care Continuum</HD>
                    <P>Section 4001(b) of the Cures Act includes two provisions related to supporting health IT across the care continuum. The first instructs the National Coordinator to encourage, keep, or recognize through existing authorities the voluntary certification of health IT for use in medical specialties and sites of service where more technological advancement or integration is needed. The second outlines a provision related to the voluntary certification of health IT for use by pediatric health providers to support the health care of children. These provisions align closely with our core purpose to promote interoperability and to support care coordination, patient engagement, and health care quality improvement initiatives. Advancing health IT that promotes and supports patient care when and where it is needed continues to be a primary goal of the Program. This means health IT should support patient populations, specialized care, transitions of care, and practice settings across the care continuum.</P>
                    <P>
                        We have explored how we might work with the health IT industry and with specialty organizations to collaboratively develop and promote health IT that supports medical specialties and sites of service. Over time, we have taken steps to make the Program modular, more open and accessible to different types of health IT, and better able to advance functionality that is generally applicable to a variety of care and practice settings. We considered a wide range of factors specific to the provisions in the Cures Act to support providers of health care for children. These include: The evolution of health IT across the care continuum, the costs and benefits associated with health IT, the potential regulatory burden and compliance timelines, and the need to help advance health IT that benefits multiple medical specialties and sites of service involved in the care of children. In consideration of these factors, and to advance implementation of section 4001(b) of the Cures Act specific to pediatric care, we held a listening session where stakeholders could share their clinical knowledge and technical expertise in pediatric care and pediatric sites of service. Through the information learned at this listening session and our analysis of the health IT landscape for pediatric settings, we identified existing 2015 Edition criteria, as well as new or revised 2015 Edition criteria proposed in the Proposed Rule, that could benefit providers of pediatric care and pediatric settings. In this final rule, we have identified the already existing 2015 Edition certification criteria and the new or revised 2015 Edition criteria adopted in this final rule that support the voluntary certification of health IT for pediatric care and pediatric settings. We also elaborate on our next steps to support pediatric care and pediatric settings through the development, adoption, certification, and use of health IT, including the continued support of a pediatrics health IT web page on 
                        <E T="03">www.healthit.gov/pediatrics</E>
                         and the future development of informational resources.
                    </P>
                    <P>
                        We also recognize the significance of the opioid epidemic confronting our nation and the importance of helping to support the health IT needs of health care providers committed to preventing inappropriate access to prescription opioids and to providing safe, appropriate treatment. Therefore, we requested public comment on how our existing Program requirements and the proposals in the Proposed Rule may support use cases related to Opioid Use Disorder (OUD) prevention and treatment and if there were additional areas that we should consider for effective implementation of health IT to help address OUD prevention and treatment. We received over 100 
                        <PRTPAGE P="25647"/>
                        comments in responses to this RFI, which we are actively reviewing.
                    </P>
                    <HD SOURCE="HD3">5. Conditions and Maintenance of Certification Requirements</HD>
                    <P>We have established in this final rule, certain Conditions and Maintenance of Certification requirements for health IT developers based on the Conditions and Maintenance of Certification requirements outlined in section 4002 of the Cures Act. The Program's Conditions and Maintenance of Certification requirements express initial requirements for health IT developers and their certified Health IT Module(s) as well as ongoing requirements that must be met by both health IT developers and their certified Health IT Module(s) under the Program. In this regard, we have implemented the Cures Act Conditions of Certification requirements with further specificity as it applies to the Program and implemented any accompanying Maintenance of Certification requirements as standalone requirements to ensure that the Conditions of Certification requirements are not only met but continually being met through the Maintenance of Certification requirements. In this rule, we capitalize “Conditions of Certification” and “Maintenance of Certification” when referring to Conditions and Maintenance of Certification requirements established for the Program under section 4002 of the Cures Act for ease of reference and to distinguish from other conditions.</P>
                    <HD SOURCE="HD3">Information Blocking</HD>
                    <P>Section 4002 of the Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, not take any action that constitutes information blocking as defined in section 3022(a) of the Public Health Service Act (PHSA). We have adopted the information blocking Condition of Certification requirement in § 170.401 as proposed. As finalized, the Condition of Certification requirement prohibits any health IT developer under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA. We have also finalized that definition in § 171.103.</P>
                    <HD SOURCE="HD3">Assurances</HD>
                    <P>Section 4002 of the Cures Act also requires that a health IT developer, as a Condition of Certification requirement under the Program, provide assurances to the Secretary that, unless for legitimate purpose(s) as specified by the Secretary, the developer 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. We have finalized our proposed implementation of this provision through several Conditions of Certification and accompanying Maintenance of Certification requirements, which are set forth in § 170.402. We have also adopted more specific Conditions and Maintenance of Certification requirements, which are also set forth in § 170.402, for certified health IT developers to provide assurances to the Secretary that it does not take any other action that may inhibit the appropriate exchange, access, and use of EHI. These requirements serve to provide further clarity under the Program as to how health IT developers must meet our requirements as promulgated under the Cures Act.</P>
                    <HD SOURCE="HD3">Communications</HD>
                    <P>The Cures Act also requires as a Condition and Maintenance of Certification requirement under the Program that health IT developers do not prohibit or restrict communications about certain aspects of the performance of health IT and the developers' related business practices. We have finalized (in § 170.403) provisions that permit developers to impose certain types of limited prohibitions and restrictions that strike a balance between the need to promote open communication about health IT, and related developer business practices, with the need to protect the legitimate business interests of health IT developers and others. The provisions identify certain narrowly-defined types of communications, such as communications required by law, made to a government agency, or made to a defined category of safety organization, which will receive “unqualified protection” under our Program. Under this policy, developers will be prohibited from imposing any prohibitions or restrictions on such protected communications. Based on public comment received, we have also finalized provisions that allow health IT developers certified under the Program to place limitations on certain types of communications, including screenshots and video.</P>
                    <P>We have adopted Maintenance of Certification requirements proposed in § 170.403(b) with modifications. A health IT developer must not impose or enforce any contractual requirement that contravenes the requirements of this Condition of Certification. Furthermore, if a health IT developer has contracts/agreements in existence that contravene the requirements of this Condition of Certification, the developer must notify all affected customers, other persons, or entities that the prohibition or restriction within the contract/agreement will not be enforced by the health IT developer. In response to comments, we have finalized in § 170.403(b)(2)(ii) that health IT developers are required to amend their contracts/agreements to remove or make void such provisions only when the contracts/agreements are next modified for other purposes and not within the proposed period of time from the effective date of this final rule.</P>
                    <HD SOURCE="HD3">Application Programming Interfaces (APIs)</HD>
                    <P>As a Condition of Certification requirement in section 4002 of the Cures Act requires health IT developers to publish 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 Cures Act's API Condition of Certification requirement in section 4002 includes several key phrases and requirements for health IT developers that go beyond the technical functionality of the Health IT Modules they present for certification. This final rule captures both the technical functionality and behaviors necessary to implement the Cures Act API Condition of Certification requirement. Specifically, we have adopted new standards, new implementation specifications, a new certification criterion, and have modified the Base EHR definition. In addition, we have finalized detailed Condition and Maintenance of Certification requirements for health IT developers.</P>
                    <HD SOURCE="HD3">Real World Testing</HD>
                    <P>
                        The Cures Act also added a new Condition and Maintenance of Certification requirement that health IT developers must successfully test the real world use of health IT for interoperability in the type(s) of setting(s) in which such technology would be marketed. This provision is critical to advancing transparency regarding Health IT Modules' performance and to users having information that could be crucial to 
                        <PRTPAGE P="25648"/>
                        their decisions to acquire certified health IT.
                    </P>
                    <P>As discussed in section VII.B.5 of this final rule, we have established in § 170.405 real world testing Condition and Maintenance of Certification requirements that include Maintenance of Certification requirements to update Health IT Modules certified to certain certification criteria (see § 170.405(b)(3) through (7) and section IV.B of this final rule preamble) to ensure this certified technology meets its users' needs for widespread and continued interoperability.</P>
                    <P>
                        As finalized, real world testing Condition and Maintenance of Certification requirements apply to health IT developers with one or more Health IT Module(s) certified to specific certification criteria focused on interoperability and data exchange that are listed in § 170.405(a), as discussed in section VII.B.5 of this final rule. Under these Condition and Maintenance of Certification requirements, health IT developers must submit publicly available annual real world testing plans as well as annual real world testing results for health IT certified to the criteria identified in § 170.405(a). We have also finalized a flexibility that we have named the Standards Version Advancement Process (SVAP). Under this flexibility, health IT developers will have the option to update their health IT that is certified to the criteria identified in § 170.405(a) to use more advanced version(s) of the adopted standard(s) or implementation specification(s) included in the criteria, provided such versions are approved by the National Coordinator for use in health IT certified under the Program. Similarly, we have finalized our proposal (84 FR 7497 through 7500) that health IT developers presenting health IT for initial certification to one of the criteria listed in § 170.405(a) would have the option to certify to National Coordinator-approved newer version(s) of one or more of the Secretary-adopted standards or implementation specifications applicable to the criterion. All health IT developers voluntarily opting to avail themselves of the SVAP flexibility must 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. In addition, we have finalized in § 170.405(b)(8)(i) the requirement that health IT developers with existing certifications to criteria listed in § 170.405(a) who wish to avail themselves of the SVAP flexibility must notify both their ONC-ACB and their affected customers of their plans to update their certified health IT, and the update's anticipated impact on their existing certified health IT and customers, specifically including but not limited to whether, and if so for how long, the health IT developer intends to continue supporting the prior version(s) 
                        <SU>3</SU>
                        <FTREF/>
                         of the standard(s) to which the Health IT Module has already been certified, in addition to the National Coordinator-approved newer version(s) included in a planned update.
                    </P>
                    <FTNT>
                        <P>
                            <SU>3</SU>
                             In the near term, many of these prior versions are likely to be the same versions adopted by the Secretary and incorporated by reference in subpart B of 45 CFR part 170. Over time, however, we anticipate increasing frequency of prior versions certified including National Coordinator-approved newer versions of these Secretary-adopted standards.
                        </P>
                    </FTNT>
                    <P>
                        We have finalized our proposal (84 FR 7501) to establish in § 170.523(p) a new PoPC for ONC-ACBs that requires ONC-ACBs to review and confirm that each health IT developer with one or more Health IT Module(s) certified to any one or more of the criteria listed in § 170.405(a) submits real world testing plans and real world results on a timeframe that allows for the ONC-ACB to confirm completeness of all plans and results by applicable annual due dates. The specific annual due dates finalized in § 170.523(p) differ from those proposed as, and for the reasons, discussed in section VII.B.5 of this final rule preamble. Once completeness is confirmed, ONC-ACBs must make the plans available to ONC and the public via the Certified Health IT Product List (CHPL).
                        <SU>4</SU>
                        <FTREF/>
                         We have also finalized, with clarifying revisions, the PoPC proposed in § 170.523(m) to require ONC-ACBs to aggregate and report to ONC no less than quarterly all updates successfully made to support National Coordinator-approved newer versions of Secretary-adopted standards in certified health IT pursuant to the developers having voluntarily opted to avail themselves of the SVAP flexibility. We also finalize in § 170.523(t) the new PoPC for ONC-ACBs that requires them to ensure that developers seeking to take advantage of the SVAP flexibility provide the advance notice required in § 170.405(b)(8) to all affected customers and its ONC-ACB, and comply with all other applicable requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>4</SU>
                             Although real world testing plans and results will not be immediately available upon publication of this final rule, an overview of the CHPL is available at 
                            <E T="03">https://chpl.healthit.gov/#/resources/overview</E>
                             (last accessed 07/12/2019). For additional information on how to navigate the CHPL, please refer to the 
                            <E T="03">CHPL Public User Guide</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Attestations</HD>
                    <P>
                        Section 4002(a) of the Cures Act requires that a health IT developer, as Condition and Maintenance of Certification requirements under the Program, provide to the Secretary an attestation to all of the other Conditions of Certification required in section 3001(c)(5)(D) of the PHSA, except for the “EHR reporting criteria submission” Condition of Certification requirement in § 3001(c)(5)(D)(vii). We have finalized regulation text implementing the Cures Act's “attestations” Condition of Certification requirement in § 170.406. Under § 170.406 as finalized by this rule, health IT developers will attest twice a year to compliance with the Conditions and Maintenance of Certification requirements (except for the EHR reporting criteria submission requirement, which would be metrics reporting requirements separately implemented through a future rulemaking). We believe requiring attestations every six months under § 170.406(b) will properly balance the need to support appropriate enforcement with our desire to limit the burden on health IT developers. In this regard, we have also identified methods to make the process as simple and efficient for health IT developers as possible (
                        <E T="03">e.g.,</E>
                         30-day attestation window, web-based form submissions, and attestation alert reminders).
                    </P>
                    <P>We have also finalized that attestations will be submitted to ONC-ACBs. We have finalized a new PoPC in § 170.523(q) that an ONC-ACB must review these submissions for completion and share the health IT developers' attestations with us. We would then make the attestations publicly available through the CHPL.</P>
                    <HD SOURCE="HD3">EHR Reporting Criteria Submission</HD>
                    <P>The Cures Act specifies that health IT developers be required, as Condition and Maintenance of Certification requirements under the Program, to submit reporting criteria on certified health IT in accordance with the EHR Reporting Program established under section 3009A of the PHSA, as added by the Cures Act. We have not yet established an EHR Reporting Program. Once we establish such program, we will undertake rulemaking to propose and implement the associated Condition and Maintenance of Certification requirements for health IT developers.</P>
                    <HD SOURCE="HD3">Enforcement</HD>
                    <P>
                        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 expands the current focus of the 
                        <PRTPAGE P="25649"/>
                        Program requirements beyond the certified health IT itself. Equally important, Cures Act section 4002(a) also provides that the Secretary may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. We, therefore, have finalized our proposed 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 have finalized our proposed corrective action process 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 have also finalized in §§ 170.580 and 170.581 our proposal to utilize, with minor modifications, the processes previously established for ONC direct review of certified health IT in the enforcement of the Conditions and Maintenance of Certification requirements. Where we identify noncompliance, our first priority will be to work with the health IT developer to remedy the matter through a corrective action process. However, under certain circumstances, ONC may ban a health IT developer from the Program and/or terminate the certification of one or more of its Health IT Modules.
                    </P>
                    <HD SOURCE="HD3">6. Information Blocking</HD>
                    <P>Section 4004 of the Cures Act added section 3022 of the PHSA (42 U.S.C. 300jj-52, “the information blocking provision”). Section 3022(a)(1) of the PHSA defines practices that constitute information blocking when engaged in by a health care provider, or a health information technology developer, exchange, or network. Section 3022(a)(3) authorizes the Secretary to identify, through notice and comment rulemaking, reasonable and necessary activities that do not constitute information blocking for purposes of the definition set forth in section 3022(a)(1).</P>
                    <P>We identify eight reasonable and necessary activities as exceptions to the information blocking definition, each of which does not constitute information blocking for purposes of section 3022(a)(1) of the PHSA. The exceptions apply to certain activities that are likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI, but that would be reasonable and necessary if certain conditions are met.</P>
                    <P>
                        In developing and finalizing the final exceptions, we were guided by three overarching policy considerations. First, the exceptions are limited to certain activities that we believe are important to the successful functioning of the U.S. health care system, including promoting public confidence in health IT infrastructure by supporting the privacy and security of EHI, and protecting patient safety and promoting competition and innovation in health IT and its use to provide health care services to consumers. Second, each exception is intended to address a significant risk that regulated individuals and entities (
                        <E T="03">i.e.,</E>
                         health care providers, health IT developers of certified health IT, health information networks, and health information exchanges) will not engage in these reasonable and necessary activities because of potential uncertainty regarding whether they would be considered information blocking. Third, and last, each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to exempt.
                    </P>
                    <P>The eight exceptions are set forth in section VIII.D of this final rule. The five exceptions finalized in §§ 171.201-205, and discussed in section VIII.D.1.a-e of this final rule, involve not fulfilling requests to access, exchange, or use EHI. These exceptions are intended to prevent harm and protect patient safety, promote the privacy and security of EHI, excuse an actor from responding to requests that are infeasible, and address activities that are reasonable and necessary to promote the performance of health IT. The three exceptions finalized in §§ 171.301-303, and discussed in section VIII.D.2.a-c of this final rule, involve procedures for fulfilling requests to access, exchange, or use EHI. These exceptions describe when an actor's practice of limiting the content of its response to or the manner in which it responds to a request to access, exchange, or use EHI will not be considered information blocking; when an actor's practice of charging fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using EHI will not be considered information blocking; and when an actor's practice to license interoperability elements for EHI to be accessed, exchanged, or used will not be considered information blocking.</P>
                    <P>
                        An actor will not be subject to enforcement actions under the information blocking provision for civil monetary penalties (CMP) or appropriate disincentives if the actor's practice satisfies at least one exception. In order to satisfy an exception, each relevant practice by an actor at all relevant times must meet all of the applicable conditions of the exception. However, failure to meet the conditions of an exception does not automatically mean a practice constitutes information blocking. A practice failing to meet all conditions of an exception only means that the practice would not have guaranteed protection from CMPs or appropriate disincentives. The practice would instead be evaluated on a case-by-case basis to assess the specific facts and circumstances (
                        <E T="03">e.g.,</E>
                         whether the practice would be considered to rise to the level of an interference, and whether the actor acted with the requisite intent) to determine whether information blocking has occurred.
                    </P>
                    <P>In addition to establishing the exceptions, we have defined and interpreted terms that are present in section 3022 of the PHSA (such as the types of individuals and entities covered by the information blocking provision). We have also finalized new terms and definitions that are necessary to implement the information blocking provision. We have codified the information blocking section in a new part of title 45 of the Code of Federal Regulations, part 171.</P>
                    <HD SOURCE="HD2">C. Costs and Benefits</HD>
                    <P>Executive Orders 12866 on Regulatory Planning and Review (September 30, 1993), and 13563 on Improving Regulation and Regulatory Review (February 2, 2011), 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). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). OMB has determined that this final rule is an economically significant rule as the costs associated with this final rule could be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of this final rule.</P>
                    <P>
                        We have estimated the potential monetary costs and benefits of this final rule for health IT developers, health care providers, patients, ONC-ACBs, ONC-ATLs, and the Federal Government (
                        <E T="03">i.e.,</E>
                         ONC), and have broken those costs and benefits out into the following categories: (1) Deregulatory actions (no associated costs); (2) updates to the 2015 Edition health IT certification criteria; (3) Conditions and Maintenance of Certification requirements for a health 
                        <PRTPAGE P="25650"/>
                        IT developer; (4) oversight for the Conditions and Maintenance of Certification requirements; and (5) information blocking.
                    </P>
                    <P>We note that we have rounded all estimates to the nearest dollar and all estimates are expressed in 2017 dollars as it is the most recent data available to address all cost and benefit estimates consistently. We also note that we did not have adequate data to quantify some of the costs and benefits within this RIA. In those situations, we have described the non-quantified costs and benefits of our provisions; however, such costs and benefits have not been accounted for in the monetary cost and benefit totals below.</P>
                    <P>We estimated that the total cost for this final rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would, on average, range from $953 million to $2.6 billion with an average annual cost of $1.8 billion. We estimate that the total perpetual cost for this final rule (starting in year two), based on the cost estimates outlined above, would, on average, range from $366 million to $1.3 billion with an average annual cost of $840 million.</P>
                    <P>We estimated the total annual benefit for this final rule, based on the benefit estimates outlined above, would range from $1.2 billion to $5.0 billion with primary estimated annual benefit of $3.1 billion.</P>
                    <HD SOURCE="HD1">II. Background</HD>
                    <HD SOURCE="HD2">A. Statutory Basis</HD>
                    <P>The Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (the Recovery Act) (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 health care quality, safety, and efficiency through the promotion of health IT and electronic health information (EHI) exchange.</P>
                    <P>The 21st Century Cures Act (hereinafter the “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, Pub. L. 114-255, included Title IV—Delivery, which amended portions of the HITECH Act (Title XIII of Division A of Pub. L. 111-5) by modifying or adding certain provisions to the PHSA relating to health IT.</P>
                    <HD SOURCE="HD3">1. Standards, Implementation Specifications, and Certification Criteria</HD>
                    <P>The HITECH Act established two new Federal advisory committees, the HIT Policy Committee (HITPC) and the HIT 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 3002 of the PHSA, as amended by section 4003(e) of the Cures Act, replaced the HITPC and HITSC with one committee, the Health Information Technology Advisory Committee (HIT Advisory Committee or HITAC). After that change, section 3002(a) of the PHSA established that the HITAC would advise and recommend 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. Further described in section 3002(b)(1)(A) of the PHSA, this included providing the National Coordinator with recommendations on a policy framework to advance interoperable health IT infrastructure, updating recommendations to the policy framework, and making new recommendations, as appropriate. Section 3002(b)(2)(A) identified that in general, the HITAC would recommend to the National Coordinator, for purposes of adoption under section 3004 of the PHSA, standards, implementation specifications, and certification criteria and an order of priority for the development, harmonization, and recognition of such standards, specifications, and certification criteria. Similar to the process previously required of the former HITPC and HITSC, the HITAC will develop a schedule for the assessment of policy recommendations for the Secretary to publish in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                    <P>
                        Section 3004 of the PHSA identifies 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 any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all determinations in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                    <P>Section 3004(b)(3) of the PHSA, which is 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 continue to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria.</P>
                    <HD SOURCE="HD3">2. Health IT Certification Program(s)</HD>
                    <P>
                        Under the HITECH Act, section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a program or programs for the voluntary certification of health IT. Specifically, 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 this subtitle (
                        <E T="03">i.e.,</E>
                         certification criteria adopted by the Secretary 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. Overall, section 13201(b) of the HITECH Act requires that with respect to the development of standards and implementation specifications, the Director of National Institute of Standards and Technology (NIST) shall support the establishment of a conformance testing infrastructure, including the development of technical test beds. The same HITECH Act provision (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 4001 of the Cures Act amended section 3001(c)(5) of the PHSA to instruct the National Coordinator to encourage, keep, or recognize, through 
                        <PRTPAGE P="25651"/>
                        existing authorities, the voluntary certification of health IT under the program for use in medical specialties and sites of service for which no such technology is available or where more technological advancement or integration is needed. Section 3001(c)(5)(C)(iii) in particular identifies that the Secretary, in consultation with relevant stakeholders, shall make recommendations for the voluntary certification of health IT for use by pediatric health providers to support the care of children, as well as adopt certification criteria under section 3004 to support the voluntary certification of health IT for use by pediatric health providers. The Cures Act further amended section 3001(c)(5) of the PHSA by adding section 3001(c)(5)(D), which provides the Secretary with the authority to require, through notice and comment rulemaking, Conditions and Maintenance of Certification requirements for the Program.
                    </P>
                    <HD SOURCE="HD2">B. Regulatory History</HD>
                    <P>The Secretary issued an interim final rule with request for comments on January 13, 2010, (75 FR 2014), which adopted an initial set of standards, implementation specifications, and certification criteria. On March 10, 2010, we published a proposed rule (75 FR 11328) that proposed both a temporary and permanent certification program for the purposes of testing and certifying health IT. A final rule establishing the temporary certification program was published on June 24, 2010, (75 FR 36158), and a final rule establishing the permanent certification program was published on January 7, 2011, (76 FR 1262). We have issued multiple rulemakings since these initial rulemakings to update standards, implementation specifications, certification criteria, and the certification program, a history of which can be found in the October 16, 2015 final rule titled, “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”). A final rule corrections and clarifications notice was published for the 2015 Edition final rule on December 11, 2015, (80 FR 76868), to correct preamble and regulatory text errors and clarify requirements of the Common Clinical Data Set (CCDS), the 2015 Edition privacy and security certification framework, and the mandatory disclosures for health IT developers.</P>
                    <P>
                        The 2015 Edition final rule established a new edition of certification criteria (“2015 Edition health IT certification criteria” or “2015 Edition”) and a new 2015 Edition Base EHR definition. The 2015 Edition established the capabilities and specified the related standards and implementation specifications that CEHRT would need to include to, at a minimum, support the achievement of “meaningful use” by eligible clinicians, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs) (now referred to as the Promoting Interoperability (PI) Programs) 
                        <SU>5</SU>
                        <FTREF/>
                         when the 2015 Edition is required for use under these and other programs referencing the CEHRT definition. The 2015 Edition final rule also made changes to the ONC HIT Certification Program. The final rule 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 PoPC for ONC-ACBs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>5</SU>
                             
                            <E T="03">https://www.federalregister.gov/d/2018-16766/p-4.</E>
                        </P>
                    </FTNT>
                    <P>After issuing a proposed rule on March 2, 2016, (81 FR 11056), we published a final rule titled, “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (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 sets forth processes for us to authorize and oversee accredited testing laboratories under the Program. In addition, it includes 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) (“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 and is the subject of this final rule.</P>
                    <HD SOURCE="HD2">C. General Comments on the Proposed Rule</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters expressed support for the overall direction of the Proposed Rule. Numerous commenters also expressed support for the policy goals expressed in the Proposed Rule, including: Reduced health care costs; improved public health surveillance; improved care coordination, continuity of care, and shared access of data between patient and provider; improved quality and patient safety; increased cost and quality transparency; greater efficiencies; and better health outcomes for patients. A few commenters also commended our interest in ways to use health IT to address opioid use disorders. Many commenters also appreciated detailed context for the provisions in the Proposed Rule. Many commenters stated that the proposed provisions and standards will provide opportunities for innovation as well as increase the ability of health care providers to connect new tools and services to their systems.
                    </P>
                    <P>A number of commenters commended our responsiveness to the health care community, including patients, in drafting the rule. A few commenters suggested that the existing language in the rule should remain mostly unchanged as ONC drafts the final rule. Many commenters commended us for collaborating with public- and private-sector partners in developing the Proposed Rule. Specifically, some commenters expressed appreciation for our work with CMS and their companion Interoperability and Patient Access Proposed Rule. A number of commenters shared that they look forward to working with us and CMS as the health care industry progresses toward an interoperable system, making it easier for small independent practices and providers to move to value-based care.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters. This final rule maintains the direction of the Proposed Rule, and we too look forward to ongoing collaboration with public and private sector partners as we implement the provisions of this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters recommended that the final rule include additional resources to assist with readability and ease of understanding.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. As we did with the 
                        <PRTPAGE P="25652"/>
                        Proposed Rule, we are providing resources such as infographics, fact sheets, webinars, and other forms of educational materials and outreach. Many of the education materials can be found on 
                        <E T="03">www.HealthIT.gov/curesrule.</E>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed the opinion that the use of EHRs—and health IT, more generally—has negatively affected the quality of health care delivery and that the Proposed Rule will exacerbate this issue. Some of these commenters stated that the need to input information into EHRs during office visits has resulted in clinicians spending less time communicating with patients, and some noted the impact of data entry on clinician burnout. A few commenters made a similar point that use of EHRs has reduced productivity and, as a result, increased health care spending.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We are aware of the challenges stakeholders have experienced in using EHRs and health IT more broadly. In the Cures Act, Congress identified the importance of easing regulatory and administrative burdens associated with the use of EHRs and health IT. Specifically, through section 4001(a) of the Cures Act, Congress directed the Department of Health and Human Services to establish a goal, develop a strategy, and provide recommendations to reduce EHR-related burdens that affect care delivery.
                    </P>
                    <P>
                        To that end, on November 28, 2018, we, in partnership with CMS, released a draft 
                        <E T="03">Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs</E>
                         
                        <SU>6</SU>
                        <FTREF/>
                         for public comment. This draft strategy reflects input HHS received through several wide-reaching listening sessions, written input, and stakeholder outreach. We released the final report on February 21, 2020. Reflective of public comment, the final 
                        <E T="03">Strategy on Reducing Regulatory and Administrative Burdens Relating to the Use of Health IT and EHRs</E>
                         
                        <SU>7</SU>
                        <FTREF/>
                         targets burdens tied to regulatory and administrative requirements that HHS can directly impact through the rulemaking process. The report's strategies, recommendations, and policy shifts aim to give clinicians more time to focus on what matters—caring for their patients. Based on stakeholder input, the final strategy outlines three overarching goals designed to reduce clinician burden: (1) Reduce the effort and time required to record health information in EHRs for clinicians; (2) reduce the effort and time required to meet regulatory reporting requirements for clinicians, hospitals, and health care organizations; and (3) improve the functionality and intuitiveness (ease of use) of EHRs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2018-11/Draft%20Strategy%20on%20Reducing%20Regulatory%20and%20Administrative%20Burden%20Relating.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>7</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>In addition to the final strategy mentioned above, we refer readers to section III of this final rule, Deregulatory Actions for Previous Rulemakings, for more information on how we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility to both health IT developers and providers, and support innovation.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments from a variety of stakeholders to extend the 60-day comment period for the Proposed Rule, stating that due to the depth and complexity of the policies proposed, it would be critical for the public to have extended time to provide sufficient and thoughtful comments to advance shared goals and shape the interoperability landscape.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In response to stakeholder inquiries to extend the 60-day public comment period and based on the stated goals of the Proposed Rule to improve interoperability and patient access to health information for the purposes of promoting competition and better care, we extended the comment period for the Proposed Rule for an additional 30 days which ended on June 3, 2019.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters recommended delaying the final rule by issuing an Interim Final Rule (IFR) with comment. Commenters noted that many organizations are providing comments that include new information blocking exceptions and that we will not be able to incorporate such suggestions into the final rule without an opportunity for comment. Several commenters stated that an IFR was appropriate due to the significance and breadth of the Proposed Rule, as well the magnitude of changes proposed and that an IFR would allow for additional opportunity for stakeholder comment.
                    </P>
                    <P>Several commenters recommended that ONC consider issuing a Supplemental Notice of Proposed Rulemaking (SNPRM) to seek additional comments on the information blocking provisions. Some of these commenters stated that new definitions and terms introduced in the Proposed Rule need additional clarification and an SNPRM would enable ONC to propose such clarifications and seek feedback on modified proposals.</P>
                    <P>
                        <E T="03">Response.</E>
                         We recognize the importance of allowing enough time for comment given the breadth of the Proposed Rule and acknowledge the comments requesting the issuance of an IFR or a SNPRM. We believe that the advance posting of the Proposed Rule on the ONC website, the initial 60-day comment period, and the 30-day extension, provided adequate time for comment, especially given the large volume of comments received.
                    </P>
                    <P>
                        As discussed in the information blocking section of the Proposed Rule (84 FR 7508), after hearing from stakeholders and based on our findings from our 2015 Report to Congress,
                        <SU>8</SU>
                        <FTREF/>
                         we concluded that information blocking is a serious problem and recommended that Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices. Congress responded by enacting the Cures Act on December 13, 2016, with many provisions specifying a need for swift implementation. It has been three years since the Cures Act was enacted and information blocking remains a serious concern. This final rule includes provisions that will address information blocking and cannot be further delayed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>8</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We have taken multiple actions to address some expressed concerns regarding the timing of the Conditions and Maintenance of Certification requirements as well as the comprehensiveness of the information blocking proposals. These actions include some burden reduction by removing certain certification criteria, narrowing the scope of certain certification criteria, and increasing the compliance timeline with criteria. For purposes of information blocking, we have established compliance date for 45 CFR part 171 that is six months, rather than sixty days, after the date this final rule publishes in the 
                        <E T="04">Federal Register</E>
                        . We have also focused the scope of EHI, and provided new and revised exceptions that are actionable and reduce burden. One of these new exceptions (see § 171.301(a) and section VIII.D.2.a of this final rule) includes a provision by which, until 24 months after this rule is published in the 
                        <E T="04">Federal Register</E>
                        , an actor's conduct can satisfy the conditions of the Content and Manner Exception (§ 171.301) if they provide at least the content that is within the USCDI in response to a request for access, exchange, or use of EHI. Because of these reasons and those noted above, we decline to issue an IFR or SNPRM. Rather, we have issued this final rule to support interoperability, empower patient control of their health care, and instill competition in health care markets.
                        <PRTPAGE P="25653"/>
                    </P>
                    <HD SOURCE="HD1">III. Deregulatory Actions for Previous Rulemakings</HD>
                    <HD SOURCE="HD2">A. Background</HD>
                    <HD SOURCE="HD3">1. History of Burden Reduction and Regulatory Flexibility</HD>
                    <P>Since the inception of the ONC Health IT Certification Program (Program), we have aimed to implement and administer the Program in the least burdensome manner that supports our policy goals. Through the years, we have worked to improve the Program with a focus on ways to reduce burden, offer flexibility, and support innovation. This approach has been consistent with the principles of Executive Order (E.O.) 13563 on Improving Regulation and Regulatory Review (February 2, 2011), which instructs agencies to periodically review its existing significant regulations and “determine whether any such regulations should be modified, streamlined, expanded, or repealed so as to make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives.” To that end, we have historically taken measures where feasible and appropriate to reduce burden within the Program and make the Program more effective, flexible, and streamlined.</P>
                    <P>
                        For example, in the 2014 Edition final rule (77 FR 54164, Sept. 4, 2012), we revised the certified electronic health record technology (CEHRT) definition to provide flexibility and create regulatory efficiencies by narrowing required functionality to a core set of capabilities (
                        <E T="03">i.e.,</E>
                         the Base EHR definition) plus the additional capabilities each eligible clinician, eligible hospital, and critical access hospital needed to successfully achieve the applicable objective and measures under the EHR Incentive Programs (now referred to as the Promoting Interoperability (PI) Programs). ONC has also supported more efficient testing and certification methods and reduced regulatory burden through the adoption of a gap certification policy. As explained in the 2014 Edition final rule (77 FR 54254) and the 2015 Edition final rule (80 FR 62681), as modified by the 2015 final rule with corrections and clarifications at 80 FR 76868, where applicable, gap certification allows for the use of a previously certified health IT product's test results for certification criteria identified as unchanged. Developers have been able to use gap certification for more efficient certification of their health IT when updating from the 2011 Edition to the 2014 Edition and from the 2014 Edition to the 2015 Edition.
                    </P>
                    <P>ONC introduced further means to reduce regulatory burden, increase regulatory flexibility, and promote innovation in the 2014 Edition Release 2 final rule (79 FR 54430) published on September 11, 2014. The 2014 Edition Release 2 final rule established a set of optional 2014 Edition certification criteria that provided flexibility and alternative certification pathways for health IT developers and providers based on their specific circumstances. The 2014 Edition Release 2 final rule also simplified the Program by discontinuing the use of the “Complete EHR” certification concept beginning with the 2015 Edition (79 FR 54443).</P>
                    <P>
                        In the 2015 Edition final rule, we did not “carry forward” certain 2014 Edition certification criteria into the 2015 Edition, such as the “image results,” “patient list creation,” and “electronic medication administration record” criteria. We determined that these criteria did not advance functionality or support interoperability (80 FR 62682 through 62684). We also did not require all health IT to be certified to the “meaningful use measurement” certification criteria for “automated numerator recording” and “automated measure calculation” (80 FR 62604 and 62605), which the 2014 Edition had previously required. Based on stakeholder feedback and Program administration observations, we also permitted testing efficiencies for the 2015 Edition “automated numerator recording” and “automated measure calculation” criteria by removing the live demonstration requirement of recording data and generating reports (80 FR 62703). Health IT developers may now self-test their Health IT Modules' capabilities and submit the resulting reports to the ONC-Authorized Testing Laboratory (ONC-ATL) to verify compliance with the “meaningful use measurement” criterion.
                        <SU>9</SU>
                        <FTREF/>
                         In order to further reduce burden for health IT developers, in our 2015 Edition final rule, we adopted a more straightforward approach to privacy and security certification requirements and clarified which requirements apply to each criterion within the regulatory functional areas (80 FR 62605).
                    </P>
                    <FTNT>
                        <P>
                            <SU>9</SU>
                             
                            <E T="03">https://www.healthit.gov/test-method/automated-numerator-recording</E>
                             and 
                            <E T="03">https://www.healthit.gov/test-method/automated-measure-calculation</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Executive Orders 13771 and 13777</HD>
                    <P>On January 30, 2017, the President issued E.O. 13771 on Reducing Regulation and Controlling Regulatory Costs, which requires agencies to identify deregulatory actions. This order was followed by E.O. 13777, titled “Enforcing the Regulatory Reform Agenda” (February 24, 2017). E.O. 13777 provides further direction on implementing regulatory reform by identifying a process by which agencies must review and evaluate existing regulations and make recommendations for repeal or simplification.</P>
                    <P>In order to implement these regulatory reform initiatives and policies, ONC reviewed and evaluated existing regulations in the year leading to the issuance of the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Proposed Rule (Proposed Rule) (84 FR 7424 through 7610). During our review, we sought to identify ways to further reduce administrative burden, to implement deregulatory actions through guidance, and to put forth deregulatory actions in this final rule that will reduce burden for health IT developer, providers, and other stakeholders.</P>
                    <P>
                        Prior to publishing the Proposed Rule, on August 21, 2017, ONC issued 
                        <E T="03">Relied Upon Software Program Guidance.</E>
                        <SU>10</SU>
                        <FTREF/>
                         Health IT developers are permitted to use “relied upon software” 
                        <SU>11</SU>
                        <FTREF/>
                         to demonstrate compliance with certification criteria adopted at 45 CFR part 170, subpart C. Historically, in cases where a Health IT Module is paired with multiple “relied upon software” products for the same capability, health IT developers were required to demonstrate compliance for the same certification criterion with each of those “relied upon software” products in order for the products to be listed on the Certified Health IT Product List (CHPL). With the guidance issued on August 21, 2017, health IT developers could demonstrate compliance with only one “relied upon software” product for a criterion/capability. Once the health IT developer demonstrates compliance with a minimum of one “relied upon software” product, the developer can have multiple, additional “relied upon software” products for the same criterion/capability listed on the CHPL (
                        <E T="03">https://chpl.healthit.gov/</E>
                        ). This approach reduces burden for health IT developers, ONC-ATLs, and ONC-Authorized Certification Bodies (ONC-ACBs).
                    </P>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/relieduponsoftwareguidance.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             “Relied upon” software is defined in the 2011 final rule establishing the permanent certification program (76 FR 1276).
                        </P>
                    </FTNT>
                    <P>
                        On September 21, 2017, ONC announced a deregulatory action to reduce the overall burden for testing 
                        <PRTPAGE P="25654"/>
                        health IT to the 2015 Edition certification criteria.
                        <SU>12</SU>
                        <FTREF/>
                         ONC reviewed the 2015 Edition test procedures and changed 30 of the 2015 Edition test procedures from requiring ONC-ATL evaluation to requiring only attestation by health IT developers that their product has capabilities conformant with those specified in the associated certification criterion/criteria.
                        <SU>13</SU>
                        <FTREF/>
                         This deregulatory action reduced burden and costs program-wide, while still maintaining the Program's high level of integrity and assurances. The total testing cost savings for health IT developers have been estimated between $8.34 and $9.26 million. ONC-ATLs also benefitted by having more time and resources to focus on tool-based testing (for interoperability-oriented criteria) and being responsive to any retesting requirements that may arise from ONC-ACB surveillance activities. Health care providers and other users of certified health IT did not lose confidence in the Program because health IT developers were still required to meet certification criteria requirements and maintain their products' conformance to the full scope of the associated criteria, including when implemented in the field and in production use. ONC and ONC-ACBs continue to conduct surveillance activities and respond to end-user complaints.
                    </P>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             
                            <E T="03">https://www.healthit.gov/buzz-blog/healthit-certification/certification-program-updates-support-efficiency-reduce-burden/</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/policy/selfdeclarationapproachprogramguidance17-04.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">B. Deregulatory Actions</HD>
                    <P>In the Proposed Rule, we proposed (84 FR 7434 through 7439) and sought comment on six specific deregulatory actions. Having considered the comments received on the proposals, which are summarized below, we have decided to finalize five of the six proposed deregulatory actions and not to finalize the proposal to recognize the FDA Software Precertification Pilot Program. We refer readers to section XIII (Regulatory Impact Analysis) of this final rule for a discussion of the estimated cost savings from these finalized deregulatory actions.</P>
                    <HD SOURCE="HD3">1. Removal of Randomized Surveillance Requirements</HD>
                    <P>
                        ONC-ACBs are required under §  170.556 to conduct surveillance of certified health IT to ensure that health IT continues to conform with and function as required by the full scope of the certification requirements. Surveillance is categorized as either reactive surveillance (for example, complaint-based surveillance) or randomized surveillance. Previously finalized regulations in § 170.556(c)(2) required ONC-ACBs to proactively surveil two percent of the certificates they issue annually. As discussed in the Proposed Rule, in the time since the two percent randomized surveillance requirement was finalized, stakeholders had expressed concern that the benefits of in-the-field, randomized surveillance may not outweigh the time commitment required by providers, particularly if no non-conformities are found (84 FR 7434). We noted in the Proposed Rule that, in general, health care providers had expressed that reactive surveillance (
                        <E T="03">e.g.,</E>
                         surveillance based on user complaints) is a more logical and economical approach to surveillance. Consistent with our September 21, 2017, exercise of enforcement discretion on implementation of randomized surveillance by ONC-ACBs,
                        <SU>14</SU>
                        <FTREF/>
                         we proposed in the Proposed Rule to eliminate certain regulatory randomized surveillance requirements (84 FR 7434).
                    </P>
                    <FTNT>
                        <P>
                            <SU>14</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/ONC_Enforcement_Discretion_Randomized_Surveillance_8-30-17.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        In the Proposed Rule, we specifically proposed to revise §  170.556(c) by changing the requirement that ONC-ACBs 
                        <E T="03">must</E>
                         conduct in-the-field, randomized surveillance to specify that ONC-ACBs 
                        <E T="03">may</E>
                         conduct in-the-field, randomized surveillance (84 FR 7434). We further proposed to remove §  170.556(c)(2), which specified that ONC-ACBs must conduct randomized surveillance for a minimum of two percent of certified health IT products per year. We also proposed to remove the requirements in § 170.556(c)(5) regarding the exclusion and exhaustion of selected locations for randomized surveillance. Additionally, we proposed to remove the requirements in §  170.556(c)(6) regarding the consecutive selection of certified health IT for randomized surveillance. As noted in the Proposed Rule, without these regulatory requirements, ONC-ACBs would still be required to perform reactive surveillance, and would be permitted to conduct randomized surveillance of their own accord, using the methodology identified by ONC with respect to scope (§  170.556(c)(1)), selection method (§  170.556(c)(3)), and the number and types of locations for in-the-field surveillance (§  170.556(c)(4)).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A substantial number of commenters supported removing the requirements for randomized surveillance. Many commenters supported the proposal to revise §  170.556(c) by changing the requirement that ONC-ACBs must conduct in-the-field, randomized surveillance to specify that ONC-ACBs may conduct in-the-field, randomized surveillance, including the removal of §  170.556(c)(2). Commenters noted that since ONC-ACBs would still be required to perform reactive surveillance, and would be permitted to conduct randomized surveillance of their own accord, the regulatory requirement to conduct randomized surveillance on a specified portion of certified health IT would be unnecessary. Commenters supporting this proposal praised the deregulatory action as allowing more flexibility for ONC-ACBs. A number of commenters were generally supportive of the proposal and applied the caveat that if an ONC-ACB did voluntarily conduct randomized surveillance, they should not do so repeatedly on the same Health IT Module. These commenters indicated a preference that the requirements in §  170.556(c)(6) regarding the consecutive selection of certified health IT for randomized surveillance remain. Several commenters were supportive of removing randomized surveillance requirements and indicated they found this appropriate in view of the Conditions and Maintenance of Certification enhancements to the Program as directed by the Cures Act, while others noted that reactive surveillance may be more effective in surfacing and correcting non-conformities. A number of commenters did not support the proposal, with many expressing concerns that this could be or be perceived to be a reduction in oversight of developers or could reduce providers' confidence that certified Health IT Modules would meet their needs. While a majority of commenters speaking to surveillance burdens on health care providers indicated the removal of mandatory randomized surveillance would, on the whole, reduce burden on health care providers, several expressed concerns about whether providers can discern when a product does not meet certification requirements or know where and how to report their concerns about their certified health IT's conformance to Program requirements. A few commenters suggested that the increased emphasis on reactive surveillance (particularly in some commenters' view because ONC is removing randomized surveillance requirements in advance of the full implementation of the EHR Reporting Program called for by section 4002 of 
                        <PRTPAGE P="25655"/>
                        the Cures Act) indicates a need for additional guidance to help providers and particularly clinicians understand how to recognize and report potential non-conformities in the certified health IT they use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input and reiterate our continued commitment to sustaining the integrity of our Program, including ensuring robust oversight of certified health IT products while avoiding unnecessary burdens on all program stakeholders. Having considered all comments received, in context of the totality of updates we proposed to the Program, we have concluded that the removal of the regulatory requirements for ONC-ACBs to conduct randomized surveillance is consistent with enhancing Program efficiency while maintaining its efficacy. We leave ONC-ACBs the option to conduct randomized surveillance as they determine necessary or appropriate to support continued conformance to Program requirements by Health IT Modules they have certified. We also note that ONC-ACBs that choose to conduct randomized surveillance will still be required to use the methodology identified by ONC with respect to scope (§ 170.556(c)(1)), selection method (§ 170.556(c)(3)), and the number and types of locations for in-the-field surveillance (§ 170.556(c)(4)). While we appreciate concerns that removal of requirements in § 170.556(c)(6) regarding the consecutive selection of certified health IT creates a potential that the same Health IT Module(s) could be selected for randomized surveillance in consecutive years, we are unaware of evidence suggesting that ONC-ACBs choosing to implement randomized surveillance would do so in a manner that would tend to erode its efficacy by over-sampling some products at the expense of under-sampling others. Rather than retain a regulatory provision intended to counterbalance a regulatory requirement for randomized surveillance of a required minimum percent of certified products each year, we believe it is more appropriate at this time to remove the restriction on consecutive selection of the same Health IT Module(s) or location(s) for randomized surveillance and monitor the results of this and other Program enhancements finalized in this rule for any indication that we may need to further adjust regulatory requirements in the future.
                    </P>
                    <P>
                        We thank commenters for bringing to our attention that health care providers may be uncertain about how or where they can engage the ONC Health IT Certification Program for assistance when the certified health IT they rely on is not performing its certified functions as they expect and their health IT developer is unresponsive or fails to resolve non-conformities with Program requirements. Reactive surveillance by ONC-ACBs, informed and focused by end-user complaints, has always been an essential component of the Program's oversight and assurance of continued conformity of certified Health IT Modules when deployed in the field. While we encourage users to begin seeking troubleshooting and issue resolution support from the developer of their health IT—because the developer is often in the best position to act most promptly to resolve problems with their products' performance—we also encourage the user to share their concerns with the ONC-ACB that certified the health IT in question when the developer has not addressed users' concerns that their certified health IT is not performing as it is certified to perform. As we recognize that users may in some circumstances need, or for purposes potentially including but not limited to their own preferences may wish, to share their concerns about their certified health IT's performance or other health IT matters directly with ONC, we invite health IT users and all other interested parties to share their health IT-related feedback or concerns with ONC through the 
                        <E T="03">Health IT Feedback Form</E>
                         on our 
                        <E T="03">HealthIT.gov</E>
                         website.
                        <SU>15</SU>
                        <FTREF/>
                         Depending on the nature of a specific feedback message, we may contact the submitter for additional information and, in some instances, may share the information provided with other appropriate entities—such as but not limited to the ONC-ACBs who certify the products about which we receive feedback, as they are often in the best position to assess and respond to feedback expressing concerns about conformance of specific certified criteria used by Health IT Modules in production environments. All information submitted through the 
                        <E T="03">Health IT Feedback Form</E>
                         is carefully reviewed and helps us to improve our awareness and ability to address health IT-related issues and challenges. Also, we note for clarity that persons sharing health IT-related concerns with ONC via the 
                        <E T="03">Health IT Feedback Form</E>
                         have the option to remain anonymous and this option has been chosen by some submitters. However, we wish to note that anonymous submissions will prevent us from acquiring additional information to fully follow up on a matter if the submission does not include sufficient detail on which to act. In general, submitters should provide as much detail as possible about the developer, product name, and version of the certified health IT as well as their specific concerns about the certified health IT's performance.
                    </P>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             
                            <E T="03">https://www.healthit.gov/form/healthit-feedback-form</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Removal of the 2014 Edition From the Code of Federal Regulations</HD>
                    <P>In the March 4, 2019 Proposed Rule, we also proposed to remove the 2014 Edition from the Code of Federal Regulations (CFR), which includes standards and functionality now significantly outmoded (84 FR 7434). We noted that removal of the 2014 Edition would make the 2015 Edition the new baseline for health IT certification. The 2015 Edition, including the additional certification criteria, standards, and requirements adopted in this final rule, will better enable interoperability and the access, exchange, and use of electronic health information, as discussed in the Proposed Rule (84 FR 7434), and its adoption and implementation by providers is expected to yield the estimated costs savings described (84 FR 7563 and 7564) within the Regulatory Impact Analysis (section XIV) of the Proposed Rule and in the Regulatory Impact Analysis section (section XIII) of this final rule.</P>
                    <P>
                        To implement the removal of the 2014 Edition from the CFR, we proposed (84 FR 7434 and 7435) to remove the 2014 Edition certification criteria (§ 170.314) and related standards, terms, and requirements from the CFR. In regard to terms, we proposed to retire the 2014 Edition-related definitions found in § 170.102, including the “2014 Edition Base EHR,” “2014 Edition EHR certification criteria,” and “Complete EHR, 2014 Edition.” As explained in the 2015 Edition final rule (80 FR 62719), the ability to maintain Complete EHR certification is only permitted with health IT certified to the 2014 Edition certification criteria. Because this concept was discontinued for the 2015 Edition, we proposed (84 FR 7435) to remove § 170.545 and any references to Complete EHR from the regulation text in conjunction with the removal of the 2014 Edition. We also proposed (84 FR 7435) to remove references to the 2014 Edition from the Common Clinical Data Set (CCDS) definition and effectively replace it with a new government-unique standard, the United States Core Data for Interoperability (USCDI). We proposed (84 FR 7435) to remove the standards and implementation specifications found in §§ 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that are only 
                        <PRTPAGE P="25656"/>
                        referenced in the 2014 Edition certification criteria. Adopted standards that are also referenced in the 2015 Edition would remain. Finally, we proposed (84 FR 7435) to remove requirements in § 170.550(f) and any other requirements in subpart E, §§ 170.500 through 170.599, which are specific to the 2014 Edition and do not apply to the 2015 Edition.
                    </P>
                    <P>As discussed in the Proposed Rule (84 FR 7435), in order to avoid regulatory conflicts, we took into consideration the final rule released by CMS on November 16, 2017, titled “Medicare Program; CY 2018 Updates to the Quality Payment Program; and Quality Payment Program: Extreme and Uncontrollable Circumstance Policy for the Transition Year” (82 FR 53568). This Quality Payment Program (QPP) final rule permits eligible clinicians to use EHR technology certified to either the 2014 or 2015 Edition certification criteria, or a combination of the two for the CY 2018 performance period. This QPP final rule also states that the 2015 Edition certified EHR technology (CEHRT) will be required starting with the CY 2019 QPP program year (82 FR 53671). Therefore, we proposed (84 FR 7435) the effective date of removal of the 2014 Edition certification criteria and related standards, terms, and requirements from the CFR would be the effective date of this final rule.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of the comments received supported removing the 2014 Edition certification criteria from the Code of Federal Regulations. Commenters supporting the removal noted that it will reduce confusion and acknowledges that standards and functionality in the 2014 Edition are now significantly outmoded. Some commenters requested the removal be delayed until the end of CY 2019.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We have finalized the removal of the 2014 Edition from the CFR as proposed, including making the removal effective as of the effective date of this final rule (60 days after the rule is published in the 
                        <E T="04">Federal Register</E>
                        ). The 2015 Edition was the sole edition permitted to meet the CEHRT definition beginning in the CY 2019 program year. This final rule is published in CY 2020. Therefore, the removal is not in conflict with CMS' regulatory requirements for QPP.
                    </P>
                    <P>To finalize removal of the 2014 Edition from the CFR, we have removed, effective as of the effective date of this final rule, the 2014 Edition certification criteria in § 170.314. We also finalized removal of 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. Therefore, in conjunction with the removal of the 2014 Edition, we also remove in this final rule § 170.545 and all other references to “Complete EHR” from the regulation text. Moreover, in finalizing the removal of the 2014 Edition from the CFR, we also finalize removal of the standards and implementation specifications found in §§ 170.200, 170.202, 170.204, 170.205, 170.207, 170.210, and 170.299 that are referenced only in the 2014 Edition certification criteria. Adopted standards that are also referenced in the 2015 Edition, as modified by this final rule, remain in the CFR. We also retained the CCDS definition in § 170.102 but removed the standards and implementation specifications that reference the 2014 Edition. Additionally, we finalized the removal of requirements in §  170.550(f) and any other requirements in subpart E, §§  170.500 through 170.599, that are specific to the 2014 Edition and do not apply to the 2015 Edition.</P>
                    <HD SOURCE="HD3">3. Removal of the ONC-Approved Accreditor From the Program</HD>
                    <P>
                        We proposed to remove the ONC-AA from the Program (84 FR 7435). The ONC-AA's role is to accredit certification bodies for the Program and to oversee the ONC-ACBs. However, years of experience and changes with the Program have led ONC to conclude that, in many respects, the role of the ONC-AA to oversee ONC-ACBs is now duplicative of ONC's oversight. More specifically, ONC's experience with administering the Principles of Proper Conduct (PoPC) for ONC-ACBs as well as issuing necessary regulatory changes (
                        <E T="03">e.g.,</E>
                         ONC-ACB surveillance and reporting requirements in the 2015 Edition final rule) has demonstrated that ONC on its own has the capacity to provide the appropriate oversight of ONC-ACBs. Therefore, we believe removal of the ONC-AA will reduce the Program's administrative complexity and burden.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         All but one commenter specifically addressing this proposal were in support of removing the ONC-AA. The one commenter opposed to the proposal stated concerns related to de-coupling accreditation to ISO/IEC 17065 standards (an internationally recognized standard for bodies certifying products, processes, and services to provide assurance of compliance with specified requirements such as initial testing, inspection, and quality management systems) from specific assessment of a certification body's ability to apply their accredited ISO/IEC 17065 capabilities to the Program's certification scheme requirements. The commenter noted that this might place a greater burden on ONC staff than did the Program structure that included an ONC-AA. Finally, one of the commenters in support of removing the ONC-AA from the Program requested additional clarification about criteria and processes that will be used for accreditation of certification bodies following removal of the ONC-AA from the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank all commenters for their thoughtful feedback. Upon consideration of all comments received on this proposal, we have finalized it as proposed. As noted in the preamble to the Proposed Rule (84 FR 7435), ONC's experience with administering the PoPC for ONC-ACBs as well as issuing necessary regulatory changes (
                        <E T="03">e.g.,</E>
                         ONC-ACB surveillance and reporting requirements in the 2015 Edition final rule) has demonstrated that ONC on its own has the capacity to provide the appropriate oversight of ONC-ACBs. Therefore, we believe removal of the ONC-AA will reduce the Program's administrative complexity and burden while maintaining its effectiveness. We anticipate providing updated information about ONC's updated processes for approval and oversight of certification bodies through familiar mechanisms including but not necessarily limited to the 
                        <E T="03">HealthIT.gov</E>
                         website prior to the effective date of this final rule, and on an ongoing basis as needed or otherwise appropriate to ensure effective transparency about this aspect of the Program.
                    </P>
                    <P>
                        To finalize this deregulatory action, we have removed the definition for “ONC-Approved Accreditor or ONC-AA” from § 170.502. We also removed §§  170.501(c), 170.503, and 170.504 regarding requests for ONC-AA status, ONC-AA ongoing responsibilities, and reconsideration for requests for ONC-AA status. Regarding correspondence and communication with ONC, we have revised § 170.505 to remove specific references to the “ONC-AA” and “accreditation organizations requesting ONC-AA status.” We also have finalized our proposal to sunset the policies reflected in the final rule titled “Permanent Certification Program for Health Information Technology; Revisions to ONC-Approved Accreditor Processes” (76 FR 72636), and to remove § 170.575, which established a process for addressing instances where the ONC-AA engages in improper conduct or does not perform its 
                        <PRTPAGE P="25657"/>
                        responsibilities under the Program. Because the regulations promulgated in this prior final rule relate solely to the role of the ONC-AA, we have finalized the removal of those requirements. Accordingly, we also revised the application process for ONC-ACB status in § 170.520(a)(3) to require documentation, with an appropriate scope, that confirms that the applicant has been accredited to ISO/IEC 17065 by any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF), in place of the ONC-AA accreditation documentation requirements. Similarly, instead of requiring the ONC-AA to evaluate the conformance of ONC-ACBs to ISO/IEC 17065, we revise § 170.523(a) to simply require ONC-ACBs to maintain accreditation in good standing to ISO/IEC 17065. This means that ONC-ACBs would need to continue to comply with ISO/IEC 17065 and requirements specific to the ONC Health IT Certification Program scheme.
                    </P>
                    <HD SOURCE="HD3">4. Removal of Certain 2015 Edition Certification Criteria and Standards</HD>
                    <P>Having reviewed and analyzed the 2015 Edition, we proposed to remove certain certification criteria and standards as discussed in the Proposed Rule (84 FR 7435 through 7437) and below. We stated (84 FR 7435) that we believe the removal of these criteria and standards will reduce burden and costs for health IT developers and health care providers by eliminating the need to: Design and meet specific certification functionalities; prepare, test, and certify health IT in certain instances; adhere to associated reporting and disclosure requirements; maintain and update certifications for certified functionalities, and participate in routine surveillance (84 FR 7435). Although we did not expressly state it in the Proposed Rule preamble, the burdens and costs reduced by removal of certain criteria from the 2015 Edition would be those associated with the needs we discussed in the preamble (84 FR 7435) specifically in connection to the criteria we proposed to remove, which are those that had been set forth in § 170.315(a)(6), (7) and (8), (10) and (11), and (13), (b)(4) and (5), and (e)(2) (as the text of 45 CFR part 170 stood prior to this final rule).</P>
                    <HD SOURCE="HD3">a. 2015 Edition Base EHR Definition Certification Criteria</HD>
                    <P>We proposed to remove certain certification criteria from the 2015 Edition that had been included in the 2015 Edition Base EHR definition. As discussed in the preamble to the Proposed Rule (84 FR 7435), the removal of these criteria supports burden and cost reductions for health IT developers and health care providers by eliminating the need to: Design and meet these specific certification functionalities; prepare, test, and certify health IT in certain instances; adhere to associated reporting and disclosure requirements; maintain and update certifications for these specific certified functionalities; and participate in surveillance of health IT certified to these criteria and standards.</P>
                    <HD SOURCE="HD3">i. Problem List</HD>
                    <P>
                        We proposed to remove the 2015 Edition “problem list” certification criterion (§ 170.315(a)(6)) from the 2015 Edition (84 FR 7436). As we noted in the Proposed Rule, the functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording problem list information. This 2015 Edition “problem list” criterion functionally remains relatively the same as the 2011 Edition and has exactly the same functionality as the 2014 Edition “problem list” criterion. We proposed to remove this criterion because the criterion no longer supports the “recording” objective and measure of the CMS PI Programs as such objective and measure no longer exist.
                        <SU>16</SU>
                        <FTREF/>
                         Additionally, we stated the functionality is sufficiently widespread among health care providers since it has been part of certification and the Certified EHR Technology definition since the 2011 Edition and has not substantively changed with the 2015 Edition. Furthermore, we stated in the Proposed Rule that the functionality is essential to clinical care and would be in EHR systems absent certification, particularly considering the limited certification requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>16</SU>
                             By stating in the NPRM that the objective and measure no longer exist, we meant in the CMS PI (formerly EHR Incentive) Programs. The authority citation for this statement is the December 15, 2015 CMS Final Rule “Medicare and Medicaid Programs; Electronic Health Record Incentive Program-Stage 3 and Modifications to Meaningful Use in 2015 Through 2017” (80 FR 62761 and 62785).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed support for removing the “problem list” certification criterion from the 2015 Edition and “Base EHR” definition. Several of those expressing support for the removal of this criterion specifically noted that the inclusion of the same data elements in the USCDI should suffice to ensure continued ability of certified health IT to record and facilitate access and exchange of these data. However, a few commenters expressed concern that removing this and other requirements would be a disincentive to maintain the functionality in the future, and some commenters expressed concern about ONC's ability to continue to provide effective oversight and require correction if developers do not ensure the functionalities perform safely and effectively. Commenters stated that while many developers will still continue to support the functionalities proposed for removal, eliminating the certification requirement may allow for developers to provide a “stripped-down” product at a lower price point and, in absence of CEHRT definition to guide the providers, mislead independent and small providers into unwittingly acquiring certified health IT that does not fully meet their needs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed in the preamble to the Proposed Rule, a criterion specific to the “problem list” functionality was first adopted in the 2011 Edition, specifically to ensure support for the associated meaningful use Stage 1 objective and the measure for recording problem list information under the CMS PI Programs. The “recording” objective and measure is no longer a part of the CMS PI Programs. However, the functionality remains widespread among EHR systems used by health care providers. While this prevalence may be due in part to its inclusion in the Certified EHR Technology definition, without substantive changes, since the 2011 Edition, we believe the more significant reason that this functionality is widely available is because it is essential to clinical care, and therefore, that the market will and should drive its continued presence in EHR systems regardless of certification requirements. While we also appreciate the concerns of commenters about the need for health IT to support the accurate recording of patients' problems and the standards-based exchange of that information, we reiterate that the interoperability-focused criteria that will remain in the Base EHR definition and reference the USCDI will ensure that any system of certified health IT meeting the Base EHR definition is capable of using and exchanging data on a patient's problems using content, format, and other standards applicable to each mode of exchange (
                        <E T="03">e.g.,</E>
                         standardized API and C-CDA). Moreover, these interoperability-focused criteria will be subject not only to the Program's familiar initial certification testing and in-the-field reactive surveillance requirements but also to the new Condition and 
                        <PRTPAGE P="25658"/>
                        Maintenance of Certification requirements for developers to test annually their certified Health IT Modules' interoperability performance in the types of real world settings for which they are sold.
                    </P>
                    <P>After consideration of all comments received, and for the reasons noted in the preamble to the Proposed Rule and above, we have finalized the removal of the “problem list” certification criterion (§ 170.315(a)(6)). We further note that upon the effective date of this final rule, the “problem list” certification criterion is removed from the 2015 Edition and the criterion will no longer be included in the 2015 Edition “safety-enhanced design” criterion. This criterion, in § 170.315(g)(3), specifies the user-centered design testing that must be applied to particular EHR functionality submitted for certification. However, in response to specific commenters' concerns about the impact of removing the functionally-based problem list criterion on our ability to take action where developers may retain the functionality, but fail to ensure it does not pose a danger to patient safety or public health, we note that our responsibility, pursuant to section 3001(b) of the PHSA, includes ensuring certified health IT does not pose a risk to patient safety or public health, and is not limited to measuring the conformity of the health IT to specific certification criteria. As discussed in the “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (EOA) rule which was proposed in 81 FR 11056, and finalized in 81 FR 72404 in 2016, ONC has the authority to address suspected or confirmed non-conformities to the requirements under the ONC Health IT Certification Program if the certified health IT is causing or contributing to serious risks to public health or safety (81 FR 72406). The EOA final rule established in § 170.580 a regulatory framework for ONC's direct review of health IT certified under the Program, which expressly addresses the potential for ONC to initiate direct review if we have a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety.</P>
                    <P>With respect to health care providers' selection of certified health IT products, we would encourage all providers to consider the Base EHR or Certified EHR Technology (CEHRT) definition as a useful starting point. Certain health care payment programs, including the CMS PI Programs, require the use of certified health IT. CMS refers to the minimum set of required certification functionalities that the health IT used by eligible clinicians must have in order to qualify for the CMS incentive programs as CEHRT.</P>
                    <P>Using certified health IT improves care coordination through the electronic exchange of clinical-care documents. It provides a baseline assurance that the technology will perform clinical-care and data-exchange functions in accordance with interoperability standards and user-centered design.</P>
                    <HD SOURCE="HD3">ii. Medication List</HD>
                    <P>We proposed to remove the 2015 Edition “medication list” certification criterion (§ 170.315(a)(7)) (84 FR 7436). As we noted in the Proposed Rule, the 2015 Edition “medication list” criterion remains functionally the same as the 2011 Edition and 2014 Edition “medication list” criteria. As also discussed in the Proposed Rule, a functionally-based “medication list” criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording medication list information. The “medication list” criterion that we proposed to remove does not require use of a specific vocabulary standard to record medications.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments on the proposal to remove the “medication list” criterion were somewhat mixed. While a number of comments expressed support for the removal of the “medication list” criterion from the 2015 Edition as duplicative of medication data included in the USCDI a number of commenters expressed concerns with, and a few commenters indicated opposition to, the removal of the “medication list” criterion. A few commenters raised concerns specific to elimination of the “medication list” criterion in view of the need to respond to the opioids crisis. One commenter expressed concern in the context of both the medication list and the drug-formulary and preferred drug lists criteria as to whether the removal of these criteria could potentially impact patients' drug costs. Several comments also expressed the same concerns for eliminating the “medication list” that were expressed in regard to removal of the “problem list” criterion, which are summarized above, regarding whether developers will continue to include the functionality and maintain its safe performance.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. Upon consideration of all comments received on this proposal, we have finalized the removal of the “medication list” criterion (§ 170.315(a)(7)). The “recording” objective and measure of the CMS PI Programs that the “medication list” criterion was originally adopted to support has since been retired from the CMS Programs. However, the functionality remains widespread among EHR systems used by health care providers. While this prevalence may be due in part to its inclusion in the Certified EHR Technology definition since the 2011 Edition, we believe this functionality is widely available and used in more significant part because it is essential to clinical care and, therefore, the market will and should drive its continued presence in EHR systems regardless of certification requirements. While we also appreciate the concerns of commenters about the need for health IT to support clinicians' ability to access, maintain, use, and exchange accurate and up-to-date information on their patients' current medication lists and medication history, we repeat for clarity and emphasis that the interoperability-focused criteria that will remain in the Base EHR definition, and their inclusion of the USCDI, will ensure that any system of certified health IT meeting the Base EHR definition is capable of using and exchanging data on a patient's medications using content, format, and other standards applicable to each mode of exchange (
                        <E T="03">e.g.,</E>
                         standardized API consistent with § 171.315(g)(10), or exchange of C-CDA documents using the transport standards and other protocols in § 171.202). We recognize the critical importance of providers' and patients' ability to have, use, and exchange medications information to avoid harms that can arise from interactions and duplications of therapeutic effects amongst newly prescribed drugs and those the patient may already be taking. While the clinical importance of maintaining and referencing current, reconciled medication lists is not limited to those medications with significant risks of misuse or dependency, we agree that it is highlighted by the urgent need to ensure opioids are prescribed and used only with due care when clinically necessary. We believe this clinical importance supports the expectation that the market will ensure this functionality is maintained and will drive innovations that improve its usability for the clinicians who use it in the course of caring for their patients. Moreover, the inclusion of medication information in interoperability-focused criteria in § 170.405(a) will ensure certified health IT can access, use, and exchange medications data according to 
                        <PRTPAGE P="25659"/>
                        applicable content and formatting standards, which the “medication list” functionality did not ensure. This interoperability of the data is critical to reducing clinician burden related to manually entering updated drug lists and necessary to enable use of medication information by clinical decision support functionalities. The interoperability-focused criteria will also be subject not only to the Program's familiar initial certification testing and in-the-field reactive surveillance requirements but also to the new Condition and Maintenance of Certification requirements for developers to test annually their certified Health IT Modules' interoperability performance in the types of real world settings for which they are marketed.
                    </P>
                    <P>We note that once removed from the 2015 Edition, the criterion will no longer be included in the 2015 Edition “safety-enhanced design” criterion in § 170.315(g)(3). However, as noted above in context of the “problem list” criterion, ONC's responsibility, pursuant to section 3001(b) of the PHSA, includes ensuring certified health IT does not pose a risk to patient safety or public health. Our responsibility for certified health IT and patient safety or public health is not limited to measuring the conformity of the health IT to specific certification criteria. As discussed in the EOA rule, ONC has the authority to address suspected or confirmed non-conformities to the requirements under the Health IT Certification Program if the certified health IT is causing or contributing to serious risks to public health or safety (81 FR 72406). The EOA final rule established in § 170.580 a regulatory framework for ONC's direct review of health IT certified under the Program, which expressly addresses the potential for ONC to initiate direct review if we have a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety.</P>
                    <HD SOURCE="HD3">iii. Medication Allergy List</HD>
                    <P>We proposed to remove the 2015 Edition “medication allergy list” certification criterion (§ 170.315(a)(8)). The functionality in this criterion was first adopted as a 2011 Edition certification criterion to support the associated meaningful use Stage 1 objective and measure for recording medication allergies information. The criterion does not require use of a vocabulary standard to record medication allergies, and does not directly support interoperability as the criterion does not require representation of medication allergies in standardized nomenclature. The criterion no longer supports a “recording” objective and measure of the CMS PI Programs as such objective and measure no longer exist. This 2015 Edition “medication allergy list” criterion remains functionally the same as the 2011 Edition and 2014 Edition “medication allergy list” criteria. The functionality is essential to clinical care and would be in EHR systems absent certification.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments on the proposed removal of the “medication allergy list” criterion were mixed, with several commenters supportive of the removal noting that the criterion would be redundant now that medication allergy data will be included in the USCDI. Commenters expressed concern with the removal of the criterion and questioned the ubiquity of the medication allergy list functionality and whether health IT developers would continue to support the functionality if not required by ONC regulations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. Upon consideration of all comments received on this proposal, we have finalized the removal of the “medication allergy list” certification criterion (§ 170.315(a)(8)). The “recording” objective and measure of the CMS PI Programs that this criterion was originally adopted to support has since been retired from the CMS Programs. However, the functionality remains widespread among EHR systems. While this prevalence may be due in part to its inclusion in the Certified EHR Technology definition since the 2011 Edition, its importance to clinical care suggests the market will drive ongoing availability and enhancement of this functionality over time. Furthermore, because medication allergies are included in the USCDI, all systems of certified health IT meeting the Base EHR definition will be required to be able to exchange and use medication allergy information according to applicable content and formatting standards, which the “medication allergies” criterion did not ensure. This interoperability is critical to reducing clinician burden related to manually entering updated drug lists and necessary to enable use of medication information by clinical decision support functionalities. We believe that requiring the interoperability of medication allergy information will facilitate innovation and improvement in health IT's ability to meet clinicians' and patients' needs more than would the continuation of the “medication allergies” functionally-based criterion.
                    </P>
                    <P>We note that once removed from the 2015 Edition, the “medication allergy list” criterion will also no longer be included in the 2015 Edition “safety-enhanced design” criterion. However, as noted in context of removed criteria above, ONC's responsibility, pursuant to section 3001(b) of the PHSA includes ensuring certified health IT does not pose a risk to patient safety or public health. Our responsibility for certified health IT and patient safety or public health is not limited to measuring the conformity of the health IT to specific certification criteria. As discussed in the EOA rule, ONC has the authority to address suspected or confirmed non-conformities to the requirements under the Health IT Certification Program if the certified health IT is causing or contributing to serious risks to public health or safety (81 FR 72406). The EOA final rule established in § 170.580 a regulatory framework for ONC's direct review of health IT certified under the Program, which expressly addresses the potential for ONC to initiate direct review if we have a reasonable belief that certified health IT may not conform to the requirements of the Program because the certified health IT may be causing or contributing to conditions that present a serious risk to public health or safety.</P>
                    <HD SOURCE="HD3">iv. Smoking Status</HD>
                    <P>We proposed to remove the 2015 Edition “smoking status” criterion (§ 170.315(a)(11)), which would include removing it from the 2015 Edition Base EHR definition (84 FR 7436). We had previously adopted a 2015 Edition “smoking status” certification criterion that does not reference a standard. However, the CCDS definition, which we proposed to remove from regulation in favor of adopting the new USCDI standard, required smoking status to be coded in accordance with a standard value set of eight SNOMED CT® codes defined in § 170.207(h). As with other functionality that was included in 2014 Edition, we believe this functionality is now widespread. Further, smoking status data will continue to be required to be available for access and exchange via the USCDI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments on this proposal were mixed, with a number of commenters expressing support for the removal of “smoking status” criterion in the Program and several noting that it is not needed or duplicative in the context of Program requirements to support the USCDI. A few commenters stated concerns that eliminating the requirement would provide a 
                        <PRTPAGE P="25660"/>
                        disincentive for developers to maintain the function in the future. Several commenters expressing concerns about removal of this criterion noted its importance to patient care and to public health, raising points such as the use of smoking status as a key determinant to classify cases of some reportable conditions, such as carbon monoxide poisoning. Concerns raised by commenters opposed to removing smoking status data from providers' EHR systems included potential for additional provider burden, such as that related to providing complete case reporting data and responding to public health requests for additional information on patient smoking status during case investigation processes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. Upon consideration of the comments, we have finalized the removal of the “smoking status” criterion (§ 170.315(a)(11)). While we continue to believe that accurate, up-to-date information on a patient's smoking status and history has significant clinical value, we believe that its importance to clinical care provides adequate motivation for the market to drive ongoing availability and enhancement of this functionality over time. Because smoking status information is included in the USCDI, all systems of certified health IT meeting the Base EHR definition will now be required to be able to exchange and use smoking status information according to applicable content and formatting standards. The “smoking status” recording functionality criterion we have removed did not ensure smoking status information was captured in a structured, interoperable manner and interoperability of this data is critical to reducing clinician burden related to maintaining complete, current smoking status information. It is also necessary to enable use of smoking status information by clinical decision support and public health reporting functionalities. We believe that interoperability and exchange of smoking status information through the interoperability-focused certification criteria that reference the USCDI standard will better facilitate innovation and improvement in health IT's ability to meet clinicians' and patients' needs than would continuation of the “smoking status” functionally-based recording criterion.
                    </P>
                    <HD SOURCE="HD3">Removal of Specific USCDI Smoking Status Code Set</HD>
                    <P>Along with the “smoking status” criterion, we proposed to remove the requirement to code smoking status according to the eight smoking status SNOMED CT® codes referenced in the value set adopted in § 170.207(h). These eight codes reflected an attempt to capture smoking status in a consistent manner. Stakeholder feedback indicated that these eight codes do not appropriately and accurately capture all clinically relevant patient smoking statuses. Accordingly, we proposed to no longer require use of only the specific eight SNOMED CT® codes for representing smoking status and remove the value set standard by deleting and reserving § 170.207(h).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments specifically addressing this proposal were generally supportive of removing the specific value set of eight SNOMED CT® codes, though many also noted the importance of continuing to require health IT certified under the Program to retain the ability to include or access, exchange, and use appropriately standardized smoking status information. Several comments made specific suggestions related to broadening or revising the vocabulary standard requirements for smoking status information going forward. Other commenters suggested adding other forms of tobacco use, including smokeless and second hand, as well as e-cigarette (vaping) use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all commenters' input and note that no comments received raised concerns that are not addressed by inclusion of smoking status information in the USCDI, which all interoperability-focused criteria within the 2015 Edition Base EHR definition, as revised through this final rule, reference. As is the case with patient problems, medications, and medication allergies, we believe having smoking status information available for standards-based exchange is an important facilitator of better care and more effective public health reporting with less data-related burden on clinicians and less need for follow-up by public health professionals to compensate for case reporting data that is incomplete or is not fully interoperable. As is the case with the other removed criteria that were focused on internal recording capabilities, we believe the market can, will, and should be the primary driver for the ongoing maintenance and enhancement of functionalities for end users to record or modify these data. Furthermore, the Program's focus is more appropriately spent on ensuring that certified health IT supports interoperable access, use, and exchange of these data as the key facilitator for more coordinated patient care and for ongoing innovation and improvement in both provider- and patient-facing functionalities. Because comments on revisions or enhancements to smoking status data standardization moving forward are outside the scope of this section, we will not address them in specific detail here. However, we note that the USCDI v1 references as the standard for smoking status information SNOMED CT®, U.S. Edition.
                        <SU>17</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>17</SU>
                             For more information on finalized policy regarding adoption of the USCDI standard, see section IV.B.1 of this final rule. USCDI v1 can be accessed freely and directly in its entirety at 
                            <E T="03">https://www.healthit.gov/isa/sites/isa/files/inline-files/USCDIv12019revised2.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>Having considered all comments received on this proposal, we have finalized the removal of the eight-code value set standard and removed and reserved § 170.207(h).</P>
                    <HD SOURCE="HD3">b. Drug-Formulary and Preferred Drug List Checks</HD>
                    <P>We proposed to remove the 2015 Edition “drug-formulary and preferred drug list checks” criterion in § 170.315(a)(10).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern that this criterion's removal could negatively impact prescribers' ability to help their patients manage their prescription drug expenses. Although several commenters supported the removal of this criterion in principle, a number of comments expressed concerns about the effect of removal of the “drug-formulary and preferred drug list checks” and other criteria from the Program on health care providers' ability to comply with CMS and State-specific regulatory requirements for successful participation in the Medicare Quality Payment Program (QPP), or the Medicare or Medicaid PI Programs. One commenter, noting that the Drug-Formulary and Preferred Drug List Checks criterion is associated with the CMS e-prescribing objective measures that CMS has finalized for 2019 and subsequent performance years specifically, recommended coordination with CMS to ensure alignment across the policies maintained by these two components of HHS.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. As discussed in the Proposed Rule (84 FR 7437), the 2015 Edition “drug-formulary and preferred drug list checks” criterion does call for functionality to check drug formulary and preferred drug lists, but does not require use of any specific interoperability standards. The 2015 Edition “drug-formulary and preferred drug list checks” criterion does not include functionality or advance interoperability beyond what was required by the 2014 Edition “drug-formulary checks” criterion. While we 
                        <PRTPAGE P="25661"/>
                        believe this functionality is fairly ubiquitous now due in part to the widespread adoption of health IT certified to the 2014 Edition, we do not believe it is necessary to continue to require certification to it under the Program in order to ensure it remains widely available. Instead, we believe, prescribers' and patients' interest in assuring patients can get the medications they need at the best available value will provide adequate motivation for the market to drive ongoing availability and enhancement of this functionality over time, including through increasing use of relevant interoperability standards essential to making this functionality more affordable and seamlessly reliable at scale than is feasible in the absence of interoperability driven by ubiquitous use of open standards. Because the “drug-formulary and preferred drug list checks” criterion we proposed to remove does not require use of standards or directly drive interoperability, we do not believe its continued inclusion in the Program would provide sufficient value to providers or patients to justify the burden on developers and providers of meeting Program compliance requirements specific to this criterion. We also recognize the importance of ensuring alignment between ONC Health IT Certification Program regulations and the CMS regulations that reference them. We have been and will continue to work in close partnership with our CMS colleagues to ensure that our regulations remain aligned, and that we provide affected stakeholders with the information they need to understand how the rules work together and how to succeed under CMS' PI Programs using health IT certified under ONC's Program. We, therefore, permit ONC-ACBs to issue certificates for this criterion up until January 1, 2022 to align with the requirements of the CMS Medicaid PI Program, as this criterion is associated with measures under the Medicaid program that will continue through 2021; after 2021 there will be no further incentives under the Medicaid Promoting Interoperability Program (84 FR 42592). We have not finalized our proposal to remove the criterion from the CFR but included a provision in § 170.550(m)(1) to only allow ONC-ACBs to issue certificates for this criterion until January 1, 2022.
                    </P>
                    <HD SOURCE="HD3">c. Patient-Specific Education Resources</HD>
                    <P>
                        We proposed to remove the 2015 Edition “patient-specific education resources” certification criterion in § 170.315(a)(13) (84 FR 7437). We stated that, based on the number of health IT products that have been certified for this functionality as part of 2014 Edition certification and already for 2015 Edition, we believe that health IT's ability to identify appropriate patient education materials is widespread now among health IT developers and their customers (
                        <E T="03">e.g.,</E>
                         health care providers). We also noted that we have recently seen innovative advancements in this field, including the use of automation and algorithms to provide appropriate education materials to patients in a timely manner. These advancements help limit clinical workflow interruptions and demonstrate the use and promise of health IT to create efficiencies and improve patient care. As such, we stated that removal of this criterion would prevent certification from creating an unnecessary burden for developers and providers and an impediment to innovation.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern related to this functionality not yet being consistently used by all providers and to whether removal of this criterion may create a barrier to successful participation for providers in the Medicaid PI Program. One commenter noted that providers' workflow changes to use this functionality are substantial and expressed concern related to providers potentially not undertaking such changes if the criteria were not required to be included in health IT and used by providers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         While we continue to recognize the importance of patient and provider interaction to promote positive health outcomes, we also believe that this criterion, narrowly focused on a specific functionality not connected to interoperability, is no longer the best way to encourage innovation and advancement in health IT's ability to support clinician-patient interactions and relationships.
                    </P>
                    <P>Having reviewed all comments received on this proposal, we have decided not to remove the “patient-specific education resources” criterion from the Program at this time. We recognize the importance of ensuring alignment between ONC Health IT Certification Program regulations and the CMS regulations that reference them. We will continue to work in close partnership with our CMS colleagues to ensure that our regulations remain aligned and that we provide affected stakeholders with the information they need to understand how the rules work together and how to succeed under CMS incentive programs using health IT certified under ONC's Program. CMS has identified this criterion as supporting the patient electronic access to health information objective and measure, which is expected to remain operational for Medicaid until January 1, 2022; after 2021, there will be no further incentives under the Medicaid Promoting Interoperability Program (84 FR 42592). We, therefore, will permit ONC-ACBs to issue certificates for this criterion up until January 1, 2022, to align with the requirements of the CMS Medicaid PI Program (84 FR 42592). We have included a provision in § 170.550(m)(1) to only allow ONC-ACBs to issue certificates for this criterion until January 1, 2022.</P>
                    <HD SOURCE="HD3">d. Common Clinical Data Set Summary Record—Create; and Common Clinical Data Set Summary Record—Receive</HD>
                    <P>As stated in the proposed rule (84 FR 7437), we assessed the number of products certified to the 2015 Edition “Common Clinical Data Set summary record—create” (§ 170.315(b)(4)) and “Common Clinical Data Set summary record—receive” (§ 170.315(b)(5)) criteria that have not also been certified to the 2015 Edition “transitions of care” criterion (§ 170.315(b)(1)) that also requires health IT be capable of creating and receiving Common Clinical Data Set (CCDS) Summary Records using the same interoperability standards. We explained that, based on our findings of only two unique products certified only to these criteria and not to the “transitions of care” criterion at the time of the drafting of the Proposed Rule, there appears to be little market demand for certification to 2015 Edition “Common Clinical Data Set summary record—create” (§ 170.315(b)(4)) and “Common Clinical Data Set summary record—receive” (§ 170.315(b)(5)) criteria alone. Therefore, we proposed to remove these certification criteria from the 2015 Edition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The comments we received on this proposal supported this removal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and have finalized removal of the 2015 Edition “Common Clinical Data Set summary record—create” (§ 170.315(b)(4)) and “Common Clinical Data Set summary record—receive” (§ 170.315(b)(5)) criteria.
                    </P>
                    <HD SOURCE="HD3">e. Secure Messaging</HD>
                    <P>
                        We proposed to remove the 2015 Edition “secure messaging” criterion (§ 170.315(e)(2)). As explained in the Proposed Rule (84 FR 7437), ONC strongly supports patient and provider communication, as well as protecting the privacy and security of patient information, but no longer believes that a separate certification criterion focused 
                        <PRTPAGE P="25662"/>
                        on a health IT's ability to send and receive secure messages between health care providers and patients is necessary. This criterion would also no longer be associated with an objective or measure under the CMS PI Programs based on proposals and determinations in recent CMS rulemakings (83 FR 41664; 83 FR 35929).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several comments specifically referencing this proposal were supportive of removing this criterion. A number of commenters expressed concern with the removal of the “secure messaging” criterion, including whether removal of this criterion may create a barrier to successful participation for providers in the CMS PI Programs. Other commenters expressed concerns about continued availability of secure digital endpoints for health care providers. Some commenters noted that some providers and patients might prefer to continue using “secure messaging” functionality in lieu of other options for a variety of purposes for which they currently use it, while others expressed concern that the separate “secure messaging” functionality will disappear from the market if no longer supported by ONC requirements. Commenters expressed that options for data access and exchange, such as portals and APIs, might satisfy providers' and patients' needs for interoperable communication. However, commenters expressed a concern that these options may not ensure continued availability to new market entrants' health IT without requiring the technology to interact with developer- or system-specific interfaces.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. Having reviewed all comments received on this proposal, we have decided not to remove the “secure messaging” criterion from the Program at this time. We recognize the importance of ensuring alignment between ONC Health IT Certification Program regulations and the CMS regulations that reference them. We will continue to work in close partnership with our CMS colleagues to ensure that our regulations remain aligned and that we provide affected stakeholders with the information they need to understand how the rules work together and how to succeed under CMS incentive programs using health IT certified under ONC's Program. CMS has identified this criterion as supporting the coordination of care through patient engagement objective and measure, which is expected to remain operational for Medicaid until January 1, 2022; after 2021 there will be no further incentives under the Medicaid Promoting Interoperability Program (84 FR 42592). We, therefore, will permit ONC-ACBs to issue certificates for this criterion up until January 1, 2022 to align with the requirements of the CMS Medicaid PI Program (84 FR 42592). We have included a provision in § 170.550(m)(1) to only allow ONC-ACBs to issue certificates for this criterion until January 1, 2022.
                    </P>
                    <P>Limiting certificates to this criterion for this period will help spur further innovations in patient engagement while helping to reduce regulatory burdens and costs for health IT developers and health care providers. The other 2015 Edition certification criteria that support patient engagement, such as the 2015 Edition “view, download, and transmit to 3rd party,” “API,” and “patient health information capture” certification criteria better support interoperability and innovation in patient engagement. We have seen developers integrate secure messaging functionality as part of other patient engagement features, such as patient portals, and integrate messaging with access to and exchange of clinical and administrative data. These integrated technologies currently in use offer more comprehensive options for providers and patients to interact and share information via a secure platform and may render the separate “secure messaging” criterion and functionality redundant to robust integrated options. We also believe removing the standalone “secure messaging” criterion will encourage the market to pursue other innovative means of offering patient engagement and interaction functionalities that providers and patients want, with the convenience and efficiency they demand. Thus, we believe that the removal of this criterion will help reduce burden and costs without negative impact on current or future innovations in patient engagement and secure information exchange. In response to the concern about new market entrants being able to receive data needed to serve their customers, we note that the “view, download, and transmit to 3rd party” criterion remains available for patients who wish to send their health information to a third party of the patient's choice. Other remaining interoperability-focused criteria, such as “transitions of care,” ensure that systems of health IT certified to at least those criteria remaining in the “Base EHR” definition will remain capable of supporting providers' use of new entrant and other third party health IT of their choosing without requiring that health IT to integrate or interface with their certified health IT.</P>
                    <HD SOURCE="HD3">5. Removal of Certain ONC Health IT Certification Program Requirements</HD>
                    <P>We proposed to remove certain mandatory disclosure requirements and a related attestation requirement under the Program. As discussed in the Proposed Rule (84 FR 7437), we believe removal of these requirements will reduce costs and burden for Program stakeholders, particularly for health IT developers and ONC-ACBs.</P>
                    <HD SOURCE="HD3">a. Limitations Disclosures</HD>
                    <P>We proposed to remove § 170.523(k)(1)(iii)(B), which requires ONC-ACBs to ensure that certified health IT includes a detailed description of all known material information concerning limitations that a user may encounter in the course of implementing and using the certified health IT, whether to meet “meaningful use” objectives and measures or to achieve any other use within the scope of the health IT's certification. We proposed to remove § 170.523(k)(1)(iv)(B) and (C), which state that the types of information required to be disclosed include, but are not limited to: (B) Limitations, whether by contract or otherwise, on the use of any capability to which technology is certified for any purpose within the scope of the technology's certification; or in connection with any data generated in the course of using any capability to which health IT is certified; (C) limitations, including but not limited to technical or practical limitations of technology or its capabilities, that could prevent or impair the successful implementation, configuration, customization, maintenance, support, or use of any capabilities to which technology is certified; or that could prevent or limit the use, exchange, or portability of any data generated in the course of using any capability to which technology is certified.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most of the comments specifically referencing this proposal were supportive. A few commenters raised concerns regarding the utility of mandatory disclosures to health care providers, their health information exchange partners, and ONC, with some commenters offering suggestions for how ONC could use disclosures information in the future. A few commenters' concerns specifically referenced the disclosure of costs information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We have finalized removal of § 170.523(k)(1)(iii)(B) and § 170.523(k)(1)(iv)(B) and (C), as proposed (84 FR 7437 and 7438). As 
                        <PRTPAGE P="25663"/>
                        discussed in the Proposed Rule (84 FR 7438), these specific disclosure requirements are superseded by the Cures Act information blocking provision and Conditions of Certification requirements, which we proposed to implement in the same Proposed Rule (84 FR 7424). As also noted in the Proposed Rule (84 FR 7438), we proposed (84 FR 7465 and 7466) a complementary Condition of Certification requirement that developers would be prohibited from taking any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the scope of the technology's certification discussed further in section VII.2.
                    </P>
                    <P>
                        We also note here to ensure clarity that we did not propose, and have not finalized, a complete removal of the transparency requirements in § 170.523(k)(1). Requirements under § 170.523(k)(1) 
                        <E T="03">other than</E>
                         those specifically proposed for removal will remain in place. The transparency requirements remaining in place include: § 170.523(k)(1)(iii)(A), which describes the plain language detailed description of all known material information concerning additional types of costs that a user may be required to pay to implement or use the Complete EHR or Health IT Module's capabilities, whether to meet meaningful use objectives and measures, or to achieve any other use within the scope of the health IT's certification; and § 170.523(k)(1)(iv)(A) specification that the types of information required by § 170.523(k)(1)(iii) include, but are not limited to, additional types of costs or fees (whether fixed, recurring, transaction-based, or otherwise) imposed by a health IT developer (or any third party from whom the developer purchases, licenses, or obtains any technology, products, or services in connection with its certified health IT) to purchase, license, implement, maintain, upgrade, use, or otherwise enable and support the use of capabilities to which health IT is certified; or in connection with any data generated in the course of using any capability to which health IT is certified.
                    </P>
                    <HD SOURCE="HD3">b. Transparency and Mandatory Disclosures Requirements</HD>
                    <P>
                        We proposed to remove the Principle of Proper Conduct (PoPC) in § 170.523(k)(2), which requires ONC-ACBs to ensure health IT developers' adherence to a requirement that the health IT developer submit an attestation that it will disclose all of the information in its mandatory disclosures per § 170.523(k)(1) to specified parties (
                        <E T="03">e.g.,</E>
                         potential customers or anyone inquiring about a product quote or description of services). As discussed in the Proposed Rule (84 FR 7438), we believe this provision is no longer necessary and that its removal is appropriate to further reduce administrative burden for health IT developers and ONC-ACBs.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters specifically discussing this proposal expressed support for the removal of the PoPC in § 170.523(k)(2). A few commenters expressed concern that the high degree of transparency ONC noted in the Proposed Rule might not be maintained as they noted a possibility that the PoPC requiring the ONC-ACBs to ensure the developers submitted an attestation, and, in turn, the developers' obligation to make the attestation, may be driving the currently observed levels of transparency.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We have decided to finalize the removal of the PoPC in § 170.523(k)(2). We appreciate the importance of holding health IT developers accountable for meeting all requirements of participation in the Program, including meeting or exceeding the minimum required transparency disclosures. We believe that the needed transparency and accountability will be maintained and enhanced by certain Condition and Maintenance of Certification requirements we have finalized in this rule, which include the assurances and attestations specifically discussed in section VII.2 in relation to this proposed removal of § 170.523(k)(2). We believe that the removal of the PoPC requirements in § 170.523(k)(2) will likely aid in the avoidance of unnecessary costs and burden for Program stakeholders, particularly health IT developers and ONC-ACBs.
                    </P>
                    <HD SOURCE="HD3">6. Recognition of Food and Drug Administration Processes</HD>
                    <P>
                        Section 618 of the Food and Drug Administration Safety and Innovation Act (FDASIA), Public Law 112-144, required that the Food and Drug Administration (FDA), in consultation with ONC and the Federal Communications Commission (FCC) (collectively referred to as “the Agencies” 
                        <SU>18</SU>
                        <FTREF/>
                         for this final rule), develop a report containing a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication. The FDASIA Health IT Report of April 2014,
                        <SU>19</SU>
                        <FTREF/>
                         contained a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health IT that promotes innovation, protects patient safety, and avoids regulatory duplication. Public comments, received prior to the report's publication and after,
                        <SU>20</SU>
                        <FTREF/>
                         recommended that health IT developers/manufacturers apply a single process that satisfies the requirements of all agencies, and existing safety and quality-related processes, systems, and standards should be leveraged for patient safety in health IT. On July 27, 2017, FDA announced a voluntary Software Precertification Pilot Program as part of a broader Digital Health Innovation Action Plan.
                        <SU>21</SU>
                        <FTREF/>
                         It was developed in order to create a tailored approach toward recognizing the unique characteristics of digital technology by looking first at the firm, rather than primarily at each product of the firm, as is currently done for traditional medical products. The FDA plans to explore whether and how pre-certified companies that have demonstrated a culture of quality, patient safety, and organizational excellence could bring certain types of digital health products to market either without FDA premarket review or with a more streamlined FDA premarket review.
                    </P>
                    <FTNT>
                        <P>
                            <SU>18</SU>
                             ONC is not an agency, but an office within the Department of Health and Human Services.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>19</SU>
                             
                            <E T="03">https://www.fda.gov/downloads/AboutFDA/CentersOffices/OfficeofMedicalProductsandTobacco/CDRH/CDRHReports/UCM391521.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>20</SU>
                             
                            <E T="03">https://www.federalregister.gov/documents/2013/05/30/2013-12817/food-and-drug-administration-safety-and-innovation-act-fdasia-request-for-comments-on-the</E>
                            , 
                            <E T="03">https://blogs.fda.gov/fdavoice/index.php/2014/04/fda-seeks-comment-on-proposed-health-it-strategy-that-aims-to-promote-innovation/</E>
                             and 
                            <E T="03">https://www.regulations.gov/document?D=FDA-2014-N-0339-0001</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>21</SU>
                             
                            <E T="03">https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/Default.htm</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">a. FDA Software Precertification Pilot Program</HD>
                    <P>
                        We proposed (84 FR 7438 and 7439) to establish processes that would provide health IT developers that can document holding pre-certification under the FDA Software Precertification Pilot Program with exemptions to the ONC Health IT Certification Program's requirements for testing and certification of its health IT to the 2015 Edition “quality management systems” criterion (§ 170.315(g)(4)) and the 2015 Edition “safety-enhanced design” criterion (§ 170.315(g)(3)), as these criteria are applicable to the health IT developer's health IT presented for 
                        <PRTPAGE P="25664"/>
                        certification. We also stated that such a “recognition” could, depending on the final framework of the FDA Software Precertification Pilot Program, be applicable to the functionally-based 2015 Edition “clinical” certification criteria (§ 170.315(a)). We noted in the Proposed Rule that the proposed “recognition” could also be appropriate to address any or all of the following functionally-based 2015 Edition criteria in the event their proposed removal were not finalized: “problem list” (§ 170.315(a)(6)), “medication list” (§ 170.315(a)(7)), “medication allergy list” (§ 170.315(a)(8)), “drug-formulary and preferred drug list checks” (§ 170.315(a)(10)),” and “smoking status” (§ 170.315(a)(11)).
                    </P>
                    <P>We noted (84 FR 7439) that despite proffered benefits including alignment with both EOs 13563 and 13771 regarding deregulatory, less burdensome, and more effective regulatory schemes and programs, and serving as a regulatory relief for those health IT developers qualifying as small businesses under the Regulatory Flexibility Act (84 FR 7587 and 7588), there may be reasons not to adopt such a “recognition” approach. We noted as examples of such reasons that stakeholders may not agree that the FDA Software Precertification Program sufficiently aligns with our Program, and that stakeholders may have operational concerns. Accordingly, we welcomed comments on these and other aspects of our proposed “recognition” approach, including the 2015 Edition certification criteria that should be eligible for “recognition.”</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters commended ONC's efforts to recognize the FDA Software Precertification Program. However, most commenters expressed concerns that FDA's program was not yet mature enough to assess the degree of alignment to the ONC Health IT Certification Program. Many commenters expressed concerns that the FDA Software Precertification Pilot Program focuses on development and business practices, with a potential for streamlining requirements for pre-market clearance of specific functionalities, while ONC's certification Program focuses less on development practices and more on certification of individual software products as meeting Program-specified requirements for functionality and interoperability, including conformance with specific interoperability standards. Many of these commenters indicated that until the FDA program is more fully mature they would prefer to reserve judgment on how recognition could or should be structured to satisfy the needs of ONC's Program at lower burden on those developers for whom dual participation is a need or an appealing option. Several commenters noted potential for recognition of developers who achieve precertification status under the FDA's program to streamline or offer them a low-burden option for satisfying certain requirements under ONC's Program. However, several commenters urged that obtaining FDA precertification status should not be the only way a developer could satisfy any requirement under ONC's Program, noting that a developer of one or more certified Health IT Modules that is newer to the market or simply smaller and not engaged in development of software subject to FDA regulation could find the FDA Software Precertification Program's requirements a higher hurdle to entering or remaining in the ONC-certified health IT market sector than the ONC requirements the recognition might replace.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Considering commenters' concerns and the maturity of the FDA Software Precertification Program—which remains in a pilot phase at the time this final rule is being drafted—we have decided not to finalize recognition of the FDA Software Precertification Program at this time. However, we anticipate continuing to consult and coordinate with our colleagues at FDA and to monitor the details and experience of the FDA Software Precertification Program as it continues to mature. We continue to believe that there may be potential for recognition of the FDA Software Precertification Program to contribute in the future to our ongoing goals of reducing burden and promoting innovation while maintaining or enhancing the assurance that the ONC Health IT Certification Program provides, but we have not finalized our proposal at this time.
                    </P>
                    <HD SOURCE="HD3">b. Development of Similar Independent Program Processes—Request for Information</HD>
                    <P>In the Proposed Rule (84 FR 7439), we included a request for information (RFI) related to the development of similar independent processes to those of the FDA Software Precertification Program for purposes of our Program. We received 21 comments on this RFI and appreciate the input provided by commenters. We will continue to consider whether to develop similar independent processes and whether this should be included in future rulemaking.</P>
                    <HD SOURCE="HD1">IV. Updates to the 2015 Edition Certification Criteria</HD>
                    <P>In order to capture and share patient data efficiently, health care providers need health IT that store data in structured formats. Structured data allows health care providers to easily retrieve and transfer patient information, and use health IT in ways that can aid patient care. We proposed to update the 2015 Edition by adopting a limited set of revised and new 2015 Edition certification criteria, including new standards, to support these objectives. Some of these criteria and standards are included in the Certified EHR Technology (CEHRT) definition used for participation in HHS Programs, such as the Promoting Interoperability (PI) Programs (formerly the EHR Incentive Programs), some are required to be met for participation in the ONC Health IT Certification Program, and some, though beneficial, are unassociated with the CEHRT definition and not required for participation in any HHS program, including the ONC Health IT Certification Program (Program).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a few comments in support of our approach to modify the 2015 Edition health IT certification criteria. One commenter commended ONC for proposing logical updates to the 2015 Edition certification criteria, rather than overhauling the Program or establishing a new edition of certification, stating iterative changes will provide stability and allow the industry to adapt to new market forces. Commenters stated that this incremental approach best serves the health care provider and health IT developer community. One commenter applauded ONC for proposing logical updates to the 2015 Edition health IT certification criteria and recommended that ONC continue to seek to maximize the impact of these certification changes and pursue all opportunities to simplify existing criteria.
                    </P>
                    <P>
                        However, a number of commenters requested that ONC put forth a new edition and suggested varied approaches to a new edition. Commenters suggested that ONC clearly delineate the difference between the editions by creating a new naming convention for the updated criteria, such as a version number. Others recommended a 2020 Edition or the corresponding year in which this rule is effective. Still other commenters recommended the proposed updated 2015 Edition be renamed to the 2021 Edition instead of renamed with a Release 2 at end of the existing name. Some commenters identified the scope of the proposed 
                        <PRTPAGE P="25665"/>
                        changes as the reason ONC should establish the updates as a new edition of certification criteria rather than simply updating the 2015 Edition. However, the majority of commenters recommending a new edition based their concern on the potential confusion among providers who purchase and use certified health IT resulting from different products available under the same label.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input on the tradeoffs associated with modifying the current 2015 Edition versus creating a new edition. We considered a variety of factors when we framed our proposals. First, we reviewed the scope of each proposed update and the cumulative scope of the proposals overall for health IT developers and sought to identify whether it would be more appropriate to require health IT developers participating in the Program to implement updates to Health IT Modules certified to the 2015 Edition or to test and certify health IT products to an entirely new edition of certification criteria. Second, we considered the impact that either approach would have on health care providers, including how such updated Health IT Modules or products certified to a new edition would be implemented by providers participating in CMS programs.
                    </P>
                    <P>We have considered the impact on health IT developers related to the scope of the individual updates as well as the cumulative scope of all updates to the 2015 Edition adopted in this final rule (see also section XIII Regulatory Impact Analysis). In this final rule, we have only adopted two new technical certification criteria in § 170.315(b)(10) and § 170.315(g)(10) to which health IT developers seeking to upgrade their products will need to present Health IT Modules for certification. Unlike the new criteria introduced in prior certification edition rulemakings, both of these new criteria are an expansion or modification of existing criteria within the 2015 Edition which are currently in use in certified health IT. The new criteria in § 170.315(b)(10) relates to the 2015 Edition criteria in § 170.315(b)(6) with an expansion of the data and a removal of the specificity for the standard requirement. The new Standardized API criteria in § 170.315(g)(10) relates to the 2015 Edition API criteria with an expansion of security requirements and the addition of applicable standards. For the remainder of the updated criteria, a developer would not be required to present a Health IT Module for certification in order to update a certified product in accordance with this final rule. Instead, a health IT developer would update their certified Health IT Module, notify the ONC-ACB that they have done so, and make the update available their customers. Additionally, unlike prior certification edition rulemakings, the certification criteria updated to address compliance with the USCDI do not include new functionality nor do they require a complete redesign of Health IT Modules certified to such certification criteria. As noted in the Proposed Rule, the updates to the CCDS to create the USCDI were intentionally limited to a modest expansion that most health IT developers already supported, were already working toward, or should be capable of updating their health IT to support in a timely manner. Please see Table 1 for a list of all certification criteria changes.</P>
                    <P>In consideration of the impact our approach would have on health care providers, we note that impact and potential burden for providers is of particular importance given that CY2019 was the first performance year where eligible clinicians (ECs), eligible hospitals, dual-eligible hospitals, and critical access hospitals (CAHs) participating in CMS programs—including the CMS Promoting Interoperability Program and the Quality Payment Program/Merit-based Incentive Payment System—were required to use health information technology certified to the 2015 Edition to meet the requirements of the CMS CEHRT definition. If we were to adopt a new edition of certification criteria, CMS programs would have to consider establishing a new CEHRT definition and a subsequent requirement for program participants who have only recently completed a full edition update to their technology used for program participation. Historically, with a new edition of certification criteria, health IT developers have packaged Health IT Modules certified to new, modified, and unchanged criteria into a wholly new certified product. Historical data indicates that these complete updates to the edition are particularly challenging for both health IT developers seeking certification and for health care providers as they place deadlines for a significant number of health IT developers to support and implement new products for a significant number of health care providers simultaneously. As a result, the burden of updating the technology is compounded for both health IT developers and health care providers. While ONC does not itself place any such requirements on health care providers, we believe the risk of such significant burden must be considered in health IT policy decisions.</P>
                    <P>Further, we believe the scope of the updates and the impact on health IT developers and health care providers must be considered in tandem—meaning that an entirely new edition should only be established when the scope of the updates is significant enough to warrant the impacts of implementation. When the scope of updates does not warrant implementation of an entirely new edition of certification criteria, we believe it is appropriate to update the existing criteria. For example the 2015 Edition included new criteria that were neither built upon nor updated to existing criteria in the 2014 Edition, which was significantly different than the 2011 Edition. In contrast, health IT developers have been able to employ regular or cyclical updates without modifying all Health IT Modules certified to unchanged criteria in order to implement updates to existing certification criteria such as the annual updates to CMS eCQMs or for changes made to public health reporting standards. In such cases, the changes may be implemented by health IT developers in the manner most appropriate for their product and their customers, such as through routine service and maintenance rather than a completely new implementation.</P>
                    <P>In order to understand the impact these updates would have on participants in the CMS programs which reference them for use by program participants, we compare these updates to the current definition of CEHRT established by CMS at 42 CFR 495.4 for eligible hospitals, CAHs and Medicaid eligible professionals and at 42 CFR 414.1305 for eligible clinicians in MIPS. For 2019 and subsequent years, the CMS CEHRT definition specifies the use of EHR technology certified to 2015 Edition including technology that meets the 2015 Edition Base EHR definition in § 170.102, as well as other certified technology necessary to be a meaningful user. The updates finalized in this final rule impact both certification criteria included in the Base EHR definition as well as criteria required for applicable objectives and measures. Specifically, this final rule updates several criteria currently applicable for certified Health IT Modules used by CMS program participants for the CMS objectives and measures necessary to be a meaningful user, including:</P>
                    <P>
                        • Revisions to the electronic prescribing criterion in § 170.315(b)(3) to reference an updated e-prescribing standard;
                        <PRTPAGE P="25666"/>
                    </P>
                    <P>• Revisions relating to the drug-formulary and preferred drug list checks criterion in § 170.315(a)(10) to include at 170.550(m)(1) to only allow ONC-ACBs to issue certificates for this criterion until January 1, 2022;</P>
                    <P>• Replacement of the API criterion in § 170.315(g)(8) with a new API criterion in § 170.315(g)(10) referencing an API standard and related security standards;</P>
                    <P>• Revisions to several criteria to reference the USCDI and implement other standards updates (see Table 1 for specifics); and</P>
                    <P>• Revisions to § 170.315(c)(3), to update quality reporting standards.</P>
                    <P>In general, health IT developers have 24 months from the publication date of the final rule to make technology certified to these updated criteria available to their customers, and during this time developers may continue supporting technology certified to the prior version of certification criteria for use by their customers. For providers participating in CMS programs, this means they can continue to use the certified technology they have available to them to support program participation and can work with their developers to implement any updates in a manner that best meets their needs.</P>
                    <P>For the revisions to electronic prescribing criterion in § 170.315(b)(3) and to the quality reporting standards, in § 170.315(c)(3), the updates adopted for certified health IT align specifically with changes already required by CMS for use by health care providers. This means health IT developers are already implementing and supporting these updates. The implementation of these updates is driven by other requirements and so repackaging such updates in a new edition (or a new product) would create a redundancy and could have unintended cost burden on health care providers. For the updates to the criteria referencing the USCDI, as noted previously, we based the USCDI on the existing CCDS with modest expansion that most health IT developers already supported, were already working toward, or should be capable of updating their health IT to support in a timely manner. Finally, for the removal of the drug-formulary and preferred drug list checks in § 170.315(a)(10), we note that the removal from the Program has negligible impact on health care providers.</P>
                    <P>
                        First, as discussed in past CMS regulations related to the use of these functionalities by participants in CMS programs, health care providers have noted that while formulary checks are a promising approach, the utility of the specific functionality that is certified is not necessarily consistently applicable for all prescriptions (80 FR 62833). Second, as it does not remove the product from the market, any providers who are using the current functionality may continue to use the technology for their purposes. For the replacement of the API criterion in § 170.315(g)(8) with a new Standardized API criterion in § 170.315(g)(10) referencing an API standard and related security standards, we reiterate that health IT developers have 24 months from the date of publication of this final rule to update their technology and make such available to their customers. The 2015 Edition final rule adopted an API criterion in § 170.315(g)(8) which was implemented by many health IT developers using the underlying standard adopted in this final rule for the Standardized API criterion in § 170.315(g)(10). This common use impacted our decision to adopt the standard in our update to the 2015 Edition (
                        <E T="03">see</E>
                         also section VII.B.4.c Standardized API for Patient and Population Services). We, therefore, believe that both the scope of the updates and the potential impact on health IT developers and health care providers do not constitute sufficient justification for the potential burden associated with adopting an entirely new edition of certification criteria. Instead, we believe it is most reasonable and effective for these updates to be part of the existing 2015 Edition as modified in this final rule.
                    </P>
                    <P>We acknowledge the concerns of commenters who expressed the potential risk of confusion about the updates among their customers and how to best communicate that a product meets the updated version of a given certification criterion. We strongly encourage health IT developers to work with their customers to promote understanding of these updates. In addition, we have taken several mitigating steps. First, we revisited our proposed regulatory structure and revised it so that the structure more clearly reflects if a change is updating the previously adopted standard, or a more significant change to the criterion such as adding a new standard. This maintains the prior 2015 Edition regulatory structure for the majority of the updates except for § 170.315(b)(10) and (g)(10) as discussed previously, and establishes a more clear sense of scope.</P>
                    <P>
                        Second, in order to support effective communication of the updates, we are implementing a practical approach to facilitate transparency using the Certified Health IT Product List (CHPL),
                        <SU>22</SU>
                        <FTREF/>
                         which is the tool that health care providers and the general public may use to identify the specific certification status of a product at any given time, to explore any certification actions for a product, and to obtain a CMS Certification ID for a product used when participating in CMS programs. While we retain the overall 2015 Edition title, we will distinguish the 2015 Edition certification criteria from the new or revised criteria adopted in this final rule by referring to the new or revised criteria as the 2015 Edition Cures Update on the CHPL for products that are certified. The CHPL will also differentiate to what standards the health IT will be certified and will allow health care providers to identify if and when a specific Health IT Module has been updated. This will help to eliminate some of the confusion among providers who are seeking to understand the certification and update the status of the product they are currently using. It can also be a resource for providers who may be making a new purchase of certified health IT to make an informed decision about which products support the most up to date available standards and functionality.
                    </P>
                    <FTNT>
                        <P>
                            <SU>22</SU>
                             ONC Certified Health IT Product List: 
                            <E T="03">https://chpl.healthit.gov.</E>
                        </P>
                    </FTNT>
                    <P>
                        We further note that, while in the past ONC has largely relied on creating a new edition to implement changes to certification criteria, in each case, those changes included some updates to existing criteria, but also criteria containing functionality and standards that were entirely new and did not build on the prior edition. In addition, the Cures Act set in motion a shift for the ONC Health IT Certification Program by including Conditions and Maintenance of Certification requirements which allowed for processes such as the Standards Version Advancement Process (SVAP) flexibility within real world testing, which allows better alignment to industry efforts for standards advancement while maintaining accountability. These new provisions help to remove barriers for standards development and version updates, which limit a health IT developer's ability to provide individually relevant, timely, and innovative solutions to their clients. This change is consistent with our approach to adopt incremental updates in this final rule rather than to adopt a complete new edition of certification criteria. This final rule is the first time we have executed on the concept of Maintenance of Certification requirements for existing certificates, and we foresee the potential for future 
                        <PRTPAGE P="25667"/>
                        rulemakings to include incremental updates to certification criteria when such updates are appropriate.
                    </P>
                    <P>Please see Table 1 for a list of all certification criteria changes.</P>
                    <GPOTABLE COLS="5" OPTS="L2,p7,7/8,i1" CDEF="s50,r40,xs60,r100,r100">
                        <TTITLE>Table 1—2015 Edition Cures Update</TTITLE>
                        <BOXHD>
                            <CHED H="1">Certification criteria</CHED>
                            <CHED H="1">Reference</CHED>
                            <CHED H="1">
                                New/revised/
                                <LI>removed/time-</LI>
                                <LI>limited certification</LI>
                            </CHED>
                            <CHED H="1">2015 Edition cures update—timing</CHED>
                            <CHED H="1">Impact on CMS promoting interoperability (PI) programs</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Problem list</ENT>
                            <ENT>§ 170.315(a)(6)</ENT>
                            <ENT>Removed</ENT>
                            <ENT>Effective date of final rule (60 days after publication)</ENT>
                            <ENT>Removed from 2015 Edition Base EHR definition.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Medication list</ENT>
                            <ENT>§ 170.315(a)(7)</ENT>
                            <ENT>Removed</ENT>
                            <ENT>Effective date of final rule (60 days after publication)</ENT>
                            <ENT>Removed from 2015 Edition Base EHR definition.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Medication allergy list</ENT>
                            <ENT>§ 170.315(a)(8)</ENT>
                            <ENT>Removed</ENT>
                            <ENT>Effective date of final rule (60 days after publication)</ENT>
                            <ENT>Removed from 2015 Edition Base EHR definition.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Drug Formulary and Preferred Drug List Checks</ENT>
                            <ENT>§ 170.315(a)(10)</ENT>
                            <ENT>Time-limited Certification</ENT>
                            <ENT>ONC-ACBs only permitted to issue certificates for this criterion until January 1, 2022</ENT>
                            <ENT>
                                PI Measures:
                                <LI> —e-Rx</LI>
                                <LI> —-Query of PDMP Operational for Medicaid until January 1, 2022.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Smoking status</ENT>
                            <ENT>§ 170.315(a)(11)</ENT>
                            <ENT>Removed</ENT>
                            <ENT>Effective date of final rule (60 days after publication)</ENT>
                            <ENT>Removed from 2015 Edition Base EHR definition.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Patient-specific Education Resource</ENT>
                            <ENT>§ 170.315(a)(13)</ENT>
                            <ENT>Time-limited Certification</ENT>
                            <ENT>ONC-ACBs only permitted to issue certificates for this criterion until January 1, 2022</ENT>
                            <ENT>Operational for Medicaid until January 1, 2022 Supports Patient Electronic Access to Health Information Objective Measure.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Transitions of Care</ENT>
                            <ENT>§ 170.315(b)(1)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Update to USCDI/C-CDA companion guide within 24 months after the publication date of final rule</ENT>
                            <ENT>
                                PI Measures:
                                <LI> —Support Electronic Referral Loops by Sending Health Information</LI>
                                <LI> —Support Electronic Referral Loops by Receiving and Incorporating Health Information.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Clinical information reconciliation and incorporation</ENT>
                            <ENT>§ 170.315(b)(2)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Update to USCDI/C-CDA companion guide within 24 months after the publication date of final rule</ENT>
                            <ENT>
                                PI Measures:
                                <LI> —Support Electronic Referral Loops by Receiving and Incorporating Health Information.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Electronic prescribing</ENT>
                            <ENT>§ 170.315(b)(3)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Update standard within 24 months after the publication of final rule</ENT>
                            <ENT>
                                PI Measures:
                                <LI> —e-Prescribing.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Common Clinical Data Set summary record—create</ENT>
                            <ENT>§ 170.315(b)(4)</ENT>
                            <ENT>Removed</ENT>
                            <ENT O="xl">Effective date of final rule (60 days after publication).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Common Clinical Data Set summary record—receive</ENT>
                            <ENT>§ 170.315(b)(5)</ENT>
                            <ENT>Removed</ENT>
                            <ENT O="xl">Effective date of final rule (60 days after publication).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Data Export</ENT>
                            <ENT>§ 170.315(b)(6)</ENT>
                            <ENT>Time-limited Certification</ENT>
                            <ENT>ONC-ACBs may only issue certificates until 36 months after the publication date of the final rule</ENT>
                            <ENT>Removed from 2015 Edition Base EHR definition effective date of the final rule (60 days after publication).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Security tags—summary of care—send</ENT>
                            <ENT>§ 170.315(b)(7)</ENT>
                            <ENT>Revised</ENT>
                            <ENT O="xl">Document, section, and entry (data element) level; or Document level for the period until 24 months after publication date of final rule.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Security tags—summary of care—receive</ENT>
                            <ENT>§ 170.315(b)(8)</ENT>
                            <ENT>Revised</ENT>
                            <ENT O="xl">Document, section, and entry (data element) level; or Document level for the period until 24 months after publication date of final rule.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Care plan</ENT>
                            <ENT>§ 170.315(b)(9)</ENT>
                            <ENT>Revised</ENT>
                            <ENT O="xl">Update to C-CDA companion guide within 24 months after publication date of final rule.</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="01">EHI export</ENT>
                            <ENT>§ 170.315(b)(10)</ENT>
                            <ENT>New</ENT>
                            <ENT O="xl">Update within 36 months of publication date of final rule.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Clinical quality measures (CQMs)—report</ENT>
                            <ENT>§ 170.315(c)(3)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Effective date of final rule (60 days after publication)</ENT>
                            <ENT>PI Programs.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Auditable events and tamper-resistance</ENT>
                            <ENT>§ 170.315(d)(2)</ENT>
                            <ENT>Revised</ENT>
                            <ENT O="xl">Update to new ASTM standard within 24 months after publication date of final rule.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Audit report(s)</ENT>
                            <ENT>§ 170.315(d)(3)</ENT>
                            <ENT>Revised</ENT>
                            <ENT O="xl">Update to new ASTM standard within 24 months after publication date of final rule.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Auditing actions on health information</ENT>
                            <ENT>§ 170.315(d)(10)</ENT>
                            <ENT>Revised</ENT>
                            <ENT O="xl">Update to new ASTM standard within 24 months after publication date of final rule.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Encrypt authentication credentials</ENT>
                            <ENT>§ 170.315(d)(12)</ENT>
                            <ENT>New</ENT>
                            <ENT O="xl">Effective date of final rule (60 days after publication) (New and updated certifications only).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Multi-factor authentication (MFA)</ENT>
                            <ENT>§ 170.315(d)(13)</ENT>
                            <ENT>New</ENT>
                            <ENT O="xl">Effective date of final rule (60 days after publication) (New and updated certifications only).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">View, Download, and Transmit to 3rd Party</ENT>
                            <ENT>§ 170.315(e)(1)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Update to USCDI/C-CDA companion guide within 24 months after publication date of final rule</ENT>
                            <ENT>
                                PI Measure:
                                <LI> —Provide Patients Electronic Access to Their Health Information.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Secure Messaging</ENT>
                            <ENT>§ 170.315(e)(2)</ENT>
                            <ENT>Time-limited Certification</ENT>
                            <ENT>ONC-ACBs only permitted to issue certificates for this criterion until January 1, 2022</ENT>
                            <ENT>Operational for Medicaid until January 1, 2022 Supports the Coordination of Care through Patient Engagement Objective.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Transmission to public health agencies— electronic case reporting</ENT>
                            <ENT>§ 170.315(f)(5)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Update to USCDI/C-CDA companion guide within 24 months after publication date of final rule</ENT>
                            <ENT>
                                PI Measure:
                                <LI> —Electronic Case Reporting.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Consolidated CDA creation performance</ENT>
                            <ENT>§ 170.315(g)(6)</ENT>
                            <ENT>Revised</ENT>
                            <ENT O="xl">Update to USCDI/C-CDA companion guide within 24 months after publication date of final rule.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Application Access—Data Category Request</ENT>
                            <ENT>§ 170.315(g)(8)</ENT>
                            <ENT>Time-limited Certification</ENT>
                            <ENT>24 months after publication date of final rule</ENT>
                            <ENT>
                                PI Measure:
                                <LI> —Provide Patients Electronic Access to Their Health Information.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25668"/>
                            <ENT I="01">Application Access—All Data Request</ENT>
                            <ENT>§ 170.315(g)(9)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Update to USCDI/C-CDA companion guide within 24 months after publication date of final rule</ENT>
                            <ENT>
                                PI Measure:
                                <LI> —Provide Patients Electronic Access to Their Health Information.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Standardized API for patient and population services</ENT>
                            <ENT>§ 170.315(g)(10)</ENT>
                            <ENT>New</ENT>
                            <ENT>Update within 24 months of publication date of final rule</ENT>
                            <ENT>Added to the 2015 Edition Base EHR definition.</ENT>
                        </ROW>
                        <TNOTE>Note: The CHPL will be updated to indicate the standards utilized for new or revised certification criteria, as well as denote criteria removed from the Program.</TNOTE>
                    </GPOTABLE>
                    <HD SOURCE="HD2">A. Standards and Implementation Specifications</HD>
                    <HD SOURCE="HD3">1. National Technology Transfer and Advancement Act</HD>
                    <P>
                        The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 
                        <E T="03">et. seq.</E>
                        ) and the Office of Management and Budget (OMB) Circular A-119 
                        <SU>23</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 standards 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 determined that such standards are inconsistent with applicable law or otherwise impractical, and instead use a government-unique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A-119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that meet the agency's regulatory, procurement or program needs, deliver favorable technical and economic outcomes, and are widely utilized in the marketplace.
                    </P>
                    <FTNT>
                        <P>
                            <SU>23</SU>
                             
                            <E T="03">https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A119/revised_circular_a-119_as_of_1_22.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters stated that they do not support Federal programs' use of the NTTAA voluntary consensus standards exceptions, and asked that the involved Federal programs continue to utilize consensus-based standards developed through work done by organizations such as HL7®. They noted that such work incorporates public health inputs, and stated that it is critical for there to be sufficient discussion and consideration of all stakeholder concerns in adopting such critical technologies such as FHIR®.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We clarify that many of the standards we adopt in this final rule are developed and/or adopted by voluntary consensus standards bodies, except where we found that a government unique standard is more appropriate. We are aware of no voluntary consensus standards that could serve as an alternative for the following purposes in this final rule.
                    </P>
                    <P>In this final rule, we use voluntary consensus standards except for:</P>
                    <P>
                        • The standard adopted in § 170.213, the United States Core Data for Interoperability (USCDI), Version 1 (v1), is a hybrid of government unique 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). We have placed time limitations on the predecessor to this standard, the Common Clinical Data Set (CCDS) definition, under this rule, and replaced it with the USCDI in all applicable criteria except for the data export criterion in § 170.315(b)(6), on which we have also placed a time limit. We refer readers to the “Revised and New 2015 Edition Criteria” in section IV.B of this preamble.
                    </P>
                    <P>• The standards adopted in § 170.205(h)(3) and (k)(3). We replaced the current HL7® QRDA standards with government unique standards, the CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting; Implementation Guide for 2019, and the CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2019, that will more effectively support the associated certification criterion's use case, which is reporting electronic clinical quality measure (eCQM) data to CMS.</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/or implementation specifications in a 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/or implementation specification includes the entire incorporated document, unless we specify otherwise. For example, for the HL7® FHIR U.S. Core Implementation Guide (IG) STU 3.1.0 adopted in this final rule (
                        <E T="03">see</E>
                         section VII.B.4), 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 
                        <E T="03">unless</E>
                         we specified otherwise in regulation. In such cases, the regulatory text would preempt the permissiveness of the IG.
                    </P>
                    <HD SOURCE="HD3">3. “Reasonably Available” to Interested Parties</HD>
                    <P>
                        The Office of the Federal Register has established requirements for materials (
                        <E T="03">e.g.,</E>
                         standards and implementation specifications) that agencies propose to incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5(b)). To comply with these requirements, in section XI (“Incorporation by Reference”) of this preamble, we provide summaries of, and uniform resource locators (URLs) to, the standards and implementation specifications we have adopted and subsequently incorporate by reference in the Code of Federal Regulations. To note, we also provide relevant information about these standards and implementation specifications 
                        <PRTPAGE P="25669"/>
                        throughout the relevant preamble policy discussions and regulation text sections of the final rule.
                    </P>
                    <HD SOURCE="HD2">B. Revised and New 2015 Edition Criteria</HD>
                    <HD SOURCE="HD3">1. The United States Core Data for Interoperability Standard (USCDI)</HD>
                    <P>As we noted in the Proposed Rule, the initial focus of the Program was to support the Medicare and Medicaid EHR Incentive Programs (76 FR 1294) now referred to as the Promoting Interoperability (PI) Programs. As such, the 2014 Edition certification criteria mirrored those functions specified by the CMS PI Programs objectives and measures for providers demonstrating meaningful use (MU) of certified health IT. In order to improve efficiency and streamline the common data within our Program's certification criteria, we created a single definition for all the required data that could be referenced for all applicable certification criteria. We created the term “Common MU Data Set” to encompass the common set of MU data types/elements (and associated vocabulary standards) for which certification would be required across several certification criteria (77 FR 54170).</P>
                    <P>The 2015 Edition final rule modified the Program to make it open and accessible to more types of health IT, and health IT that supports various care and practice settings beyond those included in the CMS PI Programs (80 FR 62604). In comparison to the previous editions, the 2015 Edition focused on identifying health IT components necessary to establish an interoperable nationwide health information infrastructure, fostering innovation and opening new market opportunities, and allowing for more health care provider and patient choices in electronic health information access and exchange. In order to align with this approach, we made changes in the 2015 Edition final rule that resulted in updated vocabulary and content standards to improve and advance interoperability and health information exchange (80 FR 62604). The 2015 Edition final rule further expanded accessibility and availability of data exchanged by updating the definition of Base EHR in the 2015 Edition to include enhanced data export, transitions of care, and application programming interface (API) capabilities, all of which previously required that, at a minimum, the CCDS be available (80 FR 62602 through 62604).</P>
                    <P>
                        We further noted in the Proposed Rule (84 FR 7440) that the regulatory approach to using and referencing a “definition” to identify electronic health information, for access, exchange and use, including associated vocabulary codes, has had its drawbacks. While ONC's “CCDS” definition served its designed purpose (to reduce repetitive text in each of the certification criteria in which it is referenced), the term CCDS, and the data set it represents, also began to be used by outside organizations such as the Argonaut Project 
                        <SU>24</SU>
                        <FTREF/>
                         for additional use cases beyond the C-CDA and ONC's Health IT Certification Program. As these organizations identified the need to expand the content of the CCDS, the CCDS definition in regulation became a limitation to developing additional data access, exchange, and uses outside of ONC's programs. As we move towards value-based care and the inclusion of Data Classes that go beyond clinical data, and as part of ONC's continued efforts to evaluate the availability of a minimum baseline of Data Classes that must be commonly available for interoperable exchange, we acknowledge the need to change and improve our regulatory approach to the CCDS. Therefore, in order to advance interoperability by adopting new data and vocabulary codes sets that support data exchange, we proposed to remove the “Common Clinical Data Set” in § 170.315(b)(4) and § 170.315(b)(5), and its references throughout the 2015 Edition and replace it with the “United States Core Data for Interoperability” (USCDI) standard. This first version of USCDI will be designated “version 1 (v1).” The USCDI standard aims to achieve the goals set forth in the Cures Act by specifying a common set of data classes and elements that have been designed to improve data usage and interoperable data exchange.
                    </P>
                    <FTNT>
                        <P>
                            <SU>24</SU>
                             
                            <E T="03">https://argonautwiki.hl7.org/Main_Page.</E>
                        </P>
                    </FTNT>
                    <P>
                        We proposed to adopt the USCDI v1 as a standard defined in § 170.102. Here, “Standard” is defined as a “technical, functional, or performance-based rule, condition, requirement, or specification that stipulates instructions, fields, codes, data, materials, characteristics, or actions.” The USCDI standard would be composed of Data Classes, which may be further delineated into groupings of specific Data Element(s). For example, “patient demographics” is a Data Class, and within that Data Class there is “patient name,” which is a Data Element. As noted in section IV.B.1.b, for the overall structure and organization of the USCDI, please consult 
                        <E T="03">www.healthIT.gov/USCDI</E>
                        .
                    </P>
                    <P>We noted in the Proposed Rule (84 FR 7441) that ONC intended to establish and follow a predictable, transparent, and collaborative process to expand the USCDI, including providing stakeholders with the opportunity to comment on the USCDI's expansion. We indicated that once the Secretary adopts the first version of the USCDI through rulemaking, which we proposed in § 170.213 in the Proposed Rule, health IT developers would be allowed to take advantage of the “Standards Version Advancement Process” (SVAP) flexibility. The SVAP (which we proposed in § 170.405(b) and which is discussed in section VII.B.5, below) would permit health IT developers to voluntarily implement and use a newer version of a Secretary-adopted standard such as the USCDI, subject to certain conditions including a requirement that the newer version is approved for use by the National Coordinator, and does not conflict with requirements under other applicable law. We received a number of comments regarding these proposals, which are outlined in the subsections below.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received broad support for the adoption of version 1 of the USCDI as a new standard defining critical health care data to promote interoperability. Some commenters from health plans, while supportive of patient and provider access to health care data, voiced concerns about health plans being required to make data available in the USCDI standard. Other commenters noted that USCDI v1 does not include data classes and elements that pertain to all health care settings, including public health, and would therefore not be broadly applicable to all health care settings.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of the adoption of USCDI v1 as a standard. We wish to clarify that the adoption of version 1 of the USCDI as a standard for our Program is not specific to a setting of care, a health care specialty, or a specific category of health IT user. Nor is the USCDI specific to a particular content exchange standard (
                        <E T="03">e.g.,</E>
                         HL7 C-CDA, HL7 FHIR, HL7 V2, and NCPDP SCRIPT). Rather, it applies to the certification of health IT and certified health IT's ability to send and receive the Data Elements defined by USCDI without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. While some users may find few opportunities to exchange these Data Elements, many will exchange these Data Elements frequently, and we believe that all health care providers should have certified health IT that can provide them with a means to appropriately share and access the USCDI data set when exchanging data with other providers. Accordingly, we 
                        <PRTPAGE P="25670"/>
                        seek to clarify a point with respect to our proposal regarding the USCDI and health IT certification. For the purposes of the ONC Health IT Certification Program, specific certification criteria are the way the USCDI comes into effect. For example, the USCDI is referenced as part of the data requirements in the updated “transitions of care” certification criterion (§ 170.315(b)(1)), which also specifies that for certification to that criterion, the C-CDA must be used as the syntax to hold all of the USCDI data.
                    </P>
                    <P>As we explained, we believe that the adoption of USCDI v1 for all certified health IT will advance interoperability by ensuring utilization of common data and vocabulary code sets, and that standardization will support both electronic exchange and usability of the data. Furthermore, because ONC will establish and follow a predictable, transparent, and collaborative process to expand future versions of USCDI, including providing stakeholders with the opportunity to comment on draft USCDI's expansion, stakeholders will have ample opportunities to advance additional Data Classes and Data Elements relevant to a wide range of health care use cases. After consideration of these comments and the overall support of commenters, we have adopted the USCDI v1 as a standard in § 170.213.</P>
                    <P>We have also extended the compliance timelines with which a health IT developer needs to update to the USCDI, therefore, we have not removed the CCDS definition from § 170.102 as proposed but revised it to remove references to 2014 Edition standards and provided time limitations for when health IT developers need to update to the USCDI.</P>
                    <HD SOURCE="HD3">a. USCDI 2015 Edition Certification Criteria</HD>
                    <P>
                        We proposed (84 FR 7441) to adopt the USCDI Version 1 (USCDI v1) in § 170.213.
                        <SU>25</SU>
                        <FTREF/>
                         The USCDI is a standardized set of health Data Classes and constituent Data Elements that would be required to support nationwide electronic health information exchange. Once adopted in this final rule, health IT developers would be required to update their certified health IT to support the USCDI v1 for all certification criteria affected by this proposed change. We also proposed conforming changes in the sections below to update the following formerly CCDS-dependent 2015 Edition certification criteria to incorporate the USCDI standard:
                    </P>
                    <FTNT>
                        <P>
                            <SU>25</SU>
                             We note that USCDI v1 is an updated version and distinguished from the 
                            <E T="03">Draft United States Core Data for Interoperability (USCDI)</E>
                             previously made available for public review and comment in the course of its development as a prospective standard. The data classes and elements in the USCDI v1 were proposed in § 170.213 and defined in the Proposed Rule, and an additional USCDI v1 document with technical standards information was posted electronically concurrent with the publication of the Proposed Rule in order to provide the public adequate time to fully review and comment on both the proposed regulation and the USCDI v1 technical information.
                        </P>
                    </FTNT>
                    <P>• “transitions of care” (§ 170.315(b)(1));</P>
                    <P>• “view, download, and transmit to 3rd party” (§ 170.315(e)(1));</P>
                    <P>• “transmission to public health agencies—electronic case reporting” (§ 170.315(f)(5));</P>
                    <P>• “consolidated CDA creation performance” (§ 170.315(g)(6)); and</P>
                    <P>• “application access—all data request” (§ 170.315(g)(9)).</P>
                    <P>We did not include the “data export” criterion (§ 170.315(b)(6)) in the proposed list of criteria that would be revised to include the USCDI standard because we proposed to remove the “data export” criterion (§ 170.315(b)(6)) and instead proposed to adopt a criterion that we referenced as “EHI export” in the Proposed Rule (§ 170.315(b)(10)). For similar reasons, we did not include the “application access—data category request” criterion (§ 170.315(g)(8)) because we proposed to replace it with the API certification criterion (§ 170.315(g)(10)) that derives its data requirements from the USCDI.</P>
                    <P>
                        We also proposed, as a Maintenance of Certification requirement (§ 170.405(b)(3)) for the real world testing Condition of Certification requirement (§ 170.405(a)), that health IT developers with health IT certified to the five above-identified certification criteria prior to the effective date of this final rule would have to update such certified health IT to the proposed revised standards (84 FR 7441 and 7596). We further proposed, as a Maintenance of Certification requirement (§ 170.405(b)(3)) for the real world testing Condition of Certification requirement (§ 170.405(a)), that health IT developers must provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the effective date of this final rule (84 FR 7441 and 84 FR 7596). For the purposes of meeting this compliance timeline, we noted that we expected health IT developers to update their certified health IT and notify their ONC-ACB on the date at which they have reached compliance. We noted that developers would also need to factor these updates into their next real world testing plan as discussed in section VII.B.5 of the Proposed Rule.
                        <SU>26</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             The finalized real world testing Condition and Maintenance of Certification requirements are discussed in section VII.B.5 of this final rule.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported the proposed adoption of USCDI v1 and incorporation of the USCDI into the revised and new certification criteria. Some commenters expressed concern that incorporation of the USCDI into the “transmission to public health agencies—electronic case reporting” certification criteria could have a negative impact on data received by public health reporting programs. Some commenters stressed the need for reasonable adoption timelines. Some suggested a longer adoption and implementation timeline for incorporation of the USCDI as part of certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC acknowledges that some entities, such as public health agencies, may need to consider what the expanded set of data the USCDI v1 offers may mean to their reporting programs and requirements. To be clear, the USCDI's existence as a stand-alone standard will not impact or change public health reporting requirements. However, certain data now included in the USCDI, such as clinical notes, would now become more readily available for public health reporting and a State's public health program's policy may need to be revisited if a State seeks to make use of the “new” data the adoption of the USCDI stands to make more easily available, and more usable upon receipt. We also believe that the proposed 24-month timeline for updating certified health IT to comply with the new USCDI standard in § 170.213 is an adequate implementation timeline, based on other adoption timelines with similar technical complexities. We, therefore, have finalized revisions for the five above-identified formerly CCDS-dependent 2015 Edition certification criteria to incorporate the USCDI standard.
                    </P>
                    <P>
                        We have finalized a modification to the regulation text for these criteria based on public comment related to mitigating the risk of potential confusion caused by updates to existing criteria. As discussed earlier in this preamble (section IV), we received public comment requesting that all revised criteria be included in a new edition of certification criteria. At the start of section IV, we discuss in response to these comments that we do not believe the creation of a new edition is appropriate given that the scope of the updates to the 2015 Edition is tied 
                        <PRTPAGE P="25671"/>
                        to standards updates required to keep pace with current industry practices. However, we do plan to distinguish the 2015 Edition certification criteria from the updated criteria in this final rule by referring to them as the 2015 Edition Cures Update on the CHPL.
                    </P>
                    <P>However, as Health IT Modules are updated to the new standards over time, there is a need to define what is required for certification and what is required for compliance to prior certification. Therefore, we have finalized that for criteria being updated from the CCDS to the USCDI, 24 months after publication date of the final rule shall be applicable for a transition from the CCDS to the USCDI. We have finalized that for the period until 24 months after the publication date of the final rule, the CCDS remains applicable for certified Health IT Modules until such Health IT Modules are updated to the USCDI. This means that upon the effective date of the rule, for the identified criteria the following apply for certification and compliance:</P>
                    <P>• The USCDI, or</P>
                    <P>• The CCDS for the period up to 24 months after the publication date of the final rule.</P>
                    <P>This allows for developers to plan the transition for their products more effectively and supports certification continuity. We have finalized a modification to the regulation text to require the USCDI, or the CCDS for the period lasting until 24 months after the publication date of the final rule.</P>
                    <P>We have finalized this modification to the regulation text for the following criteria:</P>
                    <P>• “transitions of care” (§ 170.315(b)(1));</P>
                    <P>• “view, download, and transmit to 3rd party” (§ 170.315(e)(1));</P>
                    <P>• “transmission to public health agencies—electronic case reporting” (§ 170.315(f)(5));</P>
                    <P>• “consolidated CDA creation performance” (§ 170.315(g)(6)); and</P>
                    <P>• “application access—all data request” (§ 170.315(g)(9)).</P>
                    <P>We have finalized in § 170.405(b)(3), as a Maintenance of Certification requirement under the real world testing Condition of Certification requirement, that health IT developers with health IT certified to the five above-identified certification criteria prior to the effective date of this final rule, would have to update such certified health IT to the revisions within 24 months of the publication date of this rule.</P>
                    <P>As of this final rule's effective date, the “data export” criterion in § 170.315(b)(6) is no longer required as a part of the 2015 Edition Base EHR definition. ONC-ACB's will not be permitted to issue certificates to this certification criteria after 36 months after the publication date of this final rule. As discussed in the “EHI export” section below, we have retained § 170.315(b)(6) “as is,” without updates to the USCDI. Thus, health IT developers with health IT certified to the prior certification criterion in § 170.315(b)(6) do not have to update such certified health IT to the revisions listed above, but are permitted to maintain or seek new Health IT Module certification to this criterion should they desire this functionality.</P>
                    <HD SOURCE="HD3">b. USCDI Standard—Data Classes Included</HD>
                    <P>
                        As we noted in the Proposed Rule (84 FR 7441), the USCDI Version 1 (USCDI v1) and its constituent Data Elements incorporated recommendations we had accepted from public comments we had previously received on our Draft USCDI and Proposed Expansion Process,
                        <SU>27</SU>
                        <FTREF/>
                         which we published January 5, 2018 as well as initial feedback on that draft from the Health IT Advisory Committee, both of which occurred prior to the publication of the Proposed Rule. The standard we proposed to adopt in § 170.213 also reflected and acknowledged the burden that rapidly expanding the USCDI v1 beyond the CCDS could cause. As a result, the USCDI v1 that we proposed was a modest expansion of the CCDS, which we indicated that most health IT developers already supported, were already working toward, or should be capable of updating their health IT to support in a timely manner. Therefore, in our Proposed Rule, we outlined only the delta between the CCDS and the USCDI v1. For the overall structure and organization of the USCDI standard, we urged stakeholders to consult 
                        <E T="03">www.healthIT.gov/USCDI</E>
                        .
                    </P>
                    <FTNT>
                        <P>
                            <SU>27</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/draft-uscdi.pdf</E>
                            <E T="03"> (January 5, 2018).</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received numerous comments proposing new Data Classes, Data Elements, and other changes within the USCDI beyond those we included in the Proposed Rule. Comments recommended including new Data Elements and/or classes within the USCDI v1 related to encounter data, financial transaction and insurance data, and specialty-specific Data Elements related to cancer treatment, social determinants of health, and more. Another commenter identified an error in the Procedures Data Class citing the wrong code set for dental procedures in the USCDI v1.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the many commenters for their input on the USCDI. We recognize that the USCDI v1 as proposed represents a modest change over the current CCDS definition. As we indicated in the Proposed Rule (84 FR 7441), we view this initial version of the USCDI standard as a starting point to support improved interoperability. We are also sensitive to requirements related to the development and implementation of adopting the USCDI standard. In the interests of maintaining our proposed implementation timeline of 24 months from the publication of this final rule, and after consideration of these comments and the overall support of commenters, we have finalized the adoption of the Data Classes and elements of the USCDI standard as proposed, with changes outlined in the subsections below. Additionally, in order to address the error pointed out to us via comments in the Procedures Data Class, as was stated in the draft USCDI v1,
                        <SU>28</SU>
                        <FTREF/>
                         we clarified that the American Dental Association's Code on Dental Procedures and Nomenclature (CDT) should be used for Dental Procedures in the USCDI v1, not SNODENT as was erroneously stated in the draft USCDI v1.
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/draft-uscdi.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        With respect to the USCDI's expansion in future years, ONC will establish and follow a predictable, transparent, and collaborative process to expand the USCDI, which will provide stakeholders with the opportunity to comment on the USCDI's expansion and to advance additional Data Classes and Data Elements relevant to a wide range of use cases related to health care. Prior to this final rule, we published our initial thinking as well as examples of Data Classes and Data Elements that we believed could be appropriate to propose for adding to the USCDI.
                        <SU>29</SU>
                        <FTREF/>
                         We have also solicited feedback and recommendations from the HITAC. As we evaluated public comments and conducted our own research prior to the issuance of this final rule, we also wanted to identify for stakeholders another potential source that could be used to focus efforts around new USCDI Data Classes and Data Elements. As is noted throughout this rule, the HL7® FHIR® standard represents health information in what are called “FHIR resources.” When it comes to logically organizing FHIR resources that relate to one another and share common properties, FHIR uses a concept called a “compartment.” Through the standards development process a “Patient Compartment” has been 
                        <PRTPAGE P="25672"/>
                        created, which lists all of the FHIR resources that are associated with a patient. The Patient Compartment “includes any resources where the subject of the resource is the patient, and some other resources that are directly linked to resources in the patient compartment.” This organizing framework provides a potentially rich set of a Data Classes and Data Elements to consider for inclusion in the USCDI, including clinical, encounter, specialty, and financial data. As ONC looks to make its own investments to advance the implementation experience associated with prospective USCDI Data Classes and Data Elements, we intend to leverage the Patient Compartment to guide our thinking. In addition, we will also look to and encourage industry to look at other organizing frameworks such as the Clinical Quality/Clinical Decision Support realms and the payer-to-provider community (
                        <E T="03">e.g.,</E>
                         DaVinci Project 
                        <SU>30</SU>
                        <FTREF/>
                        ) to help identify data that would be best to focus on for USCDI expansion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>29</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/draft-uscdi.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>30</SU>
                             
                            <E T="03">http://www.hl7.org/about/davinci/index.cfm.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">i. Updated Versions of Vocabulary Standard Code Sets</HD>
                    <P>We proposed (84 FR 7441) that the USCDI v1 would include the newest versions of the “minimum standard” code sets included in the CCDS available at publication of this final rule. We requested comment on that proposal and on whether it could result in any interoperability concerns. We also noted that criteria such as the 2015 Edition “family health history” criterion (§ 170.315(a)(12)), the 2015 Edition “transmission to immunization registries” criterion (§ 170.315(f)(1)), and the 2015 Edition “transmission to public health agencies—syndromic surveillance” criterion (§ 170.315(f)(2)) reference “minimum standard” code sets; however, we indicated that we were considering updating the versions of these standards listed and incorporated by reference in part 170 subpart B that are referenced by these criteria from the versions adopted in the 2015 Edition final rule.</P>
                    <P>We also noted, for purposes of clarity, that consistent with § 170.555, unless the Secretary prohibits the use of a newer version of an identified minimum standard code set for certification, health IT could continue to be certified or upgraded by developers to a newer version of an identified minimum standard code set than that included in USCDI v1 or the most recent USCDI version that the National Coordinator has approved for use in the Program using the SVAP flexibility.</P>
                    <P>
                        <E T="03">Comments.</E>
                         There was general support from commenters for updating “minimum standard” code sets requirements to the newest versions of these code sets as part of the update from CCDS to the USCDI. One commenter recommended adopting the Data Class requirement first, followed by a delayed requirement of updated versions of the “minimum standards” code sets, in order to allow implementers more time to make changes to their systems.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not believe that adopting the corresponding “minimum standards” code sets that are updated in the USCDI v1 would impose a significant burden on implementers. In consideration of the overall support from commenters, we have finalized our proposal that the USCDI v1 include the newest versions of the “minimum standard” code sets available at the time of finalization of this final rule. We have not, however, finalized the proposal for the 2015 Edition “family health history” criterion (§ 170.315(a)(12)), the 2015 Edition “transmission to immunization registries” criterion (§ 170.315(f)(1)), and the 2015 Edition “transmission to public health agencies—syndromic surveillance” criterion (§ 170.315(f)(2)) to reference the newest versions of the “minimum standard” code sets for these criteria, because the flexibility already exists to use newer versions of code sets included in these criteria. We note that for these certification criteria, health IT developers may take advantage of the previously established 
                        <SU>31</SU>
                        <FTREF/>
                         flexibility to seek certification to newer versions of the “minimum standards” code with § 170.555.
                    </P>
                    <FTNT>
                        <P>
                            <SU>31</SU>
                             77 FR 54163, 54268-69 (September 4, 2012).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. Address and Phone Number</HD>
                    <P>We proposed (84 FR 7442) new Data Elements in the USCDI v1 for “address” and “phone number.” We noted that the inclusion of “address” (to represent the postal location for the patient) and “phone number” (to represent the patient's telephone number) would improve the comprehensiveness of health information for patient care. We further noted that the inclusion of these Data Elements was consistent with the list of patient matching Data Elements already specified in the 2015 Edition “transitions of care” certification criterion (§ 170.315(b)(1)(iii)(G)), which supports the exchange of patient health information between providers of patient care.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters unanimously supported the addition of address and phone numbers to the USCDI v1. The majority of commenters on this proposal recommended the use of the U.S. Postal Service address format to improve address data quality. Commenters also recommended additional elements of address and phone number indicating effective period (
                        <E T="03">e.g.,</E>
                         current address, former address); use (
                        <E T="03">e.g.,</E>
                         mobile phone number, landline, etc.), and email address.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their recommendations and agree that these additional Data Elements can be useful to provide better care and assist with patient matching. In consideration of these comments, we have finalized the addition of the following Data Elements within the Patient Demographics Data Class:
                    </P>
                    <P>• “current address”;</P>
                    <P>• “previous address”;</P>
                    <P>• “phone number”;</P>
                    <P>• “phone number type”; and</P>
                    <P>• “email address.”</P>
                    <P>We further clarify that “phone number” and “phone number type” must be represented using the same standards, ITU-T E.123 (02/2001) and ITU-T E.164, as already adopted for this data in 45 CFR 170.207(q) and referenced in the 2015 Edition “transitions of care” certification criterion (§ 170.315(b)(1)(iii)(G)).</P>
                    <P>
                        We appreciate commenters' recommendations to use the U.S. Postal Service Postal Addressing Standards, which include address formatting guidance and a variety of products to improve address quality, such as address element standardization and validation which are published and available for public use.
                        <SU>32</SU>
                        <FTREF/>
                         The U.S. Postal Service Postal Addressing Standards include standardized names for common unit identifiers, line by line acceptance requirements for mail services, and overall address format guidance that has been specifically designed to support labelling of mail items for acceptance by the U.S. Postal Service automated sorting processes. We acknowledge the potential for its use within health IT to improve patient matching. However, while the U.S. Postal Service Postal Addressing Standards include a single representation for certain data elements (such as rendering apartment as apt, building as bldg, floor as fl, etc.) they also allow variations for other data elements, such as “acceptable” and “preferred” spellings and abbreviations for street and city names. This may result in multiple “valid” addresses. To reconcile this variation, the U.S. Postal Service provides a file listing preferred 
                        <PRTPAGE P="25673"/>
                        city and State combinations as well as a file of street name and zip code combinations and the resulting aggregated address would then require manual reconciliation. We believe the U.S. Postal Service Postal Addressing Standards may be useful guidance for health IT developers. However, because of the variation, the required use of reference files, and the manual reconciliation necessary for implementation, we have not adopted the U.S. Postal Service Postal Addressing Standards as a required standard for the address Data Elements within the USCDI. We encourage the use of standardized elements to accurately represent patient address including use of standardized references in the U.S Post Service Postal Addressing Standards where applicable. In addition, we will continue to work with standards developing organizations to evaluate potential solutions to improve patient matching, including considering the potential adaptability of the U.S. Postal Service formats for health IT use cases.
                    </P>
                    <FTNT>
                        <P>
                            <SU>32</SU>
                             U.S. Postal Service: Postal Addressing Standards (Publication 28) available at 
                            <E T="03">https://pe.usps.com/text/pub28/welcome.htm</E>
                            .
                        </P>
                    </FTNT>
                    <P>The U.S. Postal Service also maintains web based tools for address validation services and provides implementation guidance to integrate these tools into technical workflows for IT systems in e-commerce and other industries. We agree that these address validation tools have the potential to greatly improve address data quality, and we encourage health IT developers and other relevant health IT users such as health information networks to explore mechanisms by which such address validation might support patient matching. While not specifically designed for patient matching and other health care related applications, USPS address validation has been piloted in these settings. To adapt the address validation tool to a health care purpose requires the services of a third party with licensing of the tool and the development of a bespoke process to execute the tool. The aggregated patient address could then be compared against the USPS address on file and the patient data could be amended where inaccurate, appended where incomplete, or a linked record of secondary address data could be created depending on the percent of confidence in the specific match. This process would then require manual reconciliation. The results of these pilots indicate significant complexity and burden associated with implementation of this process. Given these burdens, we believe it would not be appropriate to require the integration of this distinct functionality into certified health IT at this time. We again encourage the further development and use of standardized approaches for address validation and will continue to monitor and analyze such efforts for consideration in future rulemaking.</P>
                    <HD SOURCE="HD3">iii. Pediatric Vital Signs</HD>
                    <P>As proposed (84 FR 7442), the USCDI v1 included the pediatric vital sign data elements, which are specified as optional health information in the 2015 Edition CCDS definition. The proposed pediatric vital signs included: head occipital-frontal circumference for children less than 3 years of age, BMI percentile per age and sex for youth 2-20 years of age, weight for age per length and sex for children less than 3 years of age, and the reference range/scale or growth curve, as appropriate. As explained in section VI.A.2 of this final rule, the inclusion of pediatric vital sign Data Elements in the draft USCDI v1 align with the provisions of the Cures Act related to health IT to support the health care of children. Prior to the publication of the Proposed Rule, stakeholders emphasized the value of pediatric vital sign data elements to better support the safety and quality of care delivered to children. We also note in our Proposed Rule and in the 2015 Edition proposed rule (80 FR 16818 and 16819) that the Centers for Disease Control and Prevention (CDC) recommends as part of best practices the use of these pediatric vital signs for settings of care in which pediatric and adolescent patients are seen. The availability of a reference range/scale or growth curve would help with proper interpretation of the measurements for the BMI percentile per age and sex and weight for age per length and sex.</P>
                    <P>Further, we noted our belief that the inclusion of this health information in the USCDI v1 was the appropriate next step after first specifying them as optional in the CCDS definition as part of the 2015 Edition rulemaking (80 FR 62695), and as a means of supporting patient access to their EHI in a longitudinal format through certified health IT (see section 3009(e)(2)(A)(i) of the PHSA as amended by the Cures Act). We recognized, however, that certain health IT developers and their customers may not find these capabilities and information useful. Therefore, we requested comment on the inclusion of pediatric vital signs in the USCDI v1, including the potential benefits and costs for all stakeholders stemming from its inclusion in the USCDI v1.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters generally supported the inclusion of the pediatric vital signs Data Elements in the USCDI v1. Some commenters opposed their inclusion or believed the inclusion of these Data Elements should be optional since pediatric vital signs are not applicable to all specialties and would add implementation burden and cost without benefit. One commenter stated that only the measurements and associated metadata (units of measure, date/time measurement taken, method of measurement), not the calculated percentiles according to applicable pediatric growth charts, should be required as part of the exchange of patient data. One commenter recommended adding the nutritional status Data Element “mid-arm circumference.” Finally, several commenters suggested or requested clarification on the pediatric vital signs Data Elements we proposed (84 FR 7442). Specifically, stakeholders in the pediatric community asked for clarification of the proposed pediatric vital sign “weight for age per length and sex for children less than 3 years of age,” noting it does not correspond to any existing pediatric growth charts. Rather, they noted that there is a growth chart “weight-for-length” for children less than 3 years of age.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We recognize that the adoption of these Data Elements has the potential to add burden and cost for some health IT products, but we believe the inclusion of these Data Elements can contribute significantly to the longitudinal care of patients. Pediatric care is not isolated to a single specialty or setting of care, and clinicians providing health care for children—especially those providing care for children with complex conditions—may practice in a wide range of settings using a wide range of health IT systems. Many key stakeholders believe that the ability to capture, calculate, and transmit key pediatric growth data using health IT is critical to providing care to these populations as well as communicating with other providers, parent/guardians, and patients. We also note that adoption of the USCDI standard and its Data Classes and elements is not specific as to its usage within a setting of care, a health care specialty, or by a specific category of health IT user; rather it applies to certified health IT's ability to send and receive those Data Elements without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. While some users may find few opportunities to exchange these Data Elements, many will exchange these Data Elements frequently. As we have noted previously, we believe that the adoption 
                        <PRTPAGE P="25674"/>
                        of USCDI for all certified health IT will advance interoperability by ensuring compliance with new data and vocabulary codes sets that support the data.
                    </P>
                    <P>We also appreciate the commenter's suggestion for an additional Data Element. As we have noted, ONC will establish and follow a predictable, transparent, and collaborative process to expand the USCDI, which will provide stakeholders with the opportunity to advance additional Data Classes and Data Elements relevant to a wide range of use cases related to health care.</P>
                    <P>
                        Regarding the request to clarify and better define these proposed pediatric vital signs, we note that these Data Elements, as written and proposed, were previously included as optional health information in the 2015 Edition CCDS definition. The discrepancy between the adopted pediatric vital signs and standardized pediatric growth charts was not identified previously. Therefore, we wish to clarify that the above-referenced pediatric vital signs include both the vital measurements and the percentiles used in the following growth charts currently recommended by the Centers for Disease Control and Prevention: 
                        <SU>33</SU>
                        <FTREF/>
                         for infants birth to 36 months of age: Weight-for-length; and head occipital-frontal circumference for age; and for children 2-20 years of age: Body mass index (BMI) for age.
                    </P>
                    <FTNT>
                        <P>
                            <SU>33</SU>
                             
                            <E T="03">https://www.cdc.gov/growthcharts/index.htm</E>
                            .
                        </P>
                    </FTNT>
                    <P>In consideration of these comments, we have finalized the following pediatric Data Elements in the Vital Signs Data Class of the USCDI v1: Head occipital-frontal circumference percentile (Birth to 36 Months); weight-for-length percentile (Birth to 36 Months); body mass index (BMI) percentile (2-20 Years of Age); and the reference range/scale or growth curve, as appropriate.</P>
                    <HD SOURCE="HD3">iv. Clinical Notes</HD>
                    <P>We proposed (84 FR 7442) to include in the USCDI v1 a new Data Class entitled “clinical notes.” “Clinical notes” was included in the proposed USCDI v1 based on significant feedback from the industry since the 2015 Edition final rule. We also received similar feedback during the Trusted Exchange Framework and Common Agreement (TEFCA) stakeholder sessions and public comment period. As we noted, “clinical notes” have been identified by stakeholders as highly desirable data for interoperable exchange. The free text portion of the clinical notes was most often relayed by clinicians as the data they sought, but were often missing during electronic health information exchange. We additionally noted that clinical notes can be composed of text generated from structured (pick-list and/or check the box) fields as well as unstructured (free text) data. We explained that a clinical note may include the assessment, diagnosis, plan of care and evaluation of plan, patient teaching, and other relevant data points.</P>
                    <P>
                        We recognized that a number of different types of clinical notes could be useful for stakeholders. We indicated our understanding that work is being done in the community to focus on a subset of clinical notes. We considered three options for identifying the different “note types” to adopt in USCDI v1. The first option we considered allowed for the community to offer any and all recommended notes. The second option we considered set a minimum standard of eight note types. This option was derived from the eight note types identified by the Argonaut Project participants.
                        <SU>34</SU>
                        <FTREF/>
                         The third option we identified looked to the eleven HL7 Consolidated Clinical Document Architecture (C-CDA) document types identified in the C-CDA Release 2.1, which also included the note types being identified by the Argonaut Project participants. We ultimately proposed the second option because it unites public and private interests toward the same goal. We indicated that the eight selected note types were a minimum bar and, in the future, the USCDI could be updated to include other clinical notes. Specifically, we proposed to include the following clinical note types for both inpatient and outpatient (primary care, emergency department, etc.) settings in USCDI v1 as a minimum standard: (1) Discharge Summary note; (2) History &amp; Physical; (3) Progress Note; (4) Consultation Note; (5) Imaging Narrative; (6) Laboratory Report Narrative; (7) Pathology Report Narrative; and (8) Procedures Note (84 FR 7442). We requested comment on whether to include additional note types as part of the USCDI v1.
                    </P>
                    <FTNT>
                        <P>
                            <SU>34</SU>
                             Link to the Clinical Notes Argonaut Project identified (to clarify: Seven bullets are listed, however, we split laboratory and pathology note types into their own note) 
                            <E T="03">http://wiki.hl7.org/index.php?title=201805_Clinical_Notes_Track</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters broadly supported adding “clinical notes” as a new Data Class to the USCDI v1, in particular to enable the use of free text for data exchange. Several commenters requested clarity as to whether the proposal to adopt this new Data Class would require the capture and exchange of unstructured, or “raw” or “free” text, narrative clinical information or more comprehensive documents such as those defined by C-CDA. Some commenters recommended adding certain note types—including continuity of care, operative, and nursing notes—while others recommended removing some of the proposed note types. In particular, Laboratory/Pathology Report Narrative note types were thought to be duplicative of content in the Laboratory Data Class and element Value/Results. Some commenters recommended Imaging Narrative not be used, but added to a new Data Class, Diagnostic Tests, which would combine Laboratory and Radiology tests and results.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and recommendations. While we recognize that there may be alternative methods of organizing different clinical note types, we believe there is value in grouping all clinical notes into a single Data Class within the USCDI. As we noted above and in the Proposed Rule, we have adopted the eight note types identified by the Argonaut Project participants because it unites public and private interests toward the same goal. As we indicated, the eight selected note types are a minimum bar and, in the future, the USCDI could be updated to include other clinical note types. The eight selected note types reflect the most clearly and consistently recommended set of clinical note type. While a variety of additional note types were recommended, there was no consensus for additional note types beyond these eight. In consideration of these comments, we have finalized the clinical notes as a Data Class in the USCDI v1, with only the following eight clinical note types for both inpatient and outpatient (primary care, emergency department, etc.) settings as a minimum standard as proposed: (1) Discharge Summary Note; (2) History &amp; Physical; (3) Progress Note; (4) Consultation Note; (5) Imaging Narrative; (6) Laboratory Report Narrative; (7) Pathology Report Narrative; and (8) Procedures Note.
                    </P>
                    <P>We wish to further clarify that we have adopted the new Clinical Notes Data Class in order to enable capture and exchange of free text clinical information categorized by the above clinical note types. We refer commenters to our response in section IV.B.1.d of the final rule—Clinical Notes C-CDA Implementation Specification—that addresses the relationship of the clinical notes Data Class to C-CDA implementation specification.</P>
                    <P>
                        We also seek to clarify two points. First, that these clinical note types are content exchange standard agnostic. They should not be interpreted or associated with the specific C-CDA Document Templates that may share the 
                        <PRTPAGE P="25675"/>
                        same name. Secondly, we clarify that these note types are required to be represented in their plain-text form when included in various content exchange standards (
                        <E T="03">e.g.,</E>
                         C-CDA, FHIR) as may be applicable to the certification criteria in which the USCDI is referenced.
                    </P>
                    <HD SOURCE="HD3">v. Provenance</HD>
                    <P>
                        We proposed (84 FR 7442) for the USCDI v1 to include a new Data Class, entitled “provenance.” As we indicated, stakeholders 
                        <SU>35</SU>
                        <FTREF/>
                         have identified “provenance” as valuable for interoperable exchange. Stakeholders also referenced the provenance of data as a fundamental need to improve the trustworthiness and reliability of the data being exchanged. Provenance describes the metadata, or extra information about data, that can help answer questions such as who created the data and when.
                    </P>
                    <FTNT>
                        <P>
                            <SU>35</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement</E>
                            .
                        </P>
                    </FTNT>
                    <P>In the Proposed Rule, we noted that the inclusion of “provenance” as a Data Class in the USCDI v1 would also complement the Cures Act requirement in section 4002(a) to support the exchange of data through the use of APIs. This approach differs from the exchange of data via the C-CDA. While C-CDAs are often critiqued due to their relative “length,” the C-CDA represents the output of a clinical encounter and includes relevant context. The same will not always be true in an API context. APIs facilitate the granular exchange of data and, as noted in the original 2015 Edition final rule, offer the potential to aggregate data from multiple sources using a web or mobile application (80 FR 62675). The inclusion of provenance would help retain the relevant context so the recipient can better understand the origin of the data.</P>
                    <P>We proposed to further delineate the provenance Data Class into three Data Elements: “the author,” which represents the person(s) who is responsible for the information; “the author's time stamp,” which indicates the time the information was recorded; and “the author's organization,” which would be the organization the author is associated with at the time they interacted with the data (84 FR 7442). We indicated that we identified these three Data Elements as fundamental for data recipients to have available and noted that they are commonly captured and currently available through standards. We requested comment on the inclusion of these three Data Elements and whether any other provenance Data Elements, such as the identity of the individual or entity the data was obtained from or sent by (sometimes discussed in standards working groups as the provenance of the data's “last hop”), would be essential to include as part of the USCDI v1 standard. We acknowledged that there is currently work to help define provenance in a standard robust manner, and that we anticipated adopting the industry consensus once it became available.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters overwhelmingly supported the addition of provenance as a new Data Class for USCDI v1. Several commenters stated that the proposed elements were insufficient for the purpose of audit logs for use and disclosure of health data, citing the existing standard specification ASTM E2147.
                        <SU>36</SU>
                        <FTREF/>
                         Other commenters stated that these proposed elements did not apply to all use cases of exchanged data and requested clarification regarding applicability, including whether provenance would have to be created for elements created before the implementation deadline of USCDI v1. Because this is a new Data Class, some commenters also requested additional time to adopt and implement this new requirement. Some commenters stated that there could be ambiguity in designating “author” for certain clinical information such as patient-reported medications, while in certain other cases, there could be multiple authors for the same clinical information, such as clinical notes. Additionally, some commenters suggested that the “author” be limited to only a limited set of Data Elements and not to all the Data Elements. Another commenter specifically addressed several concerns related to the definition of “author” for this purpose. Commenters specifically stated they understood author to be the person entering the data into the EHR, but noted that data may also be historical, captured from a device, started by a patient and completed by clinical staff, entered by a patient, entered by resident/students working under a supervising physician, or reported by a patient. The commenter noted that there are additional documentation scenarios such as dictation to scribes or other medical staff, which conflate “responsibility” for authorship, and that defining author for every Data Element can be complex. Finally, one health IT developer recommended a 36-month implementation period to begin only after test procedures, implementation guides, and test and validation tools are available and after ONC has consulted at least five CEHRT developers.
                    </P>
                    <FTNT>
                        <P>
                            <SU>36</SU>
                             
                            <E T="03">https://www.astm.org/Standards/E2147.htm</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We acknowledge that these Data Elements may not be able to fully support the needs of all use cases, but we believe their adoption will improve the trustworthiness and reliability of data being exchanged. For this Data Class, it appears that many commenters over-interpreted our proposal and the effect of having these data in the USCDI. As we noted earlier, the adoption of the USCDI standard and its Data Classes and elements is not specific as to its usage within a setting of care, a health care specialty, or by a specific category of health IT user. Rather it applies to certified health IT's ability to send and receive those Data Elements without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. Therefore, with respect to our reference to provenance data in the USCDI, we have no preset notion or explicit upfront requirement for how this data should be used. We believe that having provenance data is highly impactful, essential for trustworthy interoperability, and will generate greater value for stakeholders as they identify new ways to put this data to use.
                    </P>
                    <P>
                        Regarding “author” as a Data Element within the provenance Data Class, we agree that significant practical scope challenges may arise. Our analysis of the concerns raised by commenters identified a risk of unintended burden and potential risk of error and misattribution associated with this particular Data Element. In most use cases, the inclusion of author organization and author time stamp is sufficient to convey provenance. As a result, we have not finalized the “author” as a required Data Element within the provenance Data Class in USCDI. However, we understand that for exchanging certain data elements, such as “clinical notes,” it is critical to also send the “author” information if available. Our analysis of the various content exchange standards and specifications (
                        <E T="03">e.g.,</E>
                         C-CDA and FHIR) indicates that even though the “author” Data Element is not explicitly required in USCDI, the health IT specifications in which USCDI Data Elements are represented also set specific data element requirements for certain contexts. For example, in the context of clinical notes, these content exchange standards require health IT systems to be capable of exchanging “author” information when it is available. Further, “author” is treated as a “Must Support” data element in the FHIR US Core Implementation Guide STU 3.1.0 and has a “SHALL” constraint (with 
                        <PRTPAGE P="25676"/>
                        appropriate null flavor value) in the C-CDA 2.1. As we have noted previously, we believe that the proposed 24-month timeline for updating certified health IT to comply with the new USCDI standard in § 170.213 is an adequate implementation timeline and will maintain this requirement as finalized earlier in this section.
                    </P>
                    <P>Therefore, in consideration of the comments received, we have finalized the provenance Data Class in the USCDI v1 and the following two Data Elements:</P>
                    <P>• “author time stamp,” which indicates the time the information was recorded; and</P>
                    <P>• “author organization,” which would be the organization the author is associated with at the time they interacted with the data.</P>
                    <P>We believe these two provenance Data Elements, “author organization” and “author time stamp,” within the USCDI v1, which are also used in the C-CDA and FHIR-based certification criteria we have adopted that incorporate the USCDI, will serve as a foundation on which industry stakeholders can subsequently work together to build out additional provenance data requirements in the USCDI. As noted above, we have not finalized the proposed Data Element “the author,” which represents the person(s) who was responsible for the information.</P>
                    <HD SOURCE="HD3">vi. Medication Data Request for Comment</HD>
                    <P>In the Proposed Rule, we proposed (84 FR 7443) that the USCDI v1 “Medication” Data Class include two constituent Data Elements within it: Medications and Medication Allergies. With respect to the latter, Medication Allergies, we requested comment on an alternative approach. This approach would remove the Medication Allergies Data Element from the Medication Data Class and add it to a new Data Class titled “Substance Reactions,” which would include the concept of “Medication Allergies.” The new “Substance Reactions” Data Class would include the following Data Elements: “Substance” and “Reaction,” and include SNOMED CT as an additional applicable standard for non-medication substances.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported the creation of a new Data Class “Substance Reactions” but requested we preserve the Medication Allergy element because of patient safety concerns related to the adoption of an entirely new Data Element. One commenter supported the change but recommended the new Data Class name be aligned with the HL7 FHIR resource “AllergyIntolerance.” This would also be consistent with the C-CDA 2.1 “Allergy and Intolerance” section.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their input. While we appreciate that there may be some risk associated with the adoption of a new Data Element, we believe this alternative approach better aligns with other standards representing substance reactions, including medication allergies, and this alignment enhances patient safety. Additionally, we agree with the commenter who suggested renaming this new Data Class to align with FHIR and C-CDA approaches.
                    </P>
                    <P>In consideration of comments, we have finalized the creation of a Data Class in USCDI v1 entitled “Allergies and Intolerances,” instead of “Substance Reactions” from the original USCDI v1 proposal. The Allergies and Intolerances Data Class in USCDI v1 consists of the following Data Elements: “Substance—(Medication),” “Substance—(Drug Class),” and “Reaction.” “Substance—(Medication)” must be represented by RxNorm codes and “Substance—(Drug Class)” must be represented by SNOMED CT codes. The addition of the “Substance—(Drug Class)” better represents when an individual may have a reaction to an entire drug class as opposed to a specific medication. Additionally, we believe having the Allergy and Intolerances Data Class separated from the Medication Class will accommodate potential additions of other substance Data Elements such as food, environmental, and biologic agents. The Data Element “Reaction” is meant to include, but is not limited to, medication allergies. As the USCDI is updated over time to include substances other than medications, we can also see the need to have substance reactions updated as part of this Data Class. To reflect this change, we have updated the terminology in the regulatory text in § 170.315 to remove “medication allergy” and replace with “allergy and intolerance.”</P>
                    <HD SOURCE="HD3">c. USCDI Standard—Relationship to Content Exchange Standards and Implementation Specifications</HD>
                    <P>In recognition of the evolution of standards over time and to facilitate updates to newer versions of standards, we proposed (84 FR 7443) that the USCDI v1 (§ 170.213) would be agnostic as to “content exchange” standard. As we noted, the USCDI v1 establishes “data policy” and does not directly associate with the content exchange standards and implementation specifications which, given a particular context, may require the exchange of the entire USCDI, a USCDI Data Class, or some or all of the Data Elements within a given Data Class or classes. We further indicated that, to our knowledge, all Data Classes in the USCDI v1 can be supported by commonly used “content exchange” standards, including HL7 C-CDA Release 2.1 and FHIR.</P>
                    <P>We received no comments on this specific proposal and we have finalized our proposal to make USCDI v1 agnostic as to “content exchange standard” as described.</P>
                    <HD SOURCE="HD3">2. Clinical Notes C-CDA Implementation Specification</HD>
                    <P>
                        In conjunction with our proposal to adopt the USCDI v1, we proposed to adopt the HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R1 Companion Guide, Release 1 in § 170.205(a)(5) (“C-CDA Companion Guide”). The C-CDA Companion Guide provides supplemental guidance and additional technical clarification for specifying data in the C-CDA Release 2.1.
                        <SU>37</SU>
                        <FTREF/>
                         As we noted in the Proposed Rule (84 FR 7443), the proposed USCDI v1 included new Data Classes, such as “clinical notes,” which were further supported through the C-CDA Companion Guide. For example, the C-CDA Companion Guide provides specifications for clinical notes by indicating that clinical notes should be recorded in “note activity” and requires references to other discrete data, such as “encounters.” The C-CDA Companion Guide also enhances implementation of the updated 2015 Edition certification criteria that reference the C-CDA Release 2.1 (§ 170.205(a)(4)). As noted by stakeholders, the C-CDA Release 2.1 includes some optionality and ambiguity with respect to Data Element components, such as the locations and value sets. We attempted to address some of this optionality by clarifying requirements using Certification Companion Guides (CCGs) 
                        <SU>38</SU>
                        <FTREF/>
                         and by specifying in the CCDS definition where certain data should be placed in the C-CDA Release 2.1 templates (
                        <E T="03">e.g.,</E>
                         “goals” in the goals section).
                        <SU>39</SU>
                        <FTREF/>
                         The C-CDA Companion Guide, which was released in August, 2015, provides similar, but additional C-CDA implementation structure. For example, race and ethnicity are required Data Elements in the USCDI and must be included in C-CDA exchanges if known, or they may be marked with a nullFlavor value “UNK” (unknown) if not known. The 
                        <PRTPAGE P="25677"/>
                        C-CDA Release 2.1 is unclear on the location and value set, but the C-CDA Companion Guide clarifies the location and value set. We noted in the Proposed Rule that the adoption of the C-CDA Companion Guide would align with our goal to increase the use of consistent implementation of standards among health IT developers and improve interoperability. We proposed to adopt this C-CDA Companion Guide to support best practice implementation of USCDI v1 Data Classes and 2015 Edition certification criteria that reference C-CDA Release 2.1 (§ 170.205(a)(4)). The criteria include:
                    </P>
                    <FTNT>
                        <P>
                            <SU>37</SU>
                             
                            <E T="03">http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>38</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/certification-ehrs/2015-edition-test-method</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>39</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/topiclanding/2018-04/2015Ed_CCG_CCDS.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>• “transitions of care” (§ 170.315(b)(1));</P>
                    <P>• “clinical information reconciliation and incorporation” (§ 170.315(b)(2));</P>
                    <P>• “care plan” (§ 170.315(b)(9));</P>
                    <P>• “view, download, and transmit to 3rd party” (§ 170.315(e)(1));</P>
                    <P>• “consolidated CDA creation performance” (§ 170.315(g)(6)); and</P>
                    <P>• “application access—all data request” (§ 170.315(g)(9)).</P>
                    <P>
                        We proposed, as a Maintenance of Certification requirement for the real world testing Condition of Certification requirement, that health IT developers with health IT certified to the six above-identified certification criteria prior to the effective date of a subsequent final rule would have to update such certified health IT to the proposed revisions (84 FR 7443).
                        <SU>40</SU>
                        <FTREF/>
                         We further proposed as a Maintenance of Certification requirement for the real world testing Condition of Certification requirement, that health IT developers would be required to provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the effective date of a final rule (84 FR 7443). For the purposes of meeting that compliance timeline, we indicated that we expected health IT developers to update their certified health IT without new mandatory testing and notify their ONC-ACB on the date at which they have reached compliance. Developers would also need to factor these updates into their next real world testing plan as discussed in section VII.B.5 of the Proposed Rule.
                        <SU>41</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>40</SU>
                             We proposed to codify this requirement in § 170.405(b)(4) (84 FR 7596).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>41</SU>
                             The finalized real world testing plan requirements, codified in § 170.405(b)(2) are discussed in section VII.B.5 of this final rule.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter supported the use of C-CDA for Clinical Notes. One commenter sought clarity on testing for Clinical Notes conformance to C-CDA 2.1, noting that all C-CDA documents are the same except for the document header. Two commenters recommended review of the Common Well Concise Consolidated CDA white paper.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their suggestions and support. During the past few months, industry stakeholders updated the C-CDA Companion Guide to a newer version to best address how clinical notes should be handled in the C-CDA. In consideration of the update to the C-CDA Companion Guide and the comments, we have finalized the adoption of the most up-to-date version, HL7 CDA R2 IG: C-CDA Templates for Clinical Notes STU Companion Guide, Release 2 in § 170.205(a)(5) (“C-CDA Companion Guide”) and have incorporated by reference in § 170.299. This includes adoption of the USCDI v1 and the associated Data Classes.
                    </P>
                    <P>In order to align “clinical information reconciliation and incorporation” (§ 170.315(b)(2)) with the updated Data Classes in the USCDI v1 as proposed in 84 FR 7441, we have replaced the “medication allergies” data element in § 170.315(b)(2)(iii)(D)(2) criterion to “Allergies and Intolerances” Data Class and require reconciliation of all the data elements in “Allergies and Intolerances” Data Class, which includes Substance (Medication), Substance (Drug Class), and Reaction Data Elements. We have revised the regulation text (§ 170.315(b)(2)) to align with this change. We decline to accept the recommendation to adopt the CommonWell specification as we believe the criterion is best met following the C-CDA specification published by HL7.</P>
                    <P>We have additionally finalized the timeline for the update to the use of the C-CDA companion guide of 24 months after the publication date of this final rule for the following criteria:</P>
                    <P>• “transitions of care” (§ 170.315(b)(1));</P>
                    <P>• “clinical information reconciliation and incorporation” (§ 170.315(b)(2));</P>
                    <P>• “care plan” (§ 170.315(b)(9));</P>
                    <P>• “view, download, and transmit to 3rd party” (§ 170.315(e)(1));</P>
                    <P>• “consolidated CDA creation performance” (§ 170.315(g)(6)); and</P>
                    <P>• “application access—all data request” (§ 170.315(g)(9)).</P>
                    <HD SOURCE="HD3">3. Unique Device Identifier(s) for a Patient's Implantable Device(s) C-CDA Implementation Specification</HD>
                    <P>We noted in the Proposed Rule (84 FR 7443) our awareness of a recently published implementation guide (IG) by HL7 that provides further guidance on the unique device identifier (UDI) requirements. The Health Level 7 (HL7) CDA R2 Implementation Guide: C-CDA Supplemental Templates for Unique Device Identification (UDI) for Implantable Medical Devices, Release 1-US Realm (UDI IG Release 1), identifies changes needed to the C-CDA to better facilitate the exchange of the individual UDI components in the health care system when devices are implanted in a patient. The UDI components include the Device Identifier (DI) and the following individual production identifiers: The lot or batch number, serial number, manufacturing date, expiration date, and distinct identification code. As this new IG had been recently published, we requested comment on whether we should add this UDI IG as a requirement in § 170.299(f)(35) for health IT to adopt in order to meet the requirements for content exchange using C-CDA. In addition, we indicated that we did not have a reliable basis on which to estimate how much it would cost to meet the requirements outlined in the UDI IG; and, therefore, we requested comment on the cost and burden of complying with this proposed requirement.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters unanimously supported adoption of the UDI IG Release 1 as a new requirement for health IT to meet the requirements for the USCDI UDI Data Class. One commenter requested additional guidance regarding the determination of the “person responsible for the information” contained in the “Device” entry. None of the commenters provided a basis of estimate for the cost to meet the requirements outlined in the UDI IG Release 1.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support. As we noted earlier, the adoption of the USCDI standard and its Data Classes and elements is not specific as to its usage within a setting of care, a health care specialty, or by a specific category of health IT user; rather it applies to certified health IT's ability to send and receive those Data Elements without requirements regarding functionality, user interface, or the use of those Data Elements in exchange. Therefore, we do not specify who must enter such data.
                    </P>
                    <P>
                        We note also that the C-CDA Companion Guide referenced in subsection (d) below of this final rule now includes the content of the UDI IG Release 1 named in the Proposed Rule. In consideration of comments, we have finalized the proposed UDI Data Class within the USCDI v1, and have adopted the UDI Organizer Template defined in the UDI IG Release 1 and subsequently published as Appendix B of the HL7® 
                        <PRTPAGE P="25678"/>
                        CDA® R2 IG: C-CDA Templates for Clinical Notes, Release 2.1 Companion Guide, Release 2—US Realm, October 2019, as a new requirement for Health IT Modules to meet the requirements for C-CDA-based exchange. We note that the UDI Organizer Template, though subsequently published in Appendix B of the HL7 CDA R2 IG: C-CDA Templates for Clinical Notes STU Companion Guide, Release 2, September 2019, remains substantially unchanged from its previous publication in the UDI IG Release 1 in November 2018 and has been thoroughly reviewed and subjected to balloting and a public comment process.
                    </P>
                    <HD SOURCE="HD3">4. Electronic Prescribing Criterion</HD>
                    <P>We proposed to adopt a new version of the NCPDP SCRIPT standard in 45 CFR 170.205(b)(1), specifically NCPDP SCRIPT standard version 2017071 (84 FR 7444). Because we proposed to adopt a new standard for electronic prescribing (e-Rx), we also proposed to adopt a new certification criterion in § 170.315(b)(11) for the proposed e-Rx standard to replace the old standard in § 170.315(b)(3). The proposed new certification criterion reflected our proposed adoption of NCPDP SCRIPT standard version 2017071 as well as all transactions adopted for the CMS Medicare Part D E-prescribing Program (84 FR 23832). These proposals were made to realign ONC's Health IT Certification Program (Program) policies with those of CMS' Part D E-prescribing rules. ONC and CMS have historically aligned standards adopted under their programs such as those for e-Rx and medication history (MH) to ensure that entities regulated under both schemes can comply with the different programs' requirements. For this reason, we stated that should our proposal to adopt the new e-Rx criterion (§ 170.315(b)(11)) be finalized prior to January 1, 2020, we also proposed to permit continued certification to the current 2015 Edition “electronic prescribing” criterion (§ 170.315(b)(3)) that references NCPDP SCRIPT standard version 10.6 for the period of time in which that version of the NCPDP SCRIPT standard would continue to be used in the CMS Medicare Part D E-prescribing Program or the CMS Promoting Interoperability Programs. Finally, we proposed in 84 FR 7445 that once NCPDP SCRIPT standard version 10.6 is no longer used in those Programs, we would no longer permit certification to that criterion and would remove it from the Code of Federal Regulations, and that we would consider setting an effective date for such actions in a subsequent final rule based on stakeholder feedback and CMS policies at the time.</P>
                    <P>In addition to continuing to reference the current transactions included in § 170.315(b)(3), in keeping with CMS' Modernizing Part D and Medicare Advantage To Lower Drug Prices and Reduce Out-of-Pocket Expenses final rule (84 FR 23832), we also proposed in 84 FR 7445 and in § 170.315(b)(11) to require the support of all of the NCPDP SCRIPT standard version 2017071 transactions CMS has adopted for the Part D E-prescribing regulations in 42 CFR 423.160(b)(2)(iv). Given the January 1, 2020 effective date in CMS rulemaking (83 FR 16440) and the effective date of this final rule, we have finalized our proposed update to the new version of the standard for the electronic prescribing criterion in § 170.315(b)(3) instead of creating a new criterion as proposed in 84 FR 7427 in § 170.315(b)(11). Unlike other criteria in this final rule that allow testing to either version of a required standard until 24 months after the publication date of this final rule, we will not allow certification testing to version 10.6 of the NCPDP SCRIPT standard, as the implementation date for CMS' new Part D E-prescribing Program of January 1, 2020 has passed. However, based on stakeholder feedback, we have finalized a transition period in 45 CFR 170.405(b)(4)(ii) of 24 months from the date of publication of this final rule for certification so developers may test and certify to the updated criterion with all associated transactions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters were supportive of our proposal and recommended moving to the NCPDP SCRIPT standard version 2017071 for the e-Rx certification criterion in alignment with CMS' adoption of the standard for the Part D E-prescribing Program. However, a number of commenters expressed concern that while EHRs or other electronic prescribing systems may become certified, pharmacy information systems (PIS) lack a similar certification program and associated standards and technical capability requirements, thus creating a mismatch between the e-prescribing system requirements for EHR users and PIS users. Several commenters specifically noted that PIS, which send or receive these transactions, are not required to adopt the capability to support these transactions as they are out of scope for the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         First, we note that the comments suggesting that pharmacies on the sending or receiving end of Part D e-Rx transactions are not required to utilize NCPDP SCRIPT standard version 2017071 transactions are inaccurate. To the extent that a pharmacy conducts electronic prescribing with prescribers e-prescribing Part D covered drugs for Part D eligible individuals, those pharmacies are required to use the NCPDP SCRIPT version 2017071 standard. While there may not be 2015 Edition certification criteria to which pharmacy information systems can be certified, the Part D rules require support of the standard under the Part D E-prescribing Program. Thus, we believe the mismatch concerns raised by commenters are unfounded. As a general matter, Part D prescribers need health IT systems capable of conducting compliant transactions (regardless of ONC certification) and so too do Part D receiving pharmacies. ONC health IT certification will provide an added layer of assurance for Part D prescribers that their e-Rx systems have been tested and certified as being capable of accurately conducting the adopted NCPDP SCRIPT standard version 2017071 transactions.
                        <SU>42</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>42</SU>
                             
                            <E T="03">https://www.govinfo.gov/content/pkg/FR-2015-10-16/pdf/2015-25597.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>In addition, we received several comments related to the readiness of PIS for specific transactions beyond those defined for Part D. We include these comments as applicable in the discussion of each transaction below. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program, and we acknowledge the challenge of pharmacy readiness to support all transactions at this time, but if they conduct e-Rx for part D covered drugs prescribed to Part D eligible Medicare beneficiaries, they will be required to use the standard we are adopting for our program by the Medicare Part D e-Rx Program—so if they do e-prescribing at all, we expect that they will be able to conduct transactions using the standard adopted here. Generally, the goal of certification is to ensure that Health IT Modules voluntarily submitted for the Program are capable of conducting the transactions as specified. This ensures that providers have the capability to use the certified product for these transactions where feasible. For this reason, we have finalized the transactions as described below for certified Health IT Modules and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable pharmacy information systems.</P>
                    <P>
                        <E T="03">Comments.</E>
                         As noted, the majority of commenters were supportive of the proposal to remove the 2015 Edition 
                        <PRTPAGE P="25679"/>
                        certification criterion (codified in § 170.315(b)(3)) that references NCPDP SCRIPT standard version 10.6 and replace it with an updated e-Rx criterion (proposed to be codified in § 170.315(b)(11)). Commenters requested that ONC work with CMS on a smooth transition and timeline that would allow adequate time for the development, testing, and full adoption of these updates. A number of commenters stated that the NCPDP SCRIPT standard version 2017071 is not backward compatible with NCPDP SCRIPT standard version 10.6, and therefore there should be no transition period where both standards are applicable. Commenters sought clarity on the timing of the change and expressed concerns that developers and providers may face operational issues in their adoption of version 2017071 of the NCPDP SCRIPT standard by January 1, 2020. Commenters recommended that ONC allow certification timelines that support compliance with Part D while allowing adequate time to mitigate the risk associated with the additional requirements for certification to the proposed criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by commenters as well as the concern about maintaining alignment between required standards across HHS. We note that the CMS requirement for Part D e-Rx transactions includes a compliance date of January 1, 2020, and that industry feedback notes a consistent and deliberate move toward readiness for the adoption of the new standard for Part D e-Rx, including by health IT industry leaders supporting pharmacy implementation. We believe that this overall industry readiness supports our adoption of the update to the standard for certification purposes and to be in alignment with the required standard update for Part D e-Rx purposes. In response to the request for a smooth transition and continuity of certification for health care providers, we have finalized a revision to the existing criterion in § 170.315(b)(3) rather than removing and replacing the criterion. In order to support the transition to the new standard for Part D, at the request of stakeholders, ONC issued guidance 
                        <SU>43</SU>
                        <FTREF/>
                         in the third quarter of CY2019 stating, “. . . developers of 2015 Edition certified Health IT Modules certified to the e-prescribing criterion adopted at 45 CFR 170.315(b)(3) are permitted to update their products to use the NCPDP SCRIPT standard version 2017071 to meet CMS' compliance requirements . . .” This guidance also noted that ONC would discontinue certification of new products to the electronic prescribing certification criterion using version 10.6 of the NCPDP SCRIPT standard as of January 1, 2020.
                    </P>
                    <FTNT>
                        <P>
                            <SU>43</SU>
                             For Part D covered drugs prescribed for Part D eligible individuals. ONC Electronic Prescribing Certification Companion Guide: 
                            <E T="03">https://www.healthit.gov/test-method/electronic-prescribing</E>
                            .
                        </P>
                    </FTNT>
                    <P>In consideration of the comments we received, we have finalized our proposal to update the electronic prescribing (e-Rx) NCPDP SCRIPT standard used for electronic prescribing in the 2015 Edition to NCPDP SCRIPT standard version 2017071, which results in a new e-Rx standard becoming the baseline for certification. As the effective date of this final rule will occur after January 1, 2020, we have not finalized our proposal to permit new products to continue to be certified to the prior standard until the January 1, 2020 date. Instead, we discontinued certification of new products to the former electronic prescribing criterion using the NCPDP SCRIPT standard version 10.6 to align with CMS requirements. We have finalized this update as a modification to the existing certification criterion rather than as a separate new certification criterion to allow for a smooth transition, and to allow for continuity with the certification(s) issued to Health IT Modules for § 170.315(b)(3) prior to January 1, 2020 that are updated under the ONC guidance. This approach will also continue to allow for compliance with the January 1, 2020 timeline for CMS' Medicare Part D e-Rx and Medication History standards.</P>
                    <P>As noted by commenters, we understand that there is a lack of backward compatibility between the two standards. In order to allow for a reasonable transition period to certification to the full set of NCPDP SCRIPT transactions and other requirements defined in the updated e-Rx certification criterion, we have framed our Maintenance of Certification in section 45 CFR 170.405(b)(5)(ii) with flexibility that will allow health IT developers up to 24 months from the date of publication of this final rule to test and certify to the updated criterion reflective of all NCPDP SCRIPT 2017071 transactions to demonstrate full conformance with the updated criterion. After January 1, 2020, use of the NCPDP SCRIPT 10.6 standard will be prohibited under the Part D program, so we do not expect or anticipate health IT systems certified to § 170.315(b)(3) will conduct Part D transactions using that standard. We also recognize, however, for the purposes of maintaining a product certificate with § 170.315(b)(3) in its scope, that these 24 months from the date of publication from this final rule enable continued compliance and oversight associated with other capabilities in § 170.315(b)(3) that are not applicable for Part D, and for which conformance is still required.</P>
                    <P>We have finalized this 24-month period for the update for this criterion under the real world testing provisions in § 170.405(b)(5) as follows:</P>
                    <P>
                        • 
                        <E T="03">Electronic Prescribing.</E>
                         A health IT developer with health IT certified to § 170.315(b)(3) prior to June 30, 2020, must:
                    </P>
                    <P>○ Update their certified health IT to be compliant with the revised versions of this criterion adopted in § 170.315(b)(3)(ii); and</P>
                    <P>○ Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(5)(i) of this section by May 2, 2022.</P>
                    <HD SOURCE="HD3">a. Electronic Prescribing Standard and Certification Criterion</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concerns about standardization generally within the context of e-prescribing. Several commenters expressed concern about using the NCPDP SCRIPT standard version 2017071, the RxNorm standard, as a requirement for e-prescribing, and other standards such as Fast Healthcare Interoperability Resources (FHIR). One commenter further stated that only inventory (packaging or unit dose strength) codes are standardized in RxNorm, and that drug regimens should be standardized and made computable in RxNorm for safety reasons. Another commenter noted that RxNorm does not index brand names exhaustively with a single unique ID for each branded drug, but that current indexing only allows for generic-level interoperability and only at unit dose level. One commenter expressed concern that the criterion as proposed does not appear to support medication assisted treatment (MAT) for opioid use disorder (OUD) and other long-acting medications. Another commenter stated a hope that standards such as the NCPDP SCRIPT version 2017071 standard can ease data integration into the workflow, lessen burden, and help achieve greater compliance with policy and legal requirements for querying State prescription drug monitoring programs (PDMP). Another commenter supported the adoption of the NCPDP SCRIPT standard version 2017071 because the standard supports the prescribing of compound medications and the sig (
                        <E T="03">i.e.,</E>
                         instructions) field is not limited to 140 characters.
                        <PRTPAGE P="25680"/>
                    </P>
                    <P>Some commenters also provided suggestions to improve the NCPDP SCRIPT 2017071 standard and its availability to the public by the standards developing organization. Another commenter stated that today's NCPDP standards are not in an API-ready format, and recommended CMS and ONC collaborate with NCPDP to explore API FHIR standards specific to the HL7 Da Vinci Project for a January 2022 effective date or later. A few commenters stated that because many NCPDP standards are not openly accessible and require a paid membership to obtain the technical specifications, our adoption could limit widespread adoption and a standardized implementation nationwide. Several commenters suggested that ONC adopt FHIR as a standard for the Program, and for the e-Rx criterion specifically. We also received several comments that are out of scope which are not addressed in this rulemaking.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters' consideration of the standards. We note that RxNorm is a standard maintained by the National Library of Medicine (NLM). ONC adopted RxNorm to represent medication information as a vocabulary standard in § 170.207(d) (80 FR 62612). We encourage all developers who have experience with, and feedback relevant to, RxNorm to contact NLM. As a reminder, RxNorm is considered a minimum standard code set under the Program, and developers are permitted to upgrade their products to comply with a newer version of RxNorm without adversely affecting a product's certification status pursuant to 45 CFR 170.555(b)(2) as long as no other law prohibits such action.
                    </P>
                    <P>In reference to the OUD prevention and treatment-related concerns that commenters expressed, we note that the NCPDP SCRIPT 2017071 standard does support the exchange of medicines used in medication-assisted treatment (MAT) for opioid use disorder treatment purposes. An electronic prescription of controlled substances transaction containing a MAT drug such as buprenorphine can be sent from a prescriber to a pharmacy through the specified transactions, and the updated § 170.315(b)(3) criterion also requires the inclusion of a reason for the prescription using &lt;Diagnosis&gt;&lt;Primary&gt; or &lt;Secondary&gt; elements, or optionally, the technology must be able to receive and transmit the reason for the prescription using the &lt;IndicationforUse&gt; element. In addition, the RxHistoryRequest transaction contains a patient consent indicator that the receiving entity must evaluate for accurate reporting. We are also aware that many PDMPs across the country accept reporting of medication history transactions containing buprenorphine, naltrexone, and other medications that could be used in the treatment of OUD.</P>
                    <P>We thank commenters for their input related to improvements that could be made to the NCPDP SCRIPT version 2017071 standard, however NCPDP is a member-driven standards developing organization that requires membership in order to participate in standards developing and to access standards and implementation guides. We appreciate the suggestion to provide a direct link to the appropriate NCPDP SCRIPT standard implementation guide, but we have no authority over the business processes of standards developing organizations like NCPDP. We encourage any and all participants with an interest in improving the standard to engage with NCPDP. Regarding the recommendation for ONC to collaborate with NCPDP to explore FHIR, we appreciate the suggestion and support any advancements in technical standards and frameworks that support interoperability. At this time, NCPDP SCRIPT standard version 2017071 has not been mapped to FHIR, but ONC will continue to monitor the industry for opportunities to align the ONC Health IT Certification Program with industry developments.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Five commenters fully supported all proposed transactions and requirements detailed in the Proposed Rule. The vast majority of commenters noted concerns about the proposed criterion specific to the transactions proposed for adoption in the § 170.315(b)(11) e-Rx certification criterion; details in support or not in support of adoption as proposed are further detailed for each type of transaction below. As a whole, the primary concerns for the transactions and requirements as proposed include the following: (1) EHRs are required to comply with the new transactions and requirements, while receiving pharmacy information systems are not; (2) lack of pharmacy adoption and readiness, as sufficient adoption should occur prior to making the transactions required; and (3) implementation of the proposed transactions and requirements is resource intensive, if not prohibitive, in order to meet the January 1, 2020 deadline set by CMS. Several commenters suggested either an extension or that certain transactions should be made optional.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all of the public comments and have modified the transactions to specify which transactions are finalized as required for Health IT Modules for purposes of obtaining or retaining certification to § 170.315(b)(3), which are optional for Health IT Modules for purposes of obtaining or retaining certification to § 170.315(b)(3), and any other § 170.315(b)(3) requirements below. Additional public comment received and related responses are grouped below based on the comment's relation to the specific transactions. We note that “optional” for the purposes of certification does not mean, and should not be interpreted as, “optional” for Part D E-prescribing Program compliance. To the extent that prescribers and pharmacies conduct electronic prescribing with Part D covered drugs prescribed for Part D eligible individuals they will be required to use the NCPDP SCRIPT 2017071 standard to conduct those transactions under the Part D E-prescribing Program. Thus, a transaction designated as “optional” for the purposes of certification means a health IT developer can elect to have that transaction explicitly tested as part of certification for its product or can choose not to do so—either will allow its product to be certified to § 170.315(b)(3). We reiterate that comments regarding CMS' January 1, 2020 timeline are out of scope as we cannot change CMS' policy or its timeline.
                    </P>
                    <HD SOURCE="HD3">b. Electronic Prescribing Transactions</HD>
                    <P>In addition to adopting the NCPDP SCRIPT version 2017071 standard for the transactions that are listed in the current “electronic prescribing” criterion (§ 170.315(b)(3)), we also proposed to adopt and require conformance to all of the NCPDP SCRIPT version 2017071 standard transactions CMS adopted in 42 CFR 423.160(b)(2)(iv). We proposed this updated 2015 electronic prescribing criterion to therefore include the following transactions:</P>
                    <HD SOURCE="HD3">i. Create and Respond to New Prescriptions (NewRx, NewRxRequest, NewRxResponseDenied)</HD>
                    <P>
                        We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for NewRx, NewRxRequest and NewRxResponseDenied. A NewRx transaction is a new prescription from a prescriber to a pharmacy so that it can be dispensed to a patient. A NewRxRequest is a request from a pharmacy to a prescriber for a new prescription for a patient. A NewRxResponseDenied is a denied response to a previously sent NewRxRequest (if approved by the 
                        <PRTPAGE P="25681"/>
                        prescriber, a NewRx would be sent instead). A NewRxResponseDenied response may occur when the NewRxRequest cannot be processed or if information is unavailable.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         While the NewRx transaction received unanimous support as a required transaction for adoption in the updated § 170.315(b)(3) criterion, the vast majority of commenters opposed adopting the NewRxRequest and NewRxResponseDenied transactions as required transactions primarily due to a lack of adoption by the PIS involved in the exchange. Several commenters stated that the NewRxRequest and NewRxResponseDenied is not yet in broad use. A commenter who supported adoption of NewRxRequest and NewRxRequestDenied believed that they may be beneficial for electronic prescribing of controlled substances (EPCS) and noted that pharmacies have expressed interest in implementation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In consideration of public comments, we have adopted NewRx as a required transaction, and NewRxRequest and NewRxResponseDenied as optional transactions in the updated § 170.315(b)(3) electronic prescribing criterion. We have finalized these latter two transactions as optional in response to commenters' concerns regarding a lack of adoption by the PIS that would be involved in the exchange. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the NewRx transaction.
                    </P>
                    <HD SOURCE="HD3">ii. Request and Respond to Change Prescriptions (RxChangeRequest, RxChangeResponse)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxChangeRequest and RxChangeResponse. An RxChangeRequest transaction originates from a pharmacy and may be sent to a prescriber to: Request a change in the original prescription (new or fillable); validate prescriber credentials; request a review by a prescriber of the drug requested; or obtain prior authorization from the payer for the prescription. An RxChangeResponse transaction originates from a prescriber to respond to: A prescription change request from a pharmacy; a request for a prior authorization from a pharmacy; or a prescriber credential validation request from a pharmacy.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters supported the proposed adoption of the RxChangeRequest and RxChangeResponse transactions. One commenter recommended against adoption until industry adoption is more widely spread across retail pharmacies and demonstrates value.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Because the majority of commenters were in support of adoption of the RxChangeRequest and RxChangeResponse transactions as proposed, we have included these transactions as required in the updated § 170.315(b)(3) electronic prescribing criterion. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxChangeRequest and RxChangeResponse transactions.
                    </P>
                    <HD SOURCE="HD3">iii. Request and Respond to Cancel Prescriptions (CancelRx, CancelRxResponse)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for CancelRx and CancelRxResponse. A CancelRx transaction is a request from a prescriber to a pharmacy to not fill a previously sent prescription. A CancelRx must contain pertinent information for the pharmacy to be able to find the prescription in their system (patient, medication (name, strength, dosage, form), prescriber, and prescription number if available). A CancelRxResponse is a response from a pharmacy to a prescriber to acknowledge a CancelRx, and is used to denote if the cancellation is approved or denied.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of public comments reflected support for finalizing CancelRx and CancelRxResponse as required transactions. One commenter stated that the CancelRx transaction will reduce cost and improve patient safety, as patients may have remaining refills available that are subsequently modified based on a physician's new assessment. Another commenter noted that certified technology currently supports CancelRx transactions in version 10.6 of the NCPDP SCRIPT standard and encouraged developers to upgrade their technology to support CancelRx transactions in NCPDP SCRIPT standard version 2017071, as these transactions provide great value to end users. One commenter expressed concern for pharmacy readiness for CancelRx, and felt there should be sufficient industry adoption in place before it is a certification requirement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their overall support of the proposed CancelRx and CancelRxResponse transactions. In light of the commenters' overall support for the proposed CancelRx transactions and in order to support patient safety and the free flow of communication between prescribers and pharmacies, we have included these transactions as required in the revised § 170.315(b)(3) electronic prescribing criterion. We reiterate that although PIS are outside the scope of the ONC Health IT Certification Program, we encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the CancelRx transaction.
                    </P>
                    <HD SOURCE="HD3">iv. Request and Respond to Renew Prescriptions (RxRenewalRequest, RxRenewalResponse)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxRenewalRequest and RxRenewalResponse. An RxRenewalRequest transaction originates from a pharmacy to request additional refills beyond those originally prescribed. An RxRenewalResponse transaction originates from a prescriber to respond to the request from the pharmacy.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported adoption of the RxRenewalRequest and RxRenewalResponse transactions as proposed. One commenter stated that these transactions could be implemented after the CMS deadline of January 1, 2020 without loss of current functionality. Another commenter said that these transactions are widely used in the industry and provide great value to end users.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support for the RxRenewalRequest and RxRenewalResponse transactions and have included these transactions as required in the updated § 170.315(b)(3) electronic prescribing criterion. We reiterate that the entire updated § 170.315(b)(3) criterion and requirements must be met before certification can be granted. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the 
                        <PRTPAGE P="25682"/>
                        updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxRenewalRequest and RxRenewalResponse transactions.
                    </P>
                    <HD SOURCE="HD3">v. Receive Fill Status Notifications (RxFill, RxFillIndicatorChange)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxFill and RxFillIndicatorChange. An RxFill transaction is sent from a pharmacy to a prescriber or long term and post-acute care (LTPAC) facility indicating the FillStatus (dispensed, partially dispensed, not dispensed or returned to stock, or transferred to another pharmacy) of the new, refill, or resupply prescriptions for a patient. RxFillIndicator informs the pharmacy of the prescriber's intent for fill status notifications for a specific patient/medication. An RxFillIndicatorChange is sent by a prescriber to a pharmacy to indicate that the prescriber is changing the types of RxFill transactions that were previously requested, and in which the prescriber may modify the fill status of transactions previously selected or may cancel future RxFill transactions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         While the RxFill transaction received unanimous support as a required transaction, the vast majority of comments opposed adopting the RxFillIndicatorChange as proposed due to a lack of industry adoption and broad use by PIS. One commenter stated that there has not been a significant use case for the RxFillIndicatorChange transaction to prescribers. A few commenters suggested that ONC wait to require the RxFillIndicatorChange until this transaction is more widely adopted by both prescribers and pharmacies and value is realized in the industry, and suggested either removing RxFillndicatorChange from the proposed criterion or making this transaction optional. Another commenter argued that RxFillIndicatorChange should be optional as development to support this transaction in NCPDP SCRIPT standard version 2017071 would be resource intensive. Commenters in support of the adoption of the RxFillIndicatorChange transaction stated it is the only way to alter the prescriber notification preferences in an ambulatory or acute setting outside of a fillable message. Commenters supporting adoption of the RxFillIndicatorChange transaction further noted that, historically, the lack of prescriber control over notification messages may have had an impact on hindering adoption. One commenter suggested that, in lieu of the RxFillIndicatorChange transaction, EHRs receive all fill notifications and subsequently use logic to bring the clinician's attention to only important indicators.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all of the comments that supported the RxFill transaction and the RxFillIndicatorChange transaction. After consideration of comments received on the RxFill and RxFillIndicatorChange transactions, we have adopted the RxFill transaction as required and the RxFillIndicatorChange transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We encourage further development and innovation to address the concerns that we heard from commenters, and we will continue to monitor advancements in standards and technology for future rulemaking. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxFill transaction.
                    </P>
                    <HD SOURCE="HD3">vi. Request and Receive Medication History (RxHistoryRequest, RxHistoryResponse)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the related electronic transactions for RxHistoryRequest and RxHistoryResponse. An RxHistoryRequest transaction is a request from a prescriber to a pharmacy for a list of medications that have been prescribed, dispensed, claimed, or indicated by a patient. An RxHistoryResponse is a response to an RxHistoryRequest containing a patient's medication history. It includes the medications that were dispensed or obtained within a certain timeframe, and optionally includes the prescriber that prescribed it.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported adoption of the RxHistoryRequest and RxHistoryResponse transactions as proposed. One commenter also stated that both transactions could facilitate EHR and other health IT data integration with PDMP systems, yet noted that in many cases, State law or policy prohibits data integration between EHRs and PDMPs. Another commenter stated that these transactions are widely used in the industry and provide great value to end users.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments we have received on the use of the RxHistoryRequest and RxHistoryResponse transactions. We agree with the commenter that the RxHistoryRequest and RxHistoryResponse transactions support data integration between health IT systems such as EHRs and other information technology systems such as PDMPs, and encourage any efforts made by developers to fully integrate prescription and other health data into a provider's workflow within allowable law. We reiterate that ONC does not have control over State laws that govern PDMPs. We will continue to monitor regulatory and industry advancements in this area and will take them into consideration in future rulemaking. We have adopted these transactions as required in the updated § 170.315(b)(3) electronic prescribing criterion. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the RxHistoryResponse transaction.
                    </P>
                    <HD SOURCE="HD3">vii. Ask the Mailbox If There Are Any Transactions (GetMessage)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the electronic transaction GetMessage for Ask the Mailbox. This transaction is used by the prescriber or pharmacy when asking the mailbox if there are any transactions. It is the basis for the mechanism used by a prescriber or pharmacy system to receive transactions from each other, from a payer, or from the Risk Evaluation and Mitigation Strategy (REMS) Administrator via a switch acting as a mailbox.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Approximately half of commenters opposed adoption of the GetMessage transaction and the other half supported adoption in the updated § 170.315(b)(3) electronic prescribing criterion. Commenters not in support of the GetMessage transaction asserted that it is not in use by prescribers and that it is an obsolete method of message retrieval. Commenters in support of adoption argued that it is applicable when not transacting with real-time messaging, and should be adopted as an optional transaction.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. After careful consideration of all comments received, and in our ongoing efforts to align with CMS Part D requirements, we have determined to adopt the GetMessage transaction as optional for the updated § 170.315(b)(3) electronic prescribing criterion.
                        <PRTPAGE P="25683"/>
                    </P>
                    <HD SOURCE="HD3">viii. Relay Acceptance of a Transaction Back to the Sender (Status)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the related electronic transaction to relay acceptance of a transaction back to the sender. A Status transaction in response to any applicable transaction other than GetMessage indicates acceptance and responsibility for a request. A Status transaction in response to GetMessage indicates that no mail is waiting for pickup. A Status transaction cannot be held in an electronic mailbox and may not contain an error.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported adoption of the Status transaction as proposed. Two commenters noted that since the transaction is an acknowledgement, it would not contain the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments in support of the Status transaction and have included this transaction as required in the updated § 170.315(b)(3) electronic prescribing criterion. As an acknowledgement, we agree that the NCPDP SCRIPT version 2017071 standard does not support the conveying the reason for the prescription in the Status transaction, and have modified the requirement to reflect this.
                    </P>
                    <HD SOURCE="HD3">ix. Respond That There Was a Problem With the Transaction (Error)</HD>
                    <P>We proposed in 84 FR 7444 to enable a user to perform the related electronic transaction for Error response. This transaction indicates an error has occurred and that the request was terminated. An Error can be generated when there is a communication problem or when the transaction actually had an error. An Error can be held in an electronic mailbox, as it may be signifying to the originator that a transaction was unable to be delivered or encountered problems in the acceptance. The Error must be a different response than a Status, since the communication between the system and the mailbox must clearly denote the actions taking place. An Error is a response being delivered on behalf of a previous transaction, while Status signifies no more mail.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported adoption of the Error transaction as proposed. Two commenters noted that since the transaction is an acknowledgement, it would not contain the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments in support of the Error transaction and have included this transaction as required in the updated § 170.315(b)(3) electronic prescribing criterion. As an acknowledgement, we agree that the NCPDP SCRIPT version 2017071 standard does not support the reason for the prescription in the Error transaction, and we have modified that requirement to reflect this.
                    </P>
                    <HD SOURCE="HD3">x. Respond That a Transaction Requesting a Return Receipt Has Been Received (Verify)</HD>
                    <P>We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for Verify. This transaction is a response to a pharmacy or prescriber indicating that a transaction requesting a return receipt has been received. Verifications result when a “return receipt requested” flag is set in the original request. Upon receiving a transaction with ReturnReceipt set, it is the responsibility of the receiver to either generate a Verify in response to the request (recommended), or generate a Status in response to this request, followed subsequently by a free-standing Verify transaction. This transaction notifies the originator that the transaction was received at the software system. It is not a notification of action taking place, since time may elapse before the ultimate response to the transaction may take place.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported adoption of the Verify transaction as proposed. Two commenters noted that since the transaction is an acknowledgement, it would not contain the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments in support of the Verify transaction and have included this transaction as required in the updated § 170.315(b)(3) electronic prescribing criterion. As an acknowledgement, we agree that the NCPDP SCRIPT standard version 2017071 does not support the reason for the prescription in the Verify transaction, and we have modified that requirement to reflect this.
                    </P>
                    <HD SOURCE="HD3">xi. Request to Send an Additional Supply of Medication (Resupply)</HD>
                    <P>
                        We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for Resupply. This transaction is a request from a Long Term and Post-Acute Care (LTPAC) organization to a pharmacy to send an additional supply of medication for an existing order. An example use case is when a medication supply for a resident is running low (
                        <E T="03">e.g.,</E>
                         2-3 doses) and a new supply is needed from the pharmacy. In such a circumstance, the LTPAC organization sends the Resupply transaction as a way to notify the pharmacy that an additional supply for the medication is needed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concern over adopting this transaction as a required transaction for a few reasons. Some commenters noted that the Resupply transaction is only applicable to LTPAC practice settings for management of on-site pharmacy inventory and for communication between a LTPAC facility and a contracted pharmacy. Other commenters mentioned that PIS on the sending or receiving end of the transaction are not required to support this transaction. Some commenters stated that this transaction is not widely adopted among prescribers, and that it should not be adopted until this occurs. Two commenters requested that we either remove the transaction from the final rule or make the Resupply transaction optional. Other commenters stated that while this transaction may be beneficial in the future, it was their opinion that it is premature to require the Resupply transaction in the electronic prescribing criterion at this time.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments related to the Resupply transaction and have included this transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We are aware of several ONC-certified EHRs and other health IT that were either designed exclusively for, or were expressly designed to support, LTPAC providers in addition to other institutions, and encourage those and other developers to undergo certification testing to the Resupply transaction. Additionally, we note that pursuant to the certification criterion, health IT presented for certification must be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) in the Resupply transaction. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS.
                    </P>
                    <HD SOURCE="HD3">xii. Communicate Drug Administration Events (DrugAdministration)</HD>
                    <P>
                        We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for DrugAdministration. 
                        <PRTPAGE P="25684"/>
                        This transaction communicates drug administration events from a prescriber or care facility to the pharmacy or other entity. It is a notification from a prescriber or care facility to a pharmacy or other entity that a drug administration event has occurred (
                        <E T="03">e.g.,</E>
                         a medication was suspended or administration was resumed).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concern over adopting this transaction as a required transaction for a few reasons. Some commenters noted that the DrugAdministration transaction is only applicable to LTPAC practice settings and is therefore not relevant to the scope of all certified health IT products, though one commenter noted that there could be possible value of this transaction in ambulatory and acute care settings as well. In addition, one commenter reported LTPAC organizations interested in potentially using e-prescribing transactions rated DrugAdministration as a low priority transaction type, meaning there may not be a wide user base interested in implementing it.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate comments related to the DrugAdministration transaction and have included this transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We are aware of several ONC-certified EHRs and other health IT that were either designed exclusively for, or are used in support of, LTPAC providers, and encourage those and other developers to undergo certification testing to the DrugAdministration transaction. In light of the commenters' concerns, we have adopted the DrugAdministration transaction as optional because the ONC Health IT Certification Program is agnostic to care settings and programs, yet still supports many different use cases. This allows the ONC Health IT Certification Program to support multiple program and setting needs, including but not limited to the Promoting Interoperability Programs and long term and post-acute care. Because the transaction will be optional in the updated (b)(3) criterion, developers whose clients do not support long term care settings will not be required to demonstrate their capacity to send this transaction.
                    </P>
                    <HD SOURCE="HD3">xiii. Request and Respond to Transfer One or More Prescriptions Between Pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm)</HD>
                    <P>We proposed in 84 FR 7445 to enable a user to perform the related electronic transactions for RxTransferRequest, RxTransferResponse and RxTransferConfirm. The RxTransferRequest transaction is used when the pharmacy is asking for a transfer of one or more prescriptions for a specific patient to the requesting pharmacy. The RxTransferResponse transaction is the response to the RxTransferRequest which includes the prescription(s) being transferred or a rejection of the transfer request. It is sent from the transferring pharmacy to the requesting pharmacy. The RxTransferConfirm transaction is used by the pharmacy receiving (originally requesting) the transfer to confirm that the transfer prescription has been received and the transfer is complete.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The vast majority of commenters expressed concerns with the proposal to adopt RxTransferRequest, RxTransferResponse, and RxTransferConfirm transactions as proposed because they are only used in pharmacy-to-pharmacy transactions and are not applicable to EHRs. Further, two commenters noted that PIS are not required to support these transactions. Conversely, the two commenters that supported these transactions cited the benefit of allowing pharmacies to transfer unfilled controlled substance prescriptions, including Schedule 2, between pharmacies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We proposed to require all of the NCPDP SCRIPT 2017071 standard transactions CMS adopted in 42 CFR 423.160(b)(2)(iv) to illustrate our continued dedication to establish and maintain complementary policies to ensure that the current standard for certification to the electronic prescribing criterion permits use of the current Part D e-Rx and MH standards. With consideration of comments, and because it was not the intent of this certification criterion to include pharmacy specific transactions for the purposes of certification, we have adopted RxTransferRequest, RxTransferResponse, and RxTransferConfirm as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We reiterate that PIS are outside the scope of the ONC Health IT Certification Program and encourage pharmacy information system developers to advance their capacity to support a nationwide network of fully interoperable PIS.
                    </P>
                    <HD SOURCE="HD3">xiv. Recertify the Continued Administration of a Medication Order (Recertification)</HD>
                    <P>We proposed in 84 FR 7445 to enable a user to perform the related electronic transaction for Recertification. This transaction is a notification from a LTPAC facility, on behalf of a prescriber, to a pharmacy recertifying the continued administration of a medication order. An example use is when an existing medication order has been recertified by the prescriber for continued use.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concern over adopting the Recertification transaction as proposed primarily because it is only applicable to LTPAC practice settings. One commenter stated that LTPAC organizations interested in potentially using e-prescribing transactions rated Recertification as a low priority transaction type, suggesting that there may not be a wide user base interested in using it.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments in support of the Recertification transaction. In light of commenters concerns, we have adopted this transaction as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We are aware of several ONC-certified EHRs and other health IT that were either designed expressly for or in support of LTPAC providers, among other institutions, and encourage those and other developers to undergo certification testing to the Recertification transaction.
                    </P>
                    <HD SOURCE="HD3">xv. Complete Risk Evaluation and Mitigation Strategy (REMS) Transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse)</HD>
                    <P>We proposed in 84 FR 7445 to enable a user to perform the related electronic transactions for REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse. With CMS' adoption of these transactions in their recently issued final rule associated with e-Rx for Medicare Part D (42 CFR 423.160(b)(2)(iv)(W)-(Z)), we believe that it will be beneficial to include these four REMS transactions as part of this certification criterion: REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse.</P>
                    <P>
                        Furthermore, under the Food and Drug Administration Amendments Act (FDAAA) of 2007 (Pub. L. 110-85), the Food and Drug Administration (FDA) requires REMS from a pharmaceutical manufacturer if the FDA determines that a REMS is necessary to ensure the benefits of a drug outweigh the risks associated with the drug. In support of our sister agencies' work, we therefore proposed to include the REMS transactions as part of this certification criterion.
                        <PRTPAGE P="25685"/>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The vast majority of commenters supported adoption of REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse as optional, not required, transactions. Those in support of the transactions as proposed suggested that ONC should develop strategies to encourage providers to consciously consider and appropriately act on alerts to reduce the risk that these messages can easily be clicked through and missed, particularly if that provider is experiencing alert fatigue. Multiple reasons were provided by commenters who stated that the proposed REMS transactions should be adopted as optional in the proposed certification criterion. These reasons included the state of system readiness and adoption by manufacturers, REMS administrators, and pharmacy information systems. Another commenter stated that these REMS transactions are not yet in widespread use and should be piloted before being required as they require extensive design and development effort.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Given comments in support of the REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse transactions, we have included these transactions as optional in the updated § 170.315(b)(3) electronic prescribing criterion. We encourage commenters, developers, and other stakeholder to review and provide feedback on sections related to REMS (
                        <E T="03">https://www.healthit.gov/isa/allows-a-prescriber-communicate-a-rems-administrator</E>
                        ) and all other electronic prescribing use cases on the ONC Interoperability Standards (ISA) and post suggested edits and updates on these transactions as the industry advances. We encourage manufacturers, REMS administrators, and pharmacy information system developers to adopt these and other NCPDP SCRIPT standard version 2017071 transactions to improve safe prescribing practices and patient safety, and encourage developers to test their capacity to send and receive REMS messages by utilizing the testing tools that are available.
                    </P>
                    <HD SOURCE="HD3">xvi. Electronic Prior Authorization</HD>
                    <P>The Part D E-prescribing prior authorization process in 84 FR 28450 through 28458 requires that providers supply additional clinical information to verify that the medication can be covered under the Medicare Part D benefit. The prior authorization process is intended to promote better clinical decision-making and ensure that patients receive medically necessary prescription drugs. We are looking for ways that would streamline the process for exchanging clinical and financial data amongst prescribers and payers for prior authorization and improve patients' access to needed medications. Electronic prior authorization (ePA) automates this process by allowing providers to request and respond to electronic prior authorization transactions within their workflow. Using electronic prior authorization (ePA) transactions in the NCPDP SCRIPT standard version 2017071 provides a standard structure for exchanging prior authorization (PA) questions and answers between prescribers and payers, while allowing payers to customize the wording of the questions. Electronic prior authorization transactions will additionally support the automation of the collection of data required for PA consideration, allowing a health IT developer to systemically pull data from a patient's medical record. The efficiency gains offered by the ePA transactions in the NCPDP SCRIPT standard version 2017071 are the primary driver behind the development of this new capability. We believe the adoption of the ePA transactions included in version 2017071 of the NCPDP SCRIPT standard as optional transactions aligns with CMS' proposals for Part D ePA, and therefore, will not be adopting NCPDP SCRIPT standard version 2013101 as suggested by the commenter. On June 17, 2019, CMS issued the Secure Electronic Prior Authorization for Medicare Part D proposed rule (84 FR 28450), including a proposed new transaction standard for the Medicare Prescription Drug Benefit program's (Part D) e-prescribing program. Under this proposal, Part D plan sponsors would be required to support version 2017071 of the NCPDP SCRIPT standard for four ePA transactions, and prescribers would be required to use that standard when performing ePA transactions for Part D covered drugs they wish to prescribe to Part D eligible individuals. While not currently adopted as part of the Part D eRx standard, the NCPDP SCRIPT standard version 2017071 includes eight transactions that would enable the prescribers to initiate medication ePA requests with Part D plan sponsors at the time of the patient's visit. The eight transactions are: PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended the adoption of the ePA transactions available in the NCPDP SCRIPT standard version 2017071 for a variety of reasons, including improving efficiencies in the prior authorization process, improving patient outcomes, reducing point-of-sale rejections, increasing health IT developer adoption, and improving the Medicare Part D member experience. Several commenters indicated that lack of vendor support for the ePA transactions is a major barrier to physician use of the transactions. One commenter also suggested ONC adopt the NCPDP SCRIPT standard version 2013101 prior authorization transactions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. In consideration of comments, we have adopted the ePA transactions in the NCPDP SCRIPT standard version 2017071 as optional for the updated § 170.315(b)(3) electronic prescribing criterion. We believe the adoption of the ePA transactions included in version 2017071 of the NCPDP SCRIPT standard as optional transactions aligns with CMS' proposals for Part D ePA. We note that this final rule allows only for the voluntary certification of Health IT Modules by health IT developers to support these transactions, and does not require the certification, adoption, or use of such Health IT Modules by health care providers for this or any other purpose. We also note that development, testing, and implementation to support these transactions are important first steps toward integrating pharmacies in the prior authorization process for Part D prescriptions, while supporting widespread industry adoption and reducing burden on providers. We refer readers to the ONC Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs,
                        <SU>44</SU>
                        <FTREF/>
                         drafted in partnership with CMS, for further discussion of potential opportunities to ease related clinician burden through improved health IT enabled processes.
                    </P>
                    <FTNT>
                        <P>
                            <SU>44</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrs</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">xvii. Reason for the Prescription</HD>
                    <P>For each transaction specified, the technology must be able to receive and transmit the reason for the prescription.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported continued adoption of the reason for the prescription in specific electronic prescribing transactions. Some commenters noted that some of the proposed transactions would not contain the reason for the prescription as referenced in the updated 
                        <PRTPAGE P="25686"/>
                        § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We reiterate our decision to require Health IT Modules seeking certification to the updated electronic prescribing certification criterion to be capable of including the reason for the prescription as referenced in the updated § 170.315(b)(3)(ii) or § 170.315(b)(3)(ii)(D) within relevant electronic prescription transactions to support patient safety and align with HHS goals to expand safe, high quality health care. Health IT certified to the updated § 170.315(b)(3) criterion must have the capacity to enable a user to receive and transmit the reason for the prescription using the diagnosis elements: &lt;Diagnosis&gt;&lt;Primary&gt; or &lt;Secondary&gt;, or optionally, the technology must be able to receive and transmit the reason for the prescription using the &lt;IndicationforUse&gt; element, and be consistent with the International Statistical Classification of Diseases and Related Health Problems (ICDs) sent in the diagnosis element(s). The &lt;IndicationforUse&gt; element defines the indication for use of the medication as meant to be conveyed to the patient, and is included in the Sig. This requirement would apply to the following NCPDP SCRIPT standard version 2017071 transactions that we have adopted in this criterion (see discussion above): NewRx, RxChangeRequest, RxChangeResponse, CancelRx, RxRenewalRequest, RxRenewalResponse, RxFill, RxHistoryResponse, Resupply, RxTransferRequest, RxTranferResponse, REMSInitiationRequest, REMSInitiationResponse, REMSRequest, REMSResponse, PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse.
                    </P>
                    <HD SOURCE="HD3">xviii. Oral Liquid Medications</HD>
                    <P>
                        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>
                        <E T="03">Comments.</E>
                         While not within the scope of the Proposed Rule, one commenter did not support the continued requirement to prescribe oral liquids in “mL” units. The commenter supported the use of metric units, but did not agree with the requirement of the ONC Health IT Certification Program to limit this to only milliliters. The commenter recommended that the unit of measure used by a prescriber be at their discretion, as long as it is appropriate for the dosage.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for the input. Because this requirement is out of scope for the Proposed Rule in that we did not propose to change this conformance requirement, we decline to relax or retire the requirement for oral liquid medications to be prescribed in mL units. When we first adopted this requirement for the 2015 Edition Proposed Rule, several commenters were supportive of improving patient safety through use of the metric standard for dosing, but recommended that this requirement only apply to oral liquid medications. Incorrect dosage is a common error with liquid medication, often resulting from confusion between different dose measurements (
                        <E T="03">e.g.,</E>
                         mL and teaspoons). If these measurements are confused with each other, too much or too little of the medicine can be given. This requirement is also in alignment with NCPDP SCRIPT implementation recommendations.
                    </P>
                    <HD SOURCE="HD3">xix. Signatura (Sig) Element</HD>
                    <P>The Signatura (Sig) element is used to support electronic prescribing for the consistent expression of patient directions for use by relaying this information between a prescriber and a pharmacist. It must be legible, unambiguous, and complete to ensure the prescriber's instructions for use of the medication are understood. For each transaction, the technology must be able to receive and transmit the reason for the prescription using the indication elements in the SIG Segment.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested that the Sig element be required rather than optional to aid in future medication reconciliation and clinical reporting. Another commenter noted that the NCPDP SCRIPT standard version 2017071 allows for an increase in Sig length.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Given the lack of attention paid to and support for modifying the electronic prescribing criterion for Sig from optional to required, we have decided to retain Sig as optional in the updated § 170.315(b)(3) criterion. As discussed in the Reason for Prescription section, health IT may optionally seek certification to the updated electronic prescribing criterion by demonstrating their capacity to receive and transmit the reason for the prescription using the Sig element.
                    </P>
                    <HD SOURCE="HD3">xx. Real Time Pharmacy Benefit</HD>
                    <P>While development is still currently underway by NCPDP, the Real-Time Pharmacy Benefit (RTPB) standard is not yet complete. When complete, the RTPB standard is expected to facilitate the ability for pharmacy benefit payers/processors to communicate formulary and benefit information to providers. In the absence of that or another similar standard, CMS has adopted policies requiring the development and/or implementation of Real Time Benefit Transaction (RTBT) standards in the Part D e-Rx Program in the context of recent rulemaking. On May 16, 2019, CMS issued the Modernizing Part D and Medicare Advantage to Lower Drug Prices and Reduce Out-of-Pocket Expenses final rule, which includes a requirement under the electronic prescribing standards that Part D plan sponsors implement one or more electronic real-time benefit tools that are capable of integrating with at least one prescriber's electronic prescribing system or electronic health record no later than January 1, 2021 (84 FR 23832). One commenter recommended that CMS and ONC coordinate with NCPDP on requirements for real-time benefit functionality. We are also aware of industry efforts to develop a consumer-facing real-time pharmacy benefit functionality FHIR®-based implementation guide that we anticipate will be balloted in 2020. ONC will continue to monitor these efforts and consider proposing the NCPDP RTPB standard or a similar standard to enable real-time benefit transactions in future rulemaking.</P>
                    <HD SOURCE="HD3">xxi. Other Comments Received Outside the Scope of This Rule</HD>
                    <P>We note that we received several comments specifically addressing the electronic prescribing of controlled substances and prescription drug monitoring programs. We note that these specific comments are outside the scope of the proposals finalized in this rule. However, we note that we included a discussion of these topics in relation to the discussion of the RFI on OUD prevention and treatment in the Proposed Rule in 84 FR 7461.</P>
                    <HD SOURCE="HD3">5. Clinical Quality Measures—Report Criterion</HD>
                    <P>
                        In the 2015 Edition final rule, ONC adopted four clinical quality measure (CQM) certification criteria, § 170.315(c)(1) CQMs—record and export, § 170.315(c)(2) CQMs—import and calculate, § 170.315(c)(3) CQMs—report, and § 170.315(c)(4) CQMs—filter (80 FR 62649 through 62655). These four criteria were adopted with the intent to support providers' quality improvement activities and in electronically generating CQM reports for reporting with certified health IT to programs such as the EHR Incentive Programs, Quality Payment Program, and Comprehensive Primary Care plus initiative. The “CQMs—report” 
                        <PRTPAGE P="25687"/>
                        certification criterion (§ 170.315(c)(3)) included an optional certification provision for demonstrating that the health IT can create Quality Reporting Document Architecture (QRDA) reports in the form and manner required for submission to CMS programs, which is in accordance with CMS' QRDA Implementation Guide (IGs).
                    </P>
                    <P>
                        The CMS QRDA IGs provide technical guidance and specific requirements for implementing the HL7 QRDA Category I (QRDA I) and Category III (QRDA III) standards for reporting to CMS quality reporting programs.
                        <SU>45</SU>
                        <FTREF/>
                         The CMS QRDA IGs include the formal template definitions and submission criteria for submitting QRDA documents to the Comprehensive Primary Care Plus (CPC+) and Merit Based Incentive Payments System (MIPS) Programs. Some of the conformance statements in the HL7 QRDA standards have been further constrained to meet the specific requirements from these CMS programs. The CMS QRDA IGs also only list the templates specifying CMS-specific reporting requirements from the base HL7 QRDA standards. QRDA I is an individual-patient-level report. It contains quality data for one patient for one or more electronic clinical quality measures (eCQMs). QRDA III is an aggregate quality report. A QRDA III report contains quality data for a set of patients for one or more eCQMs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>45</SU>
                             The following resources provide additional information on the differences between the CMS QRDA and the HL7 QRDA standards: 
                            <E T="03">https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf</E>
                             (pg. 38) and 
                            <E T="03">https://ecqi.healthit.gov/sites/default/files/2019-07/2020-CMS-QRDA-III-Eligible-Clinicians-and-EP-IG-07182019-508.pdf</E>
                             (pg. 18).
                        </P>
                    </FTNT>
                    <P>Since the 2015 Edition final rule was published, we have gained additional certification experience and received feedback from the industry that health IT certified to the “CQMs—report” criterion (§ 170.315(c)(3)) are only/primarily being used to submit eCQMs to CMS for participation in CMS' programs. Therefore, as a means of reducing burden, we proposed to remove the HL7 CDA® Release 2 Implementation Guide: QRDA I; Release 1, Draft Standard for Trial Use (DSTU) Release 3 (US Realm), Volume 1 (§ 170.205(h)(2)), as well as the QRDA Category III, Implementation Guide for CDA® Release 2 (§ 170.205(k)(1)) and the Errata to the HL7 Implementation Guide for CDA® Release 2: QRDA Category III, DSTU Release 1 (US Realm), September 2014 (§ 170.205(k)(2)) standard requirements (HL7 QRDA standards) from the current 2015 Edition CQMs—report criterion in § 170.315(c)(3), and we also proposed to require that health IT certified to the current 2015 Edition CQMs—report criterion support the CMS QRDA IGs (84 FR 7446). We stated that this change would directly reduce burden on health IT developers and indirectly providers as they would no longer have to develop and support two forms of the QRDA standard.</P>
                    <P>We also solicited comment in the Proposed Rule on the future possibility of FHIR-enabled APIs replacing or complementing QRDA-based quality reporting. We also noted in the Proposed Rule that the Fast Health Interoperability Resources (FHIR®) standard offers the potential for supporting quality improvement and reporting needs, and holds the potential of being a more efficient and interoperable standard to develop, implement, and utilize to conduct quality reporting through APIs. We believe until the potential benefits of FHIR® APIs can be realized for quality reporting, and that solely requiring the CMS QRDA IGs for the updated 2015 Edition “CQMs—report” criterion will balance the burden on developers, while still ensuring module users' abilities to meet their quality reporting obligations to CMS (84 FR 7446).</P>
                    <P>
                        To support the proposal, we proposed to incorporate by reference in § 170.299 the latest annual CMS QRDA IGs, specifically the 2019 CMS QRDA I IG for Hospital Quality Reporting 
                        <SU>46</SU>
                        <FTREF/>
                         (§ 170.205(h)(3)) and the 2019 CMS QRDA III IG for Eligible Clinicians and Eligible Professionals (§ 170.205(k)(3)).
                        <SU>47</SU>
                        <FTREF/>
                         We noted in the Proposed Rule that developers would be able to update certified health IT to newer versions of the CMS QRDA IGs through the real world testing Maintenance of Certification provision for standards and implementation specification updates in § 170.405(b). We also proposed that a Health IT Module would need to be certified to both standards to ensure flexibility for Health IT Module users. We solicited comment on whether to consider an approach that would permit certification to only one of the standards depending on the care setting for which the Health IT Module is designed and implemented.
                    </P>
                    <FTNT>
                        <P>
                            <SU>46</SU>
                             
                            <E T="03"/>
                              
                            <E T="03">https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>47</SU>
                             
                            <E T="03">https://ecqi.healthit.gov/system/files/2019_CMS_QRDA_III_Eligible_Clinicians_and_EP_IG-508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters were supportive of the proposal to remove the HL7 QRDA standard requirements from the 2015 Edition CQMs—report criterion in § 170.315(c)(3), and to require that health IT certified to the criterion support the proposed CMS QRDA IGs. Some commenters observed that the main use cases for the certified QRDA export functionality (which is specific to CMS eCQMs) are to support direct data submission to CMS at the conclusion of reporting periods, to enable use of third party data submission Health IT Modules to meet CMS reporting requirements, and to support data extraction for registry reporting for participation in CMS programs such as MIPS. Commenters noted that while in some cases the extraction of data using a QRDA may also support other use cases—for example for a registry—because of the specificity of the criteria to the CMS eCQMs, such a transaction using the certified functionality is primarily for CMS reporting. Commenters noted the use of the CMS QRDA IG does not impede use of the data for other purposes. Finally, commenters noted that ONC should continue to provide health IT developers the flexibility to offer a non-certified QRDA functionality that could support eCQMs beyond those included for CMS programs. One commenter observed that while some health IT systems also provide tools for internal quality performance monitoring, those tools often do not rely on the generation of QRDA exports.
                    </P>
                    <P>Some commenters reported that the technical support of multiple versions of QRDA standards is unnecessary. Other commenters recommended maintaining only the HL7 standard or offering certification to the HL7 standard as an optional alternative to the CMS QRDA IG. One commenter who recommended maintaining both the HL7 standard and the CMS QRDA IGs suggested that ONC cite the CMS version(s) of the QRDA IG as a technical resource in the same manner the C-CDA companion guide is cited for the transition of care criteria and only require certifying to the HL7 version. These commenters agreed that developers should not have to certify to both HL7 QRDA and CMS QRDA IGs, but suggested if a developer passed certification for the CMS QRDA IGs, they should be deemed to have achieved certification to the HL7 QRDA standard as well. Commenters noted that the CMS QRDA apply specifications to the HL7 QRDA to support CMS eCQM reporting requirements.</P>
                    <P>
                        Other commenters specifically stated that the HL7 QRDA should remain as an optional certification criterion, since other organizations (
                        <E T="03">e.g.,</E>
                         certain hospital accreditation organizations such as The Joint Commission) use the 
                        <PRTPAGE P="25688"/>
                        HL7 QRDA, and there is need to assure the same style for submission across programs. They recommended that the HL7 QRDA IG persist as a continuing option in the Program to enhance alignment with other standards and C-CDA, and to encourage a base standard alignment across implementers such as CMS and The Joint Commission. They stated that citing only to the CMS QRDA IG may lead to misalignment with the base standards and reduce incentives to update the base standard.
                    </P>
                    <P>Some commenters expressed concern over the proposed removal of HL7 QRDA standards from the original 2015 Edition CQMs, stating it may undermine private sector efforts to self-regulate and stated that the removal of the HL7 QRDA may not achieve the envisioned burden reduction through the mere elimination of developers' need to certify and maintain multiple standards. While some commenters suggested that removing HL7 QRDA from the certification criteria could simplify the reporting process by recognizing the widespread use of CMS' QRDA IGs, they noted that the HL7 QRDA is currently the standard for most EHR systems and questioned how ONC proposed to implement this change given the prominence of HL7 standards in EHR systems. Several commenters noted that the disconnect between what the certification testing required, and how the standard was really being used in the industry (primarily but not exclusively to meet the CMS QRDA IG) created unnecessary certification testing burden, and asserted that the adoption of the CMS proprietary IG was more appropriate than to maintain HL7 QRDA.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support for the proposal and comments regarding the versions of standards. We understand the concerns expressed in opposition to this proposal, and we appreciate specifically the identification of potential risk for the elimination of the HL7 standard as applicable for other use cases. As noted previously, since the 2015 Edition final rule was published (October 16, 2015), we have gained received feedback from the industry that health IT certified to the “CQMs—report” criterion (§ 170.315(c)(3)) are only or primarily being used to submit eCQMs to CMS for participation in CMS' programs. In addition, we note that while the HL7 QRDA may be used for other purposes, the “CQMs—report” criterion (§ 170.315(c)(3)) is specific to the CMS eCQMs specified for participation in CMS reporting programs and no other eCQMs are tested under that criterion. This specificity applies not only to the current 2015 Edition “CQMs—report” criterion, but also to the other 2015 Edition CQM criteria and the prior 2014 Edition CQM criteria. This specificity is intended to provide assurances through testing and certification of the accuracy and standardization of CMS program measures across platforms, while recognizing that it would not be possible to specifically test to the entire universe of potential eCQMs in use by health care providers. Because of this dependency, testing and certification of both the HL7 QRDA for CQMs-report and the CMS QRDA IG is redundant to support eCQM data reporting.
                    </P>
                    <P>This has a dual impact on our considerations to finalize our proposal to require only the CMS QRDA IG. First, for use cases that are not related to CMS eCQM reporting, the certified functionality would not specifically support third party non-CMS eCQM reporting requirements, and so the modification to the functionality does not change the inability to use the certified version of the functionality for such purposes. Second, for those use cases involving registries or other third parties that are implementing or supporting CMS eCQM reporting, use of the CMS QRDA IG could additionally support such purposes. In addition, we are not restricting health IT developers from creating and providing to customers a non-certified functionality that supports the HL7 QRDA for the extraction of data for eCQMs that are not CMS eCQMs. We note that this is not a change from the prior policy allowing such flexibility. The prior certification for the QRDA IG included testing of CMS eCQMs only and it neither supported nor restricted any development of a QRDA functionality for non-CMS eCQMs.</P>
                    <P>We also agree that this approach will support closer alignment between the testing to the CMS QRDA IG specifications for a certified health IT module and the technical requirements for CMS program reporting. As part of the development of the CMS QRDA IGs, CMS strives to use the annual update process to resolve issues with CQMs based on updates to clinical guidelines and to advance the requirements as the standard for reporting eCQM data matures. In this way, aligning the criterion to the CMS program requirements that it specifically supports allows for alignment between these efforts as well as allowing for continued updates through the standards version advancement process. We also believe our finalized proposal will not impede private sector initiatives as the CMS IGs support the continued efforts by public/private collaboration through standards developing organizations (SDOs) to refine standards.</P>
                    <P>Therefore, as a means of reducing burden, we have finalized our proposal to remove the HL7 QRDA standard requirements from the 2015 Edition CQMs—report criterion in § 170.315(c)(3). We maintain our position that this would directly reduce burden on health IT developers and indirectly for health care providers as there would no longer be a requirement to develop and support two forms of the QRDA standard. We note that this does not preclude developers from continuing to support the underlying standard, especially where such standard may support reporting or health information exchange for other quality or public health purposes. Instead, we are simply not requiring testing and certification of any such standards, thereby eliminating testing and certification burden from a criterion that is at this time scoped to the purpose of reporting for CMS quality programs.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters did not support the proposal but instead recommended that CMS adopt the HL7 QRDA standard and do away with its own. However, several commenters offered suggestions to CMS on the development of the CMS QRDA IG and the alignment to the HL7 QRDA standard. A number of commenters noted the National Technology Transfer and Advancement Act of 1995 principle that Federal agencies are generally required to use technical standards that are developed by voluntary consensus standards bodies rather than a proprietary standard specific to an HHS program. Commenters also stated if CMS wanted to retain certain aspects of its standard, it should work with HL7 to get these vetted, balloted and approved for inclusion within the HL7 standard. Commenters also recommended working with SDOs or other organizations to sufficiently support CMS QRDA IGs. Some commenters suggested that consolidation of QRDA standards would be more likely result in reducing provider burdens than what ONC proposed.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their recommendations to improve the CMS QRDA IGs, or for CMS to work toward including the aspects of CMS QRDA IGs that they require for their program operations in SDO-balloted and approved consensus standards. Specific suggestions for CMS IG development are outside the scope of this rule. ONC had previously included the HL7 QRDA standards for certification in the 2015 Edition in order to potentially support a broader range of use cases than 
                        <PRTPAGE P="25689"/>
                        reporting for CMS programs. However, the specificity of the criterion to the CMS eCQMs limits the utility of the certified functionality beyond use with CMS eCQMs and as stated in the Proposed Rule, since the 2015 Edition final rule, ONC and CMS received significant stakeholder feedback that health IT modules certified to the “CQMs—report” criteria at 170.314(c)(3) in the 2014 Edition and 170.315(c)(3) for the 2015 Edition are used only or primarily for reporting to CMS programs. While we reiterate that these comments are outside the scope of this rule, we will continue to take this and other feedback into consideration and will continue to work with CMS, standards developing organizations, and health IT industry partners to explore the concerns raised in relation to reducing burden and promoting interoperable standards for quality reporting.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters provided mixed feedback on whether the updated 2015 Edition “CQMs—report” criterion should require adherence to both CMS QRDA IGs, specifically the 2019 CMS QRDA I IG for Hospital Quality Reporting 
                        <SU>48</SU>
                        <FTREF/>
                         and the 2019 CMS QRDA III IG for Eligible Clinicians and Eligible Professionals.
                        <SU>49</SU>
                        <FTREF/>
                         The majority of commenters recommended that to reduce burden, ONC should consider a certification approach that permits developers to seek certifications based on the care setting(s) their health IT modules are intended serve. For example, commenters suggested that ONC should only require certification to the 2019 QRDA I IG for Hospital Quality Reporting if a Health IT Module is designed exclusively for the reporting of hospital measures, and only require certification to the 2019 QRDA III IG for Eligible Clinicians and Eligible Professionals when a Health IT Module is designed exclusively for the reporting of ambulatory measures. In instances in which both populations are served, the developer would then seek certification to both standards. Commenters suggested this approach would avoid the unnecessary burden of certifying to a standard that the Health IT Module was not intended to serve. Other commenters stated that the certification requirements should ensure that certified Health IT Modules can support quality measure reporting by all potential users, especially given the potential expansion of eligible participants in certain CMS programs (
                        <E T="03">e.g.,</E>
                         should a program expand from hospital-based only to include ambulatory measures). These commenters recommended the adoption of a requirement for certified Health IT Modules to calculate and export both CMS QRDA I patient-level reports for Hospital Quality Reporting and CMS QRDA III aggregate summary reports for Eligible Clinicians and Eligible Professionals. These commenters noted that if a certified Health IT Module can only send an aggregate report without a patient level report, then this would greatly diminish the ability to verify the underlying calculations. However, commenters recommended that ONC clarify that the transition to CMS QRDA I IG-based reports (patient-level, QRDA I IG for Hospital Quality Reporting) does not necessarily mean that a hospital quality measure must be certified by any system (
                        <E T="03">i.e.,</E>
                         an ambulatory Health IT Module can certify to only CMS QRDA III IG requirements). Commenters also sought clarity that the transition to QRDA III reports (aggregate-level, IG for Eligible Clinicians and Eligible Professionals) does not necessarily mean that an ambulatory quality measure must be certified by any system (
                        <E T="03">i.e.,</E>
                         a hospital system can certify to only hospital measures). Finally, one commenter noted that certifying ambulatory quality measures for the QRDA I to a hospital IG is not effective and will interfere with the use case of using QRDA I to combine data between multiple ambulatory systems such as for group reporting.
                    </P>
                    <FTNT>
                        <P>
                            <SU>48</SU>
                             
                            <E T="03"/>
                              
                            <E T="03">https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>49</SU>
                             
                            <E T="03">https://ecqi.healthit.gov/system/files/2019_CMS_QRDA_III_Eligible_Clinicians_and_EP_IG-508.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their comments regarding whether a Health IT Module should be certified to both CMS QRDA IG standards or whether to consider an approach that permits certification to only one of the standards depending on the care setting for which the Health IT Module is designed and implemented. We agree with commenters that our certification approach should prevent unintended burden by tailoring the requirements to the type of measures being tested. This would mean that for the updated certification criterion “CQMs—report” in § 170.315(c)(3) a Health IT Module testing only ambulatory measures would test only with the CMS QRDA III IG for ambulatory measures and a Health IT Module testing only inpatient measures would test only with the QRDA I CMS IG for inpatient measures. A Health IT Module supporting both ambulatory and inpatient measures would be required to test to both the CMS QRDA I IG and the CMS QRDA III IG. We clarify that testing for the 2015 Edition “CQM—capture and export” criterion in § 170.315(c)(1) criteria includes demonstrating the capability to export a QRDA I report specific to the eCQM being tested—which would support use case noted by the commenter to combine data across multiple ambulatory systems. We have not proposed and have not finalized a change to the 2015 Edition “CQM—capture and export” criterion in § 170.315(c)(1). We further note that health IT developers may leverage QRDA file formats for a wide range of use cases and that our inclusion of the CMS QRDA I and QRDA III IGs does not prohibit the use of the QRDA standard for any other purpose. As noted above, we have finalized the adoption of the CMS QRDA IGs for the “CQMs—report” criterion in § 170.315(c)(3) for which the Health IT Module is presented for certification.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported the proposal to adopt the latest CMS QRDA IGs at the time of final rule publication, as CMS updates their QRDA IGs annually to support the latest eCQM specifications and only accepts eCQM reporting to the latest version. However, a few commenters recommended that ONC monitor this part of the certification process for unintended consequences since CMS' IGs are updated on a yearly basis. Some commenters noted that given the lack of alignment with timing, eCQM measures and standards will continue to lack testing. Other commenters recommended the IGs be updated in alignment with updates to the certification standards. A few commenters requested clarification of the effective dates and asked ONC to evaluate and propose a timeline for the implementation of an alignment between the programs. In addition, commenters asked for clarification on whether ONC will propose penalties for providers who may be unable to meet the timeline if it is insufficient.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input and have adopted the latest CMS QRDA IG versions available at the time of publication of this final rule. For details on the latest CMS QRDA IGs, we refer readers to the CMS QRDA I Implementation Guide for Hospital Quality Reporting and CMS QRDA III Implementation Guide for Eligible Clinicians and Eligible Professionals available on the eCQI Resource Center website.
                        <SU>50</SU>
                        <FTREF/>
                         We note that CMS updates 
                        <PRTPAGE P="25690"/>
                        the CMS eCQMs on an annual basis as well as the CMS QRDA IGs for reporting to CMS programs. As in prior years going back to the 2014 Edition, HHS will continue to update the Cypress testing tool to support health IT developer testing to the most recent annual update. We note that CMS has previously required that EHR technology used for eCQM reporting be certified to all eCQMs but does not need to be recertified each time it is updated to a more recent version of the eCQM electronic specifications, unless the EHR technology is supporting new eCQMs or functionality (such as the “CQM—filter” criterion in § 170.315(c)(4)) (84 FR 42505). This approach allows for continued updates to and testing of eCQMs while minimizing the burden on developers and providers to support those updates in time for each annual performance period. Finally, we note that ONC has no authority to set requirements, incentives, or penalties for health care providers related to the use of health IT, and we direct readers to CMS for information on health IT requirements in CMS programs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>50</SU>
                             The Electronic Clinical Quality Improvement (eCQI) Resource Center. CMS QRDA I Implementation Guide for Hospital Quality Reporting and CMS QRDA III Implementation Guide for Eligible Clinicians and Eligible 
                            <PRTPAGE/>
                            Professionals. Available at: 
                            <E T="03">https://ecqi.healthit.gov/qrda</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters agreed with ONC's assessment in the Proposed Rule that quality reporting is not yet ready to transition to FHIR and that more testing and validation of FHIR is needed before requiring a new API-based reporting functionality as a part of the Program. Some commenters supported the adoption of FHIR Release 4-enabled APIs as a replacement for QRDA-based reports, but stated that published documentation aligning HL7 C-CDA, QRDA, and/or FHIR standards to CMS' “Quality Data Model,
                        <SU>51</SU>
                        <FTREF/>
                        ” which is an information model that defines relationships between patients and clinical concepts in a standardized format to enable electronic quality performance measurement and that would allow for more consistent eCQM reporting and improved interoperability in clinical quality feedback between health systems and data registries. Other commenters stated that FHIR standards will likely strengthen standardized data element availability and flexibility to improve the types of eCQMs that may be developed, and suggested that CMS continue to work with the National Quality Forum, measure stewards, and measure developers to advance both existing evidence-based measures (
                        <E T="03">e.g.,</E>
                         either administrative or hybrid measures) and evolving outcome measures that utilize population-based electronic clinical data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>51</SU>
                             
                            <E T="03">https://ecqi.healthit.gov/qdm</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We believe there are potential benefits to be gained by exploring both near-term, program specific implementations of APIs to support current quality reporting submission mechanisms such as for CMS eCQM reporting as well as the long-term potential to reimagine quality measurement by leveraging API technologies. We believe that these technology approaches could help providers and payers, including CMS, move from the current approach, in which providers are required to calculate and submit results on specific quality measures, to one in which payers, including CMS, could obtain clinical data for quality measurement directly through an API. This could potentially include the ability to obtain clinical data for a defined group or sample set of patients to assess quality across patient populations, as well as to compare clinical data for patients over time to assess quality impacts through longitudinal measurement. We believe emerging innovative standards are now available to support such models, specifically the ability to respond with clinical data for a defined group or sample set of patients using the bulk data capabilities in FHIR Release 4. We note that readiness for such an approach, both for recipients of quality data and for health IT developers supporting quality improvement solutions, is not yet mature for adoption of such a criterion in the Program. However, we are committed to continuing to work with HHS partners, health care providers, health IT developers and SDOs to explore the potential for such solutions in the future.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended additional changes not considered in the Proposed Rule. For example, one commenter recommended ONC require that to be certified in § 170.315(c)(1) “CQMs—record and export,” § 170.315(c)(2), “CQMs—import and calculate,” and § 170.315(c)(3) “CQMs—report,” a Health IT Module be certified in a minimum of 9 eCQMs instead of one eCQM and that the § 170.315(c)(1) criterion should require the ability to export all patients for a given eCQM. Currently, the ability to export a QRDA I file can be limited to one patient at a time. Commenters noted that this limitation defeats the purpose of data interoperability and does not advance the goals of ONC to increase access to data and the interoperability of Health IT Modules. And another commenter recommended that, in addition to the adoption of the CMS IGs under the § 170.315(c)(3) criterion, that the CMS IGs replace the corresponding HL7 QRDA IGs as ONC's Program standard under the § 170.315(c)(1) criterion (which currently references QRDA I exclusively) and § 170.315(c)(2) criterion (which currently references only QRDA I as standard, but also involves use of QRDA III for purposes of verifying appropriate calculation of measures from imported QRDAs).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for input and clarifications. While we appreciate comments suggesting changes to § 170.315(c)(1) “CQMs—record and export,” and § 170.315(c)(2) “CQMs—import and calculate,” the recommended changes are outside the scope of our proposal. Therefore, while we may consider these recommendations for future Program rulemaking, we have not adopted the suggested changes to § 170.315(c)(1) “CQMs—record and export,” or § 170.315(c)(2) “CQMs—import and calculate in this final rule.
                    </P>
                    <P>
                        As noted previously, we have finalized the update to the “CQMs—report” criterion in § 170.315(c)(3) to require that health IT developers use the CMS QRDA IG appropriate to the measures being submitted for testing and certification to read as follows: “
                        <E T="03">Clinical quality measures—report.</E>
                         Enable a user to electronically create a data file for transmission of clinical quality measurement data in accordance with the applicable implementation specifications specified by the CMS implementation guides for Quality Reporting Document Architecture (QRDA), category I, for inpatient measures in § 170.205(h)(3) and CMS QRDA, category III, for ambulatory measures in § 170.205(k)(3).”
                    </P>
                    <HD SOURCE="HD3">6. Electronic Health Information (EHI) Export Criterion</HD>
                    <P>
                        We proposed to adopt a new 2015 Edition certification criterion referred to as “EHI Export” in § 170.315(b)(10). The criterion's conformance requirements were intended to support two contexts in which we believed 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 proposed in § 170.315(b)(10)(i) at 84 FR 7447 that health IT certified to this criterion would support single patient EHI export upon a valid request by a patient or a user on the patient's behalf. Second, we proposed in § 170.315(b)(10)(ii) at 84 FR 7447 that the proposed criterion would support the export of all EHI when a health care 
                        <PRTPAGE P="25691"/>
                        provider chooses to transition or migrate information to another health IT system. Third, we proposed in § 170.315(b)(10)(iii) that the export format(s) used to support the exports must be made available via a publicly accessible hyperlink, including keeping the hyperlink up-to-date with the current export format.
                    </P>
                    <P>At the time of the Proposed Rule, we indicated our belief that this proposed certification criterion provided a useful first step toward enabling patients to have electronic access to their EHI and equipping health care providers with better tools to transition patient EHI to another health IT system. We noted that this criterion would create a baseline capability for exporting EHI. We requested comments regarding the proposed single patient EHI export and the proposed database export functionalities, as well as the proposed scope of data export and other criterion elements throughout the Proposed Rule section at 84 FR 7447 through 7449.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters generally supported the intent of the proposed “EHI export” criterion to advance the access, exchange, and use of EHI. Commenters in favor of the criterion and its proposed conformance requirements stated that it would foster innovative export capabilities and inform areas where additional standards development could be needed. We also received a variety of comments asking for adjustments to proposed requirements. A majority of commenters requested revisions to the criterion, including calling for a defined set of data elements for export and specific data transport standards. Many commenters offered recommended standards or requested that we provide specific standards to reduce variation. These commenters indicated that no defined standard could lead to broad interpretation and potential inadequacies of the data export. Some commenters expressed a medical record keeping concern that the proposed standards-agnostic approach for the export functionality could be problematic, stating that the export could create a dissonance if the EHI renders health record content in a form or format that is different from what a provider produces or utilizes as output. Other commenters opposed the adoption of this proposed criterion. These commenters expressed concern that later implementation of standards, such as APIs, would make developers invest time and funding into the proposed requirements only for the work to be discarded in the future.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback on the proposed “EHI export” criterion at 84 FR 7446 of the Proposed Rule (§ 170.315(b)(10)). We have considered commenters' concerns, support, and recommendations and adopted a revised version of this certification criterion. This final certification criterion is designed to align with section 4006(a) of the Cures Act, which requires the Secretary, in consultation with the National Coordinator, to promote policies that ensure that a patient's EHI is accessible to that patient and the patient's designees, in a manner that facilitates communication with the patient's health care providers and other individuals (84 FR 7447). In addition, this criterion complements other provisions that support patients' access to their EHI and health care providers use of EHI, such as the secure, standard-based API certification criterion (proposed in 84 FR 7427 and finalized in § 170.315(g)(10)), and also supports longitudinal data record development. Therefore, we have finalized the criterion with revisions. Notably, in response to comments on this criterion and the proposed information blocking policies, we have adopted a focused definition of EHI in § 170.102 and § 171.102. For context purposes, the EHI definition is focused on “electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501” with additional caveats not repeated here for briefness. Put simply, the EHI definition represents the same ePHI that a patient would have the right to request a copy of pursuant to the HIPAA Privacy Rule. This is a regulatory concept with which the industry has nearly 20 years of familiarity. Health IT developers' customer base includes health care providers who are HIPAA covered entities, and in many cases developers serve as HIPAA business associates to their covered-entity customers. Thus, health IT developers should be accustomed to identifying ePHI so that their products support appropriately securing it, the fulfillment of patient access requests, and the identification and reporting on breaches. They should, therefore, be well prepared to identify what EHI their product(s) would need to export in order to support a patient's HIPAA right of access. The finalized criterion requires a certified Health IT Module to include export capabilities for a single patient (§ 170.315(b)(10)(i)) and patient population (§ 170.315(b)(10)(ii)) related to EHI. More specifically, the export(s) will need to include the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. We emphasize that such “stored” data applies to all EHI and is agnostic as to whether the EHI is stored in or by the certified Health IT Module or in or by any of the other “non-certified” capabilities of the health IT product of which the certified Health IT Module is a part. The scope of EHI applies across the product as a whole as a means to further promote the access, exchange, and use of EHI for the use cases required to be supported by this certification criterion. The finalized scope of data included in the criterion export is discussed in greater detail under the “Scope of Data Export” (IV.B.6.c) section below.
                    </P>
                    <P>While the data that must be exported has been more specifically scoped, the certification criterion does not require a specific standard format be used for the purposes of representing the exported EHI. We also modified the certification criterion's documentation requirements in § 170.315(b)(10)(iii) to be more concise. As finalized, the documentation required for the export format(s) used to support (b)(10)(i) and (ii) functionality must be kept up-to-date and made available via a publicly accessible hyperlink. Additional information is included under “Export Format” below.</P>
                    <P>
                        We appreciate the comments received regarding the specific data sets and data transmission standards for this certification criterion. We reiterate that the finalized certification criterion is specific to EHI, as defined, that can be stored at the time of certification by the product, of which the Health IT Module is part, and is not limited to a predefined data set or to specific data transmission standards. Developers are required to ensure the health IT products they present for certification are capable of exporting all of the EHI that can be stored at the time of certification by the product. We acknowledge that the amount of EHI exported and format in which such EHI is represented will differ by developer and products of which certified Health IT Modules are a part. Each product presented for certification, of which the Health IT Module is a part, will likely vary in the amount of EHI it can store. As a result, the amount of EHI that will need to be able to be exported in order to demonstrate conformance with this certification criterion will vary widely because of the diversity of products presented for certification. For example, small software components only capable of storing a certain scope of EHI (and only certified to a few certification criteria) will only need to be able to 
                        <PRTPAGE P="25692"/>
                        export that stored EHI in order to meet this certification criterion. In contrast, a more comprehensive product with an EHI storage scope well beyond all of the adopted certification criteria would by its nature need to demonstrate it could export a lot more EHI. But even in this latter case, it is important to note that while that scope of EHI may be comprehensive for that product, it may still not be all of the health information for which a health care provider is the steward and that meets the EHI definition within the health IT products deployed within their organization. In other words, a health IT user may have other health IT systems with no connection to the Certification Program that store EHI and such EHI would still be in scope from an information blocking perspective. We note all of these distinctions to make clear for and to dissuade readers from jumping to an improper conclusion that the EHI export criterion in the Certification Program is a substitute for or equivalent to the EHI definition for the purposes of information blocking. We direct readers to the information blocking section (VIII) for additional information. Unless a health care provider (which is an “actor” regulated by the information blocking provision) only used a single health IT product to store EHI that was also certified to this certification criterion, the EHI definition will always be larger. Regardless of the amount of EHI each product has within its scope to export, the purpose of this certification criterion is to make the EHI already available in such health IT products more easily available for access, exchange, and use by patients and their providers, which is a fundamental principle established by the Cures Act.
                    </P>
                    <P>As technology continues to advance, and as stated in the Proposed Rule at 84 FR 7447, this criterion may not be needed in the future. However, the comments suggesting we not adopt this certification criterion at all because it will be outmoded at some point in the future did not appear to acknowledge that all technology is eventually replaced for a variety of reasons. We too look forward to a day where standards-based APIs are the predominant method for enabling electronic health information to be accessed, exchanged, and used. We strongly encourage industry partners to engage in their own consortiums, with ONC and other Federal agencies, and other stakeholders in the health IT ecosystem to advance standards development, prototypes, and pilot testing in order to ultimately build a body of evidence that could accelerate the adoption and implementation timeline of technology that could either add more structure to or remove the need for this certification criterion in the future. However, we do not accept the promise of this future state as a reason to simply wait, nor do we believe that the potential of this future justifies delaying the incremental progress the industry can make. In this case, had we followed such commenters direction, we would be withholding from patients and health care providers the certainty that there would be technical capabilities within a defined time that could be used to enable the access, exchange, and use of EHI. We note that suggestions by commenters to structure the certification criterion to only move information within specific data sets or via specific standards-based export functionality would delay the ability of patients and users of health IT to access, exchange, and use the information they need and would run counter to the underlying principles supporting this certification criterion—that the electronic health information should be accessible for access, exchange, and use. For this reason, we have not included specific data set or export requirements in this certification criterion as some commenters suggested.</P>
                    <P>In consideration of comments, the finalized “EHI export” criterion in § 170.315(b)(10) is not included in the 2015 Edition Base EHR definition, which is a modification from what we proposed. We revised the policy in recognition of comments received, including comments regarding the structure and scope of the criterion as proposed and the development burden of the criterion. As finalized here, we believe that including this certification criterion in the Conditions and Maintenance of Certification is the best place to include the requirement associated with the criterion. Thus, we have finalized the § 170.315(b)(10) certification criterion as a general certification requirement for the ONC Health IT Certification Program, and have not included it in the 2015 Edition Base EHR Definition.</P>
                    <P>In general, we also note that those who use Health IT Module(s) certified to the “EHI export” criterion remain responsible for safeguarding the security and privacy of individuals' EHI consistent with applicable laws and regulations related to health information privacy and security, including the HITECH Act, HIPAA Privacy and Security Rules, 42 CFR part 2, and State laws. The existence of a technical capability to make EHI more accessible and useable by Health IT Module users does not alter or change any of their data protection responsibilities under applicable laws and regulations.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments received included concerns with the development and use of the certification criterion. Some commenters expressed support for the criterion's overall flexibility but cautioned ONC to be realistic regarding the goals and expectations for the certification criterion. These commenters also expressed concern that the proposed certification criterion would result in development for an ambiguous scope of data export and would divert from work needed to achieve other interoperability goals. Other commenters stated concerns that development costs could potentially be passed onto health IT users, such as health care providers. These commenters also anticipated use and implementation challenges for users that work with multiple systems.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for sharing their concerns. In regards to the use of the capabilities required by this certification criterion, we interpreted from comments some confusion related to potential “users” of the health IT. As previously defined under the Program, “user” is a health care professional or their office staff; or a software program or service that would interact directly with the certified health IT (80 FR 62611, 77 FR 54168).
                    </P>
                    <P>We also appreciate the comments and concerns regarding the potential development burden that could result to meet the requirements of the proposed criterion. In consideration of those expressed concerns, we have narrowed the scope of data that must be exported. This more focused scope should measurably reduce the stated ambiguity by commenters and development burden for health IT developers in contrast to what was proposed (84 FR 7448). We appreciate the concerns expressed for the potential user(s) of Health IT Modules, but note that the certification criterion is designed to advance the electronic movement of data out of a product while factoring in the current variability in health IT. As always, we encourage developers to seek innovative and expedient capabilities that, at minimum, meet the requirements of the certification criterion, as well as the developing needs of their health IT users.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters provided alternative ideas for the criterion specific to USCDI. Some recommended amending the criterion to require the specific structure and applicable standards for USCDI elements, or starting this criterion with a minimum of USCDI data elements. Several commenters recommended expanding 
                        <PRTPAGE P="25693"/>
                        the existing 2015 Edition “data export” criterion to include USCDI in lieu of the proposed “EHI export” criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for sharing these ideas. We have finalized the “EHI export” criterion as described above. Our intent under this finalized criterion is to advance export functionality for single patient and patient population EHI exports, while leaving flexibility in regard to format and without assigning specific data sets due to the different scopes of data that health IT may include. Toward those ends, limiting the scope of this certification criterion to solely the data represented by the USCDI would make it no different than other USCDI bounded certification criteria already adopted and would not advance the policy interests we have expressed. In regards to comments on the existing 2015 Edition “data export” criterion (§ 170.315(b)(6)), we refer readers to our discussion of the criterion below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some comments expressed confusion and asked for guidance on how this certification criterion would apply to health IT that is no longer certified. Commenters also asked for guidance on how this criterion applies to other systems that interact with Health IT Modules certified to this criterion based on the proposed scope of data for export.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for requesting clarification. We first clarify that the export functionality under this certification criterion applies to Health IT Modules presented for certification under the Program. More specifically, if a health IT developer presents for certification a health IT product of which a Health IT Module is a part and the product electronically stores EHI, certification to § 170.315(b)(10) is required. As noted in our response above, this would include the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. This includes all EHI stored by the product's certified and “non-certified” capabilities. For example, if a health IT product includes a component(s) that is presented for certification and that component stores EHI, then that EHI must be made available for export, in accordance with § 170.315(b)(10). Importantly, the scope of data required to be exported in accordance with § 170.315(b)(10) includes only to the EHI that can be stored at the time of certification by the product. We emphasize that such “stored” data applies to all EHI and is agnostic as to whether the EHI is stored in or by the certified Health IT Module or in or by any of the other “non-certified” capabilities of the health IT product of which the certified Health IT Module is a part. The scope of EHI applies across the product as a whole as a means to further promote the access, exchange, and use of EHI for the use cases required to be supported by this certification criterion.
                    </P>
                    <HD SOURCE="HD3">a. Single Patient Export To Support Patient Access</HD>
                    <P>As part of this criterion, we proposed a functionality for single patient EHI export at 84 FR 7447 which would enable a user of certified health IT to timely create an export file(s), with the proposed scope of data export of all of the EHI the health IT product produces and electronically manages on a single patient. The functionality would also require a user to be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate. In addition, we proposed that health IT certified to this criterion would be required to enable the ability to limit the users who could create such export file(s) in at least one of two ways: To a specific set of identified users, and (2) as a system administrative function. We also proposed that the export file(s) created must be electronic and in a computable format and that the export file(s) format, including its structure and syntax, must be included with the exported file(s).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments in support of the proposal for single patient export to support patient access under the certification criterion. The majority of these commenters provided recommended revisions, including suggested transmission formats and data export content standards. Some commenters recommended the addition of this certification criterion to the list of criteria subject to real world testing.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We have finalized the single patient export functionality in § 170.315(b)(10)(i) with some modifications. We finalized a focused data export scope, which applies to the data expected to be available for export under the single patient export capability. We defined the scope of data that needs to be exported to EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. Thus, we have modified the title of § 170.315(b)(10)(i) to “single patient electronic health information export” to reflect the scope of this data export. We finalized that the capability for a user to execute a single patient export must be able to be limited at least one of two ways: To a specific set of identified users, and as a system administrative function. While we finalized as proposed in § 170.315(b)(10)(i)(D) that the export files must be electronic and in a computable format, we modified in § 170.315(b)(10)(ii)(E) that the publicly accessible hyperlink of the export's format must be included with the exported file(s). This modification clarifies that the user is able to access the format, and that the developer will keep their hyperlink up-to-date.
                    </P>
                    <P>We appreciate commenter's recommendations for specific data transmission formats and data content standards, and considered the range of recommendations when developing the finalized scope of data export required for this criterion. We believe the definition of EHI as focused in § 171.102, as well as the modifications to the scope of data export, addresses the data ambiguity concerns received by commenters. We direct readers to our detailed discussion of the scope of data export below. As finalized, the certification criterion's export, for both single and patient population EHI Export, remain standards-agnostic. We believe that the finalized certification criterion will serve as an initial step towards increased access, exchange, and use of electronically available data. We will continue working alongside industry stakeholders and will revisit export strategies as standards continue to develop and mature. We appreciate confirmation that commenters support inclusion of the criterion in § 170.315(b)(10) alongside the rest of the care coordination criteria in § 170.315(b), and have finalized that this certification criterion is part of the real world testing Condition of Certification requirement.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters asked ONC to clarify how health IT developers may limit the users' ability to access and initiate the export function in § 170.315(b)(10)(i), and to include examples of potential permissible and non-permissible behaviors.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments received. We again clarify that “user” is a health care professional or their office staff; or a software program or service that would interact directly with the certified health IT (80 FR 62611, 77 FR 54168). In regards to questions on permissible behaviors for developers, the ability to limit the health IT users' access to the single patient EHI export functionality in § 170.315(b)(10)(i) is intended to be used by and at the discretion of the organization implementing the technology. We reiterate that similar to the 2015 edition “data export” criterion in §  170.315(b)(6), this cannot be used by health IT developers as a way to 
                        <PRTPAGE P="25694"/>
                        thwart or moot the overarching user-driven aspect of this capability (80 FR 62646). We do not wish to limit this functionality to specific permissible or non-permissible behaviors at this time, but reaffirm in § 170.315(b)(10)(i)(B) that a user must be able to execute the single patient EHI export capability at any time the user chooses and without subsequent developer assistance to operate. To be clear, the user must be able to execute the export without the intervention of the developer. We also finalize, as proposed, in § 170.315(b)(10)(i)(C) that this capability must limit the ability of user who create such export files(s) in at least one of two ways; (1) to a specific set of identified users, and (2) as a system administrative function.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of comments received asked for further clarity on “timely” regarding a health IT user's request to create an export file(s).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the questions. We specify that “timely” means near real-time, while being reasonable and prudent given the circumstances.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters also sought clarity on data in electronic health records that may be shared between patients and possibly included in the export. These commenters asked if under the proposed criterion, patients have a right to information about others that may be contained in their medical record.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for submitting these questions. In regards to shared patient data concerns, we note that the export functionality requirements apply to what a product with a Health IT Module certified to this criterion must be able to do regardless of whether the developer is operating the export for a health care provider or a health care provider is maintaining and operating the technology in their own production environment. Under the HIPAA Privacy Rule, when a covered health care provider, in the course of treating an individual, collects or otherwise obtains an individual's family medical history, this information may become part of the medical record for that individual and thus be included in the “designated record set” (defined at 45 CFR 164.501)). Thus, if the family medical history becomes part of the designated record set, the individual/patient may exercise the right of access (45 CFR 164.524) under the HIPAA Privacy Rule to this information in the same fashion as any other information in the medical record. The HIPAA Privacy Rule does not prevent individuals, themselves, from gathering medical information about their family members or from deciding to share this information with family members or others, including their health care providers. Thus, individuals are free to provide their doctors with a complete family medical history or communicate with their doctors about conditions that run in the family. To the degree that, for example, Patient A's medical record include that their mother had breast cancer, that information would be accessible to Patient A because it was provided by Patient A and included as part of their medical record. Under this criterion, patients would not have a “right” to other patient's records, consistent with existing laws. In general, with respect to patient access to information, we note that Health IT Module users must ensure that any disclosures of data conform to all applicable laws and regulations, including but not limited to alignment between this rule and the HIPAA Privacy Rule, as discussed in IV.B.6 above. We also refer readers to the information blocking section at VIII in this preamble, as well.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested clarity on how ONC will monitor a developer's compliance with exporting in a timely manner and what penalties ONC will impose if there is a delay in regards to a Health IT Module user's request. Commenters requested ONC release sub-regulatory guidance that describes how users may file complaints and recommended ONC work with the HHS Office for Civil Rights (OCR) on patient education.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Any noncompliance by developers with the finalized “EHI export” certification criterion (§ 170.315(b)(10)) or the associated Conditions and Maintenance of Certification requirements (
                        <E T="03">e.g.,</E>
                         § 170.402(a)(4) and (b)(2)) would be subject to review, corrective action, and enforcement procedures under the Program. We refer readers to the enforcement (VII) and information blocking (VIII) sections of this preamble for further information. We do not believe there is a general need to work with OCR further on this particular issue or to issue further sub-regulatory guidance. The functionality of the “EHI export” criterion in § 170.315(b)(10) provides a user (
                        <E T="03">e.g.,</E>
                         a health care provider) with the ability to export a file for a single patient and multiple patients. If a user or other stakeholder has concerns about ongoing compliance of health IT certified to this criterion, with the required functionality of the criterion, or the associated Conditions and Maintenance of Certification requirements, they may file a complaint with the health IT developer, an ONC-ACB, or ONC.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters requested specific stakeholder exemptions from this requirement, such as health plans.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the recommendations. We note that the “EHI export” criterion is applicable only to health IT products presented by developers for certification under the Program that meet the criterion and “Assurances” Condition of Certification requirements in § 170.402. In addition, we note that the information subject to the export requirements is EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part.
                    </P>
                    <HD SOURCE="HD3">i. EHI Export for Patient-Initiated Requests</HD>
                    <P>In the Proposed Rule, we reiterated that the “user” of the single patient export functionality would typically be a provider or their office staff on behalf of the patient (80 FR 62611, 77 FR 54168). We also recognized that in service to innovative and patient-centric approaches, a health IT developer could develop a method that allows a patient to execute the request for data export without needing a provider to do so on their behalf. Under this scenario, we sought comments on whether the single patient export functionality should be made more prescriptive and require that the developers design the health IT to allow only the patient and their authorized representative to be the requestor of their EHI (84 FR 7447).</P>
                    <P>
                        <E T="03">Comments.</E>
                         In the scenario of patient-centric approaches created by developers, the majority of commenters were in favor of developers designing the export capability to make the patient and their authorized representative able to be the direct requestors of their EHI without needing a provider to execute this capability on their behalf. We also received recommended terms to further define “authorized representative” under this scenario. Several commenters advised against specifying or restricting the potential additional user roles able to initiate a single patient export. Some commenters recommended additional requirements for developers, including requiring developers to create this capability to enable the patient or their “proxy” to request their information through and receive information from the patient's health portal or an application. Commenters asked for the final rule to include clarification on what the patient and their authorized representative can access. We did receive some comments that requested clarification of this potential approach. 
                        <PRTPAGE P="25695"/>
                        We also received comments expressing confusion with the patient and authorized representative requests applying across the certification criterion, as opposed to the proposed and previously defined “users” of health IT that will typically perform the request on behalf of a patient.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input and requests for clarification. In response to the concerns and potential confusion, we clarify the following. This certification criterion does not require “direct-to-patient” functionality in order to demonstrate conformance. Providing such a capability and demonstrating conformance to this certification criterion with such a capability would be at the sole discretion of the health IT developer. In general, just like with the “data export” criterion in § 170.315(b)(6), the capability to execute this certification criterion can be health care provider/health care organization initiated (presumably upon that organization receiving a request by patient for their EHI). In instances where the functionality certified to this criterion is implemented in a “direct-to-patient” way such that the patient can request and accept EHI export without assistance from a user, we recognize that further configuration of the functionality or product in which it is implemented may be needed in order to account for applicable laws related to the patient's information access rights and other privacy and information blocking policies that apply to the configuration and use of the Health IT Module. While this specific capability within the certification criterion emphasizes health IT developer assistance must not be needed to operate the export, we recognize that user assistance (
                        <E T="03">e.g.,</E>
                         a provider) may be necessary to initiate such capability in the user's product.
                    </P>
                    <HD SOURCE="HD3">b. Patient Population EHI Export for Transitions Between Health IT Systems</HD>
                    <P>In addition to the single patient export functionality in § 170.315(b)(10)(i), we proposed in § 170.315(b)(10)(ii) that health IT certified to this criterion would also facilitate the migration of EHI to another health IT system. We proposed that a health IT developer or health IT certified to this criterion must, at a user's request, provide a complete export of all EHI that is produced or electronically managed (84 FR 7447 through 7448) by means of the developer's certified health IT.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments in support of the functionality under this criterion for transitions between health IT systems. Many commenters recommended format and content specifications, such as the use of bulk FHIR®-based APIs for export transmission. Some commenters stressed that ONC should determine and require standards, as well as clarify the scope of data export specific to this use case. Some commenters expressed concerns, including gathering patient consent and the developer burden that may exist with gathering data from disparate systems under the proposed scope terminology. One commenter was against the transitions between health IT systems capability, citing that data structured for one system will not necessarily work in another.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback specific to the functionality of transitions between health IT systems under this criterion. We finalized this export functionality with modifications. First, this functionality is now referred to as “patient population electronica health information export” in § 170.315(b)(10)(ii) to better reflect the policy intent of patient data transitions in instances of providers switching health IT systems, and to reflect the finalized scope of data that a product with a certified Health IT Module must be capable of exporting. Similar to the modifications in § 170.315(b)(10)(i), we finalized in § 170.315(b)(10)(ii)(A) that the export files must be electronic and in a computable format and we modified in § 170.315(b)(10)(ii)(B) that the publicly accessible hyperlink of the export's format must be included with the exported file(s). This modification clarifies that the user is able to access the format, and that the developer will keep their hyperlink up-to-date.
                    </P>
                    <P>In response to comments on defining a separate scope of data export specific to the patient population export functionality, it is our final policy for this certification criterion to align both the single patient and patient population export data to EHI, as defined in this rule, that can be stored at the time of certification by the product, of which the Health IT Module is a part. This narrower scope also addressed concerns received regarding development burden expressed regarding gathering data from disparate systems under the proposed scope terminology.</P>
                    <P>In regards to the comments on enforcing format and standards for data transmission, it is our intent under this certification criterion that health IT developers have flexibility regarding how the export outcome is achieved. We again encourage the industry to work together toward this common goal and to create an industry-wide approach. We do acknowledge the comments received that data structured for one system may not necessarily seamlessly align with another, and refer commenters to the export format requirements of this certification criterion. As finalized in § 170.315(b)(10)(ii)(A), the export created must be electronic and in a computable format. In contrast with the single patient EHI export capability, which must be available to a user without subsequent developer assistance to operate, the patient population EHI export capability of this criterion could require action or support on the part of the health IT developer. We acknowledged in the Proposed Rule (84 FR 7448) that because of anticipated large volume of electronic health information that could be exported under this specific proposed capability, developer action or support could be needed. Our thinking remains the same post-public comments even with the narrowed scope of data export. While exporting one patient's data on an as-needed basis is a capability that should be executable by a user on their own, orchestrating an entire export of EHI for migration to another health IT system is an entirely different task and dependent on a variety of factors such as the organization's overall infrastructure and deployment footprint. Additionally, developers of health IT certified to this criterion are required to provide the assurances in §  170.402, which include providing reasonable cooperation and assistance to other persons (including customers, users, and third-party developers) to enable the use of interoperable products and services. Thus, while developers have flexibility regarding how they implement the export functionality for transitions between systems, they are ultimately responsible for ensuring that the capability is deployed in a way that enables a customer and their third-party contractors to successfully migrate data. Such cooperation and assistance could include, for example, assisting a customer's third-party developer to automate the export of EHI to other systems. We refer readers to the export format section below for additional details.</P>
                    <P>
                        We note that the narrowed scope of data that certified Health IT Modules must be capable of exporting does not reduce contractual obligations of health IT developers to continue to support providers if they do want to change systems, and direct readers to the information blocking section (VIII) for additional information.
                        <PRTPAGE P="25696"/>
                    </P>
                    <HD SOURCE="HD3">c. Scope of Data Export</HD>
                    <P>We proposed in 84 FR 7448 and in § 170.315(b)(10) that for both use cases supported by this criterion, the scope of data that the certified health IT product must be capable of exporting would encompass all the EHI that the health IT system produces and electronically manages for a patient or group of patients. Our intention was that “produces and electronically manages” would include a health IT product's entire database. In the Proposed Rule, our use of the term EHI was deliberate. At the time of rulemaking, the proposed definition of the EHI term in §  171.102 was intended to support the consistency and breadth of the types of data envisioned by this proposed criterion. We requested comment on the terminology used (“produces and electronically manages”) or whether there were alternatives to the proposed language.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters were supportive of our proposed scope of data export requirements, while a few others offered alternative specific terminology options. Those commenters suggested terminology such as all EHI the health IT system “collects and retains,” or “produces or can electronically access, exchange, or use.” A majority of commenters, however, stated that the proposed terminology, including the proposed EHI definition, left broad interpretations of the scope of data a Health IT Module would have to be capable of exporting under this criterion. These commenters expressed concerns that the ambiguity and potentially vast amounts of data would create undue burden on health IT developers for development and upkeep of export capabilities, as well as compliance issues with other applicable laws. A majority of commenters requested and highlighted a need for further specificity regarding the terminology used to define data exported under this criterion. Some commenters expressed concerns that a developer presenting a Health IT Module for certification may not know all systems a user may later connect to the health IT capabilities. We also received many comments reflecting varied thoughts on what should or should not be included in the criterion's data export. Some commenters strongly opposed any data limits, citing existing regulations such as the HIPAA Privacy Rule right of access, while others proposed alternatives to constrain data export requirements, citing development infeasibility.
                    </P>
                    <P>Recommendations to constrain the proposed criterion's scope included alignment with other regulations and data standards, such as the USCDI. We also received a recommended requirement for health IT developers to provide a plain language definition of the EHI typically included in their Health IT Module's export. Some commenters expressed confusion on how the criterion's proposed scope of data export may apply to EHI “produced or electronically managed” by both the product's certified and “non-certified” capabilities as well as data from third parties.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for feedback on our proposed terms and for specific recommendations. The finalized criterion draws the upper bound of its data scope from the focused definition of EHI as finalized. The criterion export includes the EHI, as defined, that can be stored at the time of certification by the product, of which the Health IT Module is a part. As defined in this rule, EHI means electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501 (other than psychotherapy notes as defined in 45 CFR 164.501 or information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding), regardless of whether the actor is a covered entity as defined in 45 CFR 160.103. In response to comments received, this revised scope of data for export provides a more manageable and less administratively burdensome certification criterion for health IT developers for several reasons.
                    </P>
                    <P>We agree with commenters that our proposed terms of all EHI a health IT system “produces and electronically manages” (84 FR 7448) raised the potential for broad variance in interpretations and concerns about the breadth of data intended for export under this criterion and potential development burden. We also considered the comments noting that a developer presenting a Health IT Module for certification may not, at the time of certification, know all systems a user will later connect to the health IT capabilities. Ultimately, we considered several approaches to better reflect the policy intent and to alleviate confusion related to the proposed criterion. In consideration of the public comments and the policy outcome we sought to address, we revised the final criterion`s phrasing to describe what information health IT products with Health IT Module(s) certified to the criterion must be capable of exporting. The revised scope of data export applies to both the single patient and patient population export functionalities as well as the Conditions and Maintenance of Certification requirements tied to this criterion.</P>
                    <P>First, we agree with comments received and acknowledge that a health IT developer is best positioned to know (and would be solely responsible for only) the EHI that can be stored by the health IT product at the time the Health IT Module is presented for certification. In response to comments regarding the applicability of the scope of export to the product's certified and “non-certified” capabilities, as well as data from third parties, we clarify and reiterate the following from our prior responses. We emphasize that such “stored” data applies to all EHI and is agnostic as to whether the EHI is stored in or by the certified Health IT Module or in or by any of the other “non-certified” capabilities of the health IT product of which the certified Health IT Module is a part. To be clear, conformance “at the time of certification” means the combined data that can be stored by the product, of which the Health IT Module is a part, at the time the Health IT Module is presented for certification. As such, for the purposes of this certification criterion, the EHI that must be exported does not include any data generated from unique post-certification in response to a particular customer (though such data could meet the definition of EHI for the purposes of information blocking). Such modifications could include custom interfaces and other data storage systems that may be subsequently and uniquely connected to a certified Health IT Module post-certification. Additionally, to remain consistent with “at the time of certification,” we clarify that any new EHI stored by the product due to ongoing enhancements would need to be included within the scope of certification only when a new version of the product with those new EHI storage capabilities is presented for certification and listing on the CHPL. In consideration of comments, we believe that this approach to define storage at the time the product is presented for certification of a Health IT Module will make the certification requirements more clear for health IT developers and more efficient to administer from a Program oversight perspective.</P>
                    <P>
                        In addition, the use of “can be stored by” refers to the EHI types stored in and by the health IT product, of which the Health IT Module is a part. This is meant to be interpreted as the combination of EHI a heath IT product stores itself and in other data storage locations. Thus, the cumulative data 
                        <PRTPAGE P="25697"/>
                        covered by these storage techniques would be in the scope of data export.
                    </P>
                    <P>Per our policy intent, by focusing the definition of EHI and defining the data for export under this criterion, users of certified Health IT, such as health care providers, will have the ability to create “readily producible” exports of the information of a single patient upon request by the user, which increases patient access as reflected in the Cures Act. Lastly, in support of the second functionality we finalized for patient population export, the EHI exported (within the Health IT product's scope of data export) would likely be of significant importance to health care providers for the purposes of transitioning health IT systems and maintaining continuity of care for patients, and also helps remove potential barriers to users switching systems to meet their needs or their patient's needs.</P>
                    <P>In finalizing this policy, we emphasize that health IT developers may provide the export of data beyond the scope of EHI and for functionalities beyond those discussed under this criterion. In such cases, for additional export purposes, it is advised that health IT developers and users discuss and agree to appropriate requirements and functionalities. We again emphasize that health IT product users must ensure that any disclosures of data conform to all applicable laws, including the HIPAA Rules and 42 CFR part 2. Stakeholders should review applicable laws and regulations, including those regarding patients' right of access to their data, in order to determine the appropriate means of disclosing patient data. We also refer readers to the information blocking section at VIII.</P>
                    <HD SOURCE="HD3">i. Image, Imaging Information, and Image Element Export</HD>
                    <P>In the Proposed Rule, we noted at 84 FR 7448 that clinical data would encompass imaging information, both images and narrative text about the image. However, we addressed that EHRs may not be the standard storage location for images. We solicited additional feedback and comments on the feasibility, practicality, and necessity of exporting images and/or imaging information. We requested comment on what image elements, at a minimum, should be shared such as image quality, type, and narrative text. We did not make any proposals in 84 FR 7448.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters were supportive of sharing images and/or related data elements, expressing that interoperability should include electronic ordering of imaging studies, which they asserted would assist health care providers in delivering care. Other commenters expressed burden concerns with data image export, particularly challenges around the movement and storage of large amounts of data and accumulating data from disparate health IT systems. A few commenters requested specific exclusion of images or videos created as a byproduct of procedures. As for minimum image data elements to share, recommendations varied and included Digital Imaging and Communications in Medicine (DICOM
                        <E T="51">TM</E>
                        ) data elements or file type recommendations. Comments included additional policy recommendations, such as making Picture Archiving and Communication Systems (PACS) developers subject to certification rules and requiring EHI export data to include links for remote authorized access to externally hosted images.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their shared insight and recommendations regarding the export of images, imaging information, and image elements. Health IT Modules certified to the finalized criterion must electronically export all of the EHI, as defined, that can be stored at the time of certification by the product, of which the Health IT Module is a part. Thus, any images, imaging information, and image elements that fall within this finalized scope of EHI that can be stored at the time of certification in or by the product, of which the Health IT Module is a part will need to be exported under this certification criterion. We appreciate the recommendations received for image transfer methods and encourage the stakeholder community to continue exploring innovative image transfer methods, including for image transfer that would fall outside of this certification criterion. We appreciate the policy recommendations, such as including PACS developers. The “EHI export” certification criterion only applies to developers of health IT seeking or maintaining certification under the Program. To the extent such providers are developers of health IT under the Program they would be included. If they are not developers under the Program, they would not be included.
                    </P>
                    <P>We also thank commenters for their suggestions to require data export to include links for remote authorized access to externally hosted images. We note that the export requirements of this certification criterion refers to the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. In the context of imaging, if the only EHI stored in or by the product to which this certification criterion applies are links to images/imaging data (and not the images themselves, which may remain in a PACS) then only such links must be part of what is exported. We encourage developers to work with their customers to achieve innovative ways to share all relevant data, including situations outside of the scope of data export under this criterion where images could be made more accessible.</P>
                    <HD SOURCE="HD3">ii. Attestation of Information a Health IT Developer Cannot Support for Export</HD>
                    <P>In the Proposed Rule (84 FR 7448), we also solicited comment on whether we should require, to support transparency, health IT developers to attest or publish as part of the export format documentation the types of EHI they cannot support for export. We did not have any specific proposals.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported public attestation regarding the information a Health IT Module is unable to export. Some commenters requested that we add to the regulatory text to state that developers attest to information they cannot support for export “and/or ingestion.” Some commenters questioned if it is fair for EHI developers to delineate what is in their Health IT Module's scope of data for export under this criterion. Another felt that this requirement should be extended to health care delivery organizations and that the attestation should be included within patient portals or other communications.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We again note the revised scope of data export under this finalized criterion. Under the finalized approach, which focuses on the export of the EHI that can be stored at the time of certification by the product, we have determined that our final requirements provide sufficient clarity and have not included any additional requirements such as those on which we sought comment. Additionally, we believe the recommendation for ingestion would be impracticable as part of this certification criterion due to the flexibility we permit for the output format(s). It would not be possible from a regulatory enforcement perspective to administer a certification criterion that included within its scope a conformance requirement for a Health IT Module's capability to import any proprietary format that may exist without prior knowledge of such formats.
                    </P>
                    <HD SOURCE="HD3">iii. Export Exclusion Request for Comments</HD>
                    <P>
                        In the Proposed Rule, we proposed metadata categories at 84 FR 7448 for 
                        <PRTPAGE P="25698"/>
                        exclusion from this criterion. We also requested feedback on what metadata elements should remain included for export or added to the list of excluded data. Metadata proposed for exclusion from the criterion included metadata present in internal databases used for physically storing the data, metadata that may not be necessary to interpret the EHI export, and metadata that refers to data that is not present in the EHI export. Examples of these proposed exclusions are provided at 84 FR 7448.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters offered varied recommendations for metadata elements to remain excluded, or to be included under the scope of data export for this criterion. We received several comments strongly supporting the inclusion of audit log metadata. Commenters noted that the inclusion of audit log metadata had potential legal utility and could aid in the patient's ability to have all of their data and knowing who has accessed their data. Commenters also requested increased clarity on the definition of metadata, audit log, and access log in regards to this rulemaking, and requested the use of standards to further clarify policy intentions. We note, however, that other commenters were against the inclusion of audit log data as part of the EHI export. Those against inclusion stated that this information was not necessary to interpret the EHI export, could be burdensome for development of export capabilities, and potentially contain personally identifiable information of the health care staff.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input on potential metadata exclusions. As noted above, we have finalized that EHI that can be stored at the time of certification by the product is the scope of data that must be included in exports pursuant to § 170.315(b)(10). Under this revised and specified scope of data export, it is no longer necessary to list specific metadata exclusions or inclusions. We direct readers to the discussion of scope of data export (IV.B.6.c) under this criterion for further details.
                    </P>
                    <HD SOURCE="HD3">d. Export Format</HD>
                    <P>We did not propose a content standard for the export. However, we did propose to require documentation in § 170.315(b)(10)(iii) that health IT developers include the export file(s) format, including its structure and syntax, such as a data dictionary or export support file, for the exported information to assist the user requesting the information in processing the EHI (84 FR 7448). This was to prevent loss of information or its meaning to the extent reasonably practicable when using the developer's certified Health IT Module(s). We also proposed in § 170.315(b)(10)(iii) that the developer's export format must be made available via a publicly accessible hyperlink and kept up-to date.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments received were in favor of this proposal in § 170.315(b)(10)(iii). Several commenters were supportive of the flexibility of export format for developers, as long as export documentation is provided as specified in the Proposed Rule, citing specifically how this would support the export capability in § 170.315(b)(10)(ii). Some commenters recommended additional clarification for the publicly accessible hyperlink, specifically to ensure that information is available without login or other associated requirements. Commenters also provided export format suggestions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback regarding developers' export format. We have finalized § 170.315(b)(10)(iii) with modifications to clarify the regulatory text. We finalized that the export format(s) used to support § 170.315(b)(10)(i) and § 170.315(b)(10)(ii) of this section must be kept up-to-date.
                    </P>
                    <P>
                        We clarify that the documentation for the export format(s) in § 170.315(b)(10)(iii) consists of information on the structure and syntax for how the EHI will be exported by the product such as, for example, C-CDA document(s) or data dictionary for comma separated values (csv) file(s), and not the actual EHI. The user will use the export format documentation to process the EHI after it is exported by the product. We also require that health IT developers keep the export format(s) used to support § 170.315(b)(10)(i) and § 170.315(b)(10)(ii) must be “up-to-date.” For example, if the health IT developer had previously specified the C-CDA standard as the export format for meeting the criterion, but subsequently updated their product to use the FHIR standard and stopped supporting C-CDA export format then the documentation for export format would need to be updated so that users are able to continue to accurately process the EHI exported by the product. We appreciate suggestions received regarding ensuring that such information is available without login or other associated requirements. In response to these comments, our policy intent to foster transparency, and in alignment with other certification criterion requirements set forth in this rule, we note our modifications in § 170.315(b)(10)(i)(E) and § 170.315(b)(10)(ii)(B) that the publicly accessible hyperlink of the export's format must be included with the exported file(s). We clarify that the hyperlink must allow any person to directly access the information without any preconditions or additional steps. We note that the export format need not be the same format used internally by the certified health IT and the health IT developer does not need to make public their proprietary data model. This certification criterion also does not prescribe how (
                        <E T="03">i.e.,</E>
                         media/medium) the exported information is to be made available to the user, as this may depend on the size and type of information to be exported. While file formats and related definitions are not finalized as specific certification requirements, we encourage developers to continue to foster transparency and best practices for data sharing, such as machine-readable format, when they create and update their export format information.
                    </P>
                    <HD SOURCE="HD3">e. Initial Step Towards Real-Time Access</HD>
                    <P>In the Proposed Rule at 84 FR 7449, we offered a clarifying paragraph to highlight that the criterion in § 170.315(b)(10) was intended to provide a step in the direction of real-time access goals, as well as a means to, within the confines of other applicable laws, encourage mobility of electronic health data while other data transfer methods were maturing. In that section, we clarified that “persistent” or “continuous” access to data is not required to satisfy the proposed “EHI export” criterion's requirements, and that the minimum requirement of developers presenting Health IT Module(s) for certification to this criterion is for a discrete data export capability. In this clarification section, we did not have specific proposals or requests for comments.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received recommendations to further specify the use of “persistent” and “continuous” in context of access to EHI. Additional commenters recommended specifying Representational state transfer (REST) or “RESTful” transfer, or specifying data transport methods.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We first clarify that this section was added to the Proposed Rule for additional clarification and to provide prospective context on the proposed certification criterion. However, we recognize from the comments received that our reference to “persistent” or “continuous” access in the Proposed Rule may have created confusion. We again note that “persistent” or “continuous” access is not required by health IT developers 
                        <PRTPAGE P="25699"/>
                        presenting Health IT Module(s) to satisfy the requirements of this certification criterion. We have finalized the “EHI export” criterion as described above in response to comments received on proposals we have made. We appreciate the responses to our future looking points in the Proposed Rule but have not made further revisions to the final certification criterion in response.
                    </P>
                    <HD SOURCE="HD3">f. Timeframes</HD>
                    <P>We requested input and comments on the criterion and timeframes at 84 FR 7449. In particular, beyond the proposal to export all the EHI the health IT system produces and electronically manages, we sought comment on whether this criterion should include capabilities to permit health care providers to set timeframes for the EHI export, such as only the “past two years” or “past month” of EHI (84 FR 7449).</P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of commenters were against the concept of allowing providers to set timeframes for the export functionality. Commenters were concerned that creating the capability to limit timeframes would involve significant technical complexity for health IT developers. Commenters also expressed concern that allowing providers the capability to limit timeframes would not align with the HIPAA Privacy Rule right of access at 45 CFR 164.524 and could potentially implicate information blocking. Commenters provided alternative approaches and concepts to implement timeframe capabilities for this criterion, including use of APIs, granting flexibility to developers, allowing intervals or dynamic timeframe requirements, and considering permitted fees. Commenters asked for clarification on how far back the data request capabilities could go and requested clarification regarding how this criterion aligns with other API-related criteria within this rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We will not require the Health IT Module support a specific or user-defined timeframe range or time limit capability for the purposes of demonstrating conformance to this certification criterion. We agree with commenters concerns regarding potential development complexity for health IT developers if we included such a requirement upfront. What this means, however, is that for the purposes of testing and certification, a health IT developer will need to prove that the product, of which a Health IT Module is part, can perform the capabilities required by the certification criterion, inclusive of all EHI that could be exported. In turn, when these capabilities are deployed in production they will need to be capable of exporting all of the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. We also agree with the points received regarding the HIPAA Privacy Rule right of access at 45 CFR 164.524 and emphasize the importance of HIPAA covered entities aligning with applicable law regarding patient access to health information.
                    </P>
                    <HD SOURCE="HD3">g. 2015 Edition “Data Export” Criterion in § 170.315(b)(6)</HD>
                    <P>We proposed to remove the “data export” criterion (defined in § 170.315(b)(6)) from the 2015 Edition Base EHR definition in § 170.102 and to replace “data export” with the proposed “EHI export” criterion (defined in § 170.315(b)(10)) by amending the third paragraph of the 2015 Edition Base EHR definition in § 170.102. We did not propose a transition period for the “data export” criterion. Rather, we proposed to remove the criterion from the 2015 Edition Base EHR definition upon the effective date of a final rule. We also proposed to modify the 2015 Edition Base EHR definition to include the new proposed export criterion (defined in § 170.315(b)(10)), with an implementation date 24 months from the effective date of the final rule. We welcomed comments on this approach.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters were in favor of immediate removal of this criterion (§ 170.315(b)(6)) from the 2015 Edition Base EHR definition, stating it would reduce burden. However, the majority of commenters were against a potential gap in functionality due to the compliance timeline for the new export criterion (§ 170.315(b)(10)) and requested that we keep the “data export” criterion until the new criterion in § 170.315(b)(10) and other standardized data transmission methods were fully implemented. Some commenters supported an indefinite retention of the “data export” criterion, regardless of the proposed addition of § 170.315(b)(10). Several commenters also recommended to expand the current § 170.315(b)(6) criterion through USCDI as an alternative approach to the proposed “EHI export” criterion in § 170.315(b)(10). In addition, some commenters expressed concern that that the “data export” criterion is inconsistent with CMS Quality Payment Program (QPP) requirements such as View, Download, and Transmit (VDT) at 83 FR 59814 of the CY 2019 Physician Fee Schedule final rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In consideration of public comments in support of the retention of the “data export” certification criterion, we have maintained the “data export” certification criterion in § 170.315(b)(6) as available for certification until 36 months after this final rule's publication date. To implement this decision, we have finalized in § 170.550(m) that ONC-ACBs are permitted to issue certificates to “data export” in § 170.315(b)(6) until, but not after, 36 months after the publication date of this final rule. However, we note the “data export” certification criterion has been removed from the 2015 Edition Base EHR definition (in § 170.102) as of the general effective date of this final rule (60 days after its publication in the 
                        <E T="04">Federal Register</E>
                        ). During the 36 months immediately following publication of this final rule, developers will be able to maintain the certification to § 170.315(b)(6) as a standardized means of exporting the discrete data specified in the CCDS, but the criterion will not be updated to the USCDI. Given that certification to the § 170.315(b)(6) criterion will no longer be available after 36 months, we do not believe an update to the USCDI is the best path. Rather, § 170.315(b)(6) will remain an unchanged criterion in the Program for the 36 months immediately following publication of this final rule in the 
                        <E T="04">Federal Register</E>
                        . After that timeframe, the EHI export criterion in § 170.315(b)(10), including that certification criterion's scope of data export, will remain an available data export certification criterion for health IT developers that present for certification a Health IT Module that is part of a heath IT product which electronically stores EHI. This approach will support prior investments in § 170.315(b)(6) by developers and their customers, and also encourage movement toward the interoperability opportunities afforded by new criteria.
                    </P>
                    <P>
                        Regarding commenter concerns that the “data export” criterion is inconsistent with CMS QPP requirements, such as View, Download and Transmit (VDT), we do not believe that this criterion would be inconsistent with QPP program requirements. In the CY 2019 Physician Fee Schedule final rule, CMS removed the VDT measure in § 170.315(e)(1) (83 FR 59814). However, the Promoting Interoperability performance category of QPP currently includes the measure entitled Provide Patients Electronic Access to their Health Information (83 FR 59812 through 59813), and CMS has identified technology certified to the “View, Download and Transmit to 3rd party” criterion at 45 CFR 170.315(e)(1) as required to meet this measure (83 FR 
                        <PRTPAGE P="25700"/>
                        59817). The Data Export criterion in § 170.315(b)(6) is not required for the Provide Patients Electronic Access to their Health Information measure included in the Promoting Interoperability performance category, nor have we proposed to change the “View, Download and Transmit to 3rd party” criterion in § 170.315(e)(1) required for this measure, thus we do not believe this final policy will conflict with CMS requirements for QPP.
                    </P>
                    <HD SOURCE="HD3">7. Standardized API for Patient and Population Services Criterion</HD>
                    <P>We proposed to adopt a new API criterion in § 170.315(g)(10) at 84 FR 7449. In response to comments, we are adopting a Standardized API for Patient and Population Services criterion for Certification in §  170.315(g)(10) with modifications. The new criterion, will replace the old “application access—data category request” certification criterion (§  170.315(g)(8)). In doing so, we are also adding the Standardized API for Patient and Population Services criterion to the updated 2015 Edition Base EHR definition and removing the application access—data category request criterion (§  170.315(g)(8)). This finalized Standardized API for patient and population services certification criterion requires the use of the FHIR Release 4 and several implementation specifications. The new criterion focuses on supporting two types of API-enabled services: (1) Services for which a single patient's data is the focus and (2) services for which multiple patients' data are the focus. Please refer to the “Application Programming Interfaces” section (VII.B.4) in this preamble for a more detailed discussion of the “API” certification criterion and related Conditions and Maintenance of Certification requirements.</P>
                    <HD SOURCE="HD3">8. Privacy and Security Transparency Attestations Criteria</HD>
                    <P>
                        In 2015, the HIT Standards Committee (HITSC) recommended the adoption of two new “authentication” certification criteria for the Program (81 FR 10635). The National Coordinator endorsed the HITSC recommendations for consideration by the Secretary, and the Secretary determined that it was appropriate to propose adoption of the two new certification criteria through rulemaking. To implement the Secretary's determination, we proposed two new criteria to which health IT would need to be certified (84 FR 7450). These would require the developer to attest to whether the Health IT Module for which they are seeking certification to the criteria encrypts authentication credentials (§ 170.315(d)(12)) and/or supports multi-factor authentication (§ 170.315(d)(13)). We did not propose to 
                        <E T="03">require</E>
                         that health IT have these authentication and encryption-related functions, but instead proposed that a health IT developer must indicate whether or not their certified health IT has those capabilities by attesting “yes” or “no.” We did, however, propose to include the two criteria in the 2015 Edition privacy and security certification framework (§ 170.550(h)). For clarity, attesting “yes” to either of these criteria indicates that the Health IT Module can support either Approach 1 or Approach 2 of the 2015 Edition privacy and security certification framework for these criteria.
                    </P>
                    <P>We note that we received many comments on the proposed “encrypt authentication credentials” and “multi-factor authentication” criteria, but the majority of comments conflated the two proposals and provided collective responses. Therefore, we have responded to them in kind to preserve the integrity of the comments.</P>
                    <HD SOURCE="HD3">a. Encrypt Authentication Credentials</HD>
                    <P>We proposed in 84 FR 7450 to adopt an “encrypt authentication credentials” certification criterion in § 170.315(d)(12) and include it in the P&amp;S certification framework (§ 170.550(h)). We proposed to make the “encrypt authentication credentials” certification criterion applicable to any Health IT Module currently certified to the 2015 Edition and any Health IT Module presented for certification that is required to meet the “authentication, access control, and authorization” certification criterion adopted in § 170.315(d)(1) as part of Program requirements.</P>
                    <P>Encrypting authentication credentials could include password encryption or cryptographic hashing, which is storing encrypted or cryptographically hashed passwords, respectively. If a developer attests that its Health IT Module encrypts authentication credentials, we proposed in 84 FR 7450 that the attestation would mean that the Health IT Module is capable of protecting stored authentication credentials in accordance with standards adopted in § 170.210(a)(2), Annex A: Federal Information Processing Standards (FIPS) Publication 140-2, “Approved Security Functions for FIPS PUB 140-2, Security Requirements for Cryptographic Modules.” We posited that FIPS Publication 140-2 is the seminal, comprehensive, and most appropriate standard. Moreover, in the specified FIPS 140-2 standard, there is an allowance for various approved encryption methods, and health IT developers would have the flexibility to implement any of the approved encryption methods in order to attest “yes” to this criterion. We noted that health IT developers should keep apprised of these standards as they evolve and are updated to address vulnerabilities identified in the current standard.</P>
                    <P>We did not propose that a Health IT Module would be required to be tested to the “encrypt authentication credentials” certification criterion. Rather, by attesting “yes,” the health IT developer is attesting that if authentication credentials are stored, then the authentication credentials are protected consistent with the encryption requirements above. We proposed in 84 FR 7450 that the attestations “yes” or “no” would be made publicly available on the Certified Health IT Product List (CHPL). We proposed in 84 FR 7450 that, for health IT certified prior to the final rule's effective date, the health IT would need to be certified to the “encrypt authentication credentials” certification criterion within six months after the final rule's effective date. For health IT certified for the first time after the final rule's effective date, we proposed that the health IT must meet the proposed criterion at the time of certification.</P>
                    <P>We also noted that some Health IT Modules presented for certification are not designed to store authentication credentials. Therefore, we specifically requested comment on whether we should include an explicit provision in this criterion to accommodate such health IT. We stated that this could be similar to the approach we utilized for the 2015 Edition “end-user device encryption” criterion (§ 170.315(d)(7)(ii)), where we permit the criterion to be met if the health IT developer indicates that their health IT is designed to prevent electronic health information from being locally stored on end-user devices.</P>
                    <HD SOURCE="HD3">b. Multi-Factor Authentication</HD>
                    <P>
                        We proposed in 84 FR 7450 to adopt a “multi-factor authentication” (MFA) criterion in § 170.315(d)(13) and include it in the P&amp;S certification framework (§ 170.550(h)). We proposed to make the “multi-factor authentication” certification criterion applicable to any Health IT Module currently certified to the 2015 Edition and any Health IT Module presented for certification that is required to meet the “authentication, access control, and authorization” certification criterion adopted in § 170.315(d)(1) as part of Program requirements. To provide clarity as to what a “yes” attestation for “multi-factor authentication” attestation would 
                        <PRTPAGE P="25701"/>
                        mean, we provided the following explanation. MFA requires users to authenticate using multiple means to confirm they are who they claim to be in order to prove one's identity, under the assumption that it is unlikely that an unauthorized individual or entity will be able to succeed when more than one token is required. MFA 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. Thus, we proposed in 84 FR 7451 that in order to be issued a certification, a health IT developer must attest to whether or not its Health IT Module presented for certification supports MFA consistent with industry-recognized standards (
                        <E T="03">e.g.,</E>
                         NIST Special Publication 800-63B Digital Authentication Guidelines, ISO 27001).
                        <SU>52</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>52</SU>
                             NIST Special Publication 800-63B: 
                            <E T="03">https://pages.nist.gov/800-63-3/sp800-63b/cover.html</E>
                        </P>
                    </FTNT>
                    <P>We proposed in 84 FR 7451 that, for health IT certified prior to the final rule's effective date, the health IT would need to be certified to the “multi-factor authentication” certification criterion within six months after the final rule's effective date. For health IT certified for the first time after the final rule's effective date, we proposed that the health IT must meet this criterion at the time of certification. We solicited comment on the method of attestation and, if the health IT developer does attest to supporting MFA, whether we should require the health IT developer to explain how they support MFA. In particular, we asked whether a health IT developer should be required to identify the MFA technique(s) used/supported by submitting specific information on how it is implemented, including identifying the purpose(s)/use(s) to which MFA is applied within their Health IT Module, and, as applicable, whether the MFA solution complies with industry standards.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The vast majority of commenters supported the adoption of the two proposed privacy and security transparency attestation certification criteria. A few commenters were opposed to the new criteria. Several supporters of the proposed criteria recommended that we make the criteria operative functional requirements (including testing), rather than yes/no attestations. Some of these commenters reasoned that MFA should be a requirement for all certified health IT, given the risks involved with single-factor authentication and how easy it is today to implement MFA. We also received a number of comments requesting that we clarify that the MFA proposal does not create a requirement for health care providers to implement MFA or encryption of authentication credentials. Similarly, we received several comments seeking clarification that a “yes” attestation would only require support of MFA, not that MFA would have to be implemented. Along these same lines, several commenters expressed concerns that the requirements could interfere with clinical care and urged that the requirements not contribute to provider burden.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have adopted both proposed privacy and security transparency attestation criteria and included both criteria (§ 170.315(d)(12) and § 170.315(d)(13)) in the P&amp;S certification framework (§ 170.550(h)), with minor modifications. While some commenters recommended that MFA should be a requirement for all certified health IT, we did not propose such a requirement nor could health IT developers have foreseen such an outcome in this final rule based on our proposals, particularly considering the clarity provided with our proposals (84 FR 7450) and the complexities of such a requirement. For example, as noted by commenters below, MFA may not be appropriate or applicable in all situations and there is wide variation in authentication needs and approaches throughout the industry. These criteria will, however, still provide increased transparency, and if a developer attests “yes” to these criteria regarding a certified Health IT Module, that Health IT Module will then be subject to ONC-ACB surveillance for any potential non-conformity with the requirements of these criteria. Given the strong support expressed in public comments for these criteria as proposed, we believe this is the appropriate approach at this time.
                    </P>
                    <P>
                        While we believe that encrypting authentication credentials and MFA represent best practices for privacy and security in health care settings, we emphasize again that these criteria do not require certified health IT to have these capabilities or for health IT developers to implement these capabilities for a specific use case or any use case. Equally important, the criteria place no requirements on health IT users, such as health care providers, to implement these capabilities (if present in their Health IT Modules) in their health care settings. However, we note that information regarding the security capabilities of certified health IT provided by such transparency can aid 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).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters who supported the proposed criteria requested clarification on the scope and intent of the criteria, including what level of authentication and which types of users and user roles the criteria apply to, as well as on how to attest for multiple sign-on paths. A number of commenters noted the wide variation in authentication needs and approaches throughout the industry, and they recommended that we permit health IT developers to describe how they support authentication, rather than simply attest “yes” or “no.” The commenters stated that such information would provide helpful clarity regarding what the certified health IT supports. Additionally, several commenters stated that we should require that health IT developers explain how they support MFA. A number of commenters stressed that MFA may not be appropriate or applicable in all situations, and in particular, several commenters noted that automated transactions, including some that may occur in the public health reporting context, cannot support MFA.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In response to requests for modifications and clarifications, we have modified the “encrypt authentication credentials” criterion to permit a health IT developer that attests “no” for its Health IT Module(s) to indicate why the Health IT Module(s) does not support encrypting stored authentication credentials. A health IT developer that attests “no” to the “encrypt authentication credentials” criterion may explain, for example, that its Health IT Module is not designed to store authentication credentials, therefore there is no need for the Health IT Module to encrypt authentication credentials because it does not store, or have the capability to store, authentication credentials.
                    </P>
                    <P>
                        For the “MFA” criterion, consistent with our solicitation of comments and the comments received recommending that health IT developers explain how they support MFA, we have modified the criterion to require health IT developers that attest “yes” to describe the use cases supported. For example, a health IT developer could attest “yes” to supporting MFA and state that the Health IT Module supports MFA for remote access by clinical users, thus providing clarity on the user roles to which MFA applies for that particular Health IT Module. To be clear, health IT 
                        <PRTPAGE P="25702"/>
                        developers are not expected to provide specific technical details about how they support MFA that could pose security risks. Again, the purpose is to enable health IT developers to give an indication of the types of uses for which their Health IT Module(s) support MFA. We note that health IT developers may wish to add new MFA use cases for their certified health IT over a period of time. In such instances, to provide the clarity sought in the Proposed Rule as to the MFA technique(s) used/supported and how MFA is implemented, including identifying the purpose(s)/use(s) to which MFA is applied within their Health IT Modules, any new MFA use cases are required to comply with this criterion's “yes” attestation provisions and be part of the quarterly CHPL reporting by health IT developers and ONC-ACBs under § 170.523(m).
                    </P>
                    <P>If a health IT developer attests “no,” then it would not be required to explain why its Health IT Module does not support authentication, through multiple elements, of the user's identity with the use of industry-recognized standards. We did not propose to require an explanation for “no” attestation nor did we request comment on allowing health IT developers to provide an explanation for a “no” attestation like we did for “yes” attestations (84 FR 7450-7451). However, in an effort to provide transparency and consistency for these privacy and security attestation criteria, we will also permit developers to provide a reason for attesting “no” in order to provide more context. Such a reason may be due to MFA being inapplicable or inappropriate. In those cases, a developer could state, for example, that the Health IT Module does not support MFA because it is engaged in system-to-system public health reporting and MFA is not applicable.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments requesting adjustment to the deadline for compliance to meet these criteria. We also received a number of comments recommending that we only apply both of the proposed criteria to new certifications and new Health IT Modules, and not to Health IT Modules already in widespread use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Regarding the timeframe for compliance, and in response to comments recommending that we only apply the criteria to “new certifications,” we have determined that certification to these criteria as part of the updated 2015 Edition privacy and security certification framework (§ 170.550(h)) will only be necessary for Health IT Modules that are presented for certification. Thus, a new Health IT Module seeking certification for the first time to the criteria specified in the 2015 Edition privacy and security certification framework (§ 170.550(h)), after the effective date of this final rule, will need to meet these privacy and security transparency attestation criteria at the time of certification. Similarly, a previously certified Health IT Module that has undergone revision, such as removal of certain capabilities, and is presenting for revised certification to the criteria specified in the 2015 Edition privacy and security certification framework (§ 170.550(h)) after the effective date of this final rule, will need to meet these privacy and security transparency attestation criteria at the time of certification. We believe that this approach will still provide the intended transparency as health IT will need to be issued new certifications as Health IT Modules are updated or certified to other new or revised criteria adopted in this final rule. At the same time, this approach should reduce burden for health IT developers and allow them more time to plan and prepare to meet these new transparency requirements.
                    </P>
                    <HD SOURCE="HD3">9. Security Tags and Consent Management Criteria</HD>
                    <P>In the 2015 Edition final rule, we adopted two “data segmentation for privacy” (DS4P) certification criteria. One criterion, “DS4P-send” (§ 170.315(b)(7)), includes capabilities for applying security tags according to the DS4P standard in § 170.205(o) at the document-level of a summary care record formatted to the C-CDA 2.1 standard in § 170.205(a)(4). The other criterion, “DS4P-receive” (§ 170.315(b)(8)), includes capabilities for receiving a summary care record formatted to the C-CDA 2.1 standard in § 170.205(a)(4) with document-level security tags according to the DS4P standard in § 170.205(o). As noted in the 2015 Edition final rule (80 FR 62646), certification to these criteria is not required to meet the CEHRT definition for PI Programs.</P>
                    <P>Security tagging enables computer systems to recognize the existence of sensitive elements in data and properly protect the privacy and security of the data by ensuring that only the appropriate individuals and entities can access it. Security tagging capabilities do not compromise the availability or comprehensiveness of health information available for treatment or research purposes; rather, they enable appropriate access controls in accordance with existing policies, governance, and applicable laws. The DS4P standard describes a method for applying security tags to HL7 CDA documents to ensure that privacy policies established at a record's source can be understood and enforced by the recipient of the record.</P>
                    <P>The utility of the DS4P standard is not limited to data subject to the Federal regulations governing the Confidentiality of Substance Use Disorder Patient Records, 42 CFR part 2 (80 FR 62647). DS4P may be implemented to support other data exchange use cases in which compliance with State or Federal legal frameworks require special protections for sensitive health information. Security tagging capabilities are an initial step towards enabling an interoperable health care system to use technical standards to permit appropriate access, use, or disclosure of sensitive health information in accordance with applicable policies and patient preferences. We understand and acknowledge additional challenges related the prevalence of unstructured data, sensitive images, and potential issues around use of sensitive health information by clinical decision support systems. The adoption of document level data tagging for structured documents would not solve these issues, but could help move technology in the direction where these issues could be addressed (80 FR 16841).</P>
                    <P>
                        Adoption of the 2015 Edition final rule DS4P criteria was consistent with earlier HIT Policy Committee (HITPC) recommendations for the use of security tagging to enable the electronic implementation and management of disclosure policies that originate from the patient, the law, or an organization, in an interoperable manner, so that electronic sensitive health information may be appropriately shared.
                        <SU>53</SU>
                        <FTREF/>
                         The HITPC recommendations consisted of a glide path for the exchange of 42 CFR part 2-protected data starting with the inclusion of Level 1 (document level tagging) send and receive functionality. The HITPC also recommended advancing the exchange of 42 CFR part 2-protected data, by outlining additional capabilities in sharing, viewing and incorporating privacy restricted data at a more granular level, as well as 
                        <PRTPAGE P="25703"/>
                        managing computable patient consent for the use of restricted data.
                        <SU>54</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>53</SU>
                             See HIT Policy Committee (HITPC) Recommendation Letter to ONC, July 2 014, 
                            <E T="03">http://www.healthit.gov/facas/sites/faca/files/PSTT_DS4P_Transmittal%20Letter_2014-07-03.pdf</E>
                            ; see also HITPC's Privacy and Security Tiger Team Public Meeting, Transcript, May 12, 2014, 
                            <E T="03">http://www.healthit.gov/facas/sites/faca/files/PSTT_Transcript_Final_2014-05-12.pdf.</E>
                            ; Public Meeting, Transcript, May 27, 2014, 
                            <E T="03">http://www.healthit.gov/facas/sites/faca/files/PSTT_Transcript_Final_2014-05-27.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>54</SU>
                             For more details on the two glide paths for part 2-protected data, see 
                            <E T="03">http://www.healthit.gov/facas/sites/faca/files/PSTT_DS4P_Transmittal%20Letter_2014-07-03.pdf.</E>
                        </P>
                    </FTNT>
                    <P>Since the 2015 Edition final rule, the health care industry has engaged in additional field testing and implementation of the DS4P standard. As of the beginning of the fourth quarter of the 2019 calendar year, 34 Health IT Modules were certified to one or both of the current 2015 Edition DS4P certification criteria (Health IT Modules with multiple certified versions were counted once). Stakeholders have shared with ONC—through public forums, listening sessions, and correspondence—that document-level security tagging does not provide enough flexibility to address more complex privacy and security use cases. Stakeholders noted that certain provider types, such as pediatrics and behavioral health, often rely on burdensome manual workflows to appropriately segment and share sensitive health information according to State and local laws. Additionally, stakeholders expressed interest in ONC adopting health IT standards that work with DS4P to support electronic consent for the exchange of security tagged data over an API.</P>
                    <P>
                        Therefore, in consideration of stakeholder feedback and HITPC recommendations to adopt DS4P certification criteria on a glide path, we proposed (84 FR 7452) to remove the 2015 Edition DS4P-send (§ 170.315(b)(7)) and DS4P-receive (§ 170.315(b)(8)) certification criteria. We proposed that the effective date of removal of these criteria would be the effective date of the final rule. We proposed to replace the removed DS4P criteria with two new 2015 Edition DS4P certification criteria in § 170.315(b)(12) and § 170.315(b)(13) that would support security tagging according to the DS4P standard at the document, section, and entry levels of C-CDA 2.1 formatted documents. Our primary purpose for proposing to remove and replace the criteria, in lieu of proposing to revise them, was to provide clarity to stakeholders about the additional functionality enabled by health IT certified to the new criteria. We also proposed a new 2015 Edition certification criteria for sharing patient consent information over an API using the Substance Abuse and Mental Health Services Administration's (SAMHSA) Consent2Share (C2S) IG a FHIR-based exchange standard, in § 170.315(g)(11). We noted resources released by ONC and OCR, such as the HHS Security Risk Assessment Tool 
                        <SU>55</SU>
                        <FTREF/>
                         and the Guide to Privacy and Security of Electronic Health Information,
                        <SU>56</SU>
                        <FTREF/>
                         as well as the Office for Civil Rights' security risk analysis guidance 
                        <SU>57</SU>
                        <FTREF/>
                         that entities may employ to make risk-based decisions regarding their implementation of the proposed DS4P criteria. We also noted the availability of the Electronic Consent Management Landscape Assessment, Challenges, and Technology report.
                        <SU>58</SU>
                        <FTREF/>
                         The report includes suggestions for overcoming barriers associated with implementing electronic consent management, which may be considered for further research and discussion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>55</SU>
                             HHS Security Risk Assessment Tool: 
                            <E T="03">http://www.healthit.gov/providers-professionals/security-risk-assessment.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>56</SU>
                             ONC Guide to Privacy and Security of Electronic Health Information: 
                            <E T="03">http://www.healthit.gov/sites/default/files/</E>
                              
                            <E T="03">pdf/privacy/privacy-and-security-guide.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>57</SU>
                             HHS Office for Civil Rights: 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html;</E>
                             and 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html?language=es.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>58</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/privacy-security/ecm_finalreport_forrelease62415.pdf.</E>
                        </P>
                    </FTNT>
                    <P>We note that we received many comments on the proposed DS4P criteria and the proposed consent management for the API criterion but the majority of comments conflated the two proposals and provided a collective response. We tried to separate where possible, but in some instances, we kept them combined in order to preserve the integrity of the comments.</P>
                    <HD SOURCE="HD3">a. Implementation With the Consolidated CDA Release 2.1</HD>
                    <P>In place of the removed 2015 Edition DS4P criteria, we proposed (84 FR 7452) to adopt new DS4P-send (§  170.315(b)(12)) and DS4P-receive (§  170.315(b)(13)) criteria that would remain based on the CDA 2.1 and the HL7 DS4P standard. These criteria would include capabilities for applying security tags according to the DS4P standard at the document, section, and entry level. We believe this offers more valuable functionality to providers and patients, especially given the complexities of the landscape of privacy laws for multiple care and specialty settings. We stated in the Proposed Rule that we believe health IT certified to these criteria would support multiple practice settings and use cases.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments both in support and against this proposal. In certain instances, commenters were supportive of our aims but felt there were too many barriers and challenges near term, including but not limited to the perceived cost involved with successful segmentation in practice and indicated we should delay our finalization of the proposal. Others felt immediate adoption of our proposal in the final rule was critical for patient care and the secure exchange of sensitive health information. Many commenters in favor of our proposal provided examples of use cases which it could support, such as helping to combat the opioid crisis by facilitating the secure exchange of sensitive health information across health care settings and including substance use disorder (SUD) information covered by 42 CFR part 2. We also received support of our proposal for the protection of women's health—the commenter explained that segmenting at the element level would protect individuals who have experienced intimate partner violence, sexual assault, and other sensitive experiences. Stakeholders shared with us that focusing certification on segmentation to only the document level does not permit providers the flexibility to address more granular segmentation needs. We received many comments on this proposal in the context of the following topics: provider and developer burden; readiness of the standard and C-CDA exchange; information blocking and EHI; future multidisciplinary activities (such as workgroups) and creating a vision for segmentation using health IT; safety; privacy policy conformity; suggested use cases; cost; and requests for specific clarifications. We describe these comments further below.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. To address the comments concerned about the cost and timing, at the current time, these criteria are voluntary and not required under the definition of CEHRT or to participate in any HHS program. For more information on the costs for the adoption of these criteria, please see the Regulatory Impact Analysis in section XIII. For the reasons noted above, in this final rule, we have finalized our proposal to support a more granular approach to privacy tagging data consent management for health information exchange supported by the C-CDA exchange standard. We do this not by removing and replacing the 2015 Edition DS4P criteria with new § 170.315(b)(12) and § 170.315(b)(13), but by revising the 2015 Edition DS4P criteria, DS4P criteria DS4P-send (§  170.315(b)(7)) and DS4P-receive (§  170.315(b)(8)), to include the full scope of the HL7 DS4P standard for 
                        <PRTPAGE P="25704"/>
                        security tagging at the document, section and entry level with modifications as described below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments regarding the perceived burden of segmentation on providers and developers including comments focused on workflow challenges. One commenter indicated a lack of system and explained that tagging is burdensome for implementers because it does not describe how to determine what information is sensitive and should be tagged. Another indicated that DS4P creates a permanent added burden of extensive and costly manual data curation to redact each page to meet overlapping Federal and State regulations. Commenters indicated end users would be required to flag each individual data element, a process that is time consuming and error prone. They further explained that granular level privacy tagging has the risk of adding additional data entry burden to provider workflows if users must tag each item individually.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the thoughtful comments submitted on the proposed criteria. Notably, with respect to the comments we received that expressed concern about the DS4P standard due to the burden, our analysis of the comments indicates that the concerns the commenters express are more closely related to the complexity of the privacy law landscape than to the specific functionality and standard in our proposal. As noted above, at the current time, these criteria are voluntary and not required under the definition of CEHRT or to participate in any HHS program. The DS4P standard is a tool and voluntary certification to these criteria is an initial step towards enabling an interoperable health care system to use technical standards to compute and persist security tags to permit access, use, or disclosure of sensitive health information. The criteria do not specify that a manual workflow is required to implement security tagging, and we understand from examples of DS4P use in practice that solutions may include the use of value sets to automate the tagging process. We reiterate that these criteria are intended to apply standards to the transmission of documents so that such security tags may be interoperable. Though the updated criteria would support a more granular approach to tagging the sensitive information, we recognize that this will not solve the whole problem of how to manage data segmentation for privacy and consent management. The recipient will still receive and can view the information that is tagged—the recipient will need to determine what they are going to do with that information. Policies and procedures for what to do with the information once it is received are outside the scope of these criteria and this final rule. However, we emphasize that health care providers already have processes and workflows to address their existing compliance obligations for State and Federal privacy laws, which could be made more efficient and cost effective through the use of health IT, rather than relying on case-by-case manual redaction and subsequent workarounds to transmit redacted documents. We believe this tool may be one part of innovative solutions to support health IT enabled privacy segmentation in care coordination workflows to significantly reduce the burden of these manual processes currently in practice.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters indicated that enhanced segmentation may unintentionally impact clinical care when providers are presented with an incomplete picture of patient data. Commenters stated there could be patient care risks involved with not sharing elements as users of downstream systems may not realize that a single element is filtered and act improperly, such as by prescribing a contraindicated medication due to missing information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         DS4P is a technical standard for C-CDA that helps health care providers comply with existing, applicable laws. As such, health care providers should already have processes and workflows in place to address their existing compliance obligations. The DS4P standard does not itself create incomplete records. Under existing law, patients already have the right to prevent re-disclosure of certain types of data by withholding consent to its disclosure or to place restrictions on its re-disclosure. DS4P allows providers to electronically tag (mark) data as sensitive and express re-disclosure restrictions and other obligations in an electronic form. DS4P does not determine whether a segmentation obligation exists legally or what that legal obligation means to the recipient. Instead, DS4P allows for tagging and exchange of health information that has already been determined to be sensitive and in need of special protections under existing law.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments in support of our proposal indicating that, without data segmentation, other mandatory criteria, such as the proposed “EHI export” criterion, would be difficult to implement without risking disclosure of sensitive data or information blocking. One commenter indicated that without this technical standard, it would be difficult for stakeholders to know whether appropriate consent has been obtained prior to releasing health information. Further, the commenter indicated concern that without such capabilities, hospitals and health systems could be accused of information blocking because they cannot verify that a patient has given consent for their EHI to be shared. They further commented that if ONC does not finalize this criterion, then we should provide an appropriate exception in the information blocking provisions so that an entity is not accused of information blocking because they do not know if another organization has obtained consent from patients. One commenter stated ONC should propose a new information blocking exception that specifically clarifies that a health IT developer's choice to not certify to an optional standard cannot be a practice that implicates information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of the DS4P standard. While we understand commenters' concerns, we first reiterate the DS4P capability enables sensitive health information to be exchanged electronically with security tags in a standardized format. It does not enable the full segmentation of a patient's record within an EHR, which may be necessary when responding to a request for EHI. Second, we have revised the Infeasibility Exception in the information blocking section of this final rule to provide that an actor is not required to fulfill a request for access, exchange, or use of EHI if the actor cannot unambiguously segment the requested EHI from other EHI: (1) Because of a patient's preference or because the EHI cannot be made available by law; or (2) because the EHI is withheld in accordance with the Harm Exception in § 171.201 (§ 171.204(a)(2)). For instance, an actor will be covered under this condition if the actor could not fulfill a request to access, exchange, or use EHI because the requested EHI could not be unambiguously segmented from patient records created by federally assisted programs (
                        <E T="03">i.e.,</E>
                         Part 2 Programs) for the treatment of substance use disorder (and covered by 42 CFR part 2) or from records that the patient has expressed a preference not to disclose. We refer readers to the Infeasibility Exception discussion in section VIII.D.1.d of this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters noted a low level of adoption for these standards and concerns related to readiness expressing that the standard 
                        <PRTPAGE P="25705"/>
                        utility is limited by lack of widespread developer implementation. Several commenters encouraged ONC to defer adoption of the DS4P criteria with a few commenters recommending that the optional 2015 Edition criterion should be maintained with document level tagging only until practical implementations at scale have been demonstrated at this level. One commenter suggested that organic adoption by end-user providers will help spark innovation in this emerging standard while expressing concern that C-CDA level data tagging for privacy is largely untested in real world scenarios. Others encouraged ONC to provide additional guidance on the adoption of the DS4P standards and certification criteria and forgo the inclusion of this requirement until additional real world testing is available. They also indicated ONC should first conduct use test cases to demonstrate how this functionality will be effectively used across a variety of environments.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments on the proposed criteria. In reference to the DS4P standard's maturity, we note that it is considered a “normative” standard from the HL7 perspective—a status which indicates the content has been enhanced and refined through trial use. While we recognize that to date the standard has not been widely adopted, the SAMHSA C2S application uses the standard to segment Part 2 information. Likewise, the U.S. Department of Veterans Affairs (VA) and private companies across the country have used the DS4P standard to support behavioral health and pediatric care models. In addition, as of the fourth quarter of 2019, 34 individual Health IT Modules obtained certification to one of or both of the prior 2015 Edition certification criteria. Our intent for adopting the updates to these criteria is that in the absence of adoption of consensus driven standards there is increased risk that single-use-case, proprietary solutions will be developed, which may increase fragmentation, provider burden, and cost while limiting interoperability. Further, the purpose of adopting these criteria is to encourage the use of interoperable standards, in this case to use technical standards to compute and persist security tags upon exchange of a summary of care document in an interoperable manner. In addition, the certification criteria using the DS4P standard are voluntary and therefore our intent is, as commenters noted, to support organic adoption of technology certified to the criteria by providers seeking to implement health IT solutions to replace burdensome manual privacy workflows.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters called for the need to increase conformity among Federal and State privacy provisions to achieve successful implementation of granular tagging. They noted the significant policy component involved with the successful implementation of the DS4P standard in practice, and in certain instances specifically noted support for HIPAA Privacy Rule and 42 CFR part 2 harmonization. Several commenters identified specific areas for technical development of IT supporting data segmentation for privacy based on Federal and State privacy provisions. One commenter indicated that ONC could map which clinical codes are associated with certain health conditions that receive special privacy protections in addition to the HIPAA Rules. Other commenters noted that mapping of privacy policy to technical specifications is not a sufficient or adequate approach given policy complexities. One commenter indicated a future approach should focus on development of criteria that support a data provenance driven method of sensitive data management as applicable under privacy laws.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As we have stated, the DS4P standard enables sensitive health information to be exchanged electronically with security tags in a standardized format and we encourage health IT developers to include DS4P functionality and pursue certification of their health IT to these criteria in order to help support their users' compliance with relevant State and Federal privacy laws that protect sensitive health information. We recognize that the current privacy law landscape is complex. In light of the complexities of the privacy law landscape, we believe that supporting a standard that allows for increased granularity in security tagging of sensitive health information would better allow for the interoperable exchange of this information to support a wide range of privacy related use cases.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters offered an approach for next steps to advance the standard. To advance adoption and implementation of the standard, several commenters suggested that ONC work closely with clinicians, privacy subject matter experts and interoperability experts (notably the HL7 Privacy and Security workgroups) to develop a clear vision for implementing enhanced data segmentation. Many commenters specifically called for ONC to sponsor or lead a multidisciplinary workgroup of stakeholders to develop recommendations for industry adoption and implementation. One commenter in support of our proposal suggested such workgroup focus on including whether additional standards are needed, as well as data visualization of non-disclosed data and its utilization in clinical decision support algorithms. Several commenters cited existing work to help support potential new multidisciplinary efforts indicating that one SDO has already undertaken early work toward evolving DS4P implementation guidance via the HL7 V2 to FHIR mapping project sponsored by the HL7 Orders Work Group. One commenter, called for an ONC led public-private collaborative effort to reduce data entry burden. One commenter recommended that ONC stand up a multi-stakeholder workgroup to identify and define policy needs and functional requirements to address patient privacy and provider needs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their recommendations. ONC believes that data segmentation is an integral capability for exchanging sensitive health data. ONC first studied policy considerations regarding data segmentation in electronic health information exchange in 2010 and informed ONC's launch of the DS4P Standards and Interoperability Framework (S&amp;I Framework) Initiative in 2011.
                        <SU>59</SU>
                        <FTREF/>
                         The initiative focused on the development of a DS4P technical specification that would allow highly sensitive health information to flow more freely to authorized users while improving the ability of users of health IT to meet their obligations under State and Federal privacy rules. Recommendations from the initiative called for the use of metadata security tags to demonstrate privacy and security obligations associated with patient health information. It also advised that patients and providers be able to share portions, or segments, of records in order to maintain patient privacy. Pilot projects conducted under the DS4P S&amp;I Framework Initiative demonstrated ways to enable the sharing of information that is protected by Federal and State laws, including the substance use disorder treatment confidentiality regulations, 42 CFR part 2. ONC's prior Federal Advisory Committee, the HITPC, also focused on the health IT certification needed to enable exchange of behavioral health data.
                        <SU>60</SU>
                        <FTREF/>
                         Additionally, ONC led a project on 
                        <PRTPAGE P="25706"/>
                        patient choice where the exchange of sensitive data was addressed.
                        <SU>61</SU>
                        <FTREF/>
                         ONC also led a project on the Behavioral Health Data Exchange (BHDE) Consortium. The purpose of the project was to facilitate and address barriers to the intra and interstate exchange of behavioral health data.
                        <SU>62</SU>
                        <FTREF/>
                         Currently, ONC's Leading Edge Acceleration Projects (LEAP) in Health Information Technology (IT) program seeks to address well-documented and fast emerging challenges inhibiting the development, use, and/or advancement of well-designed, interoperable health IT. In 2019, one of the two LEAP awards issued by ONC focused on the standardization and implementation of the Fast Healthcare Interoperability Resources (FHIR®) Consent resource. Under this project, a FHIR® Consent Implementation Guide (IG) and package of open-source prototypes and content to assist partners in using the FHIR® Consent Resource will become available.
                        <SU>63</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>59</SU>
                             
                            <E T="03">https://archive.healthit.gov/providers-professionals/ds4p-initiative.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>60</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/Federal-advisory-committees/health-it-policy-committee-recommendations-national-coordinator.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>61</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/patient-consent-electronic-health-information-exchange.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>62</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/health-it-health-care-settings/behavioral-health-data-exchange-primary-care-and-behavioral.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>63</SU>
                             
                            <E T="03">https://www.healthit.gov/topic/leading-edge-acceleration-projects-leap-health-information-technology-health-it.</E>
                        </P>
                    </FTNT>
                    <P>Also, ONC actively participates in HL7 International (HL7®) Workgroups and standards-development activities related to data segmentation and consent management. It is critical for sensitive health information to be included in health information exchange and we are exploring opportunities for additional collaboration in the future.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended a companion guide be developed to assist implementers with the standard. Another indicated ONC should provide guidance to facilitate adoption of the DS4P standards and certification criteria including dissemination of best practices to help ensure that providers can most effectively implement the standards and associated workflows. Another referred to a Query-Based Document Exchange IG which has further guidance on the ability to assert access policies and DS4P implementation considerations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The HL7 Version 3 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1, Part 1: CDA R2 and Privacy Metadata Reusable Content Profile, May 16, 2014 standard 
                        <SU>64</SU>
                        <FTREF/>
                         § 170.205(o)(1) (HL7 DS4P standard) describes the technical means to apply security tags to a health record and data may be tagged at the document-level, the section-level, or individual data element-level. The HL7 DS4P standard also provides a means to express obligations and disclosure restrictions that may exist for the data. We appreciate commenters input on additional guidance beyond these certification requirements that may prove useful for developers. However, we reiterate that in this rule we address only that guidance that is required for those developers to voluntarily submit a Health IT Module for certification to our criteria. Additional guidance on best practices would be outside the scope of this rulemaking. However, as noted above, we are committed to continuing to work with stakeholders, including health IT developers and those involved in implementing privacy policy in the health care industry, to work toward interoperable solutions for privacy and consent management.
                    </P>
                    <FTNT>
                        <P>
                            <SU>64</SU>
                             
                            <E T="03">https://www.hl7.org/implement/standards/product_brief.cfm?product_id=354.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments seeking clarification on our proposal to remove the current 2015 Edition “DS4P-send” (§ 170.315(b)(7)) and “DS4P-receive” (§ 170.315(b)(8)) certification criteria and to replace these two criteria with three new 2015 Edition DS4P certification criteria (two for C-CDA and one for a FHIR-based API). As examples, one commenter sought clarification on whether our proposal was for DS4P send and receive to become mandatory for the revised 2015 Edition certification, or if they will remain voluntary criteria. One commenter sought clarification on whether the data protections apply to FHIR transmissions. Another indicated that they believe the DS4P implementation guide only focuses on data segmentation for C-CDA documents and not for HL7 FHIR and sought ONC clarification regarding whether or not we intend to apply data segmentation labeling to the HL7 FHIR resources in support of the USCDI as well. Another commenter recommended that we require FHIR Release 4 version but commented that a consistent approach of USCDI across HL7 CDA, C-CDA and HL7 FHIR is not attainable at this time. One commenter stated a similar need for clarification indicating that the standard for DS4P should be HL7 standards for CDA Version 2 and FHIR security tagging and not be the SAMHSA C2S stating that ONC should clarify this misunderstanding. Another commenter sought clarification by ONC to indicate that the IG is for CCDS and not FHIR, and also indicated confusion regarding STU4. One commenter noted that the DS4P criteria are only effective for C-CDA-based data exchange and recommended ONC add FHIR-based standard for tagging of sensitive data. Several commenters expressed concern over what they described as misalignment of this proposal with other ONC policies explaining that neither USCDI nor ARCH, nor HL7 FHIR US Core includes the FHIR Composition resource, which would be at the equivalent level of granularity as a C-CDA document.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input and we appreciate the need for clarity requested by commenters. In the Proposed Rule (84 FR 7452), we proposed both to adopt an update to the HL7 DS4P standard for the existing 2015 Edition certification criteria to support security tagging of a C-CDA upon send and receive by removing DS4P-send (§  170.315(b)(7)) and DS4P-receive (§  170.315(b)(8)) and replacing them with DS4P-send (§  170.315(b)(12)) and DS4P-receive (§  170.315(b)(13)) and to also adopt a new criterion to support API exchange via consent management solutions using the FHIR standard. In other words, these were two separate proposals, the first to support security tags in summary of care documents and another to support consent management for specific use cases that leverage a FHIR-based API. As of this final rule, these criteria remain voluntary and not required under the definition of CEHRT or to participate in any HHS program. We proposed these several criteria in a single section of the Proposed Rule because of the relationship between them as two potential health IT tools that could be part of overarching solutions to manage privacy and consent in health information exchange. However, as stated earlier, we note that neither of these tools addresses the entirety of the scope of data segmentation for privacy. To address the comment on the DS4P implementation guide, we confirm that the HL7 DS4P standard in § 170.205(o)(1) describes the technical means to apply security tags to a health record and data may be tagged at the document-level, the section-level, or individual data element-level in the C-CDA and not for FHIR. Currently, we do not intend to apply data segmentation labeling to the HL7 FHIR resources in support of the USCDI because all FHIR resources already include the capability to apply security tags to the resource as metadata. We appreciate the recommendation to require FHIR Release 4 for consent management but as discussed below, we have decided not to finalize the proposal for consent management for APIs in this final rule. For further 
                        <PRTPAGE P="25707"/>
                        discussion of our FHIR-based consent management proposal, we direct readers to subsection b below.
                    </P>
                    <P>For the updates to the existing DS4P criteria, to support greater clarity requested by public comment, rather than removing the existing 2015 Edition criteria and replacing them with new criteria as proposed, we instead finalized a simple update to the existing criteria to note the use of the full HL7 DS4P standard for tagging or applying security tags at the document, section, and entry level.</P>
                    <P>We further note that these updated criteria remain voluntary, and that we have finalized modifications in § 170.315(b)(7)(ii) and § 170.315(b)(8)(i)(B) to our proposed effective date for this change to allow for a longer glide path for health IT developers to update Health IT Modules to the full standard to better support clinical and administrative workflows. While certification to the updated standards will be available after the effective date of this final rule upon successful testing, we have finalized that document-level tagging remains applicable for up to 24 months after the publication date of this final rule. For certification and compliance of Health IT Modules certified after 24 months after the publication date of this final rule, only the full scope of the HL7 DS4P standard is applicable. We have finalized this 24 month period for the update for these criteria under the real world testing provisions in § 170.405(b)(6) as follows:</P>
                    <P>
                        • 
                        <E T="03">Security tags.</E>
                         A health IT developer with health IT certified to § 170.315 (b)(7) and/or § 170.315 (b)(8) prior to June 30, 2020, must:
                    </P>
                    <P>○ Update their certified health IT to be compliant with the revised versions of the criteria adopted in § 170.315(b)(7) and/or the revised versions of the criteria adopted in § 170.315(b)(8); and</P>
                    <P>○ Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(6)(i) of this section by May 2, 2022,</P>
                    <P>In addition, we have finalized these updated criteria with modifications to the criteria names to better describe the function the criteria support in interoperable health IT systems. The modifications to the criteria are as follows:</P>
                    <P>• Prior criterion: “DS4P-send” (§ 170.315(b)(7)) includes capabilities for creating a summary care record formatted to the C-CDA standard and document-level tagging as restricted (and subject to restrictions on re-disclosure) according to the DS4P standard.</P>
                    <P>• Revised criterion: “Security tags—Summary of Care (send)” (§ 170.315(b)(7)) includes capabilities for creating a summary of care record formatted to the C-CDA standard and that is tagged as restricted and subject to restrictions on re-disclosure according to the DS4P standard at the document, section, and entry (data element) level, or at the document-level for the period until May 2, 2022.</P>
                    <P>• Prior criterion: “DS4P-receive” (§ 170.315(b)(8)) includes capabilities for receiving a summary care record formatted to the C-CDA standard and document-level tagged as restricted (and subject to restrictions on re-disclosure) according to the DS4P standard.</P>
                    <P>• Revised criterion: “Security tags—Summary of Care (receive)” (§ 170.315(b)(8)) includes capabilities for receiving a summary of care record formatted to the C-CDA standard and that is tagged as restricted and subject to restrictions on re-disclosure according to the DS4P standard at the document, section, and entry (data element) level, or at the document-level for the period until May 2, 2022. We have finalized our proposal to include in the voluntary “Security tags—Summary of Care (receive)” (§ 170.315(b)(8)) criterion as a requirement that the Health IT Module has the capability to preserve privacy markings to ensure fidelity to the tagging based on consent and with respect to sharing and re-disclosure restrictions as proposed.</P>
                    <HD SOURCE="HD3">b. Implementation With the Fast Healthcare Interoperability Resources (FHIR®) Standard</HD>
                    <P>
                        In collaboration with ONC, SAMHSA developed the C2Sapplication to address the specific privacy protections for patients with substance use disorders whose treatment records are covered by the Federal confidentiality regulation, 42 CFR part 2. C2S is an open source application for data segmentation and consent management. It is designed to integrate with existing FHIR systems. SAMHSA created a FHIR implementation guide (the Consent2Share Consent Profile Design, hereafter referred to as “Consent Implementation Guide”) that describes how the Consent2Share application and associated access control solution (C2S platform) uses the FHIR Consent resource to represent and persist patient consent for treatment, research, or disclosure.
                        <SU>65</SU>
                        <FTREF/>
                         The implementation guide provides instructions for using the FHIR Consent resource to capture a record of a health care consumer's privacy preferences.
                    </P>
                    <FTNT>
                        <P>
                            <SU>65</SU>
                             The draft FHIR IG titled “Consent2Share FHIR Profile Design.docx” can be accessed through the Community- Based Care and Privacy (CBCP) HL7 workgroup, within the Package Name titled “BHITS_FHIR_Consent_IG,” at 
                            <E T="03">https://gforge.hl7.org/gf/project/cbcc/frs/</E>
                            .
                        </P>
                    </FTNT>
                    <P>In section VII.B.4 of this final rule, we discuss policies related to the implementation of a standardized API to support the exchange of health information between providers and patients and among members of a care team. In the Proposed Rule, we anticipated that the proposed 2015 Edition “standardized API for patient and population services” certification criterion (§ 170.315(g)(10)) would result in a proliferation of APIs that will enable a more flexible and less burdensome approach to exchanging EHI. We stated our belief that the health care industry could leverage this API infrastructure to share segmented data in a secure and scalable manner. Therefore, we proposed to adopt a 2015 Edition certification criterion “consent management for APIs” in § 170.315(g)(11) to support data segmentation and consent management through an API in accordance with the Consent Implementation Guide.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Overall, the majority of commenters were supportive of the concept of consent management for APIs but many had concerns with the proposed criteria, specifically the adoption of the Consent Implementation Guide or the C2S platform as part of a certification criterion. Many commenters raised concerns that the Consent Implementation Guide has not been balloted as an HL7 standard and noted that C2S does not support a consenter's signature or specification to protect information content data requirements. A couple of commenters stated that the Consent Implementation Guide is a new emerging standard in pilot with feedback requested. Commenters also raised concern that the IG has not gone through an SDO process. Another commenter raised concern that SAMHSA no longer supports the C2S platform and the Consent Implementation Guide and it now lacks a steward. A couple of commenters suggested ONC defer the consent management criteria at least until an API FHIR standard version is finalized and the Consent Implementation Guide is revised to conform that to that version. One commenter supported the adoption of FHIR v3-based Consent resource, but urged ONC to also consider pediatric and geriatric use cases in its adoption. Other commenters stated that their understanding was that tagging will be 
                        <PRTPAGE P="25708"/>
                        a feature of FHIR Release 4, but were unclear how the proposal to move to FHIR Release 2 would work. One commenter questioned how if there are no standards-based approaches for identifying what in the record is sensitive, how one could feasibly implement privacy-tagging and consent management via FHIR at the Resource level and that tagging at a more granular level is too cumbersome and unrealistic. A number of commenters stated that the standards were premature and if adopted could have unintended negative effects. Commenters were not supportive of having two versions of FHIR but instead recommended the use of FHIR Release 4. Commenters recommended ONC focus on driving real-world implementation experience before adopting the standards.
                    </P>
                    <P>On the other hand, a few commenters supported our proposal, and stated that the C2S platform and the Consent Implementation Guide is mature and already supports granular level security tagging and data segmentation and supports several API standards listed in the Proposed Rule. One commenter expressed support broadly for the C2S platform indicating that, though it was originally designed to satisfy 42 CFR part 2 consent for the substance use disorder data, it supports the other sensitive categories such as HIV and mental health. Several commenters stated that the criteria should be required in the Base EHR definition.</P>
                    <P>Many providers called for patient education and for ONC to work with SAMHSA, OCR, and CMS. It was also suggested that ONC coordinate with SAMHSA to establish a public-private project to advance the C2S platform and the Consent Implementation Guide using an analogous process to that of the Da Vinci Project with transparency and with no membership fees. Finally, several commenters raised issues that are out of scope for this rule including concerns specifically with the HIPAA Rules or 42 CFR part 2 which are under the authority of OCR and SAMHSA respectively.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments received and the insights into real world implementing challenges of consent management. We agree that there is continued work to be done to ballot and field test the C2S platform and the Consent Implementation Guide and also agree with commenters that identified this resource as having significant potential to support consent management for specific use cases such as 42 CFR part 2, behavioral health, and pediatric care. We also note that we had included a series of questions in our Proposed Rule related to the alignment of FHIR releases and we appreciate comments received related to these questions. We direct readers to section VII.B.4.c for further discussion of our adoption in this rule the FHIR Release 4 standard. We note that the Consent Implementation Guide is designed in FHIR Release 3 and that there is significant work to be done in standards development before the IG would be feasible with FHIR Release 4. At this time, FHIR Release 4 version of FHIR consent resource is not normative and can change from version to version and therefore further development, review, balloting, and testing would be required for a FHIR Release 4 based IG to be a viable consensus standard for adoption in the Program. In consideration of comments, and the scope of the additional work required for readiness of an IG that could be adopted in our regulations, we have not finalized the proposed “consent management for APIs” certification criterion in § 170.315(g)(11). We maintain, as stated above, that the C2S platform and the Consent Implementation Guide may still serve as a template for implementation of consent management workflows leveraging APIs and that it may be a part of health IT solutions to facilitate health information exchange of sensitive information. We will continue to monitor the development of the Consent Implementation Guide and other FHIR resources to support consent management and may consider including in a future rulemaking.
                    </P>
                    <HD SOURCE="HD3">10. Auditable Events and Tamper-Resistance, Audit Reports, and Auditing Actions on Health Information</HD>
                    <P>Since adopting the Auditable events and tamper-resistance (§ 170.315(d)(2)), Audit Reports (§ 170.315(d)(3)), and Auditing Actions on health information (§ 170.315(d)(10)) criteria in the 2015 Edition, there has been an update to ASTM E2147—1 standard and has been replaced by a newer version. Given the older version has been deprecated and based on comments received, we have updated these criteria with the most up to date standard, ASTM E1247—18 in § 170.210(h). We have also updated the requirements to align with the new numbering sequence of the updated standard. In order to meet the minimum requirements for capturing and auditing electronic health information, we have specified, in § 170.210(e)(1)(i), that the data elements in sections 7.1.1 through 7.1.3 and 7.1.6, through 7.1.9 in ASTM E1247—18 are required. We believe that the updated standard reinforces what we have previously required and maintained with previous certification requirements and note that there is no substantial change to the standard.</P>
                    <P>We further note that health IT developers must update Health IT Modules to these updated standards referenced in these criteria within 24 months after the publication date of this final rule. We have added as a Maintenance of Certification requirement for the real world testing Condition of Certification requirement, that health IT developers are required to provide the updated certified health IT to all their customers with health IT previously certified to the identified criteria no later than 24 months after the publication date of the final rule. Developers would also need to factor these updates into their next real world testing plan as discussed in section VII.B.5 of this final rule and in § 170.405(b)(7).</P>
                    <HD SOURCE="HD2">C. Unchanged 2015 Edition Criteria—Promoting Interoperability Programs Reference Alignment</HD>
                    <P>In the FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20516), CMS proposed scoring and measurement policies to move beyond the three stages of meaningful use to a new phase of EHR measurement with an increased focus on interoperability and improving patient access to health information. To reflect this focus, CMS changed the name of the Medicare and Medicaid EHR Incentive Programs, to the Medicare and Medicaid Promoting Interoperability (PI) Programs. To align with the renaming of the EHR Incentive Programs, we proposed to remove references to the EHR Incentive Programs and replace them with “Promoting Interoperability Programs” in the updated 2015 Edition “automated numerator recording” criterion in § 170.315(g)(1) and the “automated measure calculation” criterion in § 170.315(g)(2).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on this proposal to remove references to the EHR Incentive Programs and replace them with “Promoting Interoperability Programs” in the updated 2015 Edition “automated numerator recording” criterion in § 170.315(g)(1) and the “automated measure calculation” criterion in § 170.315(g)(2).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have removed references to the EHR Incentive Programs and replaced them with “Promoting Interoperability Programs” in the 2015 Edition “automated numerator recording” criterion in § 170.315(g)(1) and the “automated measure calculation” criterion in § 170.315(g)(2).
                        <PRTPAGE P="25709"/>
                    </P>
                    <HD SOURCE="HD1">V. Modifications to the ONC Health IT Certification Program</HD>
                    <HD SOURCE="HD2">A. Corrections</HD>
                    <HD SOURCE="HD3">1. Auditable Events and Tamper Resistance</HD>
                    <P>
                        We proposed to revise § 170.550(h)(3) to require the End-User Device Encryption criterion in § 170.315(d)(7) as appropriate, and exempt Health IT Modules from having to meet § 170.315(d)(7) when the certificate scope does not require § 170.315(d)(7) certification (
                        <E T="03">see</E>
                         § 170.315(d)(2)(i)(C)) (84 FR 7454). As noted in the Proposed Rule (84 FR 7454), paragraph 170.315(d)(2)(i)(C) was not applicable to the privacy and security testing and certification of a Health IT Module required by § 170.550(h)(3)(iii), (v), (vii), and (viii), but we intended for it to also be exempted from the aforementioned paragraphs. We, therefore, proposed to revise § 170.550(h)(3)(iii), (v), (vii), and (viii) by removing references to paragraph 170.315(d)(2)(i)(C).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed support of the proposals under section V (“Modifications of the ONC Health IT Certification Program”) of the Proposed Rule as a whole. However, we received no comments specific to this proposal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the revision as proposed. Certification can proceed for the audit log process without the Health IT Module demonstrating that it can record an encryption status in accordance with § 170.315(d)(2)(i)(C). Paragraph § 170.315(d)(2)(i)(C) is not applicable for the privacy and security testing and certification of a Health IT Module required by § 170.550(h)(3)(iii), (v), (vii), and (viii). We had previously identified this error in guidance,
                        <SU>66</SU>
                        <FTREF/>
                         and have now codified the correction to § 170.550(h)(3)(iii), (v), (vii), and (viii) in regulation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>66</SU>
                             
                            <E T="03">https://www.healthit.gov/test-method/auditable-events-and-tamper-resistance</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Amendments</HD>
                    <P>We proposed to revise § 170.550(h) to remove the “amendments” criterion's application to certain non-applicable clinical criteria including: “Drug-drug, drug-allergy interaction checks for computerized provider order entry (CPOE)” in § 170.315(a)(4); “clinical decision support (CDS)” in § 170.315(a)(9); “drug-formulary and preferred drug list checks” in § 170.315(a)(10); and “patient-specific education resources” in § 170.315(a)(13) (84 FR 7454). The “amendments” certification criterion § 170.315(d)(4) is not necessarily indicated for health IT capabilities that may not have any patient data for which a request for an amendment would be relevant.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed support of the proposals under section V (“Modifications of the ONC Health IT Certification Program”) of the Proposed Rule as a whole. However, we received no comments specific to this proposal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the proposal with modifications. Health IT Modules presented for certification to these criteria do not have to demonstrate the capabilities required by the revised 2015 Edition “amendments” certification criterion (§ 170.315(d)(4)), unless the Health IT Module is presented for certification to another criterion that requires certification to the 2015 Edition “amendments” criterion under the privacy and security (P&amp;S) certification framework. We note that, because we have not finalized our proposal to remove the “drug-formulary and preferred drug list checks” criterion in § 170.315(a)(10) and the “patient- specific education” criterion in § 170.315(a)(13), but to only permit ONC-ACBs to issue certificates for these criteria until January 1, 2022, we have not removed references to these criteria from the exemption in § 170.550(h) at this time. This clarification has already been incorporated into sub-regulatory guidance,
                        <SU>67</SU>
                        <FTREF/>
                         and is now codified in regulation.
                    </P>
                    <FTNT>
                        <P>
                            <SU>67</SU>
                             
                            <E T="03">https://www.healthit.gov/test-method/drug-drug-drug-allergy-interaction-checks-cpoe; https://www.healthit.gov/test-method/clinical-decision-support-cds;</E>
                              
                            <E T="03">https://www.healthit.gov/test-method/drug-formulary-and-preferred-drug-list-checks;</E>
                             and 
                            <E T="03">https://www.healthit.gov/test-method/patient-specific-education-resources.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. View, Download, and Transmit to 3rd Party</HD>
                    <P>We proposed to remove § 170.315(e)(1)(ii)(B), which includes a cross-reference to § 170.315(d)(2) indicating that a Health IT Module may demonstrate compliance with active history log requirements if it is also certified to § 170.315(d)(2) (84 FR 7454).</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed support of the proposals under section V (“Modifications of the ONC Health IT Certification Program”) of the Proposed Rule as a whole. However, we received no comments specific to this proposal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and have finalized the proposal to remove § 170.315(e)(1)(ii)(B), which includes a cross-reference to § 170.315(d)(2). As noted in the Proposed Rule (84 FR 7454), this cross-reference indicates that a Health IT Module may demonstrate compliance with activity history log requirements if it is also certified to the 2015 Edition “auditable events and tamper-resistance” certification criterion (§ 170.315(d)(2)). However, we no longer require testing of activity history log when certifying for § 170.315(d)(2). Therefore, this cross-reference is no longer applicable to meet certification requirements for the updated 2015 Edition “view, download, and transmit to 3rd party” certification criterion (§ 170.315(e)(1)) activity history log requirements. Consequently, we have finalized our proposal to remove § 170.315(e)(1)(ii)(B).
                    </P>
                    <HD SOURCE="HD3">4. Integrating Revised and New Certification Criteria Into the 2015 Edition Privacy and Security Certification Framework</HD>
                    <P>We proposed to require the new certification criteria (§ 170.315(d)(12) and (d)(13)) to apply to all § 170.315 certification criteria (84 FR 7454). Therefore, given these and the other modifications discussed above, we proposed to revise the P&amp;S Certification Framework as shown in Table 1 of the Proposed Rule (84 FR 7455), noting that the P&amp;S Certification Framework when finalized could differ depending on finalization of proposals in section III.B.4 of the Proposed Rule (84 FR 7436 and 7437) to remove certain 2015 Edition certification criteria.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed support of the proposals under section V (“Modifications of the ONC Health IT Certification Program”) of the Proposed Rule as a whole. However, we received no comments specific to this proposal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their input regarding our proposals under section V (“Modifications of the ONC Health IT Certification Program”) of the Proposed Rule. We have adopted the revisions as proposed with modifications. As noted in section IV.B.8.a, we have also adopted both proposed privacy and security transparency attestation criteria (§ 170.315(d)(12) and (d)(13)) with minor modifications. We have applied § 170.315(d)(12) and (d)(13) to all certification criteria across the P&amp;S Certification Framework. Table 2 shows the final updated P&amp;S Certification Framework, which includes all changes including the removal of certain 2015 Edition certification criteria as finalized in section III.B.4 of this final rule. We updated the P&amp;S Certification Framework to reflect other changes made throughout this final rule. The privacy and security certification criteria applicable to a Health IT Module presented for certification is based on the other capabilities included in the Health IT Module and for which certification is sought (80 FR 62705). In this final rule, we have determined that 
                        <PRTPAGE P="25710"/>
                        § 170.315(b)(10) and, consistent with the rationale provided in the 2015 Edition final rule, (g)(1) through (6) are exempt from the P&amp;S Certification Framework due to the capabilities included in these criteria, which do not implicate privacy and security concerns (80 FR 62707). We have revised § 170.550(h) of this final rule to reflect these clarifications. We also corrected Table 2 to accurately reflect the regulatory text at § 170.315(a)(3), (a)(14), and (a)(15). Sections 170.315(a)(3), (a)(14), and (a)(15), though included in the regulatory text, were erroneously deleted in the Proposed 2015 Edition Privacy and Security Certification Framework table and we corrected it in Table 2.
                    </P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s90,r125,r125">
                        <TTITLE>Table 2—2015 Edition Privacy and Security Certification Framework</TTITLE>
                        <BOXHD>
                            <CHED H="1">
                                If the Health IT Module includes 
                                <LI>capabilities for certification listed under:</LI>
                            </CHED>
                            <CHED H="1">It will need to be certified to approach 1 or approach 2 for each of the P&amp;S certification criteria listed in the “approach 1” column</CHED>
                            <CHED H="2">Approach 1</CHED>
                            <CHED H="2">Approach 2</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">§ 170.315(a)(1) through (3), (5), (12), (14), and (15)</ENT>
                            <ENT>§ 170.315(d)(1) (authentication, access control, and authorization), (d)(2) (auditable events and tamper resistance), (d)(3) (audit reports), (d)(4) (amendments), (d)(5) (automatic log-off), (d)(6) (emergency access), (d)(7) (end-user device encryption) (d)(12) (encrypt authentication credentials) (d)(13) (multi-factor authentication)</ENT>
                            <ENT>For each applicable P&amp;S certification criterion not certified using Approach 1, the health IT developer submits system documentation that is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces for each applicable P&amp;S certification criterion that enable the Health IT Module to access external services necessary to meet the requirements of the P&amp;S certification criterion.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(a)(4), (9), (10), and (13)</ENT>
                            <ENT>§ 170.315(d)(1) through (d)(3), (d)(5) through (d)(7), (d)(12), and (d)(13)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(b)(1) through (3) and (6) through (9)</ENT>
                            <ENT>§ 170.315(d)(1) through (d)(3), (d)(5) through (d)(8) (integrity), (d)(12), and (d)(13)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(c)</ENT>
                            <ENT>§ 170.315(d)(1) through (d)(3) and (d)(5), (d)(12), and (d)(13) *</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(e)(1)</ENT>
                            <ENT>§ 170.315(d)(1) through (d)(3), (d)(5), (d)(7), (d)(9) (trusted connection), (d)(12), and (d)(13)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(e)(2) and (3)</ENT>
                            <ENT>§ 170.315(d)(1) through (d)(3), (d)(5), (d)(9), (d)(12), and (d)(13) *</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(f)</ENT>
                            <ENT>§ 170.315(d)(1) through (d)(3), (d)(7), (d)(12), and (d)(13)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(g)(7) through (g)(10)</ENT>
                            <ENT>§ 170.315(d)(1) and (d)(9); (d)(2) or (d)(10) (auditing actions on health information), (d)(12), and (d)(13)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(h)</ENT>
                            <ENT>§ 170.315(d)(1) through (d)(3), (d)(12), and (d)(13) *</ENT>
                        </ROW>
                        <TNOTE>
                            An ONC-ACB must ensure that a Health IT Module presented for certification to any of the certification criteria that fall into each regulatory text “first level paragraph” category of § 170.315 (
                            <E T="03">e.g.,</E>
                             § 170.315(a)) identified in Table 2 is certified to either Approach 1 (technically demonstrate) or Approach 2 (system documentation).
                        </TNOTE>
                        <TNOTE>In order to be issued a certification, a Health IT Module would only need to be tested once to each applicable privacy and security criterion identified as part of Approach 1 or Approach 2 so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification, except for the certification of a Health IT Module to § 170.315(e)(1) “view, download, and transmit to 3rd party.” For this criterion, a Health IT Module must be separately tested to § 170.315(d)(9) because of the specific capabilities for secure electronic transmission included in the criterion.</TNOTE>
                        <TNOTE>* § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not include end-user device encryption features.</TNOTE>
                    </GPOTABLE>
                    <HD SOURCE="HD2">B. Principles of Proper Conduct for ONC-ACBs</HD>
                    <HD SOURCE="HD3">1. Records Retention</HD>
                    <P>We proposed to revise the records retention requirement in §  170.523(g) to include the “life of the edition” as well as three years after the retirement of an edition related to the certification of Complete EHRs and Health IT Modules (84 FR 7456). We also proposed to clarify that HHS has the ability to access certification records for the “life of the edition,” which begins with the codification of an edition of certification criteria in the Code of Federal Regulations through a minimum of three years from the effective date of the final rule that removes the applicable edition from the Code of Federal Regulations (CFR), not solely during the three-year period after removal from the CFR (84 FR 7456).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed support for ONC's proposal to revise the records retention requirement. Another commenter requested that ONC provide a separate posting or notice that lists the dates specific to when the “life of the edition” starts and dates specific to when the “life of the edition” and the minimum period of three years from the effective date that removes the applicable edition end.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input and have finalized this revision as proposed. Because the “life of the edition” begins with the codification of an edition of certification criteria in the CFR and ends on the effective date of the final rule that removes the applicable edition from the CFR, the start and end dates for the “life of the edition” are published in the 
                        <E T="04">Federal Register</E>
                         in the rulemaking actions that finalize them. The period of three years beyond the “life of the edition” begins on the effective date of the final rule that removes the applicable edition from the CFR, thus the three-year period after removal from the CFR continues through three full calendar years following that date. For example, if the effective date of a hypothetical final rule removing an edition from the CFR were July 1, 2025, then the three year period following the end of the life of this hypothetical edition would be June 30, 2028. We anticipate continuing to work with ONC-ACBs to provide guidance and information resources as necessary or appropriate to promote successful adherence to all Principles of Proper 
                        <PRTPAGE P="25711"/>
                        Conduct (PoPC) applicable to their participation in the Program.
                    </P>
                    <HD SOURCE="HD3">2. Conformance Methods for Certification Criteria</HD>
                    <P>The PoPC in § 170.523(h) specified that ONC-ACBs may only certify health IT that has been tested by ONC-ATLs using tools and test procedures approved by the National Coordinator. We proposed to revise the PoPC in § 170.523(h) in three ways (84 FR 7456).</P>
                    <P>First, we proposed to revise this PoPC to additionally permit ONC-ACBs to certify Health IT Modules that the ONC-ACB has evaluated for conformance with certification criteria without first passing through an ONC-ATL. However, we proposed that such methods to determine conformity must first be approved by the National Coordinator.</P>
                    <P>
                        Second, we proposed to revise the PoPC to clarify that certifications can only be issued to Health IT Modules and not Complete EHRs. We proposed to remove the 2014 Edition from the CFR (
                        <E T="03">see</E>
                         section III.B.2 of this preamble) and Complete EHR certifications are no longer available for certification to the 2015 Edition (80 FR 62608; 79 FR 54443). We also proposed to remove the provision that permits the use of test results from National Voluntary Laboratory Accreditation Program (NVLAP)-accredited testing laboratories under the Program because the regulatory transition period from NVLAP-accredited testing laboratories to ONC-ATLs has expired (81 FR 72447).
                    </P>
                    <P>Third, we proposed to remove the provision that permits the certification of health IT previously certified to an edition if the certification criterion or criteria to which the Health IT Module(s) was previously certified have not been revised and no new certification criteria are applicable because the circumstances that this provision seeks to address are no longer feasible with certification to the 2015 Edition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter sought clarification on whether the proposal to remove references to § 170.545, which includes the ability to maintain Complete EHR certification, would impact § 170.550(k), which requires ONC-ACBs to accept requests for a newer version of a previously certified Health IT Module(s) to inherit the certified status of the previously certified Health IT Module(s) without requiring the newer version to be recertified. The commenter strongly urged ONC to allow ONC-ACBs to grant inherited certification status to updated versions of certified technology. Another commenter expressed support for ONC's proposal to revise the PoPC to clarify that certifications can only be issued to Health IT Modules and not Complete EHRs. The commenter also expressed support for ONC's proposal to remove the provision that permits the certification of health IT previously certified to an edition if the certification criterion or criteria to which the Health IT Module(s) was previously certified have not been revised and no new certification criteria are applicable because the circumstances that this provision seeks to address are no longer feasible with certification to the 2015 Edition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the proposal to revise the PoPC in § 170.523(h). As noted in the Proposed Rule, the ability to maintain Complete EHR certification is only permitted with health IT certified to the 2014 Edition certification criteria (84 FR 7435). Because this concept was not continued in the 2015 Edition (84 FR 7456), we proposed revisions to clarify that Complete EHR certifications are no longer available. We note that ONC-ACBs have discretion, and processes in place, to evaluate updates made to certified health IT and assess the need for additional testing. These ONC-ACB processes allow for efficient certification of upgraded version releases of previously certified health IT while ensuring its continued conformity with certification criteria and standards to which the prior version release of the same Module(s) had been certified. We have finalized this proposal.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Multiple commenters expressed support for the use of conformance methods approved by the National Coordinator. One commenter noted that the opportunity would enable alternative testing methods and less costly testing. Another commenter noted that this proposal would reduce burden for EHR developers and for ONC-ATLs by leveraging certification programs and alternative test methods and specifically requested that ONC consider a specific proprietary certification related to e-prescribing functionalities for potential approval. While expressing appreciation for the flexibility offered by the proposed revision, one commenter expressed concern about certifications based on other ONC-approved conformance methods that are not specifically designed to test against the ONC criteria and stressed the importance of assessing conformance to technical standards before being deployed to end users. Another commenter questioned whether the ONC-ACB would be permitted to do all evaluation directly, thus eliminating the need for ONC-ATLs entirely. Two commenters sought clarity from ONC as to what metrics the National Coordinator will use to approve a conformance method. These commenters also sought clarification on ONC's plan to reduce the risk of developers seeking certification through fraudulent means. The commenters cited the example of two developers who are currently operating under corporate integrity agreements with the HHS Office of the Inspector General due to court cases brought against them in relation to conduct including, but not limited to, the process of seeking certification.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We have finalized the proposal to revise the PoPC in §  170.523(h) to permit a certification decision to be based on an evaluation conducted by the ONC-ACB for Health IT Modules' compliance with certification criteria by use of conformity methods approved by the National Coordinator.
                    </P>
                    <P>
                        We note that all certification criteria will continue to have some method of holding developers responsible for demonstrating conformity whether through ONC-ATL testing, developer self-declaration, or some other method assessed and approved by the National Coordinator. As noted in the Proposed Rule (84 FR 7456), ONC acknowledges that there is a broad spectrum of types of evidence of conformance, from laboratory testing with an ONC-ATL to developer self-declaration. Some of these types of evidence may be more appropriate than others in specific circumstances. Historically, it has been proven that, in some circumstances, the requirement for ONC-ATL testing has presented more administrative burden on health IT developers than benefits for assessing conformity. For example, under §  170.315(a)(5) demographics certification criteria require only documentation or a visual inspection, and do not require testing by an ONC-ATL. We note that industry advancements have presented opportunities for improved efficiency for demonstrating conformity and this flexibility will allow the Program to advance as the state of the art for demonstrating conformance evolves. This flexibility addresses the current Program construct limitation of ONC-ACB certification only being permissible for health IT that has been tested by an ONC-ATL with ONC-approved test procedures. In some instances, such as developer self-declaration, there is no testing required and thus bypassing the ONC-ATL testing step reduces burden and enables a more streamlined and 
                        <PRTPAGE P="25712"/>
                        efficient process. By adopting this flexibility, we may approve conformance methods that rely solely on ONC-ACB evaluation, and not ONC-ATL testing, when appropriate.
                    </P>
                    <P>
                        We will follow the same process used for alternative test methods (76 FR 1280) for the submission of non-governmental developed conformance methods to the National Coordinator for approval. A person or entity may submit a conformance method to the National Coordinator to be considered for approval for use under the Program. The submission should identify the developer of the conformance method; specify the certification criterion or criteria that is/are addressed by the conformance method; and explain how the conformance method would evaluate a Health IT Module's or, if applicable, other type of health IT's, compliance with the applicable certification criterion or criteria. The submission should also provide information describing the process used to develop the conformance method, including any opportunity for the public to comment on the conformance method and the degree to which public comments were considered. In determining whether to approve a conformance method for purposes of the Program, the National Coordinator will consider whether it is clearly traceable to a certification criterion or criteria adopted by the Secretary; whether it is sufficiently comprehensive (
                        <E T="03">i.e.,</E>
                         assesses all required capabilities) for the assessment of Health IT Modules', or other type of health IT's, conformance to the certification criterion or criteria adopted by the Secretary; whether an appropriate public comment process was used during the development of the conformance method; and any other relevant factors. When the National Coordinator has approved a conformance method for purposes of the Program, we will publish a notice of availability in the 
                        <E T="04">Federal Register</E>
                         and identify the approved conformance method on the ONC website.
                    </P>
                    <HD SOURCE="HD3">3. ONC-ACBs To Accept Test Results From Any ONC-ATL in Good Standing</HD>
                    <P>We proposed to add the PoPC for ONC-ACBs in § 170.523(r) in order to address business relationships between ONC-ACBs and ONC-ATLs (84 FR 7456). To encourage market competition, we proposed to require ONC-ACBs to accept test results from any ONC-ATL that is in good standing under the Program and is compliant with its ISO/IEC 17025 accreditation requirements. However, if an ONC-ACB has concerns about accepting test results from a certain ONC-ATL, the ONC-ACB would have an opportunity to explain the potential issues to ONC and NVLAP, and on a case-by-case basis, ONC could consider the facts and make the final determination.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Multiple commenters expressed support for the proposed requirement that ONC-ACBs must accept test results from any ONC-ATL in good standing. One commenter expressed an opinion that this proposal has value in ensuring the credibility of the Program. Another commenter agreed that this proposal would encourage market competition and provide more options to developers. One commenter recommended that ONC-ATLs should also be required to provide their results to any ONC-ACB to which the developer has chosen to present its health IT for certification, stating that this consistency across ONC-ACBs and ONC-ATLs would ensure market competition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We have finalized the PoPC for ONC-ACBs in § 170.523(r) as proposed. While an ONC-ATL attempting to inappropriately restrict developers' choice of ONC-ACBs to those favored by the ONC-ATL would not support appropriate competition, we do not believe it would be practical to mandate direct transmission of ONC-ATL results to any ONC-ACB designated by the developer, in part because developers often do not initiate engagement with an ONC-ACB until after they have received and had a chance to review their ONC-ATL results. To date, we are not aware of substantial evidence that the standard practice of NVLAP-accredited testing laboratories providing test results to the client who engaged them to test their Health IT Modules is not serving as a sufficient safeguard against anti-competitive behavior on the part of ONC-ATLs in relation to their client developers' selection of ONC-ACBs.
                    </P>
                    <HD SOURCE="HD3">4. Mandatory Disclosures and Certifications</HD>
                    <P>We proposed to revise the PoPC in § 170.523(k) to remove § 170.523(k)(1)(ii)(B) because certifications can only be issued to Health IT Modules and not Complete EHRs (84 FR 7456). We also proposed to revise § 170.523(k)(1)(iii)(A) to broaden the section beyond the Promoting Interoperability (PI) Programs. We proposed to revise the section to include a detailed description of all known material information concerning additional types of costs or fees that a user may be required to pay to implement or use the Health IT Module's capabilities, whether to meet provisions of HHS programs requiring the use of certified health IT or to achieve any other use within the scope of the health IT's certification.</P>
                    <P>We also proposed to remove the provision in § 170.523(k)(3) that requires a certification issued to a pre-coordinated, integrated bundle of Health IT Modules to be treated the same as a certification issued to a Complete EHR for the purposes of § 170.523(k)(1), except that the certification must also indicate each Health IT Module that is included in the bundle (84 FR 7457).</P>
                    <P>We proposed to revise § 170.523(k)(4) to clarify that a certification issued to a Health IT Module based solely on the applicable certification criteria adopted by the ONC Health IT Certification Program must be separate and distinct from any other certification(s) based on other criteria or requirements (84 FR 7457).</P>
                    <P>We also proposed changes related to transparency attestations and disclosures of limitations in section III.B.5 of the Proposed Rule preamble (84 FR 7437 and 7438). Additionally, we proposed other new PoPC for ONC-ACBs as discussed in sections VII.B.5 (84 FR 7501) and VII.D (84 FR 7506 and 7507) of the Proposed Rule preamble.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Multiple commenters expressed support for ONC's proposal to include a detailed description of all known material information concerning additional types of costs or fees that a user may be required to pay to implement or use the Health IT Module's capabilities—whether to meet provisions of HHS programs requiring the use of certified health IT or to achieve any other use within the scope of the health IT's certification. One commenter endorsed the transparency that this proposal would provide, noting that it would help providers budget for their health IT, but also expressed concern that requiring developers to disclose how much they charge for a particular functionality may be impractical due to variations across contracts and over time, or potentially have unintended consequences on market pricing. Multiple commenters expressed support for our proposal to remove subsection § 170.523(k)(1)(ii)(B). One commenter expressed support for ONC's proposed revisions to § 170.523(k)(4). Another commenter was supportive of the proposal to remove the provision in § 170.523(k)(3).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We have finalized the proposals, in their entirety, as proposed. To clarify, the finalized revision in § 170.523(k) requires disclosure of a detailed description of all known material information concerning 
                        <PRTPAGE P="25713"/>
                        additional 
                        <E T="03">types</E>
                         of costs or fees a user may be required to incur or pay to implement or use the Health IT Module's capabilities to achieve any use within the scope of the health IT's certification. We emphasize that (unless required elsewhere in CFR part 170) the requirement is for a description of the 
                        <E T="03">types</E>
                         of costs or fees, not predicted 
                        <E T="03">amounts</E>
                         of these costs or fees across the full array of probable implementation circumstances or over time. Among other considerations, we note that costs required to achieve some particular uses within the scope of some certifications may be for third-party services outside the control of the developer required to disclose the detailed description.
                    </P>
                    <HD SOURCE="HD2">C. Principles of Proper Conduct for ONC-ATLs—Records Retention</HD>
                    <P>We proposed to revise the records retention requirement in §  170.524(f) to include the “life of the edition” as well as 3 years after the retirement of an edition related to the testing of Health IT Module(s) to an edition of certification criteria (84 FR 7457). The circumstances are the same as in section V.B.1 of the Proposed Rule preamble, as summarized above. Therefore, we proposed the same revisions for ONC-ATLs as we did for ONC-ACBs. We did not receive any comments specific to this proposed revision to the PoPC for ONC-ATLs. In light of the absence of comments, we have finalized the revisions as proposed.</P>
                    <HD SOURCE="HD1">VI. Health IT for the Care Continuum</HD>
                    <P>Health IT should help promote and support patient care when and where it is needed. This means health IT should help support patient populations, specialized care, transitions of care, and practice settings across the care continuum. In the Proposed Rule, we provided a history of the many actions we have taken since the inception of the ONC Health IT Certification Program through the Proposed Rule (84 FR 7457). As stated in the Proposed Rule, section 4001(b)(i) of the Cures Act instructs the National Coordinator to encourage, keep, or recognize, through existing authorities, the voluntary certification of health IT under the Program for use in medical specialties and sites of service for which no such technology is available or where more technological advancement or integration is needed. This provision of the Cures Act closely aligns with our ongoing collaborative efforts with both Federal partners and stakeholders within the health care and health IT community to encourage and support the advancement of health IT for a wide range of clinical settings. These initiatives have included projects related to clinical priorities beyond those specifically included in the EHR Incentive Programs (now called the Promoting Interoperability Programs) including efforts in public health, behavioral health, and long-term and post-acute care. We noted in the Proposed Rule that these initiatives often include the development of non-regulatory informational resources to support the specific implementation goal and align with the technical specifications already available in the Program for certification. To advance these efforts, we also explained in the Proposed Rule that we generally consider a range of factors including: Stakeholder input and identification of clinical needs and clinical priorities, the evolution and adoption of health IT across the care continuum, the costs and benefits associated with any policy or implementation strategy related to care settings and sites of service, and potential regulatory burden and compliance timelines. Our goal was then and is now to support the advancement of interoperable health IT and to promote health IT functionality in care and practice settings across the care continuum (see 80 FR 62604). As stated in the Proposed Rule (84 FR 7458), generally, our approach can be summarized in three parts:</P>
                    <P>• First, we analyze existing certification criteria to identify how such criteria may be applicable for medical specialties and sites of service.</P>
                    <P>
                        • Second, we focus on the real-time evaluation of existing and emerging standards to determine applicability to medical specialties and sites of service as well as to the broader care continuum, including the evaluation of such standards for inclusion in the ONC Interoperability Standards Advisory (ISA).
                        <SU>68</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>68</SU>
                             
                            <E T="03">https://www.healthit.gov/isa/</E>
                            .
                        </P>
                    </FTNT>
                    <P>• Third, we may work in collaboration with stakeholders to support the development of informational resources for medical specialties and sites of service for which we identify a need to advance the effective implementation of certified health IT.</P>
                    <P>We continue to believe this approach is economical, flexible, and responsive for both health care providers and the health IT industry. It is also in alignment with the provisions of section 4001(a) in the Cures Act related to burden reduction and promoting interoperability. We are committed to continuing to work with stakeholders to promote the adoption of health IT to support medical specialties and sites of service and to help ensure that providers have the tools they need (such as access to essential health information across care settings) to support patients at the point of care.</P>
                    <HD SOURCE="HD2">A. Health IT for Pediatric Setting</HD>
                    <P>Section 4001(b)(iii) of the Cures Act—“Health information technology for pediatrics” requires:</P>
                    <P>• First, that the Secretary, in consultation with relevant stakeholders, shall make recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children, and</P>
                    <P>• Second, that the Secretary shall adopt certification criteria to support the voluntary certification of health IT for use by pediatric health providers to support the health care of children.</P>
                    <P>In the Proposed Rule (84 FR 7458), we described our approach to stakeholder engagement, the analysis used to develop the recommendations, the specific 2015 Edition certification criteria that support each recommendation, and the voluntary certification of health IT for use by pediatric health providers to support the health care of children.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments requesting further clarification on whether the pediatric health IT recommendations will be adopted as an independent certification program and/or certification criteria designated specifically for pediatric care. One commenter recommended that pediatric provisions should be formalized over time within what they refer to as the current pediatric program and not as a separate program, and that this future aligns with the 2015 Children's EHR Format. One commenter also sought clarification as whether ONC intends for other government agencies/programs such as CHIP, to develop conditions of participation or financial incentives around the adoption of certification criteria identified in this rulemaking. We also received several comments stating that since current EHRs have pediatric capabilities, there is no need to specify requirements in regulation, and that there is no value in having EHRs certified as “pediatric-friendly,” only increased costs. We also received several comments stating that our approach reflects an attempt to retrofit the needs of pediatric patients by using adult requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. The comments we received suggests a need for greater clarity on our approach. We therefore reiterate that we did not propose to adopt care- or practice-specific certification tracks, or additional 
                        <PRTPAGE P="25714"/>
                        voluntary program(s), in parallel to the existing voluntary ONC Health IT Certification Program. In the Proposed Rule, we reiterated our statements from the 2015 Edition final rule, which explained that we did not intend to develop and issue separate regulatory certification “paths” or “tracks” for particular care or practice settings (
                        <E T="03">e.g.,</E>
                         a “long-term and post-acute care (LTPAC) certification”) because it would be difficult to 
                        <E T="03">independently</E>
                         construct such “paths” or “tracks” in a manner that would align with other relevant programs and specific stakeholder needs. We further stated that stakeholders had indicated that separate certification pathways could have unintended consequences related to increasing burden on health care providers and health IT developers. We also stated that we would welcome the opportunity to work with HHS agencies, other agencies, and provider associations in identifying the appropriate functionality and certification criteria in the Program to support their stakeholders (80 FR 62704). In response to the comments regarding our approach to implement section 4001(b) of the Cures Act, we clarify that the 2015 Edition certification criteria identified for the voluntary certification of health IT for use by pediatric health providers are agnostic to the age of the patient (with the exception of the pediatric vital signs in the USCDI). Therefore, we believe our approach to fulfilling the Cures Act requirement for pediatric health care providers and settings, which involves identifying existing, new, or revised 2015 Edition criteria—as applicable to an identified clinical or interoperability priority—is appropriate across patient populations. We also note that our authority is limited to implementing the described requirements of the Cures Act related to pediatric settings. We cannot speak for the actions of other Federal agencies, but would note once again that we have taken a limited regulatory approach to implementing the pediatric provisions of the Cures Act.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received multiple comments requesting clarification on the intended use and functionality of the Certified Health IT Products List (CHPL) for pediatric certification, such as guidance on navigating the CHPL to identify relevant products based on pediatric care settings.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank stakeholders for their comments on the CHPL. We do not intend to have a separate tag functionality on the CHPL that identifies a product specifically for pediatric care. We did not propose, and do not intend, for there to be a separate certification pathway or a new ONC certification designation called pediatric certification. However, we recognize that beyond certification and testing there are certain implementation needs that are important for pediatric care and services. We agree with the overwhelming prior feedback from stakeholders stating that they should not have to purchase separate products that contain universally applicable functionality, such as the “API functionality” certification criteria. We are exploring options for non-regulatory informational resources on effective implementation of health IT for use by pediatric health providers to expand the availability of health IT products supporting the care of children.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments regarding how the approach for voluntary certification of health IT for use by pediatric health providers might be applicable to other medical specialties and use cases. One commenter noted that the pediatric experience is scalable and should be extended to other disciplines. Another commenter sought clarification if this model could be used for broad applicability to multiple medical specialties such as pathologists.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank these commenters for identifying the applicability of our approach to pediatrics to other medical specialties. We confirm that our approach for advancing health IT can be used for other use cases and medical specialties, and welcome the opportunity to engage with stakeholders representing a wide range of medical specialties or sites of service to provide insight into this process and to inform stakeholder-led efforts to improve clinically-relevant health IT implementation across specialties and settings of care.
                    </P>
                    <HD SOURCE="HD3">1. Background and Stakeholder Convening</HD>
                    <P>
                        Over the past ten years, a number of initiatives have focused on the availability and use of effective health IT tools and resources for pediatric care. These have included a number of public-private partnerships including efforts between HHS, State agencies, and health systems for innovative projects that range from care coordination enterprise solutions to immunization information systems and to point of care solutions for specialty needs. In order to learn from and build upon these efforts, ONC has engaged with stakeholders in both the public and private sector including other Federal, State and local government partners, health care providers engaged in the care of children, standards developing organizations, charitable foundations engaged in children's health care research, and health IT developers supporting pediatric care settings. For example, significant work has been done by the Agency for Healthcare Research and Quality (AHRQ), CMS, the Health Resources and Services Administration (HRSA), and organizations around the Children's EHR Format (Children's Format), which is critical to any discussion of the pediatric health IT landscape.
                        <SU>69</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>69</SU>
                             Agency for Health Care Information and Technology. Health Information Technology. 
                            <E T="03">http://healthit.ahrq.gov/health-it-tools-and-resources/childrens-electronic-health-record-ehr-format</E>
                            . Accessed September, 2017.
                        </P>
                    </FTNT>
                    <P>
                        The Children's Format was authorized by the 2009 Children's Health Insurance Program Reauthorization Act (CHIPRA) 
                        <SU>70</SU>
                        <FTREF/>
                         and developed by AHRQ in close collaboration with CMS. It was developed to bridge the gap between the functionality present in most EHRs currently available and the functionality that could optimally support the care of children. Specifically, the Children's Format provides information to EHR system developers and others about critical functionality and other requirements that are helpful to include in an EHR system to address health care needs specific to the care of children. The final version of the Children's Format, released in 2015, consists of 47 high priority functional requirements in 19 topic areas that focus on improvements that would better support the safety and quality of care delivered to children. The Children's Format was intended as a starting point for developers, users, and purchasers for informing an approach for pediatric voluntary certification. We refer to the Voluntary Edition proposed rule for a description of our prior discussion around the Children's Format (79 FR 10930).
                    </P>
                    <FTNT>
                        <P>
                            <SU>70</SU>
                             Pub. L. 111-3, section 401 
                            <E T="03">https://healthit.ahrq.gov/sites/default/files/docs/citation/children-ehr-format-enhancement-final-recommendation-report-abridged.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        In the summer of 2017, the American Academy of Pediatrics (AAP) reviewed the 2015 Children's Format using a robust analytical process and engagement with their members. The result was a prioritized list of eight clinical priorities to support pediatric health care (“Priority List”). In October 2017, we held a technical discussion with stakeholders titled “Health IT for Pediatrics” with the specific purpose of obtaining input from an array of stakeholders in an effort to draw correlations between the pediatric providers' clinical priorities identified in the Priority List with the detailed 
                        <PRTPAGE P="25715"/>
                        technical requirements outlined in the Children's Format and the capabilities and standards that could be included in certified health IT. Through this collaborative approach, the meeting participants identified a set of priority needs for health IT to support pediatric care based upon those identified by the Priority List and the primary correlation to the Children's Format.
                    </P>
                    <HD SOURCE="HD3">2. Recommendations for the Voluntary Certification of Health IT for Use in Pediatric Care</HD>
                    <P>To support the first part of section 4001(b) of the Cures Act, we considered the historical efforts on the Children's Format, the input from stakeholders, and our own technical analysis and review of health IT capabilities and standards to develop a set of recommendations for voluntary certification of health information technology for use by pediatric health providers to support the health care of children. These include eight recommendations related to the Priority List:</P>
                    <P>• Recommendation 1: Use biometric-specific norms for growth curves and support growth charts for children</P>
                    <P>• Recommendation 2: Compute weight-based drug dosage</P>
                    <P>• Recommendation 3: Ability to document all guardians and caregivers</P>
                    <P>• Recommendation 4: Segmented access to information</P>
                    <P>• Recommendation 5: Synchronize immunization histories with registries</P>
                    <P>• Recommendation 6: Age- and weight- specific single-dose range checking</P>
                    <P>• Recommendation 7: Transferrable access authority</P>
                    <P>• Recommendation 8: Associate maternal health information and demographics with newborn</P>
                    <P>We also developed two additional recommendations beyond the Priority List, which relate to other items within the Children's Format that are considered important to pediatric stakeholders. These additional recommendations, which may be supported by certified health IT, are as follows:</P>
                    <P>• Recommendation 9: Track incomplete preventative care opportunities</P>
                    <P>• Recommendation 10: Flag special health care needs</P>
                    <P>In order to implement the second part of section 4001(b) of the Cures Act for the adoption of certification criteria to support the voluntary certification of health IT for use by pediatric health care providers, we identified both the 2015 Edition certification criteria and the new or revised certification criteria proposed in the Proposed Rule that support the 10 recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children. In the Proposed Rule (84 FR 7459), we directed readers to the appendix of the Proposed Rule for a set of technical worksheets, which include a crosswalk of the various criteria specifically associated with each recommendation. These worksheets outlined the following information:</P>
                    <P>
                        • The alignment of each recommendation to the primary Children's Format 
                        <SU>71</SU>
                        <FTREF/>
                         item identified by stakeholders
                    </P>
                    <FTNT>
                        <P>
                            <SU>71</SU>
                             
                            <E T="03">http://healthit.ahrq.gov/health-it-tools-and-resources/childrens-electronic-health-record-ehr-format</E>
                            .
                        </P>
                    </FTNT>
                    <P>• The alignment of each recommendation to the 2015 Edition certification criteria and the new or revised criteria described in the Proposed Rule</P>
                    <P>• Supplemental items from the Children's Format for each recommendation and the related 2015 Edition certification criteria</P>
                    <P>We also sought comment on the following:</P>
                    <P>1. Relevant gaps, barriers, safety concerns, and resources (including available best practices, activities, and tools) that may impact or support feasibility of the recommendation in practice.</P>
                    <P>2. Effective use of health IT itself in support of each recommendation as it relates to provider training, establishing workflows, and other related safety and usability considerations.</P>
                    <P>3. If any of the 10 recommendations should not be included in ONC's final recommendations for voluntary certification of health IT for use by pediatric health providers to support the health care of children.</P>
                    <P>4. Any certification criteria from the Program that is identified for the 10 recommendations that should not be included to support the specific recommendation.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments asking for detailed guidance and/or implementation specifications post final rulemaking, with one commenter noting that the majority of recommendations require additional capabilities beyond the scope of any aligned existing or proposed certification criteria. We also received many comments providing implementation recommendations specific to the 10 ONC recommendations for the voluntary certification of health IT for use by pediatric health providers such as adding in developmental activity milestones, including what versions of growth charts should be supported, and including listings to clearly identify medical home providers. Several commenters also referenced concerns regarding the feasibility of implementing the content included as part of the pediatric health IT technical worksheet crosswalk analysis included in the Proposed Rule appendix for Recommendation 5 “Synchronize immunization histories with registries.” In this regard, several commenters noted that FHIR is not currently consistent with CDC/AIRA standards or practices for immunization data submission or query/response, and that public health is not currently funded to provide this capability from IIS.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their useful input regarding the technical worksheets in the appendix we included for the Proposed Rule. As we stated in the Proposed Rule, these comments, and the detailed insights received through stakeholder outreach, will inform the future development of a non-binding informational guide or informational resource to provide useful information for health IT developers and pediatric care providers seeking to successfully implement these health IT solutions in a clinical setting. To facilitate adoption of the ten recommendations, we are developing a Pediatric Health IT Developer Informational Resource and a Pediatric Health IT Provider Informational Resource to be available for respective use in 2020. As such, we appreciate the comments we received specific to implementation recommendations and will take them into account in the support of the creation of non-regulatory informational resources for health IT developers and other stakeholders. We plan to continue working with stakeholders as we further develop and consider technical and implementation recommendations we have received through solicited public comments, the Health Information Technology Advisory Committee (HITAC), and other engagements. We also direct readers to our “pediatrics health IT” web page (
                        <E T="03">www.healthIT.gov/pediatrics</E>
                        ) for information on future work pertaining to health IT for pediatric care.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments suggesting the use of pediatric-focused clinicians and settings to test EHR systems as part of these provisions, specifically recommending that we should require EHR developers to use pediatric-focused scenarios and mock pediatric patients when testing functionality, as well as requiring the 
                        <PRTPAGE P="25716"/>
                        inclusion of pediatric clinicians as part of end-user testing.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We agree that it would be beneficial for health IT developers to include pediatric-focused testing of their health IT especially with regards to ensuring patient safety. We note that we have established requirements for real world testing that requires health IT developers to real world test their health IT for the types of setting(s) in which it is intended for use (we refer readers to section VII.B.5 for more information on real world testing Condition and Maintenance of Certification requirements).
                    </P>
                    <HD SOURCE="HD3">a. 2015 Edition Certification Criteria</HD>
                    <P>In order to implement the second part of section 4001(b) of the Cures Act to adopt certification criteria to support the voluntary certification of health IT for use by pediatric health providers to support the health care of children, we identified the following already adopted 2015 Edition certification criteria in the Proposed Rule that support the recommendations. The already adopted 2015 Edition criteria are as follows:</P>
                    <P>• “API functionality” criteria (§ 170.315(g)(7)-(g)(9)) which address many of the challenges currently faced by patients and by caregivers such as parents or guardians accessing child's health information, including the “multiple portal” problem, by potentially allowing individuals to aggregate health information from multiple sources in a web or mobile application of their choice.</P>
                    <P>• “Care plan” criterion (§ 170.315(b)(9)) which supports pediatric care by facilitating the documentation of electronic health information in a structured format to improve care coordination (80 FR 62648 and 62649).</P>
                    <P>• “Clinical decision support” (CDS) criterion (§ 170.315(a)(9)) which supports pediatric care by enabling interventions based on the capture of biometric data.</P>
                    <P>
                        • “Common Clinical Data Set” (§ 170.315(b)(4) and § 170.315(b)(5)) which includes 
                        <E T="03">optional</E>
                         pediatric vital sign data elements including as optional the reference range/growth curve for three pediatric vital signs—BMI percent per LOINC identifiers for age per sex, weight per length/sex, and head occipital-frontal circumference for children less than three years of age.
                    </P>
                    <P>• “Data segmentation for privacy” send criterion and receive criterion (§ 170.315(b)(7) and § 170.315(b)(8)) which provides the ability to: Create a summary record that is tagged at the document level as restricted and subject to re-disclosure; receive a summary record that is document-level tagged as restricted; separate the document-level tagged document from other documents received; and view the restricted document without having to incorporate any of the data from the document.</P>
                    <P>• “Demographics” criterion (§ 170.315(a)(5)) which supports pediatric care through the capture of values and value sets relevant for the pediatric health care setting as well as allowing for improved patient matching which is a key challenge for pediatric care.</P>
                    <P>
                        • “Electronic Prescribing” criterion (§ 170.315(b)(3)) which includes an 
                        <E T="03">optional</E>
                         Structured and Codified Sig Format, which has the capability to exchange weight-based dosing calculations within the NCPDP SCRIPT 10.6 standard and limits the ability to prescribe all oral, liquid medications in only metric standard units of mL (
                        <E T="03">i.e.,</E>
                         not cc) important for enabling safe prescribing practices for children.
                    </P>
                    <P>• “Family health history” criterion (§ 170.315(a)(12)) which supports pediatric care because it leverages concepts or expressions for familial conditions, which are especially clinically relevant when caring for children.</P>
                    <P>• “Patient health information capture” criterion (§ 170.315(e)(3)) which supports providers' ability to accept health information from a patient or authorized representative. This criterion could support pediatric care through documentation of decision-making authority of a patient representative.</P>
                    <P>• “Social, psychological, and behavioral data” criterion (§ 170.315(a)(15)) which supports integration of behavioral health data into a child's record across the care continuum by enabling a user to record, change, and access a patient's social, psychological, and behavioral data based using SNOMED CT® and LOINC® codes.</P>
                    <P>• “Transitions of care” criterion (§ 170.315(b)(1)) which supports structured transition of care summaries and referral summaries that help ensure the coordination and continuity of health care as children transfer between different clinicians at different health care organizations or different levels of care within the same health care organization.</P>
                    <P>• “Transmission to immunization registries” criterion (§ 170.315(f)(1)) which supports the safe and effective provision of child health care through immunizations and registry linkages. This criterion also provides the ability to request, access, and display the evaluated immunization history and forecast from an immunization registry for a patient. Immunization forecasting recommendations allow for providers to access the most complete and up-to-date information on a patient's immunization history to inform discussions about what vaccines a patient may need based on nationally recommended immunization recommendations (80 FR 62662 through 62664).</P>
                    <P>
                        • “View, download, and transmit to 3rd party” (VDT) criterion (§ 170.315(e)(1)) which supports transferrable access authority for the pediatric health care setting and provides the ability for patients (and their authorized representatives) 
                        <SU>72</SU>
                        <FTREF/>
                         to view, download, and transmit their health information to a 3rd party.
                    </P>
                    <FTNT>
                        <P>
                            <SU>72</SU>
                             The VDT criterion includes a “patient-authorized representative” concept that aligns with the use of the term under the EHR Incentive Program. A “patient-authorized representative” is defined as any individual to whom the patient has granted access to their health information (see also 77 FR 13720). However, consent is not needed for minors, for whom existing local, state, or Federal law grants their parents or guardians access (see also 77 FR 13720).
                        </P>
                    </FTNT>
                    <P>We noted in the Proposed Rule (84 FR 7460) that some of these criteria may be updated based on proposals contained in the Proposed Rule (see further discussion below on new or revised certification criteria); and stated that we continue to believe that prior to any such updates, technology that is currently available and certified to these 2015 Edition criteria can make a significant impact in supporting providers engaged in the health care of children. We invited readers to use the technical worksheets in the appendix of the Proposed Rule to inform their public comment on the recommendations, the inclusion of specific items from the Children's Format, and the identified 2015 Edition certification criteria as they relate specifically to use cases for pediatric care and sites of service.</P>
                    <HD SOURCE="HD3">b. New or Revised Certification Criteria</HD>
                    <P>In order to implement the second part of section 4001(b)(iii) of the Cures Act to adopt certification criteria to support the voluntary certification of health information technology for use by pediatric health providers to support the health care of children, we also identified new or revised 2015 Edition certification criteria (and standards) in the Proposed Rule (84 FR 7460) that support the recommendations. These proposed criteria and standards include:</P>
                    <P>
                        • New API criterion (§ 170.315(g)(10)) which would serve to implement the Cures Act requirement to permit health information to be accessed, exchanged, 
                        <PRTPAGE P="25717"/>
                        and used from APIs without special effort.
                    </P>
                    <P>• New “DS4P” criteria (two for C-CDA ((§ 170.315(b)(12)) and (§ 170.315(b)(13)) and one for FHIR (§ 170.315(g)(11))) that would support a more granular approach to privacy tagging data for health information exchange supported by either the C-CDA or FHIR-based exchange standards.</P>
                    <P>• New electronic prescribing certification criterion (§ 170.315(b)(11)), which would support improved patient safety and prescription accuracy, workflow efficiencies, and increased configurability of systems including functionality that could support pediatric medication management.</P>
                    <P>• USCDI (§ 170.213) and USCDI-based criteria which enables the inclusion of pediatric vital sign data elements, including the reference range/scale or growth curve for BMI percentile per age and sex, weight for age per length and sex, and head occipital-frontal circumference. Each of the new or revised certification criteria and standards are further described in other sections of this final rule, including all final actions related to the criteria (some of which are described below in the response to comments).</P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of comments received supported our recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children along with the alignment with the Children's Format and 2015 Edition certification criteria. Several commenters suggested that the 10 recommendations should only be the first step and encouraged future development of additional recommendations using the Children's Format. Commenters were also pleased with the 10 recommendations selected by ONC from the Children's Format stating that they represent a strong, positive step forward for improving EHRs used in the care of children. Many commenters stated that they support the continued alignment with the 2015 Edition recommendations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and feedback. As such, we have maintained the 10 recommendations for the voluntary certification of health IT for use by pediatric health providers to support the health care of children. We have finalized in this final rule the majority of the aligned proposed new 2015 Edition certification criteria that support the voluntary certification of health IT for use by pediatric health providers, with the exception of the proposed criterion for “consent management” in § 170.315(g)(11) since we did not finalize our proposal for the criterion in this final rule. The functionality of the proposed new “DS4P” criteria have been incorporated into the already adopted 2015 Edition DS4P criteria DS4P-send (§  170.315(b)(7)) and DS4P-receive (§  170.315(b)(8)) now referred to as “Security tags—Summary of Care- send” and “Security tags—Summary of Care—receive,” respectively. The functionality of the proposed new e-Rx criterion was also incorporated in the already adopted e-Rx criterion (§ 170.315(b)(3)). Last, we have removed the “Common Clinical Data Set” (§ 170.315(b)(4) and § 170.315(b)(5)) from the 2015 Edition in this final rule.
                    </P>
                    <P>We note that we are aware that the NCPDP SCRIPT Standard Version 2017071 Implementation Guide contains a number of requirements intended to improve accurate dosing and pediatric patient safety. One such requirement is the inclusion of the most recent patient height and weight in the Observation Segment on all new and renewal prescriptions sent from the prescriber to the pharmacy, along with the date associated with these measures, for all patients 18 years old and younger. We are also aware of the challenges that such a requirement may pose on specific providers and under certain circumstances where height and/or weight is not required or applicable for dosing of the product. We believe additional work must be done on refining this requirement, and will continue to monitor standards and industry advancements before proposing such a requirement. At this time, we recommend vital signs to be included in all electronic prescriptions for all patient populations when available and where applicable.</P>
                    <P>The 10 recommendations and the aligned 2015 Edition certification criteria support the health IT needs of pediatric care providers. We believe further support can be provided through non-regulatory informational resources. These resources can help inform technical and implementation specifications for health IT developers and products for use by pediatric health providers to support the health care of children. We also agree with commenters that the 10 recommendations are a first step and welcome input and collaboration from the health IT industry and health care providers to continue efforts to develop and build a health IT infrastructure supporting pediatric care and other specialty care and sites of service across the continuum.</P>
                    <HD SOURCE="HD2">B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information</HD>
                    <P>We identified a need to explore ways to advance health IT across the care continuum to support efforts to fight the opioid epidemic. For that purpose, in the Proposed Rule, we included a request for information (RFI) related to health IT and opioid use disorder prevention and treatment (84 FR 7461 through 7465). We received over 100 comments in responses to this RFI, which included recommendations from the HITAC. We appreciate the feedback and recommendations provided by commenters and the HITAC taskforce, respectively. We plan to share this feedback with appropriate Department partners.</P>
                    <HD SOURCE="HD1">VII. Conditions and Maintenance of Certification Requirements for Health IT Developers</HD>
                    <P>Section 4002 of the Cures Act modifies section 3001(c)(5) of the Public Health Service Act (PHSA) to require the Secretary of HHS, through notice and comment rulemaking, to establish Conditions and Maintenance of Certification requirements for the Program. Specifically, health IT developers or entities must adhere to certain Conditions and Maintenance of Certification requirements concerning information blocking; 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 under section 3009A(b) of the PHSA.</P>
                    <HD SOURCE="HD2">A. Implementation</HD>
                    <P>
                        To implement section 4002 of the Cures Act, we proposed an approach whereby the Conditions and Maintenance of Certification requirements express initial certification requirements for health IT developers and their certified Health IT Module(s) as well as ongoing maintenance requirements that must be met by both health IT developers and their certified Health IT Module(s) under the ONC Health IT Certification Program (Program). If these requirements are not met, the health IT developer may no longer be able to participate in the Program and/or its certified health IT may have its certification terminated. We proposed to implement each Condition of Certification requirement with further specificity as it applies to 
                        <PRTPAGE P="25718"/>
                        the Program. We also proposed to establish Maintenance of Certification requirements for certain Conditions of Certification requirements as standalone requirements. As we stated in the Proposed Rule, this approach would establish clear baseline technical and behavior Conditions of Certification requirements with evidence that the Conditions of Certification requirements are continually being met through the Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments expressing general support for the concept of requiring Conditions and Maintenance of Certification requirements. Commenters stated that these requirements are a step forward toward promoting transparency, improving usability, and achieving interoperability of health IT. We also received comments asserting that the Conditions and Maintenance of Certification requirements should only apply to developers of certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We provide further details on each of the Conditions and Maintenance of Certification requirements within their respective subsections in this section of the final rule. However, to clarify our approach to the Conditions and Maintenance of Certification requirements in response to comments, the Conditions and Maintenance of Certification requirements, except for the “information blocking” and “assurances” Conditions and Maintenance of Certification requirements, apply only to actions and behaviors of health IT developers related to their certified health IT as well as to the certified health IT itself. For the “information blocking” and “assurances” Conditions and Maintenance of Certification requirements, consistent with the Cures Act provisions and our implementation of section 3022(a) (information blocking) of the PHSA, a health IT developer is also responsible to ensure that all of its health IT and related actions and behaviors do not constitute information blocking or inhibit the appropriate access, exchange, and use of electronic health information (EHI). We refer readers to section VIII of this preamble for further discussion of the information blocking regulations.
                    </P>
                    <HD SOURCE="HD2">B. Provisions</HD>
                    <HD SOURCE="HD3">1. Information Blocking</HD>
                    <P>The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, not take any action that constitutes “information blocking” as defined in section 3022(a) of the PHSA (see 3001(c)(5)(D)(i) of the PHSA). We proposed to establish this Information Blocking Condition of Certification in § 170.401. We proposed that the Condition of Certification would prohibit any health IT developer who has at least one health IT product certified under the Program from taking any action that constitutes information blocking as defined by section 3022(a) of the PHSA and proposed in § 171.103. We clarified in the Proposed Rule that this proposed “information blocking” Condition of Certification and its requirements would be substantive requirements of the Program and would rely on the definition of “information blocking” established by section 3022(a) of the PHSA and proposed in § 171.103 (84 FR 7465).</P>
                    <P>We received no comments specifically about the Information Blocking Condition of Certification and have adopted the Condition of Certification as proposed. We received many comments regarding the information blocking provision, and have responded to those comments in the information blocking discussion in section VIII of this preamble. We also refer readers to section VII.D of this final rule for additional discussion of ONC's enforcement of this and other Conditions and Maintenance of Certification requirements.</P>
                    <HD SOURCE="HD3">2. Assurances</HD>
                    <P>The Cures Act requires 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 electronic health information (EHI). We proposed to implement this Condition of Certification and accompanying Maintenance of Certification requirements in § 170.402. As a Condition of Certification requirement, a health IT developer must comply with the Condition of Certification as recited here and in the Cures Act. We discussed in section VIII of the Proposed Rule the proposed reasonable and necessary activities specified by the Secretary, which constitute the exceptions to the information blocking definition.</P>
                    <P>We also proposed to establish more specific Conditions and Maintenance of Certification requirements for a health IT developer to provide assurances that it does not take any action that may inhibit the appropriate exchange, access, and use of EHI. These proposed requirements serve to provide further clarity under the Program as to how health IT developers can provide such broad assurances with more specific actions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters agreed with the central premise of our proposal to adopt the “assurances” Condition and Maintenance of Certification requirement, requiring that a health IT developer provide certain assurances to the Secretary, including that, unless done for one of the “legitimate purposes” specified by the Secretary, it will not take any actions 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 electronic health information (EHI). Commenters stated that they support ONC's efforts to eliminate barriers that result in information blocking. One commenter stated that it is not clear what constitutes “satisfactory to the Secretary” as interpretations may change from Secretary to Secretary, and suggested removing the term “Secretary.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We have finalized our proposal to adopt the “assurances” Condition and Maintenance of Certification requirement subject to the clarifications and revisions discussed below. In response to the comment recommending we remove the term “Secretary” as Secretaries may change over time, it will not be removed as it is in the authorizing Cures Act statutory language. For clarification, future Secretaries may establish changes to the implementation of the Cures Act “assurances” Condition and Maintenance of Certification requirements through notice and comment rulemaking, as has been done with this rulemaking.
                    </P>
                    <HD SOURCE="HD3">a. Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities</HD>
                    <P>
                        We proposed, as a Condition of Certification requirement, that a health IT developer must ensure that its health IT certified under the Program conforms to the full scope of the certification criteria to which its health IT is certified. This has always been an expectation of ONC and users of certified health IT and, importantly, a requirement of the Program. As stated in the Proposed Rule, we believe that by incorporating this expectation as an explicit Condition of Certification requirement under the Program, there 
                        <PRTPAGE P="25719"/>
                        would be assurances, and documentation via the “Attestations” Condition and Maintenance of Certification requirements proposed in § 170.406, that all health IT developers fully understand their responsibilities under the Program, including not to take any action with their certified health IT that may inhibit the appropriate exchange, access, and use of EHI. To this point, certification criteria are designed and issued so that certified health IT can support interoperability and the appropriate exchange, access, and use of EHI.
                    </P>
                    <P>We also proposed that, as a complementary Condition of Certification requirement, health IT developers of certified health IT must provide an assurance that they have made certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes. More specifically, developers would be prohibited from taking any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the scope of the technology's certification. Such actions may inhibit the appropriate access, exchange, or use of EHI and are therefore contrary to this proposed Condition of Certification requirement. While such actions are already prohibited under the Program (80 FR 62711), making these existing requirements that prohibit developers from taking any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the scope of the technology's certification explicit in this Condition of Certification requirement will ensure that health IT developers are required to attest to them pursuant to the Attestations Condition of Certification requirement in § 170.406, which will in turn provide additional assurances to the Secretary that developers of certified health IT support and do not inhibit appropriate access, exchange, or use of EHI.</P>
                    <P>As discussed at 84 FR 7466 in our Proposed Rule, actions that would violate this Condition of Certification requirement include failing to fully deploy or enable certified capabilities; imposing limitations (including restrictions) on the use of certified capabilities once deployed; or requiring subsequent developer assistance to enable the use of certified capabilities, contrary to the intended uses and outcomes of those capabilities). The Condition of Certification requirement would also be violated were a developer to refuse to provide documentation, support, or other assistance reasonably necessary to enable the use of certified capabilities for their intended purposes. More generally, any action that would be likely to substantially impair the ability of one or more users (or prospective users) to implement or use certified capabilities for any purpose within the scope of applicable certification criteria would be prohibited by this Condition of Certification requirement. Such actions may include imposing limitations or additional types of costs, especially if these were not disclosed when a customer purchased or licensed the certified health IT.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a comment recommending additional language to allow health IT developers to be able to provide an explanation of how their software conforms to the certification criteria requirements and how they enable the appropriate exchange, access, and use of EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for their input, but do not accept the recommendation. Health IT must comply with certification criteria as specified in regulation. We also refer readers to the “Attestations” Condition of Certification requirement in this section of the preamble for more information regarding how we proposed to provide flexibilities, including a method for health IT developers to indicate their compliance, noncompliance, or the inapplicability of each Condition and Maintenance of Certification requirement as it applies to all of their health IT certified under the Program, as well as the flexibility to specify noncompliance per certified Health IT Module, if necessary. As such, we have finalized the Full Compliance and Unrestricted Implementation of Certification Criteria Capabilities Condition of Certification requirement as proposed that a health IT developer must ensure that its health IT certified under the Program conforms to the full scope of the certification criteria to which its health IT is certified, and that health IT developers would be prohibited from taking any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the scope of the technology's certification. We note that because compliance with the information blocking section of this final rule (Part 171) is not required until six months after the publication date of the final rule, § 170.402(a)(1) also has a six-month delayed compliance date.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters requested clarification on whether requiring subsequent developer assistance to enable the use of certain certified capabilities would be considered noncompliance with the Condition of Certification requirement, such as managed services, hosting, connecting with exchange networks, or outsourced arrangements under agreement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We clarify that the purpose of this Condition of Certification requirement is to make certified capabilities available in ways that enable them to be implemented and used in production environments for their intended purposes. As stated above, the Condition of Certification requirement would be violated were a developer to refuse to provide documentation, support, or other assistance reasonably necessary to enable the use of certified capabilities for their intended purposes (
                        <E T="03">see</E>
                         84 FR 7466). We do not believe that actions by health IT developers to provide their customers with education, implementation, and connection assistance to integrate certified capabilities for their customers would typically constitute actions that interfere with a customer's ability to use certified capabilities for their intended purposes, but in the absence of specific facts, we cannot say that whether there are scenarios that would result in the assistance interfering with a user's ability to access or use certified capabilities for any purpose within the scope of the health IT's certification. As such, education and other assistance may be offered, but care should be taken to do so in a manner that minds the Condition of Certification requirement standards.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a comment asking that health IT developers be required to provide honest communication and expert advice as required by a user.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenter's suggestion regarding honest communication and expert advice. However, such a requirement would not be consistent with this Condition of Certification requirement, which focuses on assurances that Health IT developers did not take actions that may inhibit the appropriate exchange, access, and use of electronic health information (EHI). We also believe it would be difficult to enforce such a requirement in terms of determining what constitutes an “honest” communication and “expert advice.”
                    </P>
                    <HD SOURCE="HD3">b. Certification to the “Electronic Health Information Export” Criterion</HD>
                    <P>
                        We proposed that a health IT developer that produces and electronically manages EHI must certify their health IT to the 2015 Edition “EHI export” criterion in § 170.315(b)(10). As 
                        <PRTPAGE P="25720"/>
                        a Maintenance of Certification requirement, we proposed that a health IT developer that produces and electronically manages EHI must provide all of its customers of certified health IT Modules with health IT certified to the functionality included in § 170.315(b)(10) within 24 months of a subsequent final rule's effective date or within 12 months of certification for a health IT developer that never previously certified health IT to the 2015 Edition, whichever is longer. Consistent with these proposals, we also proposed to amend § 170.550 to require that ONC-ACBs certify health IT to the proposed 2015 Edition “EHI export” certification criterion when the health IT developer of the health IT Module presented for certification produces and electronically manages EHI. As discussed in section IV.C.1 of the Proposed Rule, the availability of the capabilities in the “EHI export” certification criterion promote access, exchange, and use of health information to facilitate electronic access to single patient and patient population health information in cases such as a patient requesting their information, or a health care provider switching health IT systems. As such, health IT developers with health IT products that have health IT Modules certified to the finalized “EHI export” certification requirement must make this functionality available to customers and provide assurances that the developer is not taking actions that constitute information blocking or any other action that may inhibit the appropriate exchange, access, and use of health information. We discussed the EHI export functionality in section IV.B.4 of the Proposed Rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters expressed their support for the Condition of Certification requirement, noting that certifying health IT to § 170.315(b)(10) would provide greater EHI access to end users. Several commenters requested extending the implementation timeframe to 36 months stating that more time is needed for analysis, product development, and testing, with an additional 12 months for client adoption, testing, and training. A couple of commenters supported the 24-month timeframe, but stated that they did not support ONC dictating the adoption schedule for providers, and that the proposal does not consider the efforts required from providers to plan and execute effective implementation and adoption. One commenter stated that 24 months is not aggressive enough and that the rule should prioritize certain aspects of patient-directed exchange and make these available in 12 months or less. Another commenter suggested that we narrow the type of health IT developer that must certify health IT to § 170.315(b)(10), noting that some Health IT Modules may manage data produced by other Health IT Modules, or received and incorporated from other sources. We did not receive any comments specific to our proposal to amend § 170.550 to require that ONC-ACBs certify health IT to the proposed 2015 Edition “EHI export” criterion when the health IT developer of the health IT Module presented for certification produces and electronically manages EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their support. In response to comments regarding scope of data export under this criterion, we have modified the proposed “EHI export” certification criterion and scope of data export. In doing so, we have also revised our Condition of Certification requirement, which we have finalized in § 170.402(a)(4), that a health IT developer of a 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). Additionally, we clarify that in attesting to § 170.406, a health IT developer must attest accurately in accordance with § 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 EHI. The finalized criterion focuses on the Health IT Module's ability to export EHI for the health IT product's single and patient population, which encompasses the EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. To note, we do not require developers to disclose proprietary information about their products. Also, as clarified above and in § 170.315(b)(10)(iii), we do not require any specific standards for the export format(s) used to support the export functionality.
                    </P>
                    <P>In regards to when health IT developers must provide all of their users of certified health IT with health IT certified to the functionality included in § 170.315(b)(10), we have removed the proposed language “within 12 months of certification for a health IT developer that never previously certified health IT to the 2015 Edition, whichever is longer.” Our intention was to provide equity between existing and new health IT developers. However, we have concluded that new health IT developers will not be at a disadvantage to meet the same timeline considering all health IT developers will be aware of requirements necessary for certification when this final rule is published. We also acknowledge the concerns expressed regarding the 24-month timeframe and have extended the compliance timeline to within 36 months of the final rule's publication date, as finalized in § 170.402(b)(2)(i). With the narrowed scope of data export for the criterion, we believe health IT developers should be able to provide all of their customers of Health IT Modules certified to § 170.315(b)(10) with the export functionality included in § 170.315(b)(10) within 36 months. We have also finalized in § 170.402(b)(2)(ii) that on and after 36 months from the publication of this final rule, health IT developers that must comply with the requirements of § 170.402(a)(4) must provide all of their customers of certified health IT with health IT certified to § 170.315(b)(10). From this milestone forward, a health IT developer's participation in the Certification Program obligates them to provide the technical capabilities expressed in § 170.315(b)(10) when they provide such certified health IT to their customers. We will monitor ongoing compliance with this Condition and Maintenance of Certification through a variety of means including, but not limited to, developer attestations pursuant to § 170.406, health IT developers real world testing plans, response to user complaints, and ONC-ACB surveillance activities.</P>
                    <P>
                        Consistent with the above revisions and in alignment with our proposal to amend § 170.550, we have also amended § 170.550(g)(5) regarding Health IT Module dependent criteria for consistency with the requirements of § 170.402(a)(4) and (b)(2) when a Health IT Module presented for certification is part of a health IT product which can store electronic health information. In addition, we have amended § 170.550(m)(2) to only allow ONC-ACBs to issue certifications to § 170.315(b)(6) until 36 months after the publication date of this final rule. Thus, ONC-ACBs may issue certificates for either § 170.315(b)(6) or (b)(10) up until 36 months after the publication date of this final rule, but on and after 36 months they may only issue certificates for Health IT Modules in accordance with § 170.315(b)(10). We note that ONC-ACBs are required by their ISO/IEC 17065 accreditation to have processes in place to meet the expectations and minimum requirements of the Program. Thus, ONC-ACBs are expected to have processes in place in order to effectively monitor these timeline requirements on and after 36 months after the 
                        <PRTPAGE P="25721"/>
                        publication of this rule, and to additionally ensure that the health IT developer attests accurately to § 170.402(a)(4) and (b)(2). Should a developer fail to comply, the ONC-ACB will follow its processes to institute corrective action and report to ONC in accordance with Program reporting requirements in 45 CFR 170.523(f)(1)(xxii). In the event the developer does not follow through with the corrective action plan established and approved with the ONC-ACB, the ONC-ACB must alert ONC of the health IT developer's failure to comply with the Conditions and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested ONC add functionality to the CHPL (or in another format) that provides a list of the start and end dates of each previously certified Health IT Module.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this suggestion and note that the CHPL already lists certification dates for certified Health IT Modules, including the dates the Health IT Module was last modified, decertified, or made inactive.
                    </P>
                    <HD SOURCE="HD3">c. Records and Information Retention</HD>
                    <P>We proposed that, as a Maintenance of Certification requirement in § 170.402(b)(1), a health IT developer must, for a period of 10 years beginning from the date of certification, retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the Program. In other words, records and information should be retained starting from the date a developer first certifies health IT under the Program and applies separately to each unique Health IT Module (or Complete EHR, as applicable) certified under the Program. This retention of records is necessary to verify health IT developer compliance with Program requirements, including certification criteria and Conditions and Maintenance of Certification requirements. As stated in the Proposed Rule, 10 years is an appropriate period of time given that many users of certified health IT participate in various CMS programs, as well as other programs, that require similar periods of records retention.</P>
                    <P>In an effort to reduce administrative burden, we also proposed, that in situations where applicable certification criteria are removed from the Code of Federal Regulations before the 10 years have expired, records must only be kept for 3 years from the date of removal for those certification criteria and related Program provisions unless that timeframe would exceed the overall 10-year retention period. This “3-year from the date of removal” records retention period also aligns with the records retention requirements for ONC-ACBs and ONC-ATLs under the Program.</P>
                    <P>We encouraged comment on these proposals and whether the proposed requirements can provide adequate assurances that certified health IT developers are demonstrating initial and ongoing compliance with the requirements of the Program; and thereby ensuring that certified health IT can support interoperability, and appropriate exchange, access, and use of EHI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters requested clarification on what records and information are expected to be maintained and how this is different from the records ONC-ACBs and ONC-ATLs retain. A couple commenters requested clarification on when the records and information retention requirement would take effect. One commenter requested clarification regarding the role of health IT developers that no longer maintain a certified Health IT Module or have their certification suspended. One commenter recommended setting a retention period for record keeping in the event that a health IT developer removes a Health IT Module from market to ensure that potentially short lived Health IT Modules would inadvertently not have their documentation maintained.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have adopted our proposal in § 170.402(b)(1) without revisions. We continue to believe that 10 years is an appropriate period of time given that many users of certified health IT participate in various CMS programs, as well as other programs, that require similar periods of records retention. We also finalized that in situations where applicable certification criteria are removed from the Code of Federal Regulations, records must only be kept for 3 years from the date of removal for those certification criteria and related Program provisions unless that timeframe would exceed the overall 10-year retention period. We clarify that health IT developers are best situated to determine what records and information in their possession would demonstrate their compliance with all of the relevant Program requirements. We note that it is our understanding that health IT developers are already retaining the majority of their records and information for the purposes of ONC-ACB surveillance and ONC direct review under the Program. We also refer readers to section VII.D of this final rule preamble for additional discussion of records necessary for the enforcement of the Conditions and Maintenance of Certification requirements. In regard to the requested clarification for the role of health IT developers that no longer maintain a certified Health IT Module or have their certification suspended, a health IT developer who does not have any certified Health IT Modules within the Program would no longer have any obligation to retain records and information for the purposes of the Program. However, we note that it may be in the health IT developer's best interest to retain their records and information. For example, records may be useful for health IT developers in any potential investigation or enforcement action taken outside of the ONC Health IT Certification Program such as by the HHS Office of the Inspector General (
                        <E T="03">e.g.,</E>
                         information blocking) or the U.S. Department of Justice (
                        <E T="03">e.g.,</E>
                         False Claims Act).
                    </P>
                    <HD SOURCE="HD3">d. Trusted Exchange Framework and the Common Agreement—Request for Information</HD>
                    <P>In the Proposed Rule, we included a Request for Information (RFI) as to whether certain health IT developers should be required to participate in the Trusted Exchange Framework and Common Agreement (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. We received 40 comments on this RFI. We appreciate the input provided by commenters and may consider them to inform a future rulemaking.</P>
                    <HD SOURCE="HD3">3. Communications</HD>
                    <P>The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, does not prohibit or restrict communication regarding the following subjects:</P>
                    <P>• The usability of the health information technology;</P>
                    <P>• The interoperability of the health information technology;</P>
                    <P>• The security of the health information technology;</P>
                    <P>• Relevant information regarding users' experiences when using the health information technology;</P>
                    <P>• The business practices of developers of health information technology related to exchanging electronic health information; and</P>
                    <P>• The manner in which a user of the health information technology has used such technology.</P>
                    <P>
                        The Cures Act established the broad communications protections delineated above (referred to hereafter as “protected communications”) and we proposed in 84 FR 7467 to implement 
                        <PRTPAGE P="25722"/>
                        this general prohibition against developers imposing prohibitions and restrictions on protected communications in § 170.403.
                    </P>
                    <P>We also recognized that there are circumstances where it is both legitimate and reasonable for developers to limit the sharing of information about their health IT. As such, we proposed to allow developers to impose prohibitions or restrictions on protected communications in certain narrowly defined circumstances. In order for a prohibition or restriction on a protected communication to be permitted, we proposed in 84 FR 7467 that it must pass a two-part test. First, the communication that is being prohibited or restricted must not fall within a class of communications (hereafter referred to as “communications with unqualified protection”) that is considered to always be legitimate or reasonable—such as communications required by law, made to a government agency, or made to a defined category of safety organizations. Second, to be permitted, a developer's prohibition or restriction on communications must also fall within a category of communications (hereafter referred to as “permitted prohibitions and restrictions”) for which it is both legitimate and reasonable for a developer to limit the sharing of information about its health IT. This would be because of the nature of the relationship between the developer and the communicator or because of the nature of the information that is, or could be, the subject of the communication. We proposed that a developer's restriction or prohibition that does not satisfy this two-part test would contravene the Communications Condition of Certification requirement. We note that this two-part test strikes a reasonable balance between the need to promote open communication about health IT and related business practices, and the need to protect the legitimate interests of health IT developers and other entities.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of public comments we received supported the proposed Communications Condition of Certification requirements, with many commenters expressing strong support. Commenters stated that the proposed requirements would enable better communication that would improve health IT and patient care. Some commenters who supported the proposed requirements sought clarification or had specific concerns, including regarding the proposed deadlines for contract modification. These matters are discussed in more detail below. Additionally, a handful of public comments strongly opposed the proposed requirements, primarily based on concerns regarding intellectual property (IP).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the overall strong support for the Communications Condition of Certification requirements as proposed and have finalized with modifications in § 170.403. We also recognize the need to provide clarification regarding some aspects of the requirements, including regarding the protections available for IP that are included in the Communications Condition and Maintenance of Certification requirements.
                    </P>
                    <P>
                        We emphasize that, under section 3001(c)(5) of the PHSA, participation in the ONC Health IT Certification Program (Program) is voluntary. In other words, ONC cannot compel health IT developers to participate in the Program nor can ONC impose consequences (
                        <E T="03">e.g.,</E>
                         enforcement actions or penalties) on health IT developers who choose not to participate in the Program. The requirements of the Program are much like requirements for any other voluntary contract or agreement an entity would enter into with the Federal Government. Through the Conditions and Maintenance of Certification requirements, we have essentially offered developers terms for participation in the Program that we believe are appropriate based on: Our statutory instruction and interpretation of the Cures Act; the utility and necessity of using intellectual property, including screenshots, to communicate issues with usability, user experience, interoperability, security, or the way the technology is used (and relatedly, the real and substantial threat to public health and safety resulting from prohibitions and/or restrictions on the communication of screenshots); and the measured approach we have taken throughout the Communications Condition and Maintenance of Certification requirements (which is discussed in detail in this section). Because the Program is voluntary, developers have the option to agree to the terms we have offered or to choose not to participate in the Program. As such, we believe our policies concerning intellectual property, including the use of screenshots, are consistent with other laws and regulations that govern terms for voluntary contracts and agreements with the Federal Government. Further, we believe that the final provisions of this Condition of Certification include appropriate consideration of health IT developers' intellectual property rights.
                    </P>
                    <P>We further discuss the various aspects of the Communications Condition of Certification requirements, as well as the changes we have made to our proposals, in more detail below.</P>
                    <HD SOURCE="HD3">a. Background and Purpose</HD>
                    <P>The Communications Condition of Certification requirements address industry practices of certified health IT developers that can severely limit the ability and willingness of health IT customers, users, researchers, and other stakeholders to openly discuss and share their experiences and other relevant information about health IT performance, including about the ability of health IT to exchange health information electronically. These practices result in a lack of transparency that can contribute to and exacerbate patient safety risks, system security vulnerabilities, and health IT performance issues.</P>
                    <P>
                        We explained in the Proposed Rule that the challenges presented by health IT developer actions that prohibit or restrict communications have been examined for some time. The problem was identified in a 2012 report by the Institute of Medicine of the National Academies (IOM) entitled “Health IT and Patient Safety: Building Safer Systems for Better Care” 
                        <SU>73</SU>
                        <FTREF/>
                         (IOM Report). The IOM Report stated that health care providers, researchers, consumer groups, and other health IT users lack information regarding the functionality of health IT.
                        <SU>74</SU>
                        <FTREF/>
                         The IOM Report observed, relatedly, that many developers restrict the information that users can communicate about developers' health IT through nondisclosure clauses, confidentiality clauses, IP protections, hold-harmless clauses, and other boilerplate contract language.
                        <SU>75</SU>
                        <FTREF/>
                         The report stressed the need for health IT developers to enable the free exchange of information regarding the experience of using their health IT, including the sharing of screenshots relating to patient safety.
                        <SU>76</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>73</SU>
                             IOM (Institute of Medicine), Health IT and Patient Safety: Building Safer Systems for Better Care (2012). Available at 
                            <E T="03">http://www.nationalacademies.org/hmd/Reports/2011/Health-IT-and-Patient-Safety-Building-Safer-</E>
                             Systems-for-Better-Care.aspx.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>74</SU>
                             Id. at 37.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>75</SU>
                             Id. at 36, 128.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>76</SU>
                             Id.
                        </P>
                    </FTNT>
                    <P>
                        Concerns have also been raised by researchers studying health IT,
                        <SU>77</SU>
                        <FTREF/>
                         who emphasize that confidentiality and IP provisions in contracts often place broad and unclear limits on authorized uses of information related to health IT, 
                        <PRTPAGE P="25723"/>
                        which in turn seriously impact the ability of researchers to conduct and publish their research.
                        <SU>78</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>77</SU>
                             See Hardeep Singh, David C. Classen, and Dean F. Sittig, Creating an Oversight Infrastructure for Electronic Health Record-Related Patient Safety Hazards, 7(4) Journal of Patient Safety 169 (2011). Available at 
                            <E T="03">https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3677059/</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>78</SU>
                             Kathy Kenyon, Overcoming Contractual Barriers to EHR Research, Health Affairs Blog (October 14, 2015). Available at 
                            <E T="03">http://healthaffairs.org/blog/2015/10/14/overcoming-contractual-barriers-to-ehr-research/</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        The issue of health IT developers prohibiting or restricting communications about health IT has been the subject of a series of hearings by the Senate Committee on Health, Education, Labor and Pensions (HELP Committee), starting in the spring of 2015. Senators on the HELP Committee expressed serious concern regarding the reported efforts of health IT developers to restrict, by contract and other means, communications regarding user experience, including information relevant to safety and interoperability.
                        <SU>79</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>79</SU>
                             Senate HELP Committee Hearing at 13 and 27 (July 23, 2015), available at 
                            <E T="03">https://www.help.senate.gov/hearings/achieving-the-promise-of-health-information-technology-information-blocking-and-potential-solutions</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Developer actions that prohibit or restrict communications about health IT have also been the subject of investigative reporting.
                        <SU>80</SU>
                        <FTREF/>
                         A September 2015 report examined eleven contracts between health systems and major health IT developers and found that, with one exception, all of the contracts protected large amounts of information from being disclosed, including information related to safety and performance issues.
                        <SU>81</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>80</SU>
                             D. Tahir, POLITICO Investigation: EHR gag clauses exist—and, critics say, threaten safety, Politico, August 27, 2015.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>81</SU>
                             Id.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Condition of Certification Requirements</HD>
                    <HD SOURCE="HD3">i. Protected Communications and Communicators</HD>
                    <P>
                        We proposed in 84 FR 7468 that the protection afforded to communicators under the requirements of the Communications Condition of Certification in § 170.403(a) would apply irrespective of the form or medium in which the communication is made. We proposed in 84 FR 7468 that developers must not prohibit or restrict communications whether written, oral, electronic, or by any other method if they are protected, unless such prohibition or restriction is otherwise permitted by the requirements of this Condition of Certification. Similarly, we proposed that these Condition of Certification requirements do not impose any limit on the identity of the communicators that are able to benefit from the protection afforded, except that employees and contractors of a health IT developer may be treated differently when making communications that are not afforded unqualified protection under § 170.403(a)(2)(i). For example, we proposed that this Condition of Certification's requirements are not limited to communications by health IT customers (
                        <E T="03">e.g.,</E>
                         providers) who have contracts with health IT developers.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters addressed the scope of protected communications in their comments. Several commenters suggested that the proposed scope of protected communications was too broad. Other commenters stated that the scope should be clarified. One commenter suggested that the scope of private communications that can be shared should be limited and that ONC should require mutual consent for such communications to be made public.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. The Cures Act identifies a list of subject areas about which health IT developers cannot prohibit or restrict communications to meet the conditions for certification. The terms we proposed for the protected subject areas are taken from the language in section 4002 of the Cures Act and include:
                    </P>
                    <P>• The usability of the health information technology;</P>
                    <P>• The interoperability of the health information technology;</P>
                    <P>• The security of the health information technology;</P>
                    <P>• Relevant information regarding users' experiences when using the health information technology;</P>
                    <P>• The business practices of developers of health information technology related to exchanging electronic health information; and</P>
                    <P>• The manner in which a user of the health information technology has used such technology.</P>
                    <P>We continue to interpret the above statutory terms broadly, but within the limiting framework we proposed, which includes a distinction between communications entitled to unqualified protections and those communications not entitled to such protection. We have, however, finalized some provisions with further limiting and clarifying language as well as provided examples to improve understanding of the provisions.</P>
                    <P>We decline to create a consent requirement as part of the requirements of this Condition of Certification because such a requirement could unnecessarily encumber vital communications protected by the Cures Act. As highlighted above, the Communications Condition of Certification requirements are intended to enable unencumbered communication about usability, interoperability, and other critical issues with health IT, and a consent requirement would chill the ability of users of health IT to engage in that communication as well as be contrary to section 4002 of the Cures Act.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that the Communications Condition of Certification requirements should apply only to certified health IT, recommending that ONC clarify that the use of “the health IT” refers only to the developer's health IT that is certified under the ONC Health IT Certification Program. The commenter stated that the use of “the health IT” in the Cures Act can only be reasonably interpreted as referring to the health IT for which a developer is seeking certification, not all of the developer's health IT. Another commenter stated that other health IT, such as billing systems, should be out of scope of this requirement and noted that to do otherwise would create a regulatory imbalance between developers of such health IT who also offer certified health IT and those who do not.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments regarding restricting the applicability of the Communications Condition of Certification requirements to certified health IT. We clarify that, as with all of the Conditions of Certification requirements, the Communications Condition of Certification requirements apply to developers of health IT certified under the Program and to the conduct of such developers with respect to health IT certified under the Program. By way of example, if a developer had health IT certified under the Program and also had health IT that was not certified under the Program, then only those communications about the certified health IT would be covered by the Communications Condition of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment requesting more specificity on the definition of communicators covered by the Communications Condition of Certification requirements. The commenter expressed concern that the broad scope could impact the ability to maintain confidentiality in traditional business-to-business relationships.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment and understand the concern noted by the commenter. As stated in the Proposed Rule and finalized in § 170.403, the Communications Condition and Maintenance of Certification requirements generally do not impose any limit on the identity of communicators that are able to benefit from the protection afforded. We also note that there are limited exceptions 
                        <PRTPAGE P="25724"/>
                        where communications by certain communicators can be restricted. Specifically, as finalized in § 170.403(a)(2)(ii)(A), health IT developers can place limited restrictions on communications by employees and contractors. We believe this will enable traditional business-to-business relationships to continue without undue disruption, including allowing implementation of non-disclosure agreements or other contracts as necessary to maintain confidentiality.
                    </P>
                    <HD SOURCE="HD3">ii. Protected Subject Areas</HD>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments requesting that we clarify how the Communications Condition of Certification requirements would apply to communications regarding public health reporting, including communications made by public health authorities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We emphasize that the Cures Act identified a list of subject areas about which we were required to forbid developers from prohibiting or restricting communications. Though public health reporting was not specifically covered by the Cures Act or our proposed regulations, it may be that certain public health communications will fall within the categories established by the statute. We also note that one of the “communications with unqualified protection” discussed later in this section is for communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations. Depending on the specific communication in question, a communication about public health reporting or a communication made to public health authorities could be a communication that could not be restricted in any way. We also emphasize that, subject to limited circumstances already discussed above, we do not impose any limit on the identity of the communicators that are able to benefit from protections afforded under the Communications Condition of Certification requirements. Communicators are broadly defined and could include public health agencies and authorities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters had concerns regarding how a developer may address communications that contain false claims or libelous statements. Commenters discussed the need to enable health IT developers to—for example—refute false claims, deal with anonymous claims, and restrict certain communications (such as false statements or communications protected by attorney-client privilege). Some of these comments emphasized that false communications such as libel should not be protected, nor should communications sent by someone who obtained them illegally, such as a hacker. Some of the commenters recommended adding a category of communications that would never be protected under the proposed framework, and such communications would not receive unqualified protection or necessitate permitted restrictions. This would allow a developer to—for example—prohibit or restrict communications that are false or deceptive, would violate a law or court order, or would result in a breach of contract.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed by commenters regarding statements that may be false or misleading. However, developers already have legal means and remedies available to them to address such statements, and this rule does not change that. For example, each State has libel laws that address libelous or defamatory statements and provide remedies in situations where the specific facts in a damaging statement can be proven to be untrue. We believe that such statements are best addressed through those laws and that it is neither prudent nor practical for ONC to use the Program and the Communications Condition of Certification requirements to attempt to assess such statements and make determinations as to their veracity.
                    </P>
                    <P>Further, we note that the Communications Condition of Certification requirements only provide that such protected communications cannot be restricted or prohibited. It is up to the health IT developer whether and how they choose to respond to the protected communication once made. Therefore, we clarify that it is not a violation of the Communications Condition of Certification requirements for developers to respond to false or unlawful comments under applicable law, as they do now, and to pursue litigation or any other available legal remedy in response to any protected communications that are covered by the Communications Condition of Certification. For example, it would not be a violation of the Communications Condition of Certification for a health IT developer who restricts the communication of screenshots as permitted under § 170.403(a)(2)(ii)(D) to pursue litigation for Copyright infringement or violation of contract if a “protected communication” disclosed more screenshots than the developer's restriction allowed.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that “safety” be added as a protected category or that ONC should include in the final rule a specific ban that prohibits any restrictions on communications about health IT-related patient safety. Additionally, several commenters noted that ONC should include specific reporting methods or standards in the final rule to improve safety reporting or add examples to help encourage reporting of safety and security issues. Several commenters also requested that ONC develop protocols for reporting safety issues, and one commenter recommended ONC develop a patient safety reporting system.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In implementing the Cures Act requirement that a health IT developer, as a Condition of Certification requirement under the Program, not restrict communications about health IT, we adhered to the list of protected subject areas identified by Congress in the Cures Act. Those subject areas include communications about “usability,” “relevant information regarding users' experiences when using the health information technology,” and the “manner in which a user of the health information technology has used such technology.” We clarify that patient safety issues related to an interaction with the health IT could be covered in one or more of those categories. Additionally, we agree with commenters that safety-related communications should receive specific protections, and we emphasize that the communication of safety concerns is also addressed as a protected communication receiving “unqualified protection.” In the section of this final rule on “Communications with Unqualified Protection,” and in § 170.403(a)(2)(i)(B), we state that communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations is a communication about which a developer would be prohibited from imposing any prohibition or restriction.
                    </P>
                    <HD SOURCE="HD3">(A) Usability of Health Information Technology</HD>
                    <P>
                        The term “usability” is not defined in the Cures Act, nor in any other relevant statutory provisions. We proposed in 84 FR 7469 that the “usability” of health IT be construed broadly to include both an overall judgment on the “usability” of a particular certified health IT product by the user, as well as any factor that contributes or may contribute to usability. We proposed that the factors of usability that could be the subject of 
                        <PRTPAGE P="25725"/>
                        protected communications include, but are not limited to, the following: The user interface (
                        <E T="03">e.g.,</E>
                         what a user sees on the screen, such as layout, controls, graphics and navigational elements); ease of use (
                        <E T="03">e.g.,</E>
                         how many clicks); how the technology supports users' workflows; the organization of information; cognitive burden; cognitive support; error tolerance; clinical decision support; alerts; error handling; customizability; use of templates; mandatory data elements; the use of text fields; and customer support.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that “usability” is too broadly defined and should relate more specifically to judgments on the ease of use of the health IT, rather than factors related to usability.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not believe that “usability” is inaccurately defined nor too broadly defined. To define usability in the Proposed Rule, we referenced the NIST standard 
                        <SU>82</SU>
                        <FTREF/>
                         as well as principles recognized by the Healthcare Information and Management Systems Society (HIMSS). We also emphasized that there are a multitude of factors that contribute to any judgment about “usability,” including factors contributing to the effectiveness, efficiency, and performance of the health IT. We have finalized the scope of the protected subject area “usability of its health IT” in § 170.403(a)(1)(i) as proposed, providing that the “usability” of health IT be construed broadly to include both an overall judgment on the “usability” of a particular certified health IT product, as well as any of the many factors that could contribute to usability as described in the Proposed Rule. We also note that communications about the usability of health IT may include communications about features that are part of the certified health IT as well as communications about what is not in the certified health IT (
                        <E T="03">e.g.,</E>
                         the absence of alerts or features that a user believes would aid in usability or are related to the other subject areas identified by the Cures Act).
                    </P>
                    <FTNT>
                        <P>
                            <SU>82</SU>
                             See 
                            <E T="03">https://www.nist.gov/programs-projects/health-it-usability.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(B) Interoperability of Health Information Technology</HD>
                    <P>The Cures Act, as codified in section 3000(9) of the PHSA, provides a definition of “interoperability” that describes a type of health IT that demonstrates the necessary capabilities to be interoperable. For the purposes of the Communications Condition of Certification requirements, we proposed that protected communications regarding the “interoperability of health IT” would include communications about whether certified health IT and associated developer business practices meet the interoperability definition described in section 3000(9) of the PHSA, including communications about aspects of the technology or developer that fall short of the expectations found in that definition. We stated that this would include communications about the interoperability capabilities of health IT and the practices of a health IT developer that may inhibit the access, exchange, or use of EHI, including information blocking. As previously noted, Congress did not define the terms used in the Communications Conditions of Certification requirements in section 4002(a) of the Cures Act and codified in section 3001(c)(5)(D)(iii) of the PHSA. We believe that “interoperability” was appropriately defined in the Proposed Rule by using the interoperability definition that is located elsewhere in section 4003(a)(2) of the Cures Act and codified in section 3000(9) of the PHSA.</P>
                    <P>We did not receive comments about this aspect of the Proposed Rule, and we have finalized the scope of the protected subject area “interoperability of its health IT” in § 170.403(a)(1)(ii) as proposed above.</P>
                    <HD SOURCE="HD3">(C) Security of Health IT</HD>
                    <P>
                        The security of health IT is addressed by the HIPAA Security Rule,
                        <SU>83</SU>
                        <FTREF/>
                         which establishes national standards to protect individuals' electronic protected health information (ePHI) that is created, received, maintained, or transmitted by a covered entity or business associate (as defined at 45 CFR 160.103). Covered entities and business associates must ensure the confidentiality, integrity, and availability of all ePHI; protect against any reasonably anticipated threats or hazards to the security or integrity of such information; and protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under the HIPAA Privacy Rule.
                        <SU>84</SU>
                        <FTREF/>
                         The HIPAA Security Rule requires health IT developers, to the extent that they are business associates of covered entities, to implement appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI.
                        <SU>85</SU>
                        <FTREF/>
                         We proposed in 84 FR 7469 that the matters that fall within the topic of health IT security should be broadly construed to include any safeguards, whether or not required by the HIPAA Security Rule, that may be implemented (or not implemented) by a developer to ensure the confidentiality, integrity, and availability of EHI (information that includes ePHI), together with the certified health IT's performance regarding security.
                    </P>
                    <FTNT>
                        <P>
                            <SU>83</SU>
                             45 CFR part 160 and subparts A and C of part 164.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>84</SU>
                             45 CFR part 160 and subparts A and C of part 164.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>85</SU>
                             Id.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter noted that it is important that developers are able to remove posts on a website or forum that could compromise the security of health IT and recommended that ONC explicitly allow developers to do so in the final rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We recognize the importance of protecting the security of EHI and health IT. We also recognize that our engagement with stakeholders, as well as the language in section 4002 of the Cures Act, emphasize the strong public interest in allowing unencumbered communications regarding the protected subject areas and communications with unqualified protection, which are discussed in more detail below and in § 170.403(a)(2)(i). We emphasize that developers may respond to communications as allowed under applicable law and may pursue any appropriate legal remedy. Taking these factors into consideration, we decline at this time to explicitly allow developers to restrict communications regarding security as suggested by the commenter.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested that ONC consider narrowing the permitted communication of security elements in § 170.403(a)(1)(iii) that might be used to compromise a particular certified health IT's security, for example restricting the sharing of authentication credentials issued to a customer or user to access a system containing sensitive information such as PHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not believe it is necessary in this final rule to narrow or restrict the information that can be communicated where security elements are included in the communication. As stated above, we believe there is a strong public interest in allowing unencumbered communications regarding the protected subject areas and communications with unqualified protection. Further, assurances that access credentials and PHI communicated under these circumstances will not be shared inappropriately are addressed in the HIPAA Security Rule and relevant State laws, and this rule does not change those protections.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One comment recommended that the Communications Condition of Certification requirements should protect communication 
                        <PRTPAGE P="25726"/>
                        regarding the overall security posture that the health IT developer takes or makes the user take, including communications regarding a system with known and longstanding issues or bugs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment and clarify that communications related to the overall security posture taken by a health IT developer would be within the subject area of “security of its health IT,” and thus would be protected communications covered by the Communications Condition of Certification requirements. We have finalized the scope of the protected subject area “security of its health IT” in § 170.403(a)(1)(iii) as proposed.
                    </P>
                    <HD SOURCE="HD3">(D) User Experiences</HD>
                    <P>The phrases “relevant information regarding users' experiences when using the health IT” and “user experience” are not defined in the Cures Act nor any other relevant statutory provisions. We proposed in 84 FR 7470 to afford the term “user experience” its ordinary meaning. To qualify as a “user experience,” we proposed that the experience would have to have been one that is had by a user of health IT. However, beyond this, we did not propose to qualify the types of experiences that would receive protection under the Communications Condition of Certification requirements based on the “user experience” subject area. To illustrate the breadth of potential user experiences that would be protected by the proposed Communications Condition of Certification requirements, we proposed that communications about “relevant information regarding users' experiences when using the health IT” would encompass, for example, communications and information about a person or organization's experience acquiring, implementing, using, or otherwise interacting with the health IT. We also proposed that this would include experiences associated with the use of the health IT in the delivery of health care, together with administrative functions performed using the health IT. We proposed that user experiences would also include the experiences associated with configuring and using the technology throughout implementation, training, and in practice. Further, we proposed that user experiences would include patients' and consumers' user experiences with consumer apps, patient portals, and other consumer-facing technologies of the health IT developer. We clarified that a “relevant user experience” would include any aspect of the health IT user experience that could positively or negatively impact the effectiveness or performance of the health IT.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that the most relevant aspect of a user's experience of a health IT system is whether that experience resulted in patient safety events and requested that ONC specify patient safety events that arise from the use, misuse, or failure of health IT systems as “user experiences” that cannot be covered by gag orders.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As previously noted in our response to patient safety comments above, we reiterate that a user experience resulting in a patient safety event would be covered under the Communications Condition of Certification requirements and that a communication about such an experience would be protected, subject to other applicable laws. Further, communications about “adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations” receive unqualified protection as described in § 170.403(a)(2)(i). We noted in the Proposed Rule that the Patient Safety and Quality Improvement Act of 2005 (PSQIA) provides for privilege and confidentiality protections for information that meets the definition of patient safety work product (PSWP). This means that PSWP may only be disclosed as permitted by the PSQIA and its implementing regulations. We clarified that to the extent activities are conducted in accordance with the PSQIA, its implementing regulation, and section 4005(c) of the Cures Act, no such activities shall be construed as constituting restrictions or prohibitions that contravene this Condition of Certification.
                    </P>
                    <P>We believe that “user experience” was appropriately defined in the Proposed Rule and have finalized the scope of the protected subject area “relevant information regarding users' experiences when using its health IT” in § 170.403(a)(1)(iv) as proposed, with the clarification provided above regarding patient safety events and to clarify that any communications regarding consumer-facing technologies would need to be about certified consumer-facing technologies per our earlier clarification about the scope of this Condition of Certification being limited to certified health IT.</P>
                    <HD SOURCE="HD3">(E) Manner in Which a User Has Used Health IT</HD>
                    <P>We proposed in 84 FR 7470 that protected communications regarding the “manner in which a user has used health IT” would encompass any information related to how the health IT has been used. We also proposed that the terms used to describe the protected subject areas should be construed broadly. We noted in the Proposed Rule that this subject area largely overlaps with the matters covered under the “user experience” subject area but may include additional perspectives or details beyond those experienced by a user of health IT. We proposed that the types of information that would fall within this subject area include but are not limited to:</P>
                    <P>• Information about a work-around implemented to overcome an issue in the health IT;</P>
                    <P>• customizations built on top of core health IT functionality;</P>
                    <P>• the specific conditions under which a user used the health IT, such as information about constraints imposed on health IT functionality due to implementation decisions; and</P>
                    <P>• information about the ways in which health IT could not be used or did not function as was represented by the developer.</P>
                    <P>We did not receive comments on this specific aspect of the Proposed Rule, and we believe the Proposed Rule appropriately outlined what would fall within the subject matter of the manner in which a user has used health IT. We have finalized the scope of the protected subject area “manner in which a user of the health IT has used such technology” in § 170.403(a)(1)(vi) as proposed, with the clarification that “used” refers to any uses of the certified health IT by the user and is not limited to uses that involve direct patient care.</P>
                    <HD SOURCE="HD3">(F) Business Practices Related to Exchange</HD>
                    <P>We proposed in 84 FR 7470 that the subject matter of “business practices of developers of health IT related to exchanging electronic health information” should be broadly construed to include developer policies and practices that facilitate the exchange of EHI and developer policies and practices that impact the ability of health IT to exchange health information. We further proposed that the exchange of EHI would encompass the appropriate and timely sharing of EHI.</P>
                    <P>We proposed that protected communications would include, but would not be limited to:</P>
                    <P>
                        • The costs charged by a developer for products or services that support the exchange of EHI (
                        <E T="03">e.g.,</E>
                         interface costs, API licensing fees and royalties, maintenance and subscription fees, transaction or usage-based costs for exchanging information);
                        <PRTPAGE P="25727"/>
                    </P>
                    <P>• the timeframes and terms on which developers would or would not enable connections and facilitate exchange with other technologies, individuals, or entities, including other health IT developers, exchanges, and networks;</P>
                    <P>• the developer's approach to participation in health information exchanges and/or networks;</P>
                    <P>• the developer's licensing practices and terms as it relates to making available APIs and other aspects of its technology that enable the development and deployment of interoperable products and services; and</P>
                    <P>• the developer's approach to creating interfaces with third-party products or services, including whether connections are treated as “one off” customizations, or whether similar types of connections can be implemented at a reduced cost.</P>
                    <P>Importantly, we further proposed in 84 FR 7470 that information regarding “business practices of developers of health IT related to exchanging electronic health information” would include information about switching costs imposed by a developer, as we are aware that the cost of switching health IT is a significant factor impacting health care providers adopting the most exchange-friendly health IT available.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that our proposed “business practices” is too broadly defined and should relate exclusively to interoperability elements of certified health IT, rather than to products and services that support exchange.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed in the Proposed Rule, we believe the term “business practices of developers of health IT related to exchanging electronic health information” should be broadly construed consistent with our interpretation of the Cures Act language regarding the Communications Condition of Certification requirements, but limited to those business practices that relate to the certified health IT as clarified previously in this Condition and Maintenance of Certification section. A wide variety of business practices could impact the exchange of EHI, including developer business strategies, pricing, and even fraudulent behavior. As such, we have finalized in § 170.403(a)(1)(v) our proposal that such business practices include developer policies and practices that impact or facilitate the exchange of EHI. They could also include costs charged by a developer not only specifically for interoperability elements of the certified health IT, but also for any products or services that support the exchange of EHI through the certified health IT. We reiterate that business practices related to exchange could include timeframes and terms on which developers facilitate exchange; the developer's approach to participating in health information exchanges and/or networks; the developer's licensing practices and terms as related to APIs and other interoperable services; and the developer's approach to creating interfaces with third-party services. As proposed in 84 FR 7473, this Communications Condition of Certification requirement will also apply to any communication concerning a Program requirement (
                        <E T="03">e.g.,</E>
                         a Condition or Maintenance of Certification requirement) related to the exchange of EHI or the information blocking provision.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters had concerns regarding communications about prices and costs, with some commenters asserting that such communications should be protected and some others asserting that developers should be able to restrict communications about prices and costs, including switching costs. Additionally, one commenter had concerns about protecting communications regarding timeframes and terms as well as workarounds and customizations. One commenter also recommended that ONC seek guidance from the Antitrust Division of the FTC regarding economic impacts of regulating health IT developer terms, prices, and timeframes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We continue to interpret costs, information regarding timeframes and terms, and information about health IT workarounds and customizations as protected communications under the “Business Practices Related to Exchange” provision of this condition. We believe that this type of information is frequently relied upon and necessary in order to optimize health IT for the exchange of EHI. We emphasize that the costs charged by a developer for certified health IT or related services that support the exchange of EHI are significant factors that can impact the adoption of interoperable certified health IT and should be protected communications. For example, pricing could include prohibitive costs that prevent or discourage customers from using certified health IT to interact with competing technologies. Likewise, information regarding timeframes and terms is the type of information considered and relied upon in the adoption of interoperable certified health IT and is a protected communication. We have also finalized in § 170.403(a)(1)(vi) that information about certified health IT workarounds and customizations relates to important aspects of how a user has used certified health IT, including how the certified health IT can be used to achieve greater interoperability, and is a protected communication.
                    </P>
                    <P>In response to the comments recommending that we seek guidance from the FTC, we note that we are not regulating health IT developer terms, prices, and timeframes under this Communications Condition of Certification requirements, and therefore do not need to seek further guidance. Rather, the Communications Condition of Certification requirements would protect communications about health IT developer costs, terms, and timeframes as described above and ensure that such information could be shared. We have finalized the scope of the protected subject area “business practices of developers of health IT related to exchanging electronic health information” in § 170.403(a)(1)(v) as proposed.</P>
                    <HD SOURCE="HD3">iii. Meaning of “Prohibit or Restrict”</HD>
                    <P>
                        The terms “prohibit” and “restrict” are not defined in the Cures Act, nor in any other relevant statutory provisions. We discussed in the Proposed Rule that communications can be prohibited or restricted through contractual terms or agreements (
                        <E T="03">e.g.,</E>
                         non-disclosure agreements or non-disparagement clauses) as well as through conduct, including punitive or retaliatory business practices that are designed to create powerful disincentives to engaging in communications about developers or their health IT. Therefore, we proposed in 84 FR 7470 that the Communications Condition of Certification requirements would not be limited to only formal prohibitions or restrictions (such as by means of contracts or agreements) and would encompass any conduct by a developer that would be likely to restrict a communication or class of communications protected by the Communications Condition of Certification requirements. We explained that the conduct in question must have some nexus to the making of a protected communication or an attempted or contemplated protected communication.
                    </P>
                    <HD SOURCE="HD3">(A) Prohibitions or Restrictions Arising by Way of Contract</HD>
                    <P>
                        We explained in the Proposed Rule that the principal way that health IT developers can control the disclosure of information about their health IT is through contractual prohibitions or restrictions. We noted that there are different ways that contractual prohibitions or restrictions arise. In some instances, a contractual prohibition or restriction will be 
                        <PRTPAGE P="25728"/>
                        expressed, and the precise nature and scope of the prohibition or restriction will be explicit in the contract or agreement. However, we also noted that a contract may also impose prohibitions or restrictions in less precise terms. We stated that a contract does not need to expressly prohibit or restrict a protected communication in order to have the effect of prohibiting or restricting that protected communication. The use of broad or vague language that obfuscates the types of communications that can and cannot be made may be treated as a prohibition or restriction if it has the effect of restricting legitimate communications about health IT.
                    </P>
                    <P>We stated that restrictions and prohibitions found in contracts used by developers to sell or license their health IT can apply to customers directly and can require that the customer “flow-down” obligations to the customer's employees, contractors, and other individuals or entities that use or work with the developer's health IT. We proposed that such contract provisions would not comply with the Communications Condition of Certification requirements and would be treated as prohibiting or restricting protected communications. We noted that prohibitions or restrictions on communications can also be found in separate nondisclosure agreements (NDAs) that developers require their customers—and in some instances the users of the health IT or third-party contractors—to enter into in order to receive or access the health IT. We proposed that such agreements are covered by the Communications Condition of Certification requirements.</P>
                    <P>We did not receive comments on this specific aspect of the Proposed Rule and have finalized our interpretation proposed in FR 7471 regarding prohibitions or restrictions arising by way of contract as stated above.</P>
                    <HD SOURCE="HD3">(B) Prohibitions or Restrictions That Arise by Way of Conduct</HD>
                    <P>We proposed in 84 FR 7471 that conduct that has the effect of prohibiting or restricting a protected communication would be subject to the Communications Condition of Certification requirements. We emphasized that the conduct in question must have some nexus to the making of a protected communication or an attempted or contemplated protected communication. As such, developer conduct that was alleged to be intimidating, or health IT performance that was perceived to be substandard, would not, in and of itself, implicate the Communications Condition of Certification requirements unless there was some nexus between the conduct or performance issue and the making of (or attempting or threatening to make) a protected communication.</P>
                    <P>We did not receive comments on this specific aspect of the Proposed Rule and have finalized our interpretation proposed in 84 FR 7471 regarding prohibitions or restrictions arising by way of conduct as stated above.</P>
                    <HD SOURCE="HD3">iv. Communications With Unqualified Protection</HD>
                    <P>We proposed in 84 FR 7472 a narrow class of communications—consisting of five specific types of communications—that would receive unqualified protection from developer prohibitions or restrictions. With respect to communications with unqualified protection, a developer would be prohibited from imposing any prohibition or restriction. We proposed that this narrow class of communications warrants unqualified protection because of the strength of the public policy interest being advanced by the class of the communication and/or the sensitivity with which the identified recipient treats, and implements safeguards to protect the confidentiality and security of, the information received. We stated that a developer that imposes a prohibition or restriction on a communication with unqualified protection would fail the first part of the two-part test for allowable prohibitions or restrictions, and as such would contravene the Communications Condition of Certification requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended adding language specifying the types of entities that can receive communications with unqualified protection, noting that such specificity would help ensure that these communications go to the appropriate entities so that they can be addressed quickly. The commenter recommended that provisions around reporting to government entities should be limited to United States government entities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not believe it is necessary to further specify the types of entities that can receive communications with unqualified protection. We intend for this protection to cover a wide variety of organizations, and further specifying the types of entities that can receive such communications, such as limiting communication to only United States government entities, would unnecessarily limit the scope of this protection and could be counter to the public policy interest to advance the ability of these communications to occur unencumbered. We have finalized in § 170.403(a)(2)(i) our proposal to prohibit developers from imposing any prohibition or restriction on communications that fall into a narrow class of communications—consisting of the five specific types of communications described below—that would receive unqualified protection.
                    </P>
                    <HD SOURCE="HD3">(A) Disclosures Required by Law</HD>
                    <P>We proposed in 84 FR 7472 that where a communication relates to subject areas enumerated in proposed § 170.403(a)(1) and there are Federal, State, or local laws that would require the disclosure of information related to health IT, developers must not prohibit or restrict in any way protected communications made in compliance with those laws. We noted that we expect most health IT contracts would allow for, or not prohibit or restrict, any communication or disclosure that is required by law, such as responding to a court or Congressional subpoena, or a valid warrant presented by law enforcement. We further proposed that if required by law, a potential communicator should not have to delay any protected communication under the Communications Condition of Certification requirements.</P>
                    <P>We did not receive comments on this aspect of the Proposed Rule and have finalized in § 170.403(a)(2)(i)(A) our approach regarding disclosures required by law as proposed.</P>
                    <HD SOURCE="HD3">(B) Communicating Information About Adverse Events, Hazards, and Other Unsafe Conditions to Government Agencies, Health Care Accreditation Organizations, and Patient Safety Organizations</HD>
                    <P>
                        We proposed in 84 FR 7472 that there is an overwhelming interest in ensuring that all communications about health IT that are necessary to identify patient safety risks, and to make health IT safer, not be encumbered by prohibitions or restrictions imposed by health IT developers that may affect the extent or timeliness of communications. In addition to the public policy interest in promoting uninhibited communications about health IT safety, we proposed that the recognized communication channels for adverse events, hazards, and unsafe conditions provide protections that help ensure that any disclosures made are appropriately handled and kept confidential and secure. We proposed that the class of recipients to which the information can be communicated under this specific category of communications given unqualified protection should provide health IT developers with comfort that there is little risk of such communications prejudicing the developer's IP rights.
                        <PRTPAGE P="25729"/>
                    </P>
                    <P>We sought comment on whether the unqualified protection afforded to communications made to a patient safety organization about adverse events, hazards, and other unsafe conditions should be limited. Specifically, we sought comment on whether the unqualified protection should be limited by the nature of the patient safety organization to which a communication can be made, or the nature of the communication that can made.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters stated that ONC should not place any limits on the unqualified protection afforded to communications made to patient safety organizations about adverse events, hazards, and other unsafe conditions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized in § 170.403(a)(2)(i)(B) as proposed regarding the unqualified protection afforded to communications about adverse events, hazards, and other unsafe conditions that are made to government agencies, health care accreditation organizations, and patient safety organizations. Additionally, we placed no limits or qualifiers on such communications, including those communications made to patient safety organizations.
                    </P>
                    <HD SOURCE="HD3">(C) Communicating Information About Cybersecurity Threats and Incidents to Government Agencies</HD>
                    <P>We proposed in 84 FR 7472 that if health IT developers were to impose prohibitions or restrictions on the ability of any person or entity to communicate information about cybersecurity threats and incidents to government agencies, such conduct would not comply with the Communications Condition of Certification requirements.</P>
                    <P>We sought comment on whether it would be reasonable to permit health IT developers to impose limited restrictions on communications about security issues to safeguard the confidentiality, integrity, and security of EHI. In the Proposed Rule, we asked if, for example, health IT developers should be permitted to require that health IT users notify the developer about the existence of a security vulnerability prior to, or simultaneously with, any communication about the issue to a government agency.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that users should never be required to notify the developer when reporting cybersecurity issues, as this would impose a burden on the user and a potential barrier to reporting. Other commenters recommended that developers should be allowed to require users to notify them simultaneously or prior to reporting such incidents, with one comment noting that this would enable developers to better address and respond to security threats prior to the knowledge of a threat becoming widespread. Some commenters recommended that ONC make it a violation for developers to not share cybersecurity vulnerabilities with providers, and that ONC work with DHS to mitigate issues around sharing such vulnerabilities. One commenter recommended changing the wording regarding communicating cybersecurity and security risks to include known vulnerabilities and health IT defects.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We strongly encourage users of health IT to notify developers as soon as possible when reporting security incidents and issues. However, it would not be appropriate to require this practice, which would impose an obligation on users of health IT that is outside the scope of this rule. It would also be outside the scope of this condition to implement additional requirements for developers regarding the sharing of cybersecurity vulnerabilities with health care providers. To be clear, we expect developers with Health IT Modules certified under the Program to share information about cybersecurity vulnerabilities with health care providers and other affected users as soon as feasible, so that these affected users can take appropriate steps to mitigate the impact of these vulnerabilities on the security of EHI and other PII in the users' systems. Thus, we have finalized the Communications Condition of Certification requirements in § 170.403(a)(2)(i)(C) as proposed. Developers must not place restrictions on communications receiving unqualified protections. We also clarify that known vulnerabilities and health IT defects would likely be considered types of “adverse events, hazards, and other unsafe conditions” that would receive “unqualified protection,” and thus a developer would not be able to restrict a health IT user from communicating about such issues in communications receiving unqualified protections under the Communications Condition of Certification requirements (see § 170.403(a)(2)(i) as finalized). However, we note that in communications not receiving unqualified protection under the Communications Condition of Certification requirements, a security vulnerability that is not already public knowledge would be considered a non-user-facing aspect of health IT, about which developers are permitted to restrict communications (see § 170.403(a)(2)(ii)(B) as finalized). Last, we note that we will continue to work with our Federal partners to mitigate and address cybersecurity threats and incidents.
                    </P>
                    <HD SOURCE="HD3">(D) Communicating Information About Information Blocking and Other Unlawful Practices to a Government Agency</HD>
                    <P>We proposed in 84 FR 7473 that the public benefit associated with the communication of information to government agencies on information blocking, or any other unlawful practice, outweighs any concerns developers might have about the disclosure of information about their health IT. We noted that reporting information blocking, as well as other unlawful practices, to a government agency would not cause an undue threat to a health IT developer's IP.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments regarding the lack of whistleblower protections in the Proposed Rule for individuals who report information blocking or other issues regarding certified health IT. These comments discussed the need to provide for whistleblower type protections for individuals who highlight information blocking practices, as well as to identify them to the appropriate authorities so that the individual is not subject to retaliatory action by the actor identified by the whistleblower.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and agree that it is extremely important for individuals to be able to report information blocking and violations of other Conditions of Certification without fear of retaliation. We note that the Communications Condition of Certification requirements provide protections against retaliation and intimidation by developers with respect to protected communications. We discussed in the Proposed Rule that the Communications Condition of Certification requirements cover communications that are prohibited or restricted through contractual terms or agreements (
                        <E T="03">e.g.,</E>
                         non-disclosure agreements, non-disparagement clauses) between the health IT developer, or offeror of health IT, and the communicator, as well as through conduct, including punitive or retaliatory business practices that are designed to create powerful disincentives to engaging in communications about developers or their health IT. We clarify, however, that merely filing a lawsuit against the communicator regarding the making of 
                        <PRTPAGE P="25730"/>
                        a communication would not be considered intimidating conduct in violation of this Condition. Any such determination would necessarily be fact-specific, and the health IT developer's lawsuit would have to be designed to intimidate a communicator in order to prevent or discourage that communicator from making a protected communication, rather than be designed to pursue a legitimate legal interest. We believe that the proposed broad interpretation of “prohibit” and “restrict” is appropriate given the intention of the Cures Act, which placed no limitations on the protection of communications about the protected subject areas. We finalized this interpretation of “prohibit” and “restrict” proposed in 84 FR 7470 and believe that the interpretation would provide significant protections for whistleblowers from retaliatory actions. Thus, retaliatory actions by a developer against a whistleblower would be in violation of this provision. We also emphasize that conduct by a developer that may be perceived as intimidating or punitive would not implicate the Communications Condition of Certification requirements unless that conduct was specifically designed to influence the making of a protected communication. In other words, punitive actions must have a nexus to the making of a protected communication, such as retaliation for reporting of information blocking, in order to violate the Communications Condition of Certification requirements in § 170.403(a)(1). Last, we refer readers to the discussion of “complaints” under the information blocking section of this final rule, which details the confidentiality provided to information blocking complaints and complainants.
                    </P>
                    <P>We have finalized the Communications Condition of Certification requirements in § 170.403(a)(2)(i)(D) as proposed.</P>
                    <HD SOURCE="HD3">(E) Communicating Information About a Health IT Developer's Failure To Comply With a Condition of Certification or Other Program Requirement</HD>
                    <P>We proposed in 84 FR 7473 that the benefits to the public and to users of health IT of communicating information about a health IT developer's failure to comply with a Condition of Certification requirement or other Program requirement (45 CFR part 170) justify prohibiting developers of health IT from placing any restrictions on such protected communications. We explained that information regarding the failure of certified health IT to meet any Condition of Certification requirement or other Program requirement is vital to the effective performance and integrity of the Program. Moreover, the failure of a certified health IT to meet such requirements could impact the performance of the certified health IT with respect to usability, safety, and interoperability. We stated that it is important to enable unencumbered reporting of such information and that such reporting is essential to the transparency that section 4002 of the Cures Act seeks to ensure. While the current procedures for reporting issues with certified health IT encourage providers to contact developers in the first instance to address certification issues, we noted that users of health IT should not hesitate to contact ONC-Authorized Certification Bodies (ONC-ACBs), or ONC itself, if the developer does not provide an appropriate response, or the matter is of a nature that should be immediately reported to an ONC-ACB or to ONC.</P>
                    <P>We did not receive any comments on this aspect of the Proposed Rule. In consideration of the above, we have finalized this provision in § 170.403(a)(2)(i)(E) as proposed.</P>
                    <HD SOURCE="HD3">v. Permitted Prohibitions and Restrictions</HD>
                    <P>We proposed in 84 FR 7473 that, except for communications with unqualified protection (§ 170.403(a)(2)(i)), health IT developers would be permitted to impose certain narrow prohibitions and restrictions on communications. Specifically, we proposed that, with the exception of communications with unqualified protection, developers would be permitted to prohibit or restrict the following communications, subject to certain conditions:</P>
                    <P>• Communications of their own employees;</P>
                    <P>• Disclosure of non-user-facing aspects of the software;</P>
                    <P>• Certain communications that would infringe the developer's or another person's IP rights;</P>
                    <P>• Publication of screenshots in narrow circumstances; and</P>
                    <P>• Communications of information that a person or entity knows only because of their participation in developer-led health IT development and testing.</P>
                    <P>The proposed Communications Condition of Certification requirements delineated the circumstances under which these types of prohibitions and restrictions would be permitted, including certain associated conditions that developers would be required to meet. We emphasized that any prohibition or restriction not expressly permitted would violate the Communications Condition of Certification requirements. Additionally, we proposed that it would be the developer's burden to demonstrate to the satisfaction of ONC that the developer met all associated requirements. Further, as an additional safeguard, we proposed that where a developer sought to avail itself of one of the permitted types of prohibitions or restrictions, the developer must ensure that potential communicators are clearly and explicitly notified about the information and material that can be communicated, and that which cannot. We proposed this would mean that the language of health IT contracts must be precise and specific. We stressed that contractual provisions or public statements that support a permitted prohibition or restriction on communication should be specific about the rights and obligations of the potential communicator. We explained that contract terms that are vague and cannot be readily understood by a reasonable health IT customer would not benefit from the qualifications to this Condition of Certification requirement as outlined in the Proposed Rule and below.</P>
                    <HD SOURCE="HD3">(A) Developer Employees and Contractors</HD>
                    <P>We recognized in the Proposed Rule in 84 FR 7473 that health IT developer employees, together with the entities and individuals who are contracted by health IT developers to deliver products and/or services (such as consultants), may be exposed to highly sensitive, proprietary, and valuable information in the course of performing their duties. We also stated that we recognize that an employer should have the ability to determine how and when the organization communicates information to the public, and that employees owe confidentiality obligations to their employers. We noted that this would similarly apply to contractors of a developer. We proposed in 84 FR 7473 that on this basis, developers would be permitted to impose prohibitions or restrictions on the communications of employees and contractors to the extent that those communications fall outside of the class of communications with unqualified protection as discussed above.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that this provision should be clarified and expanded to cover other third parties with whom the health IT developer shares its confidential information, including subcontractors, agents, auditors, suppliers, partners, co-sellers, and re-sellers, as well as 
                        <PRTPAGE P="25731"/>
                        potential relationships for which a contract has not yet been signed in case information is shared during a pre-contract evaluation stage.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We reiterate that “developer employees and contractors” include health IT developer employees, together with the entities and individuals who are contracted by health IT developers to deliver health IT and/or services who may be exposed to highly sensitive, proprietary, and valuable information in the course of performing their duties. This functional description of employees and contractors could include subcontractors, agents, auditors, suppliers, partners, co-sellers, and re-sellers, depending on the specific relationship and circumstances. We have finalized the proposed approach to describing employees and contractors in § 170.403(a)(2)(ii)(A). We note that we did not expand this description to include “potential relationships” because such an addition would make the description overly broad, and it is unlikely that individuals who are not yet under contract would be exposed to highly sensitive, proprietary, and valuable information.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment that self-developers should not be permitted to place restrictions on the communications of their employees who are using their certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree that self-developers should not be allowed to restrict the communications of users of their certified health IT who are also employees or contractors. We have revised § 170.403(a)(2)(ii)(A) to clarify that the limited prohibitions developers may place on their employees or contractors under the Communications Condition of Certification requirements cannot be placed on users of a self-developer's certified health IT who are also employees or contractors of the self-developer. For example, a large health system with a self-developed EHR cannot restrict a health care provider, who is employed by that health system and using that EHR to provide services, from communicating about the EHR as a user based on the fact that the health care provider is also an employee of the health system. We note that the concept of “self-developed” refers to a Complete EHR or Health IT Module designed, created, or modified by an entity that assumed the total costs for testing and certification and that will be the primary user of the health IT (76 FR 1300).
                    </P>
                    <HD SOURCE="HD3">(B) Non-User-Facing Aspects of Health IT</HD>
                    <P>We proposed in 84 FR 7474 that the Communications Condition of Certification requirements would permit health IT developers to impose prohibitions and restrictions on communications to the extent necessary to ensure that communications do not disclose “non-user-facing aspects of health IT.” We noted that, like all permitted prohibitions, such prohibitions and restrictions could only be put in place by developers if there is not an unqualified protection that applies. We proposed in 84 FR 7474 that a “non-user-facing aspect of health IT,” for the purpose of this Condition of Certification, was an aspect of health IT that is not a “user-facing aspect of health IT.” We stated that “user-facing aspects of health IT” would include the design concepts and functionality that is readily ascertainable from the health IT's user interface and screen display. We stated that they did not include those parts of the health IT that are not exposed to persons running, using, or observing the operation of the health IT and that are not readily ascertainable from the health IT's user interface and screen display, all of which would be considered “non-user-facing” concepts. We proposed in 84 FR 7474 that “non-user-facing aspects of health IT” would include source and object code, software documentation, design specifications, flowcharts, and file and data formats. We welcomed comments on whether these and other aspects of health IT should or should not be treated as user-facing.</P>
                    <P>In the Proposed Rule, we noted that the terminology of “non-user-facing aspects of health IT” is not intended to afford only health IT users with specific protections against developer prohibitions or restrictions on communications and is agnostic as to the identity of the communicator.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern regarding the broad scope of “user-facing” and, by extension, the scope of “non-user-facing.” One commenter asked for clarification regarding the definition of “software documentation” with regards to non-user-facing aspects of health IT and suggested that it applies to documentation that is for back-end components, not documents for normal-end use. Additionally, a couple of comments stated that administrative functions should not be considered user-facing, including one comment that the relevant users for the purpose of the Communications Condition of Certification requirements are “end” users, thus the non-user-facing provision should apply only to “non-end-user-facing” aspects of health IT. Some commenters emphasized that administrative portions of health IT contain more insight into health IT systems and that administrative functions affect a limited number of users and are not the types of communications or subject matters contemplated by the Cures Act. One commenter stated that algorithms should be considered non-user-facing. Another commenter stated that ONC should clarify the status of diagrams and flowcharts.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not see a necessary or appreciable distinction between “users” and “end users,” as we have focused on the aspects of the health IT that are and are not subject to protected communications under this Condition of Certification. We also believe that there could be unintended consequences with the term “end user,” such as limiting certain users not specified under the “
                        <E T="03">permitted prohibitions and restrictions”</E>
                         (
                        <E T="03">e.g.,</E>
                         developer employees and contractors) from making protected communications. Therefore, we believe “non-user-facing” best reflects the scope of the communications about health IT we seek to capture with these terms.
                    </P>
                    <P>We reiterate that “non-user-facing aspects of health IT” comprise those aspects of the health IT that are not readily apparent to someone interacting with the health IT as a user of the health IT, including source and object code, certain software documentation, design specifications, flowcharts, and file and data formats. We clarify that “non-user-facing aspects of health IT” would also include underlying software that is utilized by the health IT in the background and not directly by a user of the health IT. For example, the programming instructions for proprietary APIs would be considered non-user-facing because they are not readily apparent to the individual users of the health IT. In addition, underlying database software that connects to health IT and is used to store data would be considered a non-user-facing aspect of health IT because it serves data to the health IT, not directly to a user.</P>
                    <P>
                        We further clarify that algorithms would be considered “non-user-facing aspects of health IT” as they are not readily apparent to persons using health IT for the purpose for which it was purchased or obtained. Thus, communications regarding algorithms (
                        <E T="03">e.g.,</E>
                         mathematical methods and logic) could be restricted or prohibited, while communications regarding the output of the algorithm and how it is displayed in 
                        <PRTPAGE P="25732"/>
                        a health IT system could not be restricted as “non-user-facing aspects of health IT.” Similarly, we also clarify that certain “software documentation” that would be considered to be a non-user-facing aspect of health IT would include documentation for back-end components, again because it is not readily apparent to persons using health IT.
                    </P>
                    <P>Whether or not a communication would be considered a “non-user-facing aspects of health IT” would be based on whether the communication involved aspects of health IT that would be evident to anyone running, using, or observing the operation of the health IT for the purpose for which it was purchased or obtained. With respect to administrative functions, where the communication at issue relates to aspects of the health IT that are not observable by users of the health IT, it would be considered “non-user-facing” for the purpose of this Condition of Certification requirement. For example, a communication regarding an input process delay experienced by an administrator of health IT that was caused by the underlying database software could be restricted if the communication discussed the underlying database software, which would be considered a non-user-facing aspect of the health IT. However, if the communication discussed the user screens and the delay experienced by the administrator, which would be considered user-facing aspects of health IT, it could not be restricted. Similarly, as long as diagrams or flowcharts do not include aspects of the health IT that are observable by users of the health IT, as described above, they would be considered communications about non-user-facing aspects of health IT.</P>
                    <P>We have finalized in § 170.403(a)(2)(ii)(B) our proposed approach to the scope of “non-user-facing aspects of health IT” with the clarification provided above regarding scope.</P>
                    <HD SOURCE="HD3">(C) Intellectual Property</HD>
                    <P>
                        We proposed in 84 FR 7474 that the Communications Condition of Certification requirements are not intended to operate as a de facto license for health IT users and others to act in a way that might infringe the legitimate IP rights of health IT developers or other persons. Indeed, we proposed in 84 FR 7474 that health IT developers are permitted to prohibit or restrict certain communications that would infringe their IP rights so long as the communication in question is not a communication with unqualified protection. We proposed in 84 FR 7474 that any prohibition or restriction imposed by a developer must be no broader than legally permissible and reasonably necessary to protect the developer's legitimate IP interests. We also proposed in 84 FR 7474 that health IT developers are not permitted to prohibit or restrict, or purport to prohibit or restrict, communications that would be a “fair use” of any copyright work comprised in the developer's health IT.
                        <SU>86</SU>
                        <FTREF/>
                         “Fair use” is a legal doctrine that allows for the unlicensed use of copyright material in certain circumstances, which could include circumstances involving criticism, commentary, news reporting, and research.
                        <SU>87</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>86</SU>
                             See 17 U.S.C. 107 (setting forth the four factors required to evaluate a question of fair use under the statutory framework).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>87</SU>
                             See 
                            <E T="03">https://www.copyright.gov/fair-use/more-info.html</E>
                             for more information on fair use.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that fair use should not override other IP protections and stressed that relying on fair use could lead to uncertainty because it is determined on a case-by-case basis. Another commenter stated that because the fair use doctrine can be difficult to implement and can lead to uncertain results, ONC should expand the list of communications that would be explicitly protected as fair use to include news reporting, criticism, parody, and communications for educational purposes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We disagree with commenters and believe that relying on the “fair use” doctrine for determining when a screenshot or other communication cannot be restricted should be allowed under the Communications Condition of Certification requirements. This doctrine presents a framework of analysis that is well-developed in case law and thus can be interpreted and applied consistently, even when materials are not formally copyrighted. Accordingly, we are retaining the concept of “fair use” in the final provision in § 170.403(a)(2)(ii)(C). Developers and ONC will apply a fair use test to copyrighted materials and, by analogy, to materials that could be copyrighted, to determine whether developers may prohibit a communication that would infringe on IP rights.
                    </P>
                    <P>The Communication Condition of Certification requirements relate only to protected communications, thus developers can place restrictions on communications about subject matters outside of the protected communications categories without implicating the Communications Condition of Certification requirements. Also, as discussed earlier regarding developer employees and contractors in § 170.403(a)(2)(ii)(A), developers may restrict communications by their employees, contractors, and consultants without implicating the Communications Condition of Certification requirements, provided they do not restrict communications with unqualified protections. Further, as described earlier regarding non-user-facing aspects of certified health IT in § 170.403(a)(2)(ii)(B), developers may restrict communications that disclose non-user-facing aspects of the developer's certified health IT, provided they do not restrict communications with unqualified protections. We clarified in that section that screenshots or videos depicting source code would be considered communications of non-user-facing aspects of health IT and could be restricted under the Communications Condition of Certification requirements as long as they did not receive unqualified protection. We also clarify that this Condition does not prohibit health IT developers from enforcing their IP rights and that a lawsuit filed by a health IT developer in response to a protected communication regarding infringement of IP rights would not automatically be considered intimidation or retaliation in violation of this Condition.</P>
                    <P>As discussed later in the pre-market testing and development section in § 170.403(a)(2)(ii)(E), developers can place restrictions on communications related to pre-market health IT development and testing activities, which could include IP protections, provided they do not restrict communications with unqualified protections. Combined, these avenues allow for protecting IP in ways that would not implicate the Communications Condition of Certification requirements, thereby allowing developers to take a number of actions to protect and safeguard IP in their certified health IT.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarity regarding how the proposed protections for IP would work. One commenter stated that the rule must allow developers to protect legitimate IP interests and asked for clarity on how ONC would determine whether a developer's restriction on the communication of a screenshot was an allowable protection of trade secrets or an impermissible restriction of protected communications. Several other commenters, who generally supported the Communications Condition of Certification requirements, requested clarification regarding how a 
                        <PRTPAGE P="25733"/>
                        prohibition on communications that is designed to protect IP can be applied. Some commenters requested examples of the types of communications that can be restricted on the basis of IP and clarification of the standard ONC will use to determine what prohibitions are permissible.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized an approach in § 170.403(a)(2)(ii)(C) that allows developers to prohibit or restrict communications that involve the use or disclosure of intellectual property existing in the developer's health IT (including third-party intellectual property), provided that any prohibition or restriction imposed by a developer must be no broader than necessary to protect the developer's legitimate intellectual property interests and consistent with all other requirements under the “permitted prohibitions and restrictions” (§ 170.403(a)(2)(ii)) of this section. As discussed above, a restriction or prohibition would be deemed broader than necessary and inconsistent with the “permitted prohibitions and restrictions” (§ 170.403(a)(2)(ii)) if it would restrict or preclude a public display of a portion of a work subject to copyright protection (without regard to whether the copyright is registered) that would reasonably constitute a “fair use” of that work.
                    </P>
                    <P>Examples of the types of communications that could be restricted under the Communications Condition of Certification requirements might include a blog post describing a customization of a developer's health IT that includes the source code of the developer's health IT or a written review of an analytical feature of the developer's health IT that reveals the algorithms used. However, as mentioned above, the restriction must be no broader than necessary to protect the developer's legitimate IP interests, thus only the infringing portions of the communications could be restricted.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that a health IT developer must demonstrate that a communication was specifically designed to copy or steal a developer's IP in order for the developer to be allowed to prohibit the communication as an infringement on their IP rights.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment, but decline to require that a developer demonstrate that a communication was designed to copy or steal IP in order for the developer to restrict the communication as one that would infringe on IP rights. We believe that the revised approach discussed above provides appropriate balance between protecting IP rights and enabling protected communications and do not believe that an “intent” element would be necessary. We have finalized the proposals regarding IP in § 170.403(a)(2)(ii)(C), as amended above.
                    </P>
                    <HD SOURCE="HD3">(D) Faithful Reproductions of Health IT Screenshots</HD>
                    <P>We proposed in 84 FR 7475 that health IT developers generally would not be permitted to prohibit or restrict communications that disclose screenshots of the developer's health IT. We proposed that the reproduction of screenshots in connection with the making of a communication protected by this Condition of Certification would ordinarily represent a “fair use” of any copyright subsisting in the screen display, and developers should not impose prohibitions or restrictions that would limit that fair use. Notwithstanding this, we proposed that health IT developers would be allowed to place certain restrictions of the disclosure of screenshots as specified in proposed § 170.403(a)(2)(ii)(D).</P>
                    <P>With respect to the limited allowable restrictions on screenshots, we proposed in 84 FR 7475 that developers would be permitted to prevent communicators from altering screenshots, other than to annotate the screenshot or to resize it for the purpose of publication. We also proposed that health IT developers could impose restrictions on the disclosure of a screenshot on the basis that it would infringe third-party IP rights (on their behalf or as required by license). However, to take advantage of this exception, we proposed in 84 FR 7475 that the developer would need to first put all potential communicators on sufficient written notice of those parts of the screen display that contain IP and cannot be communicated, and would still need to allow communicators to communicate redacted versions of screenshots that do not reproduce those parts. Finally, we proposed in 84 FR 7475 that it would be reasonable for developers to impose restrictions on the communication of screenshots that contain PHI, provided that developers permit the communication of screenshots that have been redacted to conceal PHI, or where the relevant individual's consent or authorization had been obtained.</P>
                    <P>We welcomed comments on whether an appropriate balance had been struck between protecting legitimate IP rights of developers and ensuring that health IT customers, users, researchers, and other stakeholders who use and work with health IT can openly discuss and share their experiences and other relevant information about the performance of health IT.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A large number of commenters, particularly health care providers, supported our proposals regarding the communication of screenshots, with several stressing how helpful screenshots are when communicating usability and safety issues with health IT. One commenter noted that communication of screenshots can help different health care systems understand whether a proposed implementation of an EHR has introduced safety-related challenges at other locations, or help identify solutions to common problems, such as usability challenges. One other commenter stated that there is nothing novel displayed in health IT screenshots that would need to be protected.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the many positive comments on our proposals regarding screenshots.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters stated that the scope of protected communications as proposed should exclude disclosure of the health IT itself, such as through screenshots. The commenter stressed that the Cures Act required that health IT developers not restrict communications about the certified health IT with respect to specific topic areas, while the Proposed Rule expands that restriction to include communication of the health IT itself. One commenter noted that the Cures Act does not mention screenshots and they should not be included in the Communications Condition of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Cures Act amended title XXX of the PHSA to establish this condition of certification, which applies to “health information technology.” Title XXX of the PHSA was previously added by the HITECH Act, which included the definition of “health information technology.” Section 3000(5) of the PHSA defines health information technology to mean hardware, software, integrated technologies or related licenses, IP, 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. We emphasize both that this definition includes IP associated with the health information technology and that it applies to this condition of certification as this condition references communications regarding health information technology. We have also adopted this definition in § 170.102.
                    </P>
                    <P>
                        We disagree with the commenters' interpretation of the statutory provision. The statutory provision focuses on “communications” regarding 
                        <PRTPAGE P="25734"/>
                        enumerated aspects of the health IT. Communications are not defined nor limited in the Cures Act, and we proposed to broadly define them. Verbal, written, and visual, as well other types of communications, are all covered under the Cures Act. A screenshot is a copy/picture of the user interface of the health IT, or a “visual communication” that is protected under this condition of certification. We have specifically defined “communication” for this section in § 170.403(c) to mean any communication, irrespective of the form or medium. The term includes visual communications, such as screenshots and video.
                    </P>
                    <P>As we emphasized in the Proposed Rule in 84 FR 7475, the sharing of screenshots (with accompanying annotation and/or explanatory prose) is often a critical form of communication of issues with health IT related to—for example—usability, user experience, interoperability, security, or the way the technology is used. We believe screenshots are uniquely helpful as a form of visual communication that can non-verbally illustrate the “user's experiences when using the health information technology” and the “manner in which a user of the health information technology has used such technology” as they relate intrinsically to both subject areas and capture those user experiences immediately and directly. Further, enabling screenshot sharing can allow for clearer, more immediate, and more precise communication on these pertinent issues, potentially helping a health system avoid costly, or even deadly, complications when implementing health IT. It is also our understanding that screenshots are often the only recourse a user in a network enterprise system has for capturing, documenting, and explaining their concerns. We clarify, however, that the sharing of a screenshot alone would not be considered a protected communication as it would need to be accompanied by an explanation of the issues or aspects of the health IT that the screenshot is meant to communicate or illustrate.</P>
                    <P>Considering the value of communicating significant issues regarding health IT through screenshots, we have finalized our proposal to include screenshots as a protected communications under the Cures Act. However, as discussed in responses to other comments below, we have revised our final policy in multiple ways.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that screenshots should be defined broadly to include video and other media that can be helpful in demonstrating challenges with EHRs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the recommendation that protections afforded to screenshots should extend to video. We clarify that, like screenshots, video is considered a form of visual communication. A video of a computer screen while a software program is in operation would capture the user experience of interacting with that program and essentially would show a number of screenshots from that program in rapid succession. We emphasize that video, similarly to individual screenshots, is a critical form of communication of issues with the health IT, including issues related to usability, user experience, interoperability, security, or the way the technology is used.
                    </P>
                    <P>As with screenshots, video is particularly useful in communicating a user's experience with health IT and the manner in which the user has used health IT. This is especially the case when issues of a temporal nature are involved. For example, video would be essential for illustrating a latency issue experienced during drug ordering that could not be communicated through screenshots or other forms of communication. Video also could be critical to demonstrating an issue with a clinical decision support alert that is designed to appropriately and timely notify the provider of a patient matter but fails to do so.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern regarding how a developer's IP may be impacted by the proposed Communications Condition of Certification requirements. Several commenters stated that the Proposed Rule goes beyond protecting communications for the purposes of patient safety and system improvement and would enable or require inappropriate sharing and disclosure of IP, potentially creating security risks, increased IP theft, and harming innovation and the marketplace for health IT. Several commenters stated that trade secrets, patent protections, and protections for confidential and proprietary information were not addressed or considered appropriately in the Proposed Rule, and that as a result it would be possible for bad actors to create pirated health IT based on the disclosure of screenshots and similar communications. Commenters stated that developers of health IT have successfully used licensing and nondisclosure agreements that apply to user-facing aspects of the technology to maintain the trade secret status of their health IT and that the Proposed Rule would impact their ability to do so and remain competitive in the market.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments regarding how a developer's IP may be impacted by the Communications Condition of Certification requirements. As discussed earlier in this section, participation in the Program is voluntary; and developers have the option to agree to the terms we have offered or to choose not to participate in the Program. However, we recognize the need to properly balance the protection of a developer's IP with the need to advance visual communications (
                        <E T="03">e.g.,</E>
                         screenshot and video communications) under the Communications Condition and Maintenance of Certification requirements, which we believe is critical to addressing—among other things—the usability, interoperability, and security of health IT. As discussed throughout this section and in section (C) above, we believe that we have properly considered and addressed health IT developers' IP rights in this final rule in § 170.403(a)(2)(ii)(C) by amending the proposed regulation as described above.
                    </P>
                    <P>We emphasize that the communication of screenshots is essential to protect public health and safety and that our final policies take a measured approach to responding to and addressing a real and substantial threat to public health and safety. The communication of screenshots enables providers, researchers, and others to identify safety concerns, share their experiences with the health IT, learn from the problems, and then repair dangers that could otherwise cause serious harm to patients. Our position is informed both by years of experience regulating health IT and overwhelming research and academia, which is discussed below.</P>
                    <P>
                        For instance, a study published in 2018 was performed to better characterize accessibility to EHRs among informatics professionals in various roles, settings, and organizations across the United States and internationally.
                        <SU>88</SU>
                        <FTREF/>
                         To quantify the limitations on EHR access and publication rights, the researchers conducted a survey of informatics professionals from a broad spectrum of roles including practicing clinicians, researchers, administrators, and members of industry. The results were analyzed and levels of EHR access were stratified by role, organizational affiliation, geographic region, EHR type, and restrictions with regard to 
                        <PRTPAGE P="25735"/>
                        publishing results of usability testing, including screenshots. Among faculty members and researchers, 72 percent could access the EHR for usability and/or research purposes, but, of those, fewer than 1 in 3 could freely publish screenshots with results of usability testing and half could not publish such data at all. Across users from all roles, only 21 percent reported the ability to publish screenshots freely without restrictions.
                        <SU>89</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>88</SU>
                             Khairat, S, et al. 2018 Assessing the Status Quo of EHR Accessibility, Usability, and Knowledge Dissemination. eGEMs (Generating Evidence &amp; Methods to improve patient outcomes), pp. 1-11, 
                            <E T="03">https://doi.org/10.5334/egems.228</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>89</SU>
                             Id. at 1.
                        </P>
                    </FTNT>
                    <P>
                        The study explained that the patient safety implications of EHR publication censorship and restricted EHR access are multiple. First, limiting institutions from sharing usability research findings can prevent the correction of known problems. Second, without public dissemination, poor design practices will propagate to future iterations of existing vendor systems. Finally, research efforts are directed away from real-world usability problems at a time when EHR systems have become widely deployed and when an urgency exists to accelerate usability testing. The study referenced the 2011 Institute of Medicine report (as discussed in the Proposed Rule and in additional detail below), which identified contractual restrictions as a barrier to knowledge regarding patient safety risks related to health IT.
                        <SU>90</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>90</SU>
                             Id. at 2.
                        </P>
                    </FTNT>
                    <P>
                        The study emphasized that the result of this level of censorship is that a vast majority of scientists researching EHR usability are either prevented from publishing screenshots altogether or must first obtain vendor permission, thus impeding the free dialogue necessary in communities of investigation.
                        <SU>91</SU>
                        <FTREF/>
                         The study argued that: (1) Lack of EHR access makes many critical EHR usability research activities impossible to conduct, and (2) publication censorship, especially regarding screenshots, means that even those usability studies which can be conducted may not have the impact they otherwise would. As a consequence, innovation can be stifled. As such, one of the recommendations made by the researchers was that there should be a mandate that screenshots and images from EHR systems be freely publishable without restrictions from copyright or trade secret constraints.
                        <SU>92</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>91</SU>
                             Id. at 7.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>92</SU>
                             Id. at 8.
                        </P>
                    </FTNT>
                    <P>
                        In the report by the Institute of Medicine that was noted above, entitled Health IT and Patient Safety: Building Safer Systems for Better Care,
                        <SU>93</SU>
                        <FTREF/>
                         the Committee on Patient Safety and Health Information Technology (Committee) explained that a significant impediment to gathering safety data is contractual barriers (
                        <E T="03">e.g.,</E>
                         nondisclosure, confidentiality clauses) that can prevent users from sharing information about health IT-related adverse events. They further explained that such barriers limit users' abilities to share knowledge of risk-prone user interfaces, for instance through screenshots and descriptions of potentially unsafe processes. In addition, some vendors include language in their sales contracts and escape responsibility for errors or defects in their software (
                        <E T="03">i.e.,</E>
                         “hold-harmless clauses”). The Committee concluded that these types of contractual restrictions limit transparency, which significantly contributes to the gaps in knowledge of health IT-related patient safety risks. Further, these barriers to generating evidence pose unacceptable risks to safety.
                        <SU>94</SU>
                        <FTREF/>
                         Based on these findings, the committee recommended that the Secretary of HHS should ensure insofar as possible that health IT vendors support the free exchange of information about health IT experiences and issues and not prohibit sharing of such information, including details (
                        <E T="03">e.g.,</E>
                         screenshots) relating to patient safety.
                        <SU>95</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>93</SU>
                             Institute of Medicine 2012. Health IT and Patient Safety: Building Safer Systems for Better Care. Washington, DC: The National Academies Press, 
                            <E T="03">https://doi.org/10.17226/13269</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>94</SU>
                             Id. at 3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>95</SU>
                             Id. at 7.
                        </P>
                    </FTNT>
                    <P>
                        Recently, the U.S. Food and Drug Administration (FDA) funded Brigham and Women's Hospital Center for Patient Safety Research and Practice to conduct an exploration of computerized prescriber order entry (CPOE)-related potential for errors in prescribing, particularly as these relate to drug name displays, and ordering and workflow design issues. The project investigated ways to better identify, understand, and prevent electronic ordering errors in the future.
                        <SU>96</SU>
                        <FTREF/>
                         However, the researchers noted that one large vendor would not grant permissions to share requested screenshots necessary for the study. This refusal ran counter to both the FDA's task order initial precondition as well as multiple high-level panels' health IT safety recommendations. The FDA emphasized that it is hard to justify from a safety viewpoint why such permission was withheld, despite the vendors' proprietary concerns. FDA explained that identifying, preventing, and learning from errors and improving prescribing safety should be a priority and should take precedence over commercial considerations (and to the extent correctable problems can be identified, likely would result in an improved commercial CPOE product). In cases where the FDA sought to illustrate problems in the system, they drew generic screenshots to illustrate the issue in question.
                        <SU>97</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>96</SU>
                             U.S. Food &amp; Drug Admin., UCM477419, Computerized Prescriber Order Entry Medication Safety: Uncovering and Learning from Issues and Errors, 
                            <E T="03">https://www.fda.gov/downloads/Drugs/DrugSafety/MedicationErrors/UCM477419.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>97</SU>
                             Id. at 44.
                        </P>
                    </FTNT>
                    <P>
                        Among their recommendations, the FDA recommended that vendors be required to share screenshots and error reports. The FDA emphasized that vendors should be required to permit the sharing of screenshots and information with the FDA and other institutions regarding other CPOE system issues of concern or that pose risk for errors. They stressed that the practice of prohibiting such sharing via copyright must be eliminated. Further, the FDA recommended that vendors should be required to disclose errors reported to them or errors identified in their products, analogous to the requirement that drug manufacturers report significant adverse drug effects.
                        <SU>98</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>98</SU>
                             Id. at 52.
                        </P>
                    </FTNT>
                    <P>
                        One of the co-authors of the FDA study recently wrote a law review article that discussed the significance of screenshots.
                        <SU>99</SU>
                        <FTREF/>
                         The author noted that the results of the FDA study were remarkable and remarkably distressing, as they identified and took screenshots of over fifty different dangers in the health IT. He expressed frustration that it took up to two years of additional discussions with the vendors to get permission to share the screenshots publicly, and that even after these extended discussions, one vendor—“with more than a lion's share of the market”—prevented the study from displaying the screenshots, some of which were clearly dangerous or deadly. He explained that they had worked around that limitation by substituting the one vendor's screens with parallel screens taken from Harvard's homegrown, but by then superannuated, EHR. The author emphasized that those images and screenshots illustrated over fifty EHR risks caused by dangerous and confusing EHR interfaces. The author also emphasized that the study could have been even more helpful in identifying these risks if the FDA had been able to present the findings when first available, rather than haggle for a year or two, and if the study was able 
                        <PRTPAGE P="25736"/>
                        to include all of the full images from each system they studied.
                        <SU>100</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>99</SU>
                             Ross Koppel, Uses of the Legal System That Attenuate Patient Safety, 68 DePaul L. Rev. (2019) Available at: 
                            <E T="03">https://via.library.depaul.edu/law-review/vol68/iss2/6</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>100</SU>
                             Id. at 280-81.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter recommended that ONC draw a distinction around purpose of use in relation to the fair use of screenshots and require that the discloser of a screenshot be responsible for ensuring the appropriateness of that purpose.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed under section (C) above we have retained the concept of “fair use” as it applies to all health IT developer intellectual property covered under “permitted prohibitions and restrictions” (§ 170.403(a)(2)(ii)). As discussed throughout this section, we have placed certain restrictions on the sharing of screenshots responsive to the commenter.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter urged ONC to revise the proposed approach to screenshots by adopting a process that would allow developers to review and approve screenshots for publication for specific purposes, such as communications about safety and usability.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         A pre-approval process could create potential or perceived barriers to communications and thus could discourage or delay the making of protected communications that are vital to patient safety or other important issues regarding certified health IT. For example, a user might be less willing to go through the process, the time the process takes could undermine the conveyance of the communications, and the objections raised during the process may not be valid or amenable to all parties.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters had concerns regarding the volume of screenshots that could be shared under our proposal and potential harms that could occur. One commenter emphasized that sharing of screenshots could disclose information about how health IT works, including algorithms and workflows, and enable creation of duplicate software and theft of valuable IP. One commenter suggested that if a user of health IT published hundreds of screenshots of the health IT, a bad actor could theoretically deduce trade secrets based on the screenshots. Several additional commenters were also concerned that the Proposed Rule could allow communication of an unlimited number of screenshots of certified health IT, and one commenter suggested revising the proposed approach to include limiting sharing of screenshots to a reasonable number, such as seven.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate those comments expressing concerns regarding the volume of screenshots that could be shared and the potential negative consequences of allowing screenshots to be shared. In the Proposed Rule in 84 FR 7475, we proposed to allow developers to place limited restrictions on the sharing of screenshots. We stressed in the Proposed Rule that our goal with our proposals concerning screenshots was to enable communications that will address matters such as patient safety, system security vulnerabilities, health IT performance, and usability. Our intent was not to prevent developers from restricting the communication of screenshots for purposes outside the scope of the protected communications detailed in the Cures Act. Additionally, we believe that modern software design best practices uncouple screen design from underlying algorithms, and that limited use of screenshots for safety would not allow reverse engineering of large parts of the underlying code. However, we further emphasize that it was never our intention that screenshots (or other visual communications such as video) depicting source or object codes would be protected communications (
                        <E T="03">see</E>
                         the non-user-facing aspects provision of this Condition of Certification), so long as such communications are not communications with unqualified protection.
                    </P>
                    <P>
                        We reviewed comments that suggested establishing a set numerical limit for the sharing of screenshots. However, we have not finalized a requirement in § 170.403(a)(2)(ii)(D) with a fixed numerical limit because there is no non-arbitrary way to determine what the “right” or “appropriate” number is in a one-size-fits-all way. That is because the number of screenshots or amount of video that would be needed to communicate about the health IT could vary, from one situation to the next, based on the specific issue and circumstances. For instance, an issue with health IT functionality regarding a particular process that involves the user viewing and making selections on several different screens may necessitate images of all of the screens involved in order to communicate the issue. However, an issue regarding how one value is being displayed in a particular context (
                        <E T="03">e.g.,</E>
                         a medication name being truncated) may only necessitate one screenshot in order to communicate the issue. Thus, we believe the best approach is to adopt a qualitative standard that is designed to be sufficiently flexible for the wide range of health IT issues that may arise and the varying visual communications that need to be communicated to demonstrate or display the issue.
                    </P>
                    <P>
                        We have finalized provisions in § 170.403(a)(2)(ii)(D)(
                        <E T="03">2</E>
                        ) and (
                        <E T="03">3</E>
                        ) that allow health IT developers to require persons who communicate screenshots to limit the sharing of screenshots to only the relevant number of screenshots and amount of video that are needed to communicate about the health IT regarding one or more of the six subject areas identified in the Cures Act and detailed in § 170.403(a)(1). Allowing developers to limit the sharing of screenshots to only the relevant number needed to communicate about the health IT—regarding one or more of those six subject areas—places a limitation on the number of screenshots allowed to be shared under the Communications Condition of Certification requirements and requires that the screenshots are related to, and thus necessary in illustrating, the protected communication being made. In practice, this would mean that if a particular safety issue in the health IT could be communicated using three screenshots, the communicator should not share additional screenshots that are irrelevant or only potentially relevant to communicate the safety issue with the health IT. If the communication included additional screenshots that were not necessary to visually communicate about the particular safety issue with the health IT that falls within the usability category, the health IT developer would have grounds to seek redress.
                    </P>
                    <P>
                        As with screenshots, we wish to be sensitive to concerns regarding protecting IP in health IT and allow developers to appropriately limit video communication in order to protect against harms that could occur due to unlimited sharing. Similar to screenshots, the amount of video that may be necessary to make a protected communication about health IT could vary, depending on the nature of the issue or aspect of the health IT being addressed. For example, a video meant to communicate a delay in order entry would need to be long enough to communicate the significance of the delay, but would not need to include video of the log-in process or other unrelated functionality of the health IT. We have finalized a provision in § 170.403(a)(2)(ii)(D)(
                        <E T="03">3</E>
                        ) that allows health IT developers to place certain limitations on the communication of video. Under this provision, a health IT developer may require persons who communicate video to limit the sharing of video to: (1) The relevant amount of video needed to communicate about the health IT regarding one or more of the 
                        <PRTPAGE P="25737"/>
                        subject areas identified in the Cures Act and detailed in § 170.403(a)(1); and (2) only videos that address temporal matters that the user reasonably believes cannot be communicated through screenshots or other forms of communications.
                    </P>
                    <P>In sum, any disclosure must be limited to the relevant number of screenshots or amount of video that is necessary to convey the matter that falls within one of the six subject areas, with video only being used to convey temporal matters that cannot be communicated through screenshots or other forms of communication. We believe these additional limitations on the communication of screenshots and video will further bolster protections for developer IP, while still allowing necessary and effective communication about health IT issues within the six subject areas.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters stated that there should be a way to protect against doctored screenshots.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As proposed, communicators of screenshots must not alter the screenshots (or video), except to annotate the screenshots or resize the screenshots (§ 170.403(a)(2)(ii)(D)(
                        <E T="03">1</E>
                        )). These restrictions similarly apply to video as well (§ 170.403(a)(2)(ii)(D)(
                        <E T="03">1</E>
                        )). We further note that, despite a lack of comments, on further reflection, we have elected to not finalize proposed limitations to allow developers to impose restrictions on the communication of screenshots that contain PHI. We have made this determination because we believe that most of the individuals or entities communicating the screenshots would be bound by other laws, including the HIPAA Rules and State privacy laws, which would be applicable to the PHI at issue. Therefore, we do not believe it is necessary to provide for developers policing the release of such data in the form of screenshots in this Condition of Certification.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters discussed the infeasibility of the proposed requirements regarding restricting communication of screenshots, and in particular, the requirement that health IT developers put all potential communicators on sufficient written notice of each aspect of its screen display that contains third-party content that cannot be communicated because it would infringe IP rights. Some commenters stated that the proposed language should be amended to require a list of third-party content that might appear in a screen or that the developer sublicenses, or to require a notice on the developer's website. Other commenters stated that the proposal should be removed. One commenter recommended ONC consider not making developers accountable for actions by health IT users regarding the disclosure of screenshots with third-party information. One commenter requested additional guidance from ONC for dealing with third-party, non-health IT content in health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Where a health IT developer is prohibited by this rule from restricting the communication of a screenshot and allows a screenshot containing third-party content to be communicated, the health IT developer is acting as required by this final rule and enabling important communication regarding critical health IT issues to occur. Thus, we believe developers acting in accordance with this final rule should not be responsible for third-party content in screenshots that are communicated as required by the Communications Condition of Certification requirements. As such, in § 170.403(a)(2)(ii)(D) we have removed from the requirements related to third-party IP rights proposed in 84 FR 7475.
                    </P>
                    <HD SOURCE="HD3">(E) Testing and Development</HD>
                    <P>We discussed in the Proposed Rule in 84 FR 7475 that some health IT developers expose aspects of their health IT to health care providers and others for the purpose of testing and development prior to a product's “general availability” release. We stated that such disclosures may relate to beta releases that are shared with certain customers for testing prior to the software being made generally available to the market, or may be made as part of a joint-venture or cooperative development process. In these circumstances, we proposed in 84 FR 7475 that a health IT developer would be justified in keeping information about its health IT confidential. We explained that this permitted prohibition or restriction would allow developers to seek appropriate IP protection and discuss novel, “unreleased” product features with their customer base, which has significant public policy benefits for research and innovation in the health IT industry.</P>
                    <P>We proposed in 84 FR 7475 that this permitted restriction would be limited and would not apply to communications that are subject to unqualified protection as specified in proposed § 170.403(a)(2)(i). We proposed that this permitted restriction would also not apply to communications about the released version of the health IT once the health IT has been released.</P>
                    <P>We requested comment on whether we should limit the time this protection would apply for testing purposes. We also requested comment on whether we should set specific parameters for covered testing.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters stated that there should be no limit on how long testing and development could last for the purpose of the restrictions that developers would be allowed to place on communications regarding products in development. These commenters stressed that any limit would be arbitrary and that until certified health IT is in live commercial use, health IT developers should be permitted to restrict communications about it.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenters and did not propose to add a time limit on testing and development phases for the purpose of this Condition of Certification requirement.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters requested clarification that providers testing products in real-world environments would not be considered “contractors” of developers for the purpose of the Communications Condition of Certification requirements because such treatment could result in developers being allowed to place additional communication restrictions on employees and contractors under the Communication Condition of Certification requirements. One comment also stated that restrictions on communications by employees and contractors should not extend to their communications regarding product features and functionality that the employees and contractors were not involved in developing or testing.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The applicability of this allowable restriction to providers testing products would be determined by the particular facts at issue and whether or not the provider was an actual contractor, employee, or consultant for the developer. We also clarify that this final rule does not limit the restrictions a developer may place on an employee, contractor, or consultant with regard to protected communications, except to the extent that the communication is one with unqualified protection, in which case no such restrictions would be allowed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that a health IT user must have used health IT in a real-world context before a communication by the user about the health IT can be protected.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized our proposal in § 170.403(a)(2)(ii)(E) that a health IT developer would be justified in keeping information about its health 
                        <PRTPAGE P="25738"/>
                        IT confidential prior to a product's “general availability” release. We note that a health IT developer would also be justified in keeping information about a product update confidential because the update is not yet generally available. We do not place any limits on who the communicator has to be in order to be covered by the Communications Condition of Certification requirements, particularly since the protections in the Communications Condition of Certification requirements extend beyond users of certified health IT to cover researchers and other stakeholders who may experience certified health IT in a variety of settings and scenarios. As such, we have decided not to limit the communication protection to only those communications that are made by users of certified health IT in the real-world context.
                    </P>
                    <HD SOURCE="HD3">c. Maintenance of Certification Requirements</HD>
                    <P>We proposed in 84 FR 7476 that to maintain compliance with the Communications Condition of Certification requirements, a health IT developer must not establish or enforce any contract or agreement provision that contravenes the Communications Condition of Certification requirements. We also proposed in 84 FR 7476 that a health IT developer must notify all entities or individuals with which it has a contract/agreement related to certified health IT that any communication or contract/agreement provision that contravenes the Communications Condition of Certification requirements will not be enforced by the health IT developer. We proposed in 84 FR 7476 that such notification must occur within six months of the effective date of the final rule. Further, we proposed in 84 FR 7476 that this notice would need to be provided annually up to and until the health IT developer amends the contract or agreement to remove or make void any contractual provision that contravenes the Communications Condition of Certification requirements. We further proposed as a Maintenance of Certification requirement in proposed § 170.403(b)(2) that health IT developers must amend their contracts/agreements to remove or make void any provisions that contravene the Communications Condition of Certification requirements within a reasonable period of time, but not later than two years from the effective date of a final rule.</P>
                    <P>In the event that a health IT developer cannot, despite all reasonable efforts, locate an entity or individual that previously entered into an agreement with the developer that prohibits or restricts communications protected by the Communications Condition of Certification requirements, we proposed in 84 FR 7476 that the developer would not be in contravention of the Communications Condition of Certification requirements so long as it takes no step to enforce the prohibition or restriction. We did not propose that health IT developers be required to furnish to ONC or their ONC-ACB copies of notices made to customers, or copies of contracts or agreements revised, in satisfaction of this Maintenance of Certification requirement, although we noted that those communications could be requested by ONC or an ONC-ACB in the usual course of business or to demonstrate compliance.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed concerns regarding the proposed deadlines for complying with the requirements. Several commenters stated that the requirement to notify customers and others with whom the developer has contracts or agreements within six months was too long and recommended that the deadline be shortened. Regarding the deadline for amending contracts/agreements that contravene the Communications Condition of Certification requirements, most commenters stated that the deadline was too short, with several requesting that it be extended to five years. Some other commenters recommended that modification of any contracts/agreements to comply with the Communications Condition of Certification requirements should occur whenever such contracts/agreements are renewed, or at the earliest available time, without the need for a specific deadline. A couple of commenters recommended that a health IT developer not be held responsible for amending contracts within two years of the effective date of the final rule if it has made reasonable efforts to do so. Several comments recommended that ONC should allow alternative means of completing this requirement, such as posting relevant language on the developer's website. One commenter stated that it would be helpful to have a “standard exception clause” that developers could use in their contracts and agreements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments we received on this provision. We clarify in § 170.403(b)(2)(i) that a developer may not include provisions that contravene the Communications Condition of Certification requirements in any new contract as of the effective date of the final rule. In consideration of comments, we have decided to modify the timeframe requirement proposed in 84 FR 7476 for amending contracts/agreements to be in compliance with this condition. While we considered extending the deadline to five years to allow developers to have additional time for compliance, we determined that a more flexible solution is appropriate. As such, we have modified the requirement in § 170.405(b)(2)(ii) to state that any contracts/agreements in place as of the effective date of the final rule and containing language in contravention of the Communications Condition of Certification requirements must be revised to remove or void the contractual provision that contravenes the Communications Condition of Certification requirements whenever the contract is next modified for any reason. We clarify that where a contract automatically renews, the developer would still be prohibited under the Program from enforcing any agreement or contract provisions that contravene the Communications Condition of Certification requirements in § 170.403(a) and the developer would also be responsible for sending an annual notice as described above until such provisions have been modified. To note, we decline to absolve a developer of the requirement to modify the contract solely because the developer has made a reasonable effort to do so.
                    </P>
                    <P>
                        We finalized the notification requirements proposed in 84 FR 7476. A health IT developer must notify all entities and individuals with which it has a contract/agreement related to certified health IT that any communication or contract/agreement provision that contravenes the Communications Condition of Certification requirements will not be enforced by the health IT developer. However, we no longer require that such notification must occur within six months of the effective date of the final rule and annually thereafter until contravening provisions are amended. Instead, notification must only occur annually, beginning in calendar year 2020, and continue until all contravening provisions are amended. Given the timing of the publication of the final rule, health IT developers could have potentially been required to provide both initial notification and an annual notification in the same calendar year. We believe the removal of the six months notification deadline and retention of an annual requirement only, beginning with notification in calendar year 2020, will simplify compliance for health IT developers while still providing adequate notice and ensuring that initial notification is provided in a reasonable amount of time. Therefore 
                        <PRTPAGE P="25739"/>
                        we have finalized the deadline for the notice requirement in § 170.403(b)(1) to be annually, beginning in calendar year 2020.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarification that once the final rule goes into effect, contravening provisions in developer contracts prohibiting communications cannot be enforced. One of these commenters stated that developers would often include language in their contracts prohibiting communication on the part of end users and entities, thus preventing communication about issues with EHRs. Several commenters requested that ONC explicitly state that any permitted communication made following the effective date of the final rule be inadmissible as a violation of a contract/agreement regardless of whether the customer has been notified. One commenter requested that ONC clarify that, with respect to protecting communications regarding developer business practices, where the disclosure of certain information is prohibited by contract, the developer would not be liable for its inability to communicate such information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We emphasize that as of the effective date of the final rule, contravening provisions in contracts or agreements cannot be enforced without the risk of losing certification for the developer's health IT or a certification ban for the developer under the Program, regardless of whether the customer was notified as required by the Communications Condition of Certification requirements. We clarify that provisions of contracts requiring that the health IT customer “flow-down” obligations onto the customer's employees, contractors, and other users of the health IT that would restrict protected communications would be in contravention of this Condition of Certification. Such provisions could not be enforced after the effective date of the final rule without risking loss of certification as noted above for the developer under the Program.
                    </P>
                    <P>We appreciate commenters' concern regarding disclosing information that may be otherwise prohibited by contract. However, we clarify that the purpose of the Communications Condition of Certification requirements is to prevent developers from improperly restricting protected communications, including communications about a developer's practices and policies related to facilitating the exchange of health information. As discussed earlier in this section, costs, timeframes, licensing practices and terms, as well as the developer's approach to working with third-party services, could all be considered protected communications to the extent they relate to facilitating the exchange of health information. Thus, we reiterate that where a contract entered into by the developer would restrict a communication protected by the Communications Condition of Certification requirements, the developer may not enforce such a contract and may not restrict a protected communication in violation of the Communications Condition of Certification requirements after the effective date of the final rule without risking loss of certification. It is also important to note that not all contractual provisions related to communications would create a risk of de-certification. As noted above, the Communications Condition of Certification requirements in § 170.403(a)(2)(ii) do allow for developers to place restrictions on certain communications as discussed above. Therefore, contractual provisions that appropriately address those allowances would not create a risk of de-certification under the Program.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested that “renew” should be added to the maintenance requirement to not establish or enforce any contract or agreement that contravenes the Communications Condition of Certification requirements in § 170.403(a).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment and amended the proposed regulatory text in § 170.403(b)(2)(i) to include “renew.” We clarify that where a contract auto-renews, the developer would still be prohibited under the Program from enforcing any agreement or contract provisions that contravene the Communications Condition of Certification requirements without risking loss of certification and would also be responsible for sending an annual notice as described above until such provisions have been modified.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters expressed concern about developer efforts to re-negotiate other terms of a contract that are unrelated to protected communications as part of the contract modification process.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We stress that the contract modifications required as part of the Communications Condition of Certification requirements are strictly limited to removing any provisions of the relevant contract/agreement that would restrict protected communications in contravention of the Communications Condition of Certification requirements and are not required to be done until the contract/agreement is modified for other purposes.
                    </P>
                    <HD SOURCE="HD3">4. Application Programming Interfaces</HD>
                    <P>The API Condition of Certification requirement in Section 4002 of the Cures Act requires health IT developers to publish 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 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.” Additionally, the API Condition of Certification requirement of the Cures Act includes several key phrases and requirements for health IT developers that go beyond the technical functionality of the Health IT Modules they present for certification. In this section of the preamble, we outline the proposals we have adopted to implement the API Condition of Certification requirement of the Cures Act to provide compliance clarity for health IT developers.</P>
                    <P>We have adopted new standards, new implementation specifications, a new certification criterion, Condition and Maintenance of Certification requirements, and modified the Base EHR definition. Health IT developers should consider these final requirements in the context of information blocking provisions described in section VIII of this preamble.</P>
                    <HD SOURCE="HD3">a. Statutory Interpretation and API Policy Principles</HD>
                    <P>Section 4002 of the Cures Act requires health IT developers certified to the Program to publish 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.” To implement the Cures Act API requirements, we proposed a new 2015 Edition Cures Update “API” certification criterion at 84 FR 7476 that included requirements for an API to have “read” capabilities that support two types of services: (1) Services for which a single patient's data is the focus; and (2) services for which multiple patients' data are the focus.</P>
                    <P>
                        We conveyed in the Proposed Rule our belief that “without special effort” requires APIs and the health care ecosystem in which they are deployed to be standardized, transparent, and pro-
                        <PRTPAGE P="25740"/>
                        competitive. Therefore, we noted that any Health IT Module certified to the new 2015 Edition Cures Update API criterion and a health IT developer's business practices would have to have these attributes.
                    </P>
                    <HD SOURCE="HD3">b. API Standards and Implementation Specifications</HD>
                    <HD SOURCE="HD3">i. Base Standard</HD>
                    <P>We proposed in § 170.215(a)(1) at 84 FR 7477 to adopt HL7® FHIR® Draft Standard for Trial Use (DSTU) 2 for reference in the criterion proposed in § 170.315(g)(10). Additionally, we requested comment in 84 FR 7478 and 7479 on four options to determine the best version of HL7 FHIR to reference for use in §  170.315(g)(10): Option 1: FHIR DSTU 2, Option 2: FHIR DSTU 2 and FHIR Release 3, Option 3: FHIR DSTU 2 and FHIR Release 4, and Option 4: FHIR Release 4 only. We requested commenters review the proposed certification criterion in § 170.315(g)(10) and the accompanying Condition of Certification requirements attributed to the API certification criteria. Notably, we stated in the Proposed Rule at 84 FR 7479 that if we adopted another FHIR Release in a final rule as an alternative to FHIR Release 2 for the proposed API criterion in § 170.315(g)(10), then we would also adopt the applicable implementation specifications associated with the FHIR Release.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received overwhelming support for Option 4: Adopt solely FHIR Release 4 in the final rule for reference in § 170.315(g)(10). We received support for the adoption of FHIR Release 4 across a broad array of stakeholders, including health IT developers, medical trade associations, software application developers, and payers. Commenters noted that FHIR Release 4 is the first FHIR release with normative FHIR resources and support for enhanced capabilities. Most commenters emphasized that Option 4 will allow the industry to unify and focus on a single baseline standard, rather than accommodating multiple releases proposed in Options 2 and 3. A minority of commenters suggested alternative or multiple versions, noting this would allow for flexibility, but the vast majority of commenters supported the adoption of FHIR Release 4 only.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback and agree with commenters that adoption of a single standard is the best option to align industry and enable widespread interoperability. We have adopted the latest version of the standard at the time of this final rule publication (FHIR Release 4.0.1) in § 170.215(a)(1) and finalized its use in § 170.315(g)(10).
                    </P>
                    <HD SOURCE="HD3">ii. United States Core Data for Interoperability</HD>
                    <P>We proposed in § 170.215(a)(2) at 84 FR 7479 to adopt the API Resource Collection in Health (ARCH) Version 1 implementation specification, which listed a set of base HL7® FHIR® resources that Health IT Modules certified to the proposed criterion in § 170.315(g)(10) would need to support.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters were opposed to the adoption of the ARCH in the final rule. Commenters argued for the use of American National Standards Institute accredited standards, and suggested ONC work with standards developing organizations for standards development and maintenance.
                    </P>
                    <P>Several commenters noted that the ARCH has not gone through a formal balloting process, did not support ONC's proposal to rely upon the National Technology Transfer and Advancement Act's exception to adopt the ARCH in the final rule, and encouraged the use of technical standards developed or adopted by voluntary consensus standards bodies. Several commenters noted that requiring the ARCH in addition to the other adopted standards could create confusion. Commenters further emphasized the importance of maintaining ongoing consistency between the ARCH and the other adopted standards, and noted this would be challenging to achieve.</P>
                    <P>Additional comments against the ARCH expressed concern with the proposed updates through the Standards Version Advancement Process, and with ONC over-regulating API functionality. Commenters also noted that ONC could encourage API access to specific data elements without creating a new implementation specification.</P>
                    <P>Some commenters in favor of the ARCH implementation specification asked for data element revisions. Commenters also asked for clarity that EHRs will not need to provide the full set of data to modular applications, and asked for specificity on how much of this data would need to be mapped by the API Technology Supplier. Additionally, commenters asked for guidance on lab results, including application creation implementation guides that would ensure accuracy and compliance when incorporating lab data.</P>
                    <P>
                        <E T="03">Response.</E>
                         In response to commenters, we did not adopt the ARCH as an implementation specification in the final rule. Upon consideration of public comments and in an effort to consistently approach how we reference the United States Core Data for Interoperability (USCDI) with various content standards (
                        <E T="03">e.g.,</E>
                         C-CDA), we determined that having an implementation specification to map USCDI to HL7 FHIR could create more restrictions than we intended. We appreciate the concerns raised by stakeholders, and as we evaluated the ARCH in context of our other proposals, we determined that we could achieve our desired policy outcome to link the USCDI Data Elements to FHIR Resources without the ARCH. We refer commenters to the sections that follow for further clarity regarding the implementation of Data Elements included in the USCDI implementation specification (IV.B.1).
                    </P>
                    <HD SOURCE="HD3">iii. US Core IG and Bulk IG</HD>
                    <P>
                        We proposed in 84 FR 7480 in § 170.215(a)(3) to adopt the Argonaut Data Query Implementation Guide version 1 (Argonaut IG) implementation specification, which specifies constraints for 13 of the HL7® FHIR
                        <E T="03">®</E>
                         resources proposed in § 170.215(a)(2). Additionally, we proposed in § 170.215(a)(4) to adopt the Argonaut Data Query Implementation Guide Server implementation specification.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters advocated for the adoption of the FHIR US Core Implementation Guide STU 3 Release 3.0.0 implementation specification instead of the Argonaut Implementation Guides. Commenters noted that the US Core Implementation Guide was built from the Argonaut Implementation Guides and has been balloted by the standards community.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We note that in the Proposed Rule at 84 FR 7479 we stated that if we were to adopt another FHIR Release in the final rule as an alternative to FHIR Release 2, then we would also adopt the applicable implementation specifications and FHIR profiles associated with the FHIR Release. Considering this and commenters' recommendations, we have adopted the HL7 FHIR US Core Implementation Guide STU 3.1.0 (US Core IG) implementation specification in § 170.215(a)(2). We note that we adopted the latest version of the US Core IG at the time of the final rule publication. The US Core IG defines the minimum conformance requirements for accessing patient data using FHIR Release 4 (adopted in § 170.215(a)(1)), including profiled resources, operations, and search parameters for the Data Elements required in the USCDI implementation specification (adopted in § 170.213).
                        <PRTPAGE P="25741"/>
                    </P>
                    <P>We note that in the Proposed Rule at 84 FR 7479 we proposed to require that the “Patient.address” and “Patient.telecom” elements of the “Patient” resource must be supported. We note these requirements have since been subsumed by the US Core IG, given that “Patient.address” and “Patient.telecom” elements are both flagged “must support” for the “Patient” profile in the US Core IG. We also proposed to require that the “Device.udi” element follow the human readable representation of the unique device identifier found in the recommendation, guidance, and conformance requirements section of the “HL7 Version 3 Cross Paradigm Implementation Guide: Medical Devices and Unique Device Identification Pattern, Release 1.” These requirements have also been subsumed by the US Core IG. Additional information can be found in the “Device” profile of the US Core IG adopted in § 170.215(a)(2).</P>
                    <P>
                        We note that in the Proposed Rule we proposed in 84 FR 7480 that the clinical note text included in the “DocumentReference” resource would need to be represented in its “raw” text form, and further proposed in 84 FR 7480 that it would be unacceptable for the note text to be converted to another file or format (
                        <E T="03">e.g.,</E>
                         .docx, PDF) when it is provided as part of an API response. We clarify that the clinical note text included in any of the notes described in the “Clinical Notes Guidance” section of the US Core IG adopted in § 170.215(a)(2) must be represented in a “plain text” form, and would be unacceptable for the note text to be converted to another file or format (
                        <E T="03">e.g.,</E>
                         .docx, PDF) when it is provided as part of an API response.
                    </P>
                    <P>We note that in the Proposed Rule we proposed in 84 FR 7480 to require that the “Provenance.recorded” and “Provenance.agent.actor” elements of the “Provenance” resource must be supported. We note these requirements have been subsumed by the US Core IG, given that “Provenance.recorded” and “Provenance.agent.who” elements are both flagged “must support” for the “Provenance” profile in the US Core IG.</P>
                    <P>As addressed under the header “Standardized API for Patient and Population Services” in the section V.B.4.c, we have finalized the adoption of the HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (Bulk IG), including mandatory support for the “group-export” “OperationDefinition” in § 170.215(a)(4).</P>
                    <HD SOURCE="HD3">iv. HL7 SMART IG and Backend Services Authorization</HD>
                    <P>We proposed in 84 FR 7481 in § 170.215(a)(5) to adopt the HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0 implementation specification, a profile of the OAuth 2.0 specification.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters expressed support for the HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0 (SMART IG) implementation specification. Multiple commenters suggested that in addition to requiring support for “refresh tokens,” “Standalone Launch,” and “EHR Launch” capabilities from the SMART IG, ONC also require support for “sso-openid-connect,” “launch-standalone,” “launch-ehr,” “client-public,” “client-confidentialsymmetric,” “context-ehr-patient,” “context-standalone-patient,” “permission-patient,” “permission-user,” and “permission-offline” capabilities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank stakeholders for their comments. The ten optional capabilities commenters suggested are included in the “SMART on FHIR Core Capabilities” section of the SMART IG. The “SMART on FHIR Core Capabilities” suggested by commenters include “sso-openid-connect,” which allows for support of the OpenID Connect profile in the SMART IG; “client-public” and “client-confidential-symmetric,” which allow for client authentication; “context-ehr-patient” and “context-standalone-patient,” which provide context to apps at launch time; and “permission-patient,” “permission-user,” and “permission-offline,” which allow support for patient-level scopes, user-level scopes, and refresh tokens, respectively. Other “SMART on FHIR Core Capabilities” that were not suggested by commenters include “context-banner” and “context-style,” which provide basic context to apps at launch time, and ”context-ehr-encounter” and “context-standalone-encounter,” which provide encounter-level granularity to apps at launch time. Given the importance of these “SMART on FHIR Core Capabilities,” and in consideration of public comments and our own research, we have adopted the SMART IG, including mandatory support for the “SMART on FHIR Core Capabilities” in § 170.215(a)(3). We explicitly require mandatory support of the “SMART on FHIR Core Capabilities” in § 170.215(a)(3) because these capabilities are indicated as optional in the implementation specification. We further clarify these “SMART on FHIR Core Capabilities” are in scope for Program testing and certification. Additionally, we clarify that by requiring the “permission-patient” “SMART on FHIR Core Capability” in § 170.215(a)(3), 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. Specifically, this means patients would need to have the ability to authorize access to their EHI at the individual FHIR resource level, from one specific FHIR resource (
                        <E T="03">e.g.,</E>
                         “Immunization”) up to all FHIR resources necessary to implement the standard adopted in § 170.213 and implementation specification adopted in § 170.215(a)(2). This capability will give patients increased control over how much EHI they authorize applications of their choice to receive. For example, if a patient downloaded a medication management application, they would be able to use these authorization scopes to limit the EHI accessible by the application to only information contained in FHIR “MedicationRequest” and “Medication” profile.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters noted concerns for privacy and security of APIs. Specifically, one commenter explained the threat of cross-site request forgery (CSRF), and suggested we take action to mitigate that risk, including by requiring the use of both OAuth 2.0 and OpenID Connect Core 1.0.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed by commenters regarding the privacy and security of APIs. The OAuth 2.0 standard defined at Request For Comment (RFC) 6749 
                        <SU>101</SU>
                        <FTREF/>
                         describes that “[The OAuth 2.0 authorization] framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.” The SMART IG serves as a “prescriptive profile” as described in RFC 6749. Thus, consistent with commenters' recommendations, we have adopted a profile of the OAuth 2.0 standard (SMART IG) in § 170.215(a)(3). Additionally, we have adopted OpenID Connect Core 1.0 incorporating errata set 1 in § 170.215(b), and require conformance with the relevant parts of this standard as part of testing and certification. CSRF is a well-documented security threat in OAuth 2.0, which can be prevented with adequate security practices. We encourage implementers to adhere to industry best practices to mitigate CSRF and other known security threats. Relatedly, we note that the HL7 community has developed an 
                        <PRTPAGE P="25742"/>
                        “Implementer's Safety Check List,” 
                        <SU>102</SU>
                        <FTREF/>
                         a guide of security best practices for implementing FHIR-based APIs. We encourage stakeholders to consult this guide during development and implementation of § 170.315(g)(10)-certified Health IT Modules to minimize security risks.
                    </P>
                    <FTNT>
                        <P>
                            <SU>101</SU>
                             
                            <E T="03">https://tools.ietf.org/html/rfc6749</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>102</SU>
                             
                            <E T="03">https://www.hl7.org/FHIR/safety.html</E>
                            .
                        </P>
                    </FTNT>
                    <P>For backend services authorization, as addressed under the header “Standardized API for Patient and Population Services” in the section V.B.4.c, we have finalized the adoption of the HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1) implementation specification (Bulk IG), which includes the “Backend Services Authorization Guide” in § 170.215(a)(4).</P>
                    <HD SOURCE="HD3">v. OpenID Connect</HD>
                    <P>We proposed in 84 FR 7480 through 7481 in § 170.215(b) to adopt OpenID Connect Core 1.0 including errata set 1.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received few comments regarding the adoption of OpenID Connect Core 1.0 including errata set 1, however, commenters generally supported the adoption of this standard.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. Given their support, we have finalized the adoption of OpenID Connect Core 1.0 including errata set 1 as proposed in § 170.215(b). We clarify that only the relevant parts of the OpenID Connect Core 1.0 including errata set 1 adopted in § 170.215(b) that are also included in the implementation specification adopted in § 170.215(a)(3) will be in-scope for testing and certification.
                    </P>
                    <HD SOURCE="HD3">c. Standardized API for Patient and Population Services</HD>
                    <P>We proposed in 84 FR 7481 to adopt a new certification criterion, § 170.315(g)(10), to replace § 170.315(g)(8), and we proposed in 84 FR 7495 to update the 2015 Edition Base EHR definition, as referenced in § 170.102. The proposed certification criterion would require Health IT Modules to support API-enabled “read” services for single and multiple patients. “Read” services include those that allow authenticated and authorized third-party applications to view EHI through a secure API. These services specifically exclude “write” capabilities, where authenticated and authorized third-party applications would be able to create or modify EHI through a secure API.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported the proposed adoption of a new certification criterion, § 170.315(g)(10), to replace § 170.315(g)(8).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support from commenters. As a result, we have adopted a new certification criterion in § 170.315(g)(10), to replace § 170.315(g)(8) and made several revisions to address public comment as discussed further below. Although the certification criteria finalized at § 170.315(g)(10) will replace § 170.315(g)(8), we note that § 170.315(g)(8) is not removed from regulation. We maintain § 170.315(g)(8) and have finalized in § 170.550(m) that ONC-ACBs can issue certificates for § 170.315(g)(8) during the transition period to § 170.315(g)(10) for 24 months after the publication date of the final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested dividing the § 170.315(g)(10) criterion into two separate criteria for single and multiple patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. We decline to split the certification criterion into two criteria. In consideration of comments and for clarity, we have improved the organization of the final certification requirements for API-enabled “read” services for single and multiple patients by separating the criterion into distinct sections in the regulation text.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported referencing a standard for API-enabled “read” services for multiple patients, including the HL7® FHIR® Bulk Data Access Implementation Guide Release 1.0.0. Commenters felt that omitting a standard in the criterion would undermine interoperability for API-enabled “read” services for multiple patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. To enable consistent health IT implementation of API-enabled “read” services for multiple patients, we have finalized the adoption of the Bulk IG, including mandatory support for the “group-export” “OperationDefinition” in § 170.215(a)(4). As part of the Program, we require Health IT Modules presented for testing and certification to conform to the Bulk IG implementation specification finalized in § 170.215(a)(4). The adoption of an implementation specification for API-enabled “read” services for multiple patients in § 170.215(a)(4) is responsive to stakeholder concerns and further supports our intent to prevent “special effort” for the use of APIs as mandated in section 4002 of the Cures Act. Furthermore, based on our analysis, we believe the “group-export” “OperationDefinition,” as defined in the Bulk IG implementation specification is essential to fulfill the use cases envisioned for API-enabled “read” services for multiple patients. The “group-export” “OperationDefinition” will allow application developers interacting with § 170.315(g)(10)-certified Health IT Modules to export the complete set of FHIR resources as constrained by the US Core IG adopted in § 170.215(a)(2) and USCDI adopted in § 170.213 for a pre-defined cohort of patients. We appreciate commenters' recommendations, and agree that coalescing around a common implementation specification will advance interoperability of API-enabled “read” services for multiple patients. We provide further discussion of the supported search operations, data response, and authentication and authorization requirements for API-enabled “read” services for multiple patients in the sections below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested clarification that API-enabled “read” services for multiple patients are not intended for patient end users and that health IT developers and health care providers are therefore not expected to supply a patient-facing mechanism for these requests.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. API-enabled “read” services for multiple patients are not intended for patient end users because API-enabled “read” services for multiple patients allow for the disclosure of multiple patients' records, and individual patients only have the right to access their own records or records of patients to whom they are the personal representative (45 CFR 164.502(f)(1)). Health IT Modules are not required to support patient-facing API-enabled “read” services for multiple patients for the purposes of this certification criterion.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested we modify the language that defines the purpose of this section to provide more clarity, specifically the term “services.” The commenter also requested we include the scope of cohorts we intended to address in “population services.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. The term “services” includes all § 170.315(g)(10)-related technical capabilities included in a Health IT Module presented for testing and certification. The API-enabled “read” services for single patients is intended to support EHI requests and responses for individual patient records and the API-enabled “read” services for multiple patients is intended to support EHI requests and responses for multiple patients' records. The scope of patient cohorts for “population services” can include various groups defined at the 
                        <PRTPAGE P="25743"/>
                        discretion of the user of the API-enabled “read” services for multiple patients, including, for example, a group of patients that meet certain disease criteria or fall under a certain insurance plan. We have adopted the Bulk IG in § 170.215(a)(4) to support this function as discussed further below. The technical capabilities expected of API-related Health IT Modules presented for testing and certification are included in § 170.315(g)(10).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested clarification for information blocking policies and health care provider obligations for API-enabled “read” services for multiple patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the request for clarification from commenters. We clarify that the criteria finalized in § 170.315(g)(10) includes the technical capabilities that must be met by API-related Health IT Modules presented for testing and certification. The information blocking policies in this rule do not compel health care providers to implement Health IT Modules certified to requirements in 170.315(g)(10). We note that other programs, like CMS value-based programs, may require the use of this technology. We refer commenters to the information blocking section (VIII) for additional clarification.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters asked us to clarify the relationship between the API-enabled “read” services for single and multiple patients in § 170.315(g)(10) and the “EHI export” criterion in § 170.315(b)(10).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for this request. The API criterion in § 170.315(g)(10) is separate from the “EHI export” criterion in § 170.315(b)(10). While both criteria aim to advance health IT in alignment with the Cures Act's goal of “complete access, exchange, and use of all electronically accessible health information” for both single and multiple patients, the criteria specifications and Condition and Maintenance of Certification requirements are distinct.
                    </P>
                    <P>The “EHI export” criterion focuses on a Health IT Module's ability to electronically export EHI, as defined in § 171.102, that can be stored at the time of certification by the product, of which the Health IT Module is a part. In contrast, the finalized API criterion in § 170.315(g)(10) focuses on “read” services for single and multiple patients for the USCDI (adopted in § 170.213) Data Elements and US Core IG (adopted in § 170.215(a)(2)) FHIR profiles. Additionally, the “EHI export” criterion finalized in § 170.315(b)(10) does not mandate conformance to standards or implementation specifications, whereas the criterion finalized in § 170.315(g)(10) requires conformance to several standards and implementation specifications, as described further below. We refer to the finalized “EHI export” criterion in § 170.315(b)(10) for additional information.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported requiring Health IT Modules to support API-enabled “write” services for single patients, either in this rule or in a future rulemaking. One commenter suggested including a subset of data classes for “write” services for single patients, including “patient goals,” “patient-generated health data” (including patient-reported outcomes, patient generated device data, and questionnaires), and “care plans.” Another commenter suggested adding a list of required operations (“read” and “write”) to USCDI elements, limited to “read” for this rulemaking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. While we support the interest in API-enabled “write” services, we have not adopted such requirements. We do not believe API-enabled “write” services have reached a level of a maturity to warrant the addition of regulatory conformance requirements within the Program. We encourage industry to consider all the implications and implementation requirements for API-enabled “write” services, and perform additional API-enabled “write” pilot implementations to demonstrate the readiness for API-enabled “write” services in the testing and certification of Health IT Modules. Additionally, we encourage industry to expand existing profiles like the US Core IG to support “write” services.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended including a requirement for event logging for “read” services for single and multiple patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the recommendation from commenters. The 2015 Edition Privacy and Security Certification Framework requires that if a Health IT Module includes capabilities for certification under § 170.315(g)(10) it needs to be certified to several privacy and security certification criteria including auditable events in § 170.315(d)(2) or auditing actions on health information in § 170.315(d)(10).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters noted that references to APIs focus exclusively on RESTful query and ignore “push” elements of the FHIR API, such as “POST,” “PUT,” and FHIR messaging.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. While we support the interest in the “push” operations of the FHIR standard, including “POST,” “PUT,” and FHIR messaging, we have not adopted such requirements for the Program. We encourage industry stakeholders to further consider all the requirements and implications for the “push” operations of the FHIR standard, develop use cases, perform additional API-enabled “push” pilot implementations, create or expand implementation profiles to support “push” services, and demonstrate the utility of the “push” operations of the FHIR standard for future potential inclusion in the Program.
                    </P>
                    <HD SOURCE="HD3">i. Data Response</HD>
                    <P>We proposed in 84 FR 7482 in § 170.315(g)(10)(i) that Health IT Modules presented for testing and certification must be capable of responding to requests for data on single and multiple patients in accordance with proposed standards and implementation specifications adopted in § 170.215(a)(1) (HL7® FHIR® DSTU 2 (v1.0.2-7202)), specified in the proposed § 170.215(a)(2) (API Resource Collection in Health (ARCH) Version 1), and consistent with the proposed specifications in § 170.215(a)(3) (Argonaut Data Query Implementation Guide Version 1.0.0). We clarified that all data elements indicated as “mandatory” and “must support” by the proposed standards and implementation specifications must be supported and would be in scope for testing.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concern with fully enforcing “mandatory” and “must” support requirements of the referenced specifications and implementation guides, explaining that developers may be required to support requirements that are not applicable to the stated intended use of the Health IT Module(s).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the concerns expressed by commenters. We clarify that the standards and implementation specifications adopted and required for this certification criterion were created by standards developing organizations to support a wide range of health care use cases.
                    </P>
                    <P>
                        We have finalized in § 170.315(g)(10)(i)(A) that Health IT Modules presented for testing and certification must be capable of responding to requests for a single patient's data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the Data Elements included in the standard adopted in § 170.213. This requirement will enable Health IT Modules to support US Core IG 
                        <PRTPAGE P="25744"/>
                        operations for each of the Data Elements included in the USCDI.
                    </P>
                    <P>Additionally, we have finalized in § 170.315(g)(10)(i)(B) that Health IT Modules presented for testing and certification must be capable of responding to requests for data on multiple patients as a group according to the standard adopted in § 170.215(a)(1) and implementation specifications adopted in § 170.215(a)(2) and § 170.215(a)(4), for each of the Data Elements included in the standard adopted in § 170.213. Finally, we clarify that the use of the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) is required for API “read” services for multiple patients as finalized in § 170.315(g)(10)(i)(B) and described above.</P>
                    <P>For requests for data on multiple patients, we note that the implementation specification adopted in § 170.215(a)(4) has optional parameters which can be used to filter results to a period of time, or one or several specified FHIR resources. While these parameters are not required for testing and certification, we encourage health IT developers to adopt these parameters and other “OperationDefinitions” to enhance the utility of requests for data on multiple patients.</P>
                    <HD SOURCE="HD3">ii. Search Support</HD>
                    <P>
                        We proposed in 84 FR 7482 in § 170.315(g)(10)(ii) that Health IT Modules presented for testing and certification must be capable of responding to all of the “supported searches” specified in the proposed implementation specification in § 170.215(a)(4) (Argonaut Data Query Implementation Guide Server). We reiterated that Health IT Modules presented for testing and certification and as implemented must support all search capabilities for single and multiple patients in accordance with the proposed implementation specification in § 170.215(a)(4). We also requested comments on the minimum “search” parameters that would need to be supported for the ”DocumentReference” and “Provenance” HL7
                        <E T="03">®</E>
                         FHIR
                        <E T="03">®</E>
                         resources.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Most commenters supported this proposal. One commenter recommended only requiring the “target” query parameter for the “Provenance” FHIR resource, and “patient” and “date” query parameters for the “DocumentReference” FHIR resource. One commenter suggested deferring this certification requirement until a standard is published by HL7.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. Since we have not finalized the adoption of the ARCH as proposed in § 170.215(a)(2), and instead rely on the search parameters specified in the US Core IG finalized in § 170.215(a)(2) and Bulk IG finalized in § 170.215(a)(4), the comments related to the specific “Provenance” and “DocumentReference” FHIR resources are no longer applicable. We have finalized in § 170.315(g)(10)(ii)(A) that Health IT Modules presented for testing and certification must support all search capabilities for single patients according to the implementation specification adopted in § 170.215(a)(2), including support for all mandatory capabilities included in the “US Core Server CapabilityStatement.” Additionally, we have finalized in § 170.315(g)(10)(ii)(B) that Health IT Modules presented for testing and certification must respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4). We clarify that the scope of data available in the data responses defined in § 170.315(g)(10)(i) must be supported for single and multiple patient searches via the supported search operations finalized in § 170.315(g)(10)(ii). Additionally, we clarify for the requirements finalized in § 170.315(g)(10)(i) and (ii) that all data elements indicated as “mandatory,” “must support,” by the standards and implementation specifications must be supported and are in scope for testing.
                    </P>
                    <HD SOURCE="HD3">iii. Application Registration</HD>
                    <P>
                        We proposed in 84 FR 7483 in § 170.315(g)(10)(iii) that Health IT Modules presented for testing and certification must be capable of enabling apps to register with an “authorization server.” As proposed, this would have required an API Technology Supplier to demonstrate its registration process, but would not have required conformance to a standard. We requested comment at 84 FR 7483 on whether to require the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) 
                        <SU>103</SU>
                        <FTREF/>
                         standard as the sole method to support registration for the proposed certification criterion in § 170.315(g)(10), and requested comment on whether we should require its support as part of the final rule's certification criterion. Additionally, we requested comment at 84 FR 7483 on whether to include application registration in the testing and certification of apps executed within an API Data Provider's clinical environment.
                    </P>
                    <FTNT>
                        <P>
                            <SU>103</SU>
                             
                            <E T="03">https://tools.ietf.org/html/rfc7591</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters generally supported that Health IT Modules presented for testing and certification must enable apps to register with an authorization server. Some commenters supported excluding application registration from the testing and certification of apps executed within an API Data Provider's clinical environment.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. Given the overwhelming support, we have finalized in § 170.315(g)(10)(iii) that Health IT Modules presented for testing and certification must enable apps to register with an authorization server. We clarify that 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). This certification criterion requires a health IT developer, as finalized in the Condition of Certification requirements section below, to demonstrate its registration process, but does not require conformance to a standard. Additionally, we expect that apps executed within an implementer's clinical environment will be registered with an authorization server, but we do not require a health IT developer to demonstrate its registration process for these “provider-facing” apps. We reiterate that we believe implementers of § 170.315(g)(10)-certified Health IT Modules should have the discretion to innovate and execute various methods for application registration within a clinical environment.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters provided a mix of support and opposition for requiring the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) standard as the sole method of application registration. Some commenters felt that the Program should require dynamic client registration in the context of patient-access scenarios only, and others felt the standard is not ready for mandated adoption in the Program. Commenters opposed to requiring the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) felt that not specifying a standard would allow flexibility for different innovative registration approaches to be used and developed. Other commenters suggested there should be an option for data holders to support dynamic client application registration if the data holder prefers that approach, including support for dynamic application registration via trusted networks.
                        <PRTPAGE P="25745"/>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We have not adopted a requirement for Health IT Modules presented for testing and certification to support the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) standard. We agree with commenters and believe that requiring registration without a mandated standard will allow registration models to develop further. We encourage health IT developers to coalesce around the development and implementation of a common standard for application registration with an API's authorization server.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested permitting implementers of § 170.315(g)(10)-certified Health IT Modules to undertake a review of third-party applications prior to permitting them to connect to the implementers' deployed APIs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the suggestion from commenters. The requirement that health IT developers must enable an application to register with the § 170.315(g)(10)-certified Health IT Module's authorization server only applies for the purposes of demonstrating technical conformance to the finalized certification criterion and Condition and Maintenance of Certification requirements. The practices by all parties (including implementers of Health IT Modules) other than developers of certified Health IT Modules are not in scope for this certification criterion nor the associated Condition and Maintenance of Certification requirements. All other practices associated with third-party application review or “vetting” by implementers must not violate the information blocking provision described in section VIII of this preamble and applicable laws and regulations. In general, an implementer of § 170.315(g)(10)-certified Health IT Modules (
                        <E T="03">e.g.,</E>
                         health care providers) would be allowed to review third-party applications the implementer intends to use for its own business use (
                        <E T="03">e.g.,</E>
                         a third-party decision-support application used by the health care provider in the course of furnishing care) prior to permitting the third-party applications to connect to the implementer's deployed APIs within its enterprise and clinical users' workflow. However, implementers of § 170.315(g)(10)-certified Health IT Modules (
                        <E T="03">e.g.,</E>
                         health care providers) are not permitted to review or “vet” third-party applications intended for patient access and use (see section VII.C.6 of this preamble). We clarify that the third-party application registration process that a health IT developer must meet under this criterion is not a form of review or “vetting” for purposes of this criterion.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested clarity on whether the “EHR Launch” scenario was out of scope for testing during registration with an authorization server.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Commenters referred to the “EHR Launch” scenario, which is the “launch-ehr” “SMART on FHIR Core Capability” included in the implementation specification adopted in § 170.215(a)(3). Health IT Modules presented for testing and certification must enable all apps that utilize the SMART IG “launch-standalone” “SMART on FHIR Core Capability” to register with an authorization server. We reiterate that the application registration requirement finalized in § 170.315(g)(10)(iii) does not require conformance to a standard or implementation specification. We envision that apps using only the SMART IG “launch-ehr” “SMART on FHIR Core Capability” will be tightly integrated with § 170.315(g)(10)-certified Health IT Modules deployed by implementers, and will be able to accommodate registration processes that best suit the needs of those implementers. Additionally, while we do not require conformance to a standard or implementation specification for application registration, we clarify that Health IT Modules presented for testing and certification are required to support application registration functions to enable authentication and authorization as finalized in § 170.315(g)(10)(v).
                    </P>
                    <HD SOURCE="HD3">iv. Secure Connection</HD>
                    <P>We proposed in 84 FR 7483 in § 170.315(g)(10)(iv) that Health IT Modules presented for testing and certification must be capable of establishing a secure and trusted connection with an application requesting patient data in accordance with the proposed § 170.215(a)(5) (HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0), including mandatory support for “Standalone Launch” and “EHR Launch” modes.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters asked for clarification around where “Standalone Launch” and “EHR Launch” capabilities are required, suggesting that “Standalone Launch” support be used exclusively for patient access and “EHR Launch” support be used exclusively for provider/clinician access. They also noted that testing and certification of “Standalone Launch” would not be a valid use case and should be excluded from the certification criterion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. The SMART IG “Standalone Launch” and “EHR Launch” modes can be used by both provider- and patient-facing applications. We refer to the adopted implementation specification in § 170.215(a)(3) for clarification of certification requirements for the SMART IG. We have finalized in § 170.315(g)(10)(iv)(A) that Health IT Modules presented for testing and certification must demonstrate the ability to establish a secure and trusted connection with an application requesting data for a single patient in accordance with the implementation specifications adopted in § 170.215(a)(2) and (a)(3). We amended this text from the Proposed Rule by adding the US Core IG implementation specification adopted in §  170.215(a)(2) because the US Core IG specifically requires Transport Layer Security 1.2 (RFC 5246) 
                        <SU>104</SU>
                        <FTREF/>
                         or higher for all transmissions not taking place over a secure network connection. Pursuant to this adopted implementation specification, we will test Health IT Modules for support for all “SMART on FHIR Core Capabilities” including both “launch-ehr” and “launch-standalone.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>104</SU>
                             
                            <E T="03">https://tools.ietf.org/html/rfc5246</E>
                            .
                        </P>
                    </FTNT>
                    <P>Additionally, we have finalized in § 170.315(g)(10)(iv)(B) that Health IT Modules presented for testing and certification must demonstrate the ability to establish a secure and trusted connection with an application requesting data for multiple patients in accordance with the implementation specification adopted in § 170.215(a)(4). The implementation specification adopted in § 170.215(a)(4) has several sections, but for testing and certification to this criterion, we specifically require conformance to, but not limited to, the “SMART Backend Services: Authorization Guide.”</P>
                    <HD SOURCE="HD3">v. Authentication and Authorization</HD>
                    <P>
                        We proposed in 84 FR 7483 in § 170.315(g)(10)(v) that Health IT Modules presented for testing and certification must demonstrate the ability to perform user authentication, user authorization, and issue a refresh token valid for a period of at least 3 months during its initial connection with an application to access data for a single patient in accordance with the proposed standard in § 170.215(b) (OpenID Connect Core 1.0 incorporating errata set 1) and the proposed implementation specification in § 170.215(a)(5) (HL7® SMART Application Launch Framework Implementation Guide Release 1.0.0). 
                        <PRTPAGE P="25746"/>
                        Additionally, we proposed in § 170.315(g)(10)(vi) that Health IT Modules presented for testing and certification must demonstrate the ability of an application to access data for a single patient and multiple patients during subsequent connections of applications capable of storing a client secret, in accordance with the proposed implementation specification in § 170.215(a)(5) (HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0), without requiring the user to re-authorize and re-authenticate when a valid refresh token is supplied. Additionally, we proposed in 84 FR 7483 that Health IT Modules presented for testing and certification must demonstrate it can issue a new refresh token to an application, valid for a period of at least 3 months.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of commenters supported that Health IT Modules presented for testing and certification must demonstrate the ability to perform user authentication, user authorization, and issue a refresh token valid for a period of at least 3 months. Some commenters noted that the OAuth 2.0 implementation guide does not recommend servers provide refresh tokens to public/non-confidential applications.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. Given the general support and in response to these comments, we have consolidated the proposed requirements in § 170.315(g)(10)(v) and § 170.315(g)(10)(vi) as a revised set of requirements finalized in § 170.315(g)(10)(v). Specifically, we have finalized requirements for authentication and authorization for patient and user scopes in § 170.315(g)(10)(v)(A) and requirements for authentication and authorization for system scopes in § 170.315(g)(10)(v)(B). We have focused the revised requirements around authentication and authorization scopes to remove any confusion associated with requirements for single and multiple patients. We have finalized authentication and authorization requirements for first time connections for patient and user scopes in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        ). This include the requirement finalized in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">i</E>
                        ) that Health IT Modules presented for testing and certification must demonstrate that authentication and authorization occurs during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b). It also includes the requirement finalized in § 170.315(g)(10)(v)(A)(
                        <E T="03">1</E>
                        )(
                        <E T="03">ii</E>
                        ) that an application capable of storing a client secret must be issued a refresh token valid for a period of no less than three months. Additionally, we have finalized authentication and authorization requirements for subsequent connections for patient and user scopes in § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        ). This includes the requirements finalized in § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">i</E>
                        ) that Health IT Modules presented for testing and certification must demonstrate that access is granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application. It also includes the requirements finalized in § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ) that an application capable of storing a client secret must be issued a new refresh token valid for a new period of no less than three months.
                    </P>
                    <P>Additionally, we have finalized requirements for authentication and authorization for system scopes in § 170.315(g)(10)(v)(B), which require that Health IT Modules presented for testing and certification must demonstrate that authentication and authorization occurs during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token. We note that for system scopes, applications will likely be authorized via a prior authorization negotiation and agreement between applications and Health IT Modules.</P>
                    <P>
                        For clarity, we use the term “an application capable of storing a client secret” to refer to “confidential clients.” In the definition at RFC 6749, “confidential” clients are “clients capable of maintaining the confidentiality of their credentials (
                        <E T="03">e.g.,</E>
                         client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.” RFC 6749 also defines “public” clients as “clients incapable of maintaining the confidentiality of their credentials (
                        <E T="03">e.g.,</E>
                         clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.” We clarify that the term “an application capable of storing a client secret” specifically excludes “public” clients.
                    </P>
                    <P>Additionally, we clarify that Health IT Modules will be explicitly tested for US Core IG operations using authentication and authorization tokens acquired via the process described in the implementation specification adopted in § 170.215(a)(3), and Health IT Modules will be explicitly tested for Bulk IG operations using authentication and authorization tokens acquired via the process described in the implementation specification adopted in § 170.215(a)(4).</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that ONC introduce a Condition of Certification requirement to ensure that implementers of § 170.315(g)(10)-certified Health IT Modules can obtain automated system-level access to all API calls from the API servers offered by the Certified Health IT Developers (
                        <E T="03">e.g.,</E>
                         via the SMART Backend Services authorization guide), with “system/*.*” scopes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We decline to accept the recommendation to require “system/*.*” scopes as a certification requirement in § 170.315(g)(10). Insofar as the commenter requested that Health IT Modules make available automated system-level scopes for the purposes of an “all information export,” we have finalized a similar requirement in § 170.315(b)(10), and refer the commenter to that section for additional detail. Additionally, we have finalized in §  170.315(g)(10)(v)(B) that Health IT Modules must perform authentication and authorization during the process of granting an application access to patient data using system scopes in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4). We recognize that the capabilities supported by “SMART Backend Services: Authorization Guide” could be used for many other use cases that are currently not required by the criterion. We clarify that implementers of Health IT Modules are not prohibited from configuring Health IT Modules to support the backend “system” scope described in the “SMART Backend Services: Authorization Guide” section of the Bulk IG adopted in § 170.215(a)(4) for API-enabled “read” services defined in the US Core IG. Indeed, we strongly encourage health IT developers to support these use cases as they develop in order to make full use of the certified functions of Health IT Modules and advance the state of the industry.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested specifying that refresh tokens apply exclusively to patient access scenarios, noting that there are too many security risks to allow persistent tokens for provider-facing applications. 
                        <PRTPAGE P="25747"/>
                        Additionally, commenters suggested permitting Health IT Modules to support the revocation of refresh tokens in appropriate scenarios to address legitimate security concerns.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We do not agree that there are too many security risks to allow refresh tokens to be used for provider-facing applications. Refresh tokens are commonly used in health care and other industries to provide seamless integration of systems with other applications while reducing the need for the burdensome process of re-authentication and re-authorization. We expect implementers of § 170.315(g)(10)-certified Health IT Modules to have the capability of revoking refresh tokens where appropriate. Additionally, we clarify that implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from changing the length of refresh tokens for users of the API including patients and providers to align with their institutional policies. However, implementers of § 170.315(g)(10)-certified Health IT Modules should be mindful of information blocking provisions applicable to them and that requiring patients to re-authenticate and re-authorize at a high frequency could inhibit patient access and implicate information blocking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested amending the time from three months to 12 months. One commenter agreed that the patient token should be valid for three months, but suggested the provider token be limited to 24 hours. One commenter suggested requiring re-authentication every time information is sought via APIs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We believe a refresh token valid for a period of three months is sufficient to balance persistent access and security concerns. Moreover, for subsequent connections of applications capable of storing a client secret, Health IT Modules are required to issue a new refresh token valid for a new period of no shorter than three months per the API certification criterion requirement finalized in § 170.315(g)(10)(v)(A)(
                        <E T="03">2</E>
                        )(
                        <E T="03">ii</E>
                        ). Given this requirement, we anticipate that the user's application will renew its refresh token (valid for a new period of three months) every time the user actively engages with the application. We believe this justifies a refresh token length for a moderate period of no shorter than three months rather than a long period of 12 months suggested by commenters. Additionally, as stated above, implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from changing the length of refresh tokens for users of the API, including patients and providers, to align with their institutional policies. Further, implementers of § 170.315(g)(10)-certified Health IT Modules are not prohibited from implementing their § 170.315(g)(10)-certified Health IT Modules in accordance with their organizational security policies and posture, including by instituting policies for re-authentication and re-authorization (
                        <E T="03">e.g.,</E>
                         providers and/or patients could always be required to re-authenticate and re-authorize after a set number of refresh tokens have been issued). We also note that we have finalized a requirement in § 170.315(g)(10)(vi) that a Health IT Module's authorization server must be able to revoke an authorized application's access at a patient's direction. This required capability will enable patients to definitively revoke an application's authorization to receive their EHI until reauthorized, if ever, by the patient.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested creating a more robust assessment process for identity management, including adding additional criteria for identity proofing, authentication, and authorization, and ensuring software developers do not act in a way that could inhibit patient control of their data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback and suggestions. Although we agree that identity proofing is an important practice, we did not include requirements for identity proofing in the Proposed Rule, and have not finalized requirements for identity proofing in response to this comment. We note that the certification criterion finalized in § 170.315(g)(10) only applies to health IT developers. Given the scope of the Program, we believe that mandating identity proofing, which are generally business practices performed by organizations and other entities, is not something appropriate to require of health IT developers. We note that per the requirements of the 2015 Edition Privacy and Security Certification Framework, health IT developers with Health IT Modules certified to § 170.315(g)(7) through (g)(10) are required to certify to § 170.315(d)(1), which includes requirements for authentication, access control, and authorization. Additionally, authentication and authorization for use of § 170.315(g)(10)-certified Health IT Modules are included in the requirements finalized in § 170.315(g)(10)(v). We appreciate the sentiment expressed by commenters, and have created thorough and rigorous requirements to ensure adequate privacy and security capabilities are present in § 170.315(g)(10)-certified Health IT Modules. Regarding the request for certification requirements to ensure that software developers do not act in a way that could inhibit patient control of their data, we refer to the requirement finalized in § 170.315(g)(10)(A), which requires that patients have the ability to grant applications authorization to access their EHI using granular FHIR Resources of their choice to comply with the adopted implementation specification in § 170.215(a)(3), and requirement in § 170.315(g)(10)(vi), which requires that a Health IT Module's authorization server must be able to revoke an authorized application's access at a patient's direction.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested that patients be able to specify refresh token length, if desired, and revoke a third-party application's access at any time. Commenters suggested that clear information be provided to patients whether authorized access is one-time or ongoing.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. Refresh tokens are an OAuth 2.0 concept, and are largely opaque to the end user. However, we clarify that patients are not prohibited from changing the length of refresh tokens to the degree this option is available to them. Additionally, pursuant to these comments, and to ensure patients have the ability to revoke an application's access to their EHI at any time, we have finalized an additional certification requirement in § 170.315(g)(10)(vi) which requires that a Health IT Module's authorization server must be able to revoke an authorized application's access at a patient's direction. We have finalized this as a functional requirement to allow health IT developers the ability to implement it in a way that best suits their existing infrastructure and allows for innovative models for authorization revocation to develop. Additionally, per the requirement finalized in § 170.315(g)(10)(v)(A), Health IT Modules must perform authorization conformant with the implementation specification adopted in § 170.215(a)(3), including all “SMART on FHIR Core Capabilities.” The “permission-offline” “SMART on FHIR Core Capability” includes support for the “offline_access” scope. Importantly, the implementation specification adopted in § 170.215(a)(3) requires that patients have the ability to explicitly enable the “offline_access” scope during authorization. If the “offline_access” scope is not enabled by patients, patients will be required to re-
                        <PRTPAGE P="25748"/>
                        authenticate and re-authorize an application's access to their EHI after the application's access token expires.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested providing the ability for implementers of § 170.315(g)(10)-certified Health IT Modules to perform token introspection using services enabled by health IT developers to ensure that additional resource servers can work with the same access tokens and authorization policies as the resource servers provided by API Technology Suppliers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. Based on feedback, we have finalized in § 170.315(g)(10)(vii) that Health IT Modules presented for testing and certification must demonstrate the ability to receive and validate a token issued by its authorization server, but we did not specify a standard for this requirement. Token introspection will allow implementers of § 170.315(g)(10)-certified Health IT Modules to use API authorization servers and authorization tokens with various resource servers. This functionality has the potential to reduce complexity for implementers of § 170.315(g)(10)-certified Health IT Modules authorizing access to several resource servers and reduces the overall effort and subsequent use of § 170.315(g)(10)-certified Health IT Modules consistent with the goals of section 4002 of the Cures Act to enable the use of APIs without “special effort.” Although we do not specify a standard for token introspection, we encourage industry to coalesce around using a common standard, like OAuth 2.0 Token Introspection (RFC 7662).
                        <SU>105</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>105</SU>
                             
                            <E T="03">https://tools.ietf.org/html/rfc7662</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concerns with the privacy and security of APIs, and nefarious actors posing as legitimate health facilities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Regarding the privacy and security of APIs, the Standardized API for Patient and Population Services certification criterion finalized in § 170.315(g)(10) requires Health IT Modules presented for testing and certification to implement the implementation specification adopted in § 170.215(a)(3), which is based on the OAuth 2.0 security standard that is widely used in industry. The implementation of OpenID Connect paired with OAuth 2.0 allows health care providers to securely deploy and manage APIs consistent with their organizational practices. Health care providers retain control over how their workforce and patients authenticate when interacting with the API. For example, a patient may be required to use the same credentials (
                        <E T="03">e.g.,</E>
                         username and password) they created and use to access their EHI through a patient portal as they do when authorizing an application to access their data. Since patients complete the authentication process directly with their health care provider, no application will have access to their credentials. There is little protection software can provide to protect against nefarious actors posing as legitimate health facilities, however, we believe that implementing the security controls and safeguards described above, along with the privacy and security requirements required under the 2015 Edition Privacy and Security Certification Framework, will help to protect Health IT Modules against nefarious actors. Additionally, the protections required for ePHI in Health IT Modules offered by health IT developers acting as business associates of health care providers remain unchanged.
                    </P>
                    <HD SOURCE="HD3">vi. Technical Documentation</HD>
                    <P>We proposed in 84 FR 7484 in § 170.315(g)(10)(vii) that an API Technology Supplier needed to provide complete documentation via a publicly accessible hyperlink, without additional access requirements, for all aspects of its § 170.315(g)(10)-certified API, especially for any unique technical requirements and configurations, including 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, the software components and configurations necessary for an application to successfully interact with the API and process its response(s), and all applicable technical requirements and attributes necessary for an application to be registered with an authorization server. Additionally, we proposed in 84 FR 7484 to remove the “terms of use” documentation provisions in the API certification criteria adopted in § 170.315(g)(7) through (g)(9) in order to reflect the Condition of Certification requirements and not be duplicative of the terms and conditions transparency Condition of Certification requirements proposed in 84 FR 7485.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters generally supported the requirements for this criterion as proposed. Some commenters suggested technical documentation should be limited to descriptions of how the API differs from the utilized standards and implementation specifications, like HL7® FHIR® and the SMART IG.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We did not make substantive changes to the requirements proposed in § 170.315(g)(10)(vii). We have finalized these requirements § 170.315(g)(10)(viii). We recognize that our formal adoption of the HL7 FHIR standard and the associated implementation specifications referenced in § 170.315(g)(10) would be consistent across all Health IT Modules presented for certification. As a result, there may be minimal additional documentation needed for these capabilities beyond what is already documented in adopted standards and implementation specifications. We expect health IT developers to disclose any additional data their § 170.315(g)(10)-certified Health IT Module supports in the context of the adopted standards and implementation specifications. The content of technical documentation required to meet this certification criteria are described in requirements finalized in § 170.315(g)(10)(viii)(A). We expect these and any additional documentation relevant to the use of a health IT developer's § 170.315(g)(10)-certified Health IT Module to be made available via a publicly accessible hyperlink without preconditions or additional steps to meet the requirement as finalized in § 170.315(g)(10)(viii)(B).
                    </P>
                    <HD SOURCE="HD3">d. API Condition of Certification Requirements</HD>
                    <HD SOURCE="HD3">i. Key Terms</HD>
                    <P>We proposed in 84 FR 7477 to adopt new definitions for “API Technology Supplier,” “API Data Provider,” and “API User” in § 170.102 to describe the stakeholders relevant to our proposals.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters recommended updating definitions and providing examples for the key terms, including API User. Most commenters recommended dividing “API User” into two categories: “First-Order Users,” to include patients, health care providers, and payers that use apps/services that connect to API technology, and “Third-Party Users,” to include third-party software developers, and developers of software applications used by API Data Providers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We note that in this section we use the terms proposed in § 170.102 that we finalized in § 170.404(c) with added quotation marks for emphasis and clarity. We considered separating the term “API User” into distinct terms for developers of software applications and other users, such as patients and health care providers. However, we determined that this distinction was unnecessary from a regulatory perspective. Narrowing our 
                        <PRTPAGE P="25749"/>
                        definitions to distinct subgroups could exclude unforeseen stakeholders that emerge in a future API ecosystem. The term “API User” was intended to describe stakeholders that interact with the certified API technology either directly (
                        <E T="03">e.g.,</E>
                         to develop third-party apps/services) or indirectly (
                        <E T="03">e.g.,</E>
                         as a user of a third-party app/service).
                    </P>
                    <P>Based on suggestions to revise the proposed key terms, we have renamed the term “API Data Provider” to “API Information Source” finalized in § 170.404(c) to make clear which party is the source and responsible for the EHI (as in “the source of the information is the health care provider”), and “API Technology Supplier” to “Certified API Developer” finalized in § 170.404(c) to more clearly refer to health IT developers with Health IT Modules certified to any of the API criteria under the Program. Rather than keeping “API technology” an undefined term, we renamed it to “certified API technology” and finalized a definition in § 170.404(c). Additionally, we amended the definition of “API User” for clarity in § 170.404(c) to “API User means a person or entity that creates or uses software applications that interact with the `certified API technology' developed by a `Certified API Developer' and deployed by an `API Information Source.'” Additionally, we did not include the non-exhaustive list of examples of “API User” in the definition finalized in § 170.404(c). Instead, we rely on preamble to provide guidance for examples of “API Users” rather than appearing to limit the regulatory definition to these examples. We interpret that “API Users” can include, but are not limited to, software developers, patients, health care providers, and payers. We simplified the definition of “API Information Source” in § 170.404(c) to “API Information Source means an organization that deploys `certified API technology' created by a `Certified API Developer.'” We revised the definition of “Certified API Developer” in § 170.404(c) to “Certified API Developer means a health IT developer that creates the `certified API technology' that is certified to any of the certification criteria adopted in § 170.315(g)(7) through (10).” We added the definition of “certified API technology” in § 170.404(c) as “certified API technology 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).” For ease of reference and to clarify that these terms only apply to the Condition and Maintenance of Certification requirements, we have finalized these revised definitions in § 170.404(c). In this and other sections of the rule, we use the original proposed terms in the proposal and comment summaries, and the finalized terms in our responses.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters suggested ONC allow flexibility for instances where stakeholders may meet the definition of more than one key term, and others recommended restricting stakeholders from meeting the definition of more than one key term. Commenters expressed concern with the complexity of key terms in the Proposed Rule, and confusion with the interaction of these terms with other criteria within the rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for expressing their concern about stakeholders being able to serve more than one role under the definitions proposed in § 170.102 that we have finalized in § 170.404(c). We do not believe it is practical to restrict persons or entities to just one definition. We anticipate situations where a person or entity can serve more than one role. For example, a large health care system could purchase and deploy “certified API technology” as an “API Information Source” and have “API Users” on staff that create or use software applications that interact with the “certified API technology.” Additionally, a health IT developer could serve as a “Certified API Developer” that creates “certified API technology” for testing and certification and as an “API User” when it creates software applications that connect to “certified API technology.” We clarify that a stakeholder will meet a role defined in § 170.404(c) based on the context in which they are acting. For example, only health IT developers (when acting in the context of a “Certified API Developer”) are required to comply with these API Condition and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concern that ONC exceeded its regulatory authority by implicating physicians in the definition of “API Data Providers.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We remind commenters that these definitions were created to describe relationships between key API stakeholders and to help describe the Condition and Maintenance of Certification requirements. We clarify that health care providers are not covered by the Condition and Maintenance of Certification requirements to which the definitions apply in § 170.404(c) unless they are serving the role of a “Certified API Developer.
                    </P>
                    <HD SOURCE="HD3">ii. Scope and Compliance</HD>
                    <P>We proposed in 84 FR 7485 that the Condition and Maintenance of Certification requirements proposed in § 170.404 apply to API Technology Suppliers with Health IT Modules certified to any API-focused certification criteria adopted in the proposed § 170.315(g)(7) through (11).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters agreed that the proposed applicability for the Condition of Certification requirements proposed in § 170.404 should be limited to health IT developers certified to any API-focused criteria adopted in the proposed § 170.315(g)(7) through (11). One commenter requested clarification whether non-certified internally developed laboratory systems would be subject to this requirement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank stakeholders for their comments. We have generally finalized the scope and compliance for the Condition and Maintenance of Certification requirements as proposed in § 170.404 with one modification. Given that we have not adopted the certification criterion proposed for adoption in § 170.315(g)(11), the scope of the Condition and Maintenance of Certification requirements apply only to health IT developers with Health IT Modules certified to any of the API-focused criteria finalized in § 170.315(g)(7) through (10). The Condition and Maintenance of Certification requirements finalized in § 170.404 do not apply to health IT developers not seeking certification, nor do they apply to health IT developers certified to solely non-API-focused criteria. Additionally, we clarify that the Condition and Maintenance of Certification requirements only apply to practices of Certified API Developers with respect to the capabilities included in § 170.315(g)(7) through (10). In other words, the Condition and Maintenance of Certification requirements would not apply to practices of Certified API Developers with respect to non-certified capabilities or practices associated with, for example, the immunization reporting certification criterion in § 170.315(f)(1), because that criterion is not one of the API-focused criteria finalized in § 170.315(g)(7) through (10). However, health IT developers should understand that other requirements in this final rule, especially those related to information blocking, could still apply to its business practices associated with non-API-focused certification criteria.
                    </P>
                    <HD SOURCE="HD3">iii. General</HD>
                    <P>
                        We proposed in 84 FR 7485 in § 170.404(a)(1) to adopt the Cures Act's 
                        <PRTPAGE P="25750"/>
                        API Condition of Certification requirement stating that an API Technology Supplier 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.” We then subsequently proposed in 84 FR 7485 to interpret “all data of a patient's electronic health record” for the purposes of the scope of this API Condition of Certification requirement to include the proposed ARCH standard, its associated implementation specifications, and the policy expressed around the data elements that must be supported by § 170.315(g)(10)-certified APIs.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported our adoption of the Cures Act's API Condition of Certification requirement. For the purposes of the scope of data covered under this API Condition of Certification requirement, most commenters recommended defining “all data elements” as the Data Elements referenced by the USCDI and the FHIR resources in the FHIR US Core Implementation Guide STU 3 (US Core IG) for FHIR Release 4. We received comments recommending additional data elements to be included that we discuss in our comment summary for the ARCH in the “API Standards, Implementation Specifications, and Certification Criterion” section of this final rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate stakeholder feedback. The § 170.315(g)(10) certification criterion requirement and associated standards and implementation specifications will enable secure, standards-based API access to a specific set of information. We have finalized that a Certified API Developer must publish APIs, and must allow EHI 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, including providing access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws, in § 170.404(a)(1). Additionally, for the purposes of meeting this portion of the Cures Act's API Condition of Certification requirement, we clarify the data required and that must be supported to demonstrate conformance to the final § 170.315(g)(10) certification criterion (including all of its associated standards and implementation specifications) constitutes “all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws.” Regarding the recommendation by commenters that the scope of “all data elements” include the Data Elements of the standard adopted in § 170.213 and FHIR resources referenced by the implementation specification adopted in § 170.215(a)(2), we note that both the standard and implementation specification are included in the interpretation of “all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws” above. We note that this specific interpretation does not extend beyond the API Condition and Maintenance of Certification requirements finalized in § 170.404 and cannot be inferred to reduce the scope or applicability of other Cures Act Conditions of Certification or the information blocking policies, which include a larger scope of data.
                    </P>
                    <HD SOURCE="HD3">iv. Transparency Conditions</HD>
                    <P>We proposed in 85 FR 7485 and 7486 in § 170.404(a)(2)(i) to require API Technology Suppliers make available complete business and technical documentation via a publicly accessible hyperlink, including all terms and conditions for use of its API technology. Additionally, we proposed that API Technology Suppliers must make clear to the public the timing information applicable to their disclosures in order to prevent discrepancies between an API Technology Supplier's public documentation and its direct communication to customers. Additionally, we requested comment at 84 FR 7486 on whether the expectation for API Technology Suppliers to make necessary changes to transparency documentation should be finalized in regulation text, or whether this would be standard practice as part of making this documentation available.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received overall support from commenters for the need to make complete business and technical documentation available via a publicly accessible hyperlink. We did not receive public comment on whether we should formally include public disclosure requirements for regular updates to business and technical documentation in regulatory text.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support to make complete business and technical documentation available via a publicly accessible hyperlink. We have finalized in § 170.404(a)(2)(i) that a Certified API Developer must publish complete business and technical documentation, including the documentation described in § 170.404(a)(2)(ii), via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps. We made small adjustments to § 170.404(a)(2)(i) to reflect the changes in API definitions finalized in § 170.404(c).
                    </P>
                    <P>Given that we did not receive public comment on whether we should formally include public disclosure requirements for regular updates to business and technical documentation in regulatory text, so we have finalized in 170.404(a)(4)(iii)(B) that a Certified API Developer must provide notice and a reasonable opportunity for API Information Sources and API Users to update their applications to preserve compatibility with certified API technology and to comply with applicable terms and conditions. We note that notice could include a public notice made available on a website, but also encourage Certified API Developers to contact API Information Source customers and registered API Users (application developers) directly prior to updating business and technical documentation.</P>
                    <HD SOURCE="HD3">(A) Terms and Conditions</HD>
                    <P>We proposed in 84 FR 7485 in § 170.404(a)(2)(ii)(A) that API Technology Suppliers must publish all terms and conditions for its API technology, including any restrictions, limitations, obligations, registration process requirements, or other similar requirements that would be needed to: Develop software applications to interact with the API technology; distribute, deploy, and enable the use of software applications in production environments that use the API technology; use software applications, including to access, exchange, and use EHI by means of the API technology; use any EHI obtained by means of the API technology; and register software applications. Additionally, we proposed in § 170.404(a)(2)(ii)(B) that any and all fees charged by an API Technology Supplier for the use of its API technology must be described in detailed, plain language, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and 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>
                    <P>
                        <E T="03">Comments.</E>
                         We received support from stakeholders regarding the transparency of “all terms and conditions” associated with the use of API technology.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We believe this terms and conditions transparency requirement would ensure that API Information Sources and API Users do not experience “special effort” in the form 
                        <PRTPAGE P="25751"/>
                        of unnecessary costs or delays in obtaining the terms and conditions for certified API technology. Furthermore, we believe full transparency is necessary to ensure that API Users have a thorough understanding in advance of any terms or conditions that might apply to them once they have committed to developing software that interacts with certified API technology. We have finalized in § 170.404(a)(2)(ii)(A) that Certified API Developers must publish all terms and conditions for its certified API technology, including any fees, restrictions, limitations, obligations, registration process requirements or other similar requirements as enumerated in § 170.404(a)(2)(ii)(A)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">6</E>
                        ). We made small adjustments to § 170.404(a)(2)(ii)(A) to reflect the changes in API definitions finalized in § 170.404(c). Additionally, we moved “App developer verification” from its proposed location in § 170.404(a)(2)(ii)(C) and finalized it in § 170.404(b)(1) to improve organization. We added the phrase “Used to verify the authenticity of API Users” to the regulation text finalized in § 170.404(a)(2)(ii)(A)(
                        <E T="03">5</E>
                        ) for consistency with our proposed policy. We also moved the phrase “Register software applications” from its proposed location in § 170.404(a)(2)(ii)(A)(
                        <E T="03">5</E>
                        ) to the finalized location in § 170.404(a)(2)(ii)(A)(
                        <E T="03">6</E>
                        ) and revised the phrase for consistency. Additionally, we made small changes to the regulation text finalized in § 170.404(a)(2)(ii)(A)(
                        <E T="03">1</E>
                        ) through § 170.404(a)(2)(ii)(A)(
                        <E T="03">6</E>
                        ) for clarity.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received both support and disagreement for the requirement to publish transparency documentation on API fees. Some commenters felt transparency documentation of API fees should be limited to value-added services, because those are the only permitted fees applicable to API Users, and the other permitted fees applicable to API Data Providers (usage-based fees and fees to recover costs for development, deployment, and upgrades) would be included in contractual documentation with their customers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We recognize that some commenters had concern with making documentation on permitted fees publicly available. We believe that transparent documentation of all permitted fees is necessary to maintain a competitive marketplace and ensure that fees are reasonably related to the development, deployment, upgrade, and use of certified API technology. Fee transparency will also enable API Information Sources and API Users to shop for certified API technology and related services that meet their needs. We have finalized in § 170.404(a)(2)(ii)(B) that 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, including all material information described in § 170.404(a)(2)(ii)(B)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">3</E>
                        ). Additionally, we made small adjustments to § 170.404(a)(2)(ii)(B) to reflect the changes in API definitions finalized in § 170.404(c).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Multiple stakeholders expressed the need to include consumer protections in the terms and conditions documentation with an explanation about how EHI will be used.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         This provision of the Condition of Certification requirements does not prohibit additional content or limit the type of content a Certified API Developer may include in its terms and conditions. A Certified API Developer would be permitted to include consumer protections in their terms and conditions documentation. Additionally, we clarify these API Conditions of Certification requirements only apply to Certified API Developers. As such, API Information Sources and API Users are not required by the API Condition of Certification requirements to publish any terms and conditions, including those that apply to consumer protections.
                    </P>
                    <HD SOURCE="HD3">v. Fees Conditions</HD>
                    <HD SOURCE="HD3">(A) General Fees Prohibition</HD>
                    <P>
                        We proposed in § 170.404(a)(3)(i)(A) that API Technology Suppliers would be prohibited from imposing fees associated with API technology as a Condition of Certification requirement. In establishing this general prohibition, ONC was mindful of the need for API Technology Suppliers to recover their costs and to earn a reasonable return on their investments in providing API technology that has been certified under the Program. Accordingly, we identified categories of “permitted fees” in 84 FR 7487 that API Technology Suppliers would be permitted to charge and still be compliant with the Condition of Certification and Program requirements. These include the proposed § 170.404(a)(3)(ii) (permitted fee for developing, deploying, and upgrading API technology), proposed § 170.404(a)(3)(iii) (permitted fee to recover costs of supporting API usage for purposes other than patient access), and proposed § 170.404(a)(3)(iv) (permitted fee for value-added services). We also proposed in 84 FR 7487 that API Technology Suppliers would not be permitted to impose fees on any person in connection with an API Technology Supplier's work to support the use of API technology to facilitate a patient's ability to access, exchange, or use their EHI. We also clarified that while the proposed permitted fees set the boundaries for the fees API Technology Suppliers would be permitted to charge and to whom those permitted fees could be charged, the proposed regulations did not specify who could pay the API Technology Supplier's permitted fee. Rather, we proposed general conditions that an API Technology Supplier's permitted fees must satisfy in § 170.404(a)(3)(i)(B)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">4</E>
                        ), and requested comment in 84 FR 7488 on these conditions and whether they sufficiently restrict fees from being used to prevent access, exchange, and use of EHI through APIs without special effort. We include detailed discussions of permitted fees and related conditions below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters supported the clear prohibition on API fees outside those fees permitted in § 170.404(a)(3)(ii) through (iv), expressing that the language in the rule would prevent confusion regarding allowable and restricted fees. Some commenters noted that prohibiting fees would enable patients to exercise their HIPAA right of access without experiencing cost barriers, and remove cost barriers to hospitals and health care facilities using APIs for interoperability. Commenters noted that the proposals addressed many of the access and pricing practices that API Technology Suppliers engaged in to limit data exchange and gain a competitive advantage. Commenters noted that API Technology Supplier pricing practices often create barriers to entry and competition for apps that health care providers seek to use. Some commenters supported the proposal that prohibits API Technology Suppliers from charging fees to API Users.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank stakeholders for their support of and feedback on our proposal. We have finalized in § 170.404(a)(3)(i)(A) that all fees related to certified API technology not otherwise permitted by § 170.404(a)(3) are prohibited from being imposed by a Certified API Developer. Additionally, we have modified and reorganized these Condition of Certification requirements for clarity. We have renamed the title for the section from the Proposed Rule to “Fees conditions” because the requirements include both permitted and prohibited fees. We have updated the terminology used in this section to reflect changes made to the terminology used throughout the API Condition of 
                        <PRTPAGE P="25752"/>
                        Certification requirements and finalized in § 170.404(c). We finalized a requirement in § 170.404(a)(3)(i)(A) that permitted fees in paragraphs § 170.404(a)(3)(ii) and § 170.404(a)(3)(iv) may include fees that result in a reasonable profit margin in accordance with the information blocking Costs Exception provision finalized in § 170.302. We clarify that any fee that is not covered by those exceptions would be suspect under the information blocking provision, and would equally not be permitted by this API Condition of Certification requirement.
                    </P>
                    <P>This general prohibition on fees as finalized in § 170.404(a)(3)(i)(A) is meant to ensure that Certified API Developers do not engage in pricing practices that create barriers to entry and competition for apps and API-based services that health care providers seek to use. Such activities are inconsistent with the goal of enabling API-based access, exchange, and use of EHI by patients and other stakeholders without special effort. As finalized, this general prohibition allows for three categories of permitted fees (§ 170.404(a)(3)(ii) through (iv)) to allow Certified API Developers to recover their costs and to earn a reasonable return on their investments in providing certified API technology while being compliant with the Condition of Certification and Program requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters were critical of our proposals, expressing concerns that the proposed policies may stifle relationships between API Technology Suppliers and application developers. Others expressed concern that the proposed fee structure would place undue burden on API Data Providers, and that ONC should instead consider regulations that allow fee sharing across stakeholders. Some commenters stated that ONC should remove all prohibitions, and allow for market pricing and revenue sharing.
                    </P>
                    <P>Several commenters, many of whom were providers and provider organizations, requested additional clarity and guidance regarding the API fees that can be charged under the Condition of Certification requirements. Some commenters requested clarification regarding whether an API Data Provider can transfer costs to API Users. Other commenters requested clarification regarding when it is (and is not) appropriate for an API User to be charged a fee in connection with use of API technology. A few commenters requested that ONC provide a chart that lists all actors, all types of costs, and who can charge whom.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this feedback from commenters. These “general conditions,” as finalized in § 170.404(a)(3)(i) and discussed above, will facilitate API-based access, exchange, and use of EHI by patients and other stakeholders without special effort. We disagree with commenters that the permitted fee policies will stifle relationships between Certified API Developers and API Users. Cumulatively, these final policies create guardrails to protect against anti-competitive practices and reinforce the independence that we believe API Information Sources should have to establish relationships with API Users. Furthermore, we believe these fee policies are necessary in light of the potential for Certified API Developers to use their market position and control over certified API technology to engage in discriminatory practices that create special effort and barriers to the use of certified API technology. We continue to receive evidence that some Certified API Developers are engaging in practices that create special effort for the use of certified API technology. These practices include fees that create barriers to entry or competition as well as rent-seeking and other opportunistic behaviors. For example, we have received feedback that some Certified API Developers are conditioning access to technical documentation on revenue sharing or royalty agreements that bear no plausible relation to the costs incurred by the Certified API Developer to provide or enable the use of certified API technology. We are also aware of discriminatory pricing policies that have the purpose or effect of excluding competitors from the use of APIs and other interoperability elements despite the fact that the API Information Source would like to partner with and use these competitive, best-of-breed services. These practices from Certified API Developers close off the market to innovative applications and services that could empower patients and enable providers to deliver greater value and choice to health care consumers and other service providers.
                    </P>
                    <P>We note that Certified API Developers and API Users have the ability to collaborate and form relationships, so long as these relationships do not conflict with any of the provisions of this final rule or other applicable Federal and State laws and regulations. Further, we clarify that while the permitted fees set the boundaries for the fees Certified API Developers are permitted to charge and to whom those permitted fees can be charged, they do not prohibit who may pay the Certified API Developer's permitted fee. In other words, these conditions limit the party from which a Certified API Developer may require payment, but they do not speak to who may pay the fee. For example, a permitted practice under these conditions could include a relationship or agreement where an API User or other party offered to pay the fee owed by the API Information Source to a Certified API Developer. This is an acceptable practice because the fee is first agreed upon between the Certified API Developer and API Information Source and subsequently paid by the API Information Source directly or by a third party on behalf of the API Information Source. We note that fees charged for “value-added services” can arise between an API Information Source and Certified API Developer or API User. As a general matter, we note that stakeholders should be mindful of other Federal and State laws and regulations that could prohibit or limit certain types of relationships involving remuneration.</P>
                    <P>We provide additional clarity and guidance regarding the API fees that can be charged under the Condition of Certification requirements in the sections that follow. Additionally, we appreciate commenters' requests for clarification, including a chart of actors and costs. We will take this comment into consideration as we develop educational materials to help explain the permitted fees conditions finalized in § 170.404(a)(3).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested that one way to clarify the limits on API fees would be to require API Technology Suppliers provide fee information to ONC and for ONC to make this information publicly available, including information on individual pricing transactions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the recommendation from commenters to require Certified API Developers to provide fee information to ONC. We view fee transparency as a responsibility that a Certified API Developer can fulfill without having to send a listing of its API fees to ONC. We have finalized the provision in § 170.404(a)(2)(ii) that a Certified API Developer must publish all terms and conditions for its certified API technology, including any fees. Specifically, we have finalized in § 170.404(a)(2)(ii)(B) that 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, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and the amount of the fee, which for variable fees must include the specific variable(s) and 
                        <PRTPAGE P="25753"/>
                        methodology(ies) that will be used to calculate the fee.
                    </P>
                    <HD SOURCE="HD3">(B) Certified API Developer Permitted Fees Conditions</HD>
                    <P>
                        We proposed general conditions in § 170.404(a)(3)(i)(B)(
                        <E T="03">1</E>
                        ) through (
                        <E T="03">4</E>
                        ) that an API Technology Supplier's permitted fees must satisfy in order for such fees to be expressly permitted.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received support for the general conditions for permitted fees from commenters. Some commenters expressed appreciation for the guardrails and transparency of the permitted fees. Under the first condition, commenters sought clarity on the nature and extent of some of the permissible fees an API Technology Supplier can charge and how to model such fees, specifically regarding the “objective and verifiable” criteria. Another commenter supported the second condition that fees must be reasonably related to API Technology Supplier's costs of supplying and, if applicable, supporting the API technology to the API Data Provider, especially in situations where physicians may also develop APIs or support apps.
                    </P>
                    <P>However, some commenters expressed concern with the third condition to reasonably allocate fees across all customers of the API. Commenters explained that fees could not be reasonably allocated across all customers of the API, because the number of customers will change over time. We received no comments on the fourth condition that API Technology Suppliers must ensure that fees are not based on whether the requestor or other person is a competitor who will be using the API technology in a way that facilitates competition. In addition to the general permitted fees proposed, some commenters recommended clear fee exemption for any health information provided or reported by a practice for the purpose of meeting reporting requirements.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate feedback from commenters. We have finalized these general conditions for permitted fees in § 170.404(a)(3)(i)(B) with some modifications as described further below. We have finalized that for all permitted fees, a Certified API Developer must: (1) Ensure that such fees are based on objective and verifiable criteria that are uniformly applied to all similarly situated API Information Sources and API Users; (2) Ensure that such fees imposed on API Information Sources are reasonably related to the Certified API Developer's costs of supplying certified API technology to, and if applicable, support certified API technology for, API Information Sources; (3) Ensure that such fees for supplying, and if applicable, supporting certified API technology are reasonably allocated among all similarly situated API Information Sources; and (4) Ensure that such fees are not based on whether API Information Sources or API Users are competitors, potential competitors, or will be using the certified API technology in a way that facilitates competition with the Certified API Developer. We have revised the term “substantially similar” to “similarly situated” in § 170.404(a)(3)(i)(B)(
                        <E T="03">1</E>
                        ) for clarity and to align with changes made in § 171.302. Additionally, in response to comments and to align with changes made in § 171.302 and § 170.404(a)(3)(i)(B)(
                        <E T="03">1</E>
                        ), we have revised the term “substantially similar” to “similarly situated” in § 170.404(a)(3)(i)(B)(
                        <E T="03">3</E>
                        ). We emphasize that this provision is meant to prevent one customer or a specific group of customers to whom the certified API technology is supplied or for whom it is supported from bearing an unreasonably high cost compared to other customers, which could lead to “special effort” for accessing and using APIs. We believe the final policy achieves the same goal as proposed and provides clearer guidelines for the regulated community to follow. Additionally, we have revised the phrase “classes of persons and requests” to “API Information Sources and API Users” in § 170.404(a)(3)(i)(B)(
                        <E T="03">1</E>
                        ) to clearly express the actors being charged fees by Certified API Developers. Additionally, we have revised the sentence structure and grammar in § 170.404(a)(3)(i)(B)(
                        <E T="03">2</E>
                        ) through (
                        <E T="03">4</E>
                        ) for simplification.
                    </P>
                    <P>
                        In response to comments requesting clarity on the nature and extent of permissible fees a Certified API Developer can charge and how a Certified API Developer should model such fees, specifically regarding the “objective and verifiable” requirement finalized in §  170.404(a)(3)(i)(B)(
                        <E T="03">1</E>
                        ), we emphasize that there will be significant variability in the fee models and specific fees charged by each Certified API Developer. Our goal with the requirement that fees be “objective and verifiable” is to require Certified API Developers to apply fee criteria that, among other things, will lead the Certified API Developer to come to the same conclusion with respect to the permitted fee's amount each time it administers a fee to an API Information Source or API User. Accordingly, the fee cannot be based on the Certified API Developer's subjective judgment or discretion.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters suggested that ONC allow API Data Providers the ability to recoup the costs for upgrading technology.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         This comment appears to misunderstand the scope and applicability of ONC's authority with respect to these Condition of Certification requirements. We clarify that these Condition of Certification requirements apply only to Certified API Developers. We note that similar to any IT investment, API Information Sources (as “health care providers”) would generally be expected to recover these costs through fees administered while delivering health care services. Additionally, if an API Information Source were to recoup such costs they would need to do so consistent with the information blocking exceptions and other applicable laws and regulations.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters requested that ONC conduct evaluations after the implementation of the rule and use the results to drive future policy. Some commenters recommended a study to evaluate the real-world cost of APIs used by health systems in areas such as clinical decision support, payments, machine learning, and precision medicine. Commenters also suggested ONC conduct a study on whether these regulations improve patient access to their EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the evaluation recommendations. We will consider these suggestions as we implement and administer the Program.
                    </P>
                    <HD SOURCE="HD3">(C) Certified API Developer Prohibited Fees</HD>
                    <P>We proposed in 84 FR 7595 in §  170.404(a)(3)(iii)(B) that permitted fees would not include costs associated with intangible assets (including depreciation or loss of value), except the actual development or acquisition costs of such assets. Additionally, we proposed in §  170.404(a)(3)(iii)(C) that permitted fees would not include opportunity costs, except for the reasonable forward-looking cost of capital.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the proposal for costs associated with intangible assets other than actual development or acquisition costs of such assets.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We moved the proposed §  170.404(a)(3)(iii)(B) and (C) to the general conditions for permitted fees finalized in §  170.404(a)(3)(i)(C)(
                        <E T="03">1</E>
                        ) and (
                        <E T="03">2</E>
                        ), respectively, because they are general conditions on permitted fees rather than conditions for “Recovering API usage costs.” We did not make 
                        <PRTPAGE P="25754"/>
                        other changes to the proposed regulation text in these two sections other than updating terms to the finalized definitions in §  170.404(c).
                    </P>
                    <P>
                        Additionally, in the discussion of the Fees Exception in this final rule (VIII.D.2.b), we discussed that one commenter expressed concern that the overlap between the Fees Exception and the Licensing Exception creates the potential for actors to recover the same costs twice. The commenter explained that licensing of IP is intended to recoup the costs of development of that IP, so where the IP is an interoperability element, the costs reasonably incurred for its development should be incorporated into the royalty rate. The commenter recommended that we be clearer that, in these circumstances, only a single recovery is permitted. In order to address this comment and align the API permitted fees with related provisions finalized in the Fees Exception (§  170.302(a)(2)(vi)) and Licensing Exception (§  170.303(b)(2)(iv)), we have added and finalized §  170.404(a)(3)(i)(C)(
                        <E T="03">3</E>
                        ), which states that the permitted fees in this section cannot include any costs that that led to the creation of IP if the actor charged a royalty for that IP pursuant to §  170.303 and that royalty included the development costs for the creation of the IP. We refer readers to the “Basis for Fees Condition” sub-section within section VIII.D.2.b for a more detailed discussion of the rationale for this addition.
                    </P>
                    <HD SOURCE="HD3">(i) General Examples of Prohibited Fees</HD>
                    <P>As discussed in the Proposed Rule in 84 FR 7481 and finalized in § 170.404(a)(3)(i)(A), any API-related fee imposed by a Certified API Developer that is not expressly permitted is prohibited. In the Proposed Rule, we provided the following non-exhaustive examples of fees for services that Certified API Developers would be prohibited from charging, and reiterate them here in the final rule for clarity:</P>
                    <P>(1) Any fee for access to the documentation that a Certified API Developer is required to publish or make available under this Condition of Certification requirement.</P>
                    <P>(2) Any fee for access to other types of documentation or information that a software developer may reasonably require to make effective use of certified API technology for any legally permissible purpose.</P>
                    <P>
                        (3) Any fee in connection with any services that would be essential to a developer or other person's ability to develop and commercially distribute production-ready applications that use certified API technology. These services could include, for example, access to “test environments” and other resources that an application developer would need to efficiently design and develop apps. The services could also include access to distribution channels if they are necessary to deploy production-ready software and to production resources, such as the information needed to connect to certified API technology (
                        <E T="03">e.g.,</E>
                         service base URLs) or the ability to dynamically register with an authorization server.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         At least one commenter expressed concern about the open-ended nature of the examples of prohibited fees we provided in the Proposed Rule. In particular, that any fee in connection with any services that would be essential to a developer or other person's ability to develop and commercially distribute production-ready applications that use API technology would be prohibited. They stated that if the example were not more clearly defined and scoped, it could be used by API Users to create requirements for API Technology Suppliers beyond what would normally be considered necessary to successfully deploy apps in production. They requested ONC more clearly define “essential services” in final rulemaking or withdraw the reference.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We disagree with commenters that the examples are too broad. We believe that in some cases they need to be general because of the diverse and varied practices that could be used by Certified API Developers to create special effort to use certified API technology. While we understand that the generality of the example regarding “essential services” may at first appear difficult for Certified API Developers to follow and, per the commenter, could be creatively used by an API User to request more support than necessary, we offer the following as additional guidance: A Certified API Developer is best positioned to know what an API User, for example, needs to have access to and do programmatically in order for the API User's application to be developed and commercially distributed as production-ready for use with certified API technology. From a Certified API Developer's perspective, if that requires any number of mandatory steps (
                        <E T="03">e.g.,</E>
                         passing tests in sandbox/test environment, conducting a demo, submitting documentation or paperwork) in order for the application to be production-ready for use with certified API technology, then fees associated with those mandatory steps are prohibited. Conversely, fees for requirements beyond what a Certified API Developer considers necessary to successfully deploy applications in production are considered supplemental to the development, testing, and deployment of software applications that interact with certified API technology, and are permitted fees for value added services as finalized in § 170.404(a)(3)(iv).
                    </P>
                    <HD SOURCE="HD3">(D) Record-Keeping Requirements</HD>
                    <P>We proposed in § 170.404(a)(3)(v) that API Technology Suppliers must keep for inspection detailed records of all API technology fees charged, all costs incurred to provide API technology to API Data Providers, methodologies used to calculate such fees, and the specific costs to which such fees are attributed. We requested comment in 84 FR 7492 on whether these requirements provide adequate traceability and accountability for costs permitted under this API Condition of Certification and whether to require more detailed accounting records or prescribe specific accounting standards.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of commenters expressed concerns with the level of granularity proposed for record keeping in § 170.404(a)(3)(v). These commenters stated that the required recordkeeping would exceed documentation performed for any other purpose. Some commenters stated that the requirement for health IT developers to track who pays fees and how fees enter the system will cause significant administrative burden, especially on smaller vendors or vendors with business models that require less operational overhead. Additionally, they stated that the requirement for clients to maintain and potentially publicly disclose records of fees for inspection would place a burden on IT providers, and could potentially allow bigger companies to engage in practices such as predatory pricing. Commenters suggested ONC have a more scaled-back method, and simply allow patients the ability to access their EHI without charge. These commenters recommended focusing on a good conduct approach rather than prescriptive requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback and perspective. We moved § 170.404(a)(3)(v) to 170.404(a)(3)(i)(D) for better organization because this provision applies to the permitted fee Condition of Certification requirements finalized in § 170.404(a)(3)(ii) through (iii). We have finalized in § 170.404(a)(3)(i)(D) that Certified API Developers must keep detailed records for inspection of all fees charged, all costs incurred to provide certified API technology to API Information Sources, methodologies 
                        <PRTPAGE P="25755"/>
                        used to calculate such fees, and the specific costs to which fees are attributed. Considering the feedback on perceived burden, we believe transparency and documentation of API fees is necessary to mitigate unfair pricing practices that may stifle innovation or otherwise create barriers to the goals of enabling API-based access, exchange, and use of EHI without special effort. Further, we believe that the accounting practices already used by health IT developers will largely support the health IT developer to meet this requirement. Examples of these practices by health IT developers include the methods used to track their own investments, determine how to bill and issue invoices to their customers, document receipt of payment, and to maintain overall accurate financial records of business transactions. We find it difficult to believe, as some commenters appeared to indicate, that health IT developers are not already keeping such financial records and that this requirement would create substantial new documentation burden for Certified API Developers. The record-keeping requirements finalized in 170.404(a)(3)(i)(D) foster transparency and promote accountability in the Program. In response to the comments received, we have not added additional requirements for accounting records or standards.
                    </P>
                    <HD SOURCE="HD3">(E) Permitted Fee for Development, Deployment, and Upgrades</HD>
                    <P>We proposed in § 170.404(a)(3)(ii) to permit an API Technology Supplier to charge API Data Providers reasonable fees for developing, deploying, and upgrading Health IT Modules certified to § 170.315(g)(7) through (g)(11).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters applauded the permitted fee related to development, deployment, and upgrading API technology. The majority supported the proposal that fees would not be permitted if they interfere with an API User's ability to efficiently and effectively develop and deploy production-ready software. A few commenters expressed concern that our proposals regarding development, deployment, and upgrade fees were not restrictive enough. Commenters noted that API Technology Suppliers will use the allowable fees, such as for program upgrades, as a barrier to providing interoperability between systems or other applications and a means to eliminate competitive threats. Some of these commenters recommended that ONC explicitly prohibit API Technology Suppliers from charging any fees for implementing APIs and for facilitating the interoperable exchange of EHI and that this blanket prohibition apply to all new and updated API technology. A few commenters noted that it is possible that API Technology Suppliers will bundle or upcharge service fees to recoup API technology development costs and API Technology Suppliers should not be allowed to charge costs for development or impose surcharges for product feature development. They noted that product feature development should be considered a cost of doing business and can be amortized as a one-time capital expense across the vendor's entire customer base without the need for recovering costs from API Users. They emphasized that API access and use prices need to be transparent as the intent of Congress was to have APIs be made easily available and at no or low cost, not to be a source of revenue for profit. Other commenters noted that the development of the APIs themselves should be regarded as part of the license fee and the API Technology Suppliers should not be permitted to charge an additional license fee to either the API Data Provider or API User for what is an inherent part of the software. Another commenter requested that consideration be applied toward potential additional hidden integration fees.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support, concerns, and recommendations from commenters. We finalized this proposal in § 170.404(a)(3)(ii) as proposed with updated terms based on the revised finalized definitions in §  170.404(c). We refer to the discussions below and 84 FR 7488 for additional details on what Certified API Developer fees for “developing,” “deploying,” and “upgrading” certified API technology comprise. We also note that the nature of the costs charged under this category of permitted fees depends on the scope of the work to be undertaken by a Certified API Developer (
                        <E T="03">i.e.,</E>
                         how much or how little labor an API Information Source requires of the Certified API Developer to deploy and upgrade the certified API technology).
                    </P>
                    <P>We sincerely thank commenters for the various recommendations to prohibit or restrict fees regarding certified API technology. In order to reconcile the recommendations specific to § 170.404(a)(3)(ii) and other conditions in this final rule, we have aligned related conditions to address concerns and mitigate potential fee practices that could limit API-based access, exchange, and use of EHI by patients and other stakeholders without special effort. As finalized, we believe the fees permitted in § 170.404(a)(3)(ii) and § 170.404(a)(3)(i)(B), transparency requirements in § 170.404(a)(2), and openness and pro-competitive conditions in § 170.404(a)(4) will ensure that fees permitted for upgrade costs will not be used as a barrier to providing interoperability between systems or other applications, or as a means to eliminate competitive threats. Additionally, the transparency requirements regarding the publication of fees finalized in § 170.404(a)(2)(ii)(B) will help prevent hidden integration fees cited by commenters.</P>
                    <P>
                        We thank commenters for recommending and noting that development of the APIs themselves should be regarded as part of a license fee and that Certified API Developers should not be permitted to charge an additional license fee for what is an inherent part of the software. In response to this recommendation, we have added a provision in § 170.404(a)(3)(i)(C)(
                        <E T="03">3</E>
                        ) that states that permitted fees in § 170.404(a)(3)(ii) through (iv) may not include any costs that led to the creation of IP, if the actor charged a royalty for that IP pursuant to the information blocking Licensing Exception (§ 171.303). This provision aligns with similar provisions included in the information blocking section and will ensure that Certified API Developers cannot earn a double recovery in instances described by the commenter.
                    </P>
                    <P>
                        We will continue to work with stakeholders to advance policies that promote interoperability and deter practices that may stifle innovation or present barriers to the access, exchange, and use of EHI through APIs. Subject to the general conditions in §  170.404(a)(3)(i), our final policies support the ability of Certified API Developers to recover the full range of reasonable costs associated with developing, deploying, and upgrading API technology over time. It is important that Certified API Developers be able to recover these costs and earn a reasonable return on their investments so that they have adequate incentives to make continued investments in these technologies. In particular, we anticipate Certified API Developers will need to continually expand the data elements and upgrade the capabilities associated with certified APIs as the USCDI and HL7® FHIR® standard and associated implementation specifications mature. We refer readers to the information blocking section of this preamble (VIII) for additional information on activities that may constitute information blocking and for discussion about how the fees provisions in this Condition of Certification and within the information blocking section support innovation.
                        <PRTPAGE P="25756"/>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some developers expressed concern regarding balancing and distributing costs with regard to the permitted fee for developing, deploying, and upgrading technology. The commenters noted ONC proposed that the cost for development be distributed among those who will use it, which they felt was problematic in many ways, but most fundamentally because it suggests a serious misconception about how software development is funded, priced, and sold. The commenters emphasized that requiring development costs to be divided among clients purchasing the API necessitates new and complex business processes and creates unsolvable scenarios that could easily create business conflicts between API Technology Suppliers and their clients. At least one commenter suggested that ONC should consider balancing the costs associated with API development and deployment across both API Data Providers and certain API Users to ensure that third-party software application developers also bear some of the financial burden, since they stand to generate revenue from the use of their apps. Commenters asked ONC clarify why it believes it is inappropriate to pass development, deployment, and upgrade costs on to API Users. Other commenters noted that the costs for updating information systems and Health IT Modules to the new standards and requirements should not be passed on to physicians and patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We proposed and finalized this permitted fee for development, deployment, and upgrade costs because we believe that these costs should be negotiated solely between the Certified API Developer that supplies the capabilities and the API Information Source that implements them in their production environment. In our view, it is inappropriate for Certified API Developers to go around the API Information Source to directly impose financial cost burdens on API Users for the benefit of working with or connecting to the API Information Source. Based on our experience, the practice of a Certified API Developer going around its customer (the API Information Source) to also charge API Users erodes an API Information Source's choice and the independence of their relationship with API Users. As such, that kind of business practice would be something that we would consider creating special effort on the part of the API Users if they had to continue to face additional fees just for permission to work with or connect to an API Information Source's certified API technology.
                    </P>
                    <P>While the development, deployment, and upgrade permitted fee is limited between the Certified API Developer and API Information Source as a way to recoup a Certified API Developer's costs to supply certified API technology to a particular API Information Source, we again reiterate that the value added services permitted fee providers Certified API Developers a wide range of options to make additional revenue related to their certified API technology.</P>
                    <P>Should API Users stand to generate revenue from the use of their apps, any fee an API Information Source may impose would not be in scope for this Condition of Certification but would be likely be covered by information blocking. Accordingly, we emphasize that such stakeholders should take care to ensure they are compliant with other Federal and State laws and regulations that may prohibit or limit certain types of relationships involving remuneration.</P>
                    <P>In response to comments suggesting that costs for updating information systems and Health IT Modules to the new standards and requirements would be passed on to physicians and patients, we disagree. We emphasize that most of the information contained in a patient's electronic record has been documented during the practice of medicine or has otherwise been captured in the course of providing health care services to patients. In our view, patients have effectively paid for this information, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf, and should be able to access the information via certified API technology without fees.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some developers suggested that API Technology Suppliers should be able to charge fees for access to a test environment and requested clarification as to whether an API Technology Supplier can charge for the use of sandboxes by API Users.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. As detailed in the “General Examples of Prohibited Fees” section of the preamble text and included in the general prohibition finalized in § 170.404(a)(3)(i)(A), Certified API Developers are prohibited from charging fees in connection with any services essential to a developer or other person's ability to develop and commercially distribute production-ready applications for use with certified API technology. In general, if a test environment or sandbox is required to be used by a Certified API Developer and is essential for an application to be developed in order to be considered production-ready by the Certified API Developer for use with its certified API technology, then fees associated with that kind of test environment would be prohibited as they would impose special effort. However, we note that this prohibition is not globally applicable. If instead, the purpose of the testing environment was to provide specific testing above-and-beyond production-readiness for use with certified API technology, then fees could be charged for such testing as part of the value-added services permitted fee.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested guidance on how ONC expects API Technology Suppliers to account for the costs incurred to develop, deploy, and upgrade the API technology, which is part of, and not necessarily separable from, the broader EHR product. Several commenters opposed the prohibition against charging for work to upgrade the broader EHR product, expressing that this is essential work needed to modernize their solutions as broader technologies evolve. One commenter noted that the Proposed Rule does not set specific guidelines on what constitutes an upgrade or how much the fee could be, and it is the commenter's experience that EHR systems often charge fees for such services as integrating with a clinical data registry or using outside or non-preferred software.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank stakeholders for their comments. While we understand that there is overlap between features of the certified API technology and the “broader EHR product,” we refer specifically to development, deployment, and upgrades made to “certified API technology” as defined in § 170.404(c). Namely, development, deployment, and upgrades made to the capabilities of certified Health IT Modules that fulfill the API-focused certification criteria adopted at § 170.315(g)(7) through (10). In response to commenters concerned that EHR developers often charge fees for services such as integrating with a clinical data registry or using outside or non-preferred software, we note that, as described in § 170.404(a)(3)(i)(A), Certified API Developers are prohibited from imposing fees associated with certified API technology unless included as a permitted fee in § 170.404(a)(3)(ii) through (iv). We do not include specific price information for permitted fees to develop, deploy, or upgrade API technology, because these costs are subject to change over time with new technology and varying development, deployment, and upgrade 
                        <PRTPAGE P="25757"/>
                        efforts. Instead, we allow Certified API Developers to recover their costs (including costs that result in a reasonable profit margin for permitted fees in § 170.404(a)(3)(ii) and § 170.404(a)(3)(iv)) in providing certified API technology while being compliant with the Condition and Maintenance of Certification and Program requirements. We include descriptions of fees for developing, deploying, and upgrading API technology in the sections that follow, in which we offer additional clarity, as discussed in the Proposed Rule at 84 FR 7488, on the fees for developing, deploying, and updating API technology.
                    </P>
                    <HD SOURCE="HD3">(i) Fees for Developing Certified API Technology</HD>
                    <P>Fees for “developing” certified API technology comprise the Certified API Developer's costs of designing, developing, and testing certified API technology. In keeping with our discussion at 84 FR 7488, fees for developing certified API technology must not include the Certified API Developer's costs of updating the non-API related capabilities of the Certified API Developer's existing Health IT Modules, including its databases, as part of its development of the certified API technology. As we further discussed in 84 FR 7488 in our Proposed Rule, these costs are connected to past business decisions made by the Certified API Developer and typically arise due to Health IT Modules being designed or implemented in nonstandard ways that unnecessarily increase the complexity, difficulty or burden of accessing, exchanging, or using EHI. The recovery of costs associated with updating a Certified API Developer's non-API related Health IT Modules capabilities would be inconsistent with the Cures Act requirement that API technology be deployed “without special effort.”</P>
                    <HD SOURCE="HD3">(ii) Fees for Deploying Certified API Technology</HD>
                    <P>Certified API Developer's fees for “deploying” certified API technology comprise the Certified API Developer's costs of operationalizing certified API technology in a production environment. Such fees include, but are not limited to, standing up hosting infrastructure, software installation and configuration, and the creation and maintenance of API Information Source administrative functions. We discussed in our Proposed Rule that a Certified API Developer's fees for “deploying” certified API technology does not include the costs associated with managing the traffic of API calls that are used to access the certified API technology, which a Certified API Developer can only recover under the permitted fee for usage support costs (§ 170.404(a)(3)(iii)). We emphasize that for the purpose of this Condition of Certification, we consider that certified API technology is “deployed” by the customer—the API Information Source—that purchased or licensed it.</P>
                    <HD SOURCE="HD3">(iii) Fees for Upgrading Certified API Technology</HD>
                    <P>
                        The Certified API Developer's fees for “upgrading” certified API technology comprise the Certified API Developer's costs of supplying an API Information Source with an updated version of certified API technology. Such costs would include the costs required to bring certified API technology into conformity with new requirements of the Program, upgrades to implement general software updates (not otherwise covered by development fees or under warranty), or developing and releasing newer versions of the certified API technology at the request of an API Information Source. The nature of the costs that can be charged under this category of permitted fees depends on the scope of the work undertaken by a Certified API Developer (
                        <E T="03">i.e.,</E>
                         how much or how little labor an API Information Source requires of the Certified API Developer to upgrade the certified API technology being supplied from one version or set of functions to the next).
                    </P>
                    <HD SOURCE="HD3">(F) Permitted Fee to Recover Costs of Supporting API Usage</HD>
                    <P>We proposed in 84 FR 7489 in § 170.404(a)(3)(iii) to permit an API Technology Supplier to charge API usage-based fees to API Data Providers to recover the API Technology Supplier's reasonable incremental costs for purposes other than facilitating the access, exchange, or use of EHI by patients or their applications, technologies, or services. We considered “usage-based” fees to be the fees imposed by an API Technology Supplier to recover the costs that would typically be incurred supporting API interactions at increasing volumes and scale within established service levels. Additionally, in 84 FR 7489 under § 170.404(a)(3)(iii), we proposed that any usage-based fees associated with API technology be limited to the recovery of the API Technology Supplier's “incremental costs.” Additionally, we proposed in § 170.404(a)(3)(iii)(A) that the permitted fee would not include any costs incurred by the API Technology Supplier to support uses of the API technology that facilitate a patient's ability to access, exchange, or use their EHI. Finally, we proposed in § 170.404(a)(3)(iii)(B)-(C) restrictions for permitted fees that were moved to the general permitted fees section finalized in § 170.404(a)(3)(i)(C).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters generally supported our proposal to permit an API Technology Suppliers to charge usage-based fees to API Data Providers to the extent that the API technology is used for purposes other than facilitating the access, exchange, or use of EHI by patients or their applications, technologies, or services.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate support from commenters and have finalized this proposal in § 170.404(a)(3)(iii) with some modification. We amended the title of the regulation text for clarity in § 170.404(a)(3)(iii) to “Permitted fee—Recovering API usage costs.” Additionally, we amended the regulation text to focus on usage-based fees and Certified API Developer's reasonable incremental costs. We did not finalize the specific prohibition on permitted fees proposed in § 170.404(a)(3)(iii)(A) that the “permitted fee does not include costs incurred by the API Technology Supplier to support uses of the API technology that facilitate a patient's ability to access, exchange, or use electronic health information.” We did not finalize this aspect of the provision because upon further consideration of this cost and the fee prohibition included in information blocking related to patient access, we determined that these fees remain necessary in order to allow Certified API Developers to recover incremental costs reasonably incurred during the process of hosting certified API technology on behalf of the API Information Source. We reiterate that a Certified API Developer's “incremental costs” comprise the Certified API Developer's costs that are directly attributable to supporting API interactions at increasing volumes and scale within established service levels. A Certified API Developer should “price” its costs of supporting access to the certified API technology by reference to the additional costs that the Certified API Developer would incur in supporting certain volumes of API use. For comments and responses related to the proposed provisions in § 170.404(a)(3)(iii)(B) and (C), we refer readers to the header “Certified API Developer Prohibited Fees.”
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a few comments focused on volume thresholds and incremental costs. A few commenters supported a reasonable cap for API call fees. Several recommended changing the parameters around API usage-based fees to focus on volume 
                        <PRTPAGE P="25758"/>
                        thresholds being included in any contractual language related to these fees, to ensure that any incremental costs attributable to supporting API interactions at increasing volumes and scale are addressed appropriately. Commenters noted that if an API Technology Supplier is receiving fees to develop, deploy, and upgrade API technology, it is unlikely that they would also need to charge for usage of the APIs, as long as their usage remains under a pre-determined volume threshold. A few commenters noted that the volume of requests that will be pinging APIs may compromise the performance of data retrieval and effective user experience. In order to protect against denial of service attacks whether intentional or inadvertent, they stated ONC should consider an additional throttling or rate-limiting layer or capability onto the API in order for the API to accept and digest the data being entered or extracted. A few commenters noted that our proposal could create loopholes that would enable certain organizations to charge highly burdensome, excessive fees to clinical registries to access their data.
                    </P>
                    <P>A few commenters expressed concern that this proposal is not restrictive enough. Some commenters requested that ONC provide more definitive guidance, including a range of prices based on examples from the current marketplace, to ensure providers are not charged unreasonable fees by API Technology Suppliers and can reasonably charge API Users for the cost of accessing their API technology.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. This Condition of Certification requirement offers the flexibility necessary to accommodate reasonable pricing methodologies and will allow Certified API Developers to explore innovative approaches to recovering the costs associated with supporting the use of certified API technology with a permitted fee. As described in the Proposed Rule (84 FR 7489), “usage-based” fees are fees imposed by a Certified API Developer to recover costs typically incurred for supporting API interactions at increasing volumes and scale within established service levels. That is, “usage-based” fees recover costs incurred by a Certified API Developer due to the actual use of the certified API technology once it has been deployed (
                        <E T="03">e.g.,</E>
                         costs to support a higher volume of traffic, data, or number of apps via the certified API technology). Certified API Developers can adopt a range of pricing methodologies when charging for the support of API usage. We appreciate commenters' request to establish a reasonable cap for API usage-based fees, but the focus of our policy is to identify usage fees as a type of permitted fee and not to dictate a singular fee model, which we believe could limit Certified API Developers ability to create innovative fee models that serve to benefit themselves and API Information Sources. We decline to include a price cap for API usage-based fees or a range of prices for API fees based on examples from the current marketplace because we anticipate the cost of technology will change over time and so too will the way in which usage costs are calculated. Additionally, while we understand and expect that Certified API Developers and API Information Sources will deploy particular security methods to mitigate the risk of denial of service attacks and other impacts on API availability, these types of technology layers are separate from the focus of our policy on permitted API usage fees.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that ONC further clarify that API Technology Suppliers should not attempt to charge different fees for different API transactions as they frequently do today.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this information and feedback from commenters. We clarify that Certified API Developers are permitted to charge “usage-based” fees to recover the costs that would typically be incurred supporting API transactions at increasing volumes and scale within established service levels. To clarify, usage-based fees recover costs incurred by a Certified API Developer related to the actual use of certified API technology once it has been deployed (
                        <E T="03">e.g.,</E>
                         costs to support a higher volume of traffic, data, or number of apps via the API Technology). We acknowledge that Certified API Developers could adopt a range of pricing methodologies when charging for the support of API usage, including potentially charging higher prices for some API transactions that incur relatively higher costs than others. However, in combination with this flexibility, Certified API Developers will still need to be mindful of not violating any overarching information blocking policies. We refer readers to a discussion in the Proposed Rule in 84 FR 7489 for additional discussions on usage-based fees.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters emphasized that it is unreasonable to presume that API User-driven data overages should be the responsibility of the API Data Provider. While other commenters expressed concern that our proposal will leave providers, who are mandated to use certified EHRs that include API technology and provide patients with access to data via those APIs, responsible for a variety of unwarranted costs with little recourse to recover those costs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         While we understand the perspective from which these concerns arise, especially regarding unpredictable overuse of certified API technology, an API Information Source has financial responsibility for its overall technology infrastructure. This accountability is no different for certified API technology than it is for non-certified APIs and other interfaces that may also create costs for the API Information Source (
                        <E T="03">i.e.,</E>
                         health care provider). Given that API Users can also include an API Information Source's own employees/internal tools and 3rd party partners' tools, an API Information Source is best positioned and generally accountable for its financial commitments. Again, as noted above, we do not limit who may pay for the charges an API Information Source incurs. An API Information Source should have full knowledge and ability to assess what employees, internal applications, and 3rd party services it has granted access to use and interact with its certified API technology. With respect to potential overages as a result of patient access, as we have stated before, we believe patients have effectively paid for this information, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf, and believe they should not be charged.
                    </P>
                    <P>
                        Additionally, as stated in the Proposed Rule (84 FR 7489) and finalized here, usage fees for certified API technology will only apply when the Certified API Developer acts on behalf of the API Information Source to deploy its certified API technology. In scenarios where the API Information Source, such as a large hospital system, assumes full responsibility for the technical infrastructure necessary to deploy and host the certified API technology it has acquired, the volume and scale of its usage would be the API Information Source's sole responsibility, and a Certified API Developer would not be permitted to charge usage-based fees. Instead, the Certified API Developer would be limited to charge fees under the “development, deployment, upgrade” permitted fee in § 170.404(a)(3)(ii). Additionally, the costs recovered under “usage-based” fees can only reflect “post-deployment” costs. As such, “usage-based” fees cannot include any costs necessary to prepare and “get the certified API technology up, running, and ready for use,” which are costs that must be 
                        <PRTPAGE P="25759"/>
                        recovered as part of the deployment services delivered by the Certified API Developer if permitted under § 170.404(a)(3)(ii).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported ONC's efforts to bolster patient access, noting that the capacity to offer a patient's access to all elements of their electronic medical record, through an API, without cost, is well-supported in the Proposed Rule. One commenter noted that the proposed provisions regarding fees supports uses of the API technology that facilitate a patient's ability to access, exchange, or use their EHI. The commenters noted that the clear language in the Proposed Rule will prevent any potential confusion or friction in the future.
                    </P>
                    <P>A few commenters expressed concern that application developers will attempt to leverage the patient access fee limitations by claiming to be patient facing. One commenter suggested that the proposed fee limitations regarding patient access applied only with respect to fees API Technology Providers impose on API Data Providers, should also apply to fees charged to consumer-facing application developers who in the past have been charged high fees by CEHRT developers. One commenter recommended making it clear that provider organizations and health IT developers cannot charge patients, or the apps that they use, for using patient-facing APIs. At least one commenter requested that ONC clarify that permitted usage-based fees do not apply to patients or patient designees.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support for restricting API-related fees. As noted above, we have reconfigured the permitted fee for usage costs in response to public comments and our assessment of the intersection of API permitted fees policies and information blocking policies. We have finalized an approach that permits Certified API Developers to recover incremental usage costs reasonably incurred during the process of hosting certified API technology on behalf of an API Information Source, which could include fees to the API Information Source for providing and supporting patient access. However, the Certified API Developers and API Information Sources cannot recover these costs from patients or the developers of applications that facilitate access to and receipt of patients' EHI. Patients have already effectively paid for their EHI, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf. We refer readers to the Fees Exception in the information blocking section of this final rule in VII.D.2.b, which applies to health IT developers and a broader set of actors than these Condition and Maintenance of Certification requirements, for a discussion of the restrictions on charging patients for access to their EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that ONC provide further guidance on the types of costs that a developer could charge to permit API Data Suppliers to offer population-level queries to API Users. They requested ONC clarify that such usages fees must relate to the costs associated with actual hardware (
                        <E T="03">e.g.,</E>
                         server space) needed to support the increased volume of queries for non-patients and not the cost of implementing the population-level query functionality itself.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We clarify that API usage fees related to API “read” services for multiple patients would be calculated using a similar methodology to calculate API usage fees related to API “read” services for single patients. These “usage-based” fees are fees imposed by a Certified API Developer to recover the costs typically incurred to support API interactions for API “read” services for multiple patients once these services have been deployed. This could include, but not be limited to, costs to support a higher volume of traffic, data, or number of apps via the certified API technology (which could include higher costs for hardware, including server space). We appreciate the recommendation from commenters; however, we have not prescribed the centralization of all of this content.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters suggested that API Technology Suppliers publish their fees on the same website as their API documentation so there is full transparency and an API Data Supplier and API User can easily understand costs before embarking upon development.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the recommendation and support from commenters. As finalized under § 170.404(a)(2)(ii)(B), a Certified API Developer must publish all terms and conditions for its certified API technology, including any fees. 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, including the persons or classes of persons to whom the fee applies; the circumstances in which the fee applies; and 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>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that usage-based fees may not be appropriate. They stated that, in the case of TEFCA, HIEs and providers must be responsive to inbound requests to broadcast data and should not be charged a fee for responding to such requests. They explained that such an arrangement could be used maliciously between market participants seeking to increase the operational expenses of their competitors.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment, but we continue to believe that that usage-based fees should be permitted subject to the conditions described in § 170.404(a)(3)(iii). We have addressed commenter's concern regarding potential anticompetitive behavior through the final provisions in § 170.404(a)(3)(i)(B). Specifically, in § 170.404(a)(3)(i)(B)(
                        <E T="03">1</E>
                        ), a Certified API Developer must ensure that fees are based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons and requests. In addition, under § 170.404(a)(3)(i)(B)(
                        <E T="03">4</E>
                        ), a Certified API Developer must ensure that fees are not based in any part on whether the requestor or other person is a competitor, potential competitor, or will be using the certified API technology in a way that facilitates competition with the Certified API Developer.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern about incremental costs that can be recovered by actors supporting the use of APIs for purposes other than patient access. They requested ONC clarify that recovery of incremental costs for these other purposes should not be allowed, because they believed the incremental costs do not add any efficiency to the health care system, do not benefit patients, and do not serve any other procompetitive purpose.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments, but continue to believe that “incremental costs” should be allowed. A Certified API Developer's “incremental costs” comprise the Certified API Developer's costs that are directly attributable to supporting API interactions at increasing volumes and scale within established service levels. We believe a Certified API Developer should “price” its costs of supporting access to the certified API technology by reference to the additional costs that the Certified API Developer would incur in supporting certain volumes of API use. In practice, we expect that this means that a Certified API Developer will offer a certain number of “free” API calls based on the fact that, up to a certain threshold, the Certified API Developer will not incur any material costs in supporting certified API technology in addition to the costs recovered for 
                        <PRTPAGE P="25760"/>
                        deployment services. However, after this threshold is exceeded, we expect that the Certified API Developer will impose usage-based costs commensurate to the additional costs that the Certified API Developer must incur to support certified API technology use at increasing volumes and scale.
                    </P>
                    <P>We expect that Certified API Developers will charge fees that are correlated to the incremental rising of costs required to meet increased demand. For example, if, at a certain volume of API calls, the Certified API Developer needed to deploy additional server capacity, the associated incremental cost of bringing an additional server online could be passed on to the API Information Source because the certified API technology deployed on behalf of the API Information Source was the subject of the higher usage. In this example, up until the point that the threshold is reached, the additional server capacity is not required, so the Certified API Developer would not be permitted to recover the costs associated with it. Moreover, the additional server capacity would support ongoing demand up to a certain additional volume, so the Certified API Developer would not be permitted to recover the costs of further additional server capacity until the existing capacity was exhausted.</P>
                    <HD SOURCE="HD3">(G) Permitted Fee for Value-Added Services</HD>
                    <P>We proposed in 84 FR 7490 and 7491 in § 170.404(a)(3)(iv) to permit an API Technology Supplier to charge fees to API Users for value-added services supplied in connection with software that can interact with the API technology. We also clarified in 84 FR 7491 that a fee will only be permitted if it relates to a service that an API User, such as a software developer, can elect to purchase, but is not required to purchase in order to develop and deploy production-ready apps for API technology.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported our proposal to permit an API Technology Supplier to charge fees to API Users for value-added services supplied in connection with software that can interact with certified API technology. Some commenters requested certain clarifications regarding our proposal. One commenter requested that we clarify within the discussion of value-added services, that references to “app stores” and “listing processes” for software applications that register to connect with the API technology are solely intended as examples to illustrate when a fee would or would not qualify as a “value-added service,” and are not meant to convey a requirement or expectation that API Technology Suppliers provide an app store with application listing free of charge. A few commenters requested that ONC clarify that EHR developers can charge value-add fees without triggering the information blocking provision. A couple other commenters requested additional examples of what constitutes a “value-added” service for which an API Technology Supplier can charge fees to an API User.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback. We have finalized §  170.404(a)(3)(iv) as proposed, with the exception of updating terms based on the definitions finalized in §  170.404(c). Our final policy permits Certified API Developers to charge fees, including a reasonable profit margin, to API Users for value-added services related to certified API technology, so long as such services are not necessary to efficiently and effectively develop and deploy production-ready software that interacts with certified API technology. We clarify that the value-added services need to be provided in connection with and supplemental to the development, testing, and deployment of production-ready software applications that interact with certified API technology. A fee is permitted if it relates to a service that a software developer can elect to purchase from a Certified API Developer, but is not required to purchase in order to develop and deploy production-ready apps for certified API technology.
                    </P>
                    <P>In response to comments for clarity, we note that examples used to illustrate when a fee would or would not qualify as a “value-added service,” such as app store listing, are demonstrative, but not required unless otherwise noted in the regulation text. Under this condition, we permit fees for services associated with the listing and promotion of apps beyond basic application placement so long as the Certified API Developer ensures that basic access and listing in the app store is provided free of charge (if an application developer depended on such listing to efficiently and effectively develop and deploy production-ready apps for use with certified API technology). Fees charged for additional/specialized technical support or promotion of the API User's application beyond basic access and listing services would be examples of permitted value-added services. We caution health IT developers not to over-interpret the scope of this Condition of Certification, which is focused on certified API technology. To the degree that a health IT developer administers an “app store” and offers value-added services associated with certified API technology, the Condition of Certification covers its practices related to certified API technology only. Conversely, this Condition of Certification would not apply to any practices that do not involve certified API technology. However, health IT developers would need to be mindful of any applicable information blocking rules that may apply to their app store practices given applicable facts and circumstances. Regarding the request for specific value-added fees that would not constitute information blocking, we refer readers to the information blocking section (VIII) of this preamble.</P>
                    <HD SOURCE="HD3">(H) Request for Comment on § 170.404(a)(3)</HD>
                    <P>We requested comment at 84 FR 7491 on any additional specific “permitted fees” not addressed in our Proposed Rule (84 FR 7491) that commenters felt API Technology Suppliers should be able to recover in order to assure a reasonable return on investment. Furthermore, we requested comment on whether it would be prudent to adopt specific, or more granular, cost methodologies for the calculation of the permitted fees. We encouraged commenters to consider, in particular, whether the approach we described would be administrable and appropriately balance the need to ensure that stakeholders do not encounter unnecessary costs and other special effort with the need to provide adequate assurance to API Technology Suppliers, investors, and innovators that they will earn a reasonable return on their investments in API technology. We welcomed comments on whether the approach adequately balances these concerns and achieves our stated policy goals. We also welcomed comments on potential revisions or alternative approaches. We encouraged detailed comments that included, where possible, economic justifications for suggested revisions or alternative approaches.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested we alter our approach to APIs so that it is tiered fee structure. They suggested that ONC could establish categories where the technology requirements designate the fees: (1) A “no fee” category would limit API Technology Suppliers from charging API Data Providers or API Users any fees for exchanging data in compliance with Federal requirements; (2) an “at cost” category would allow API Technology Suppliers to charge API Data Providers or API Users the cost of interfacing APIs with a non-API Technology Supplier's commercial technology; and (3) a “cost plus reasonable profit” category would allow 
                        <PRTPAGE P="25761"/>
                        API Technology Suppliers to charge API Data Providers or API Users a reasonable profit when conducting legitimate custom API development or creating custom apps.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the recommendation from commenters, but we have not adopted a tiered fee structure in the final rule because it would require unnecessary specificity and prescribe a particular method that could have unintended effects of limiting the market's evolution over time. We believe the current structure for prohibited and permitted fees allows for the adequate cost recovery and reasonable profit by Certified API Developers while also establishing the guardrails around which API access can be enabled without special effort.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters expressed concerns related to the effect our proposals regarding API fees would have on innovation and business. Several commenters noted that the structure of permitted fees could have unintended consequences that will ultimately work to impede innovation, increase administrative burden, and focus on cost recovery rather than creation of novel ways to improve data access.
                    </P>
                    <P>Several developers stated that the proposed fee structure specifically works to sever business relationships between API Technology Providers and API Users for anything other than “value added services” and effectively eliminates the ability for API Users to work directly with API Technology Suppliers to innovate and accelerate API development, and to achieve truly integrated and supported products throughout the product lifecycle. They suggested that a better model would be one that gives API Data Providers rights to leverage APIs “without special effort,” while supporting the ability for API Technology Suppliers and API Users to voluntarily engage in direct business relationships under mutually agreeable terms that are fair and equitable. Some developers stated that the market should determine permitted fees. They stated that in order to maintain a vigorously competitive market, API Technology Suppliers must be adequately compensated for their work to create and deploy non-standard APIs and support expanding standards. They explained that without this compensation, there will be far fewer entrants into the certified health IT space and current participants will depart.</P>
                    <P>A couple of developers recommended that ONC allow revenue-sharing models for certain components of certified APIs. The commenters suggested that ONC should view revenue sharing arrangements as a type of market-based compensation that will ultimately benefit innovation and competition. Conversely, one commenter stated that it is essential that API Technology Suppliers be expressly prohibited from conditioning access to API technology on charging revenue-sharing or royalty agreements to API Data Providers or API Users outside of actual usage costs incurred. The commenter noted this rent-seeking behavior is anti-competitive in nature and can have a significant impact on squelching any new market entrants and allow existing health IT actors to prevent all the positive outcomes that could arise from the ONC's proposed rules. Some developers stated that the prohibition against health IT developers charging for work to update their code structure is unreasonable, emphasizing that this is important work that is necessary for companies to be able to modernize their solutions as broader technologies evolve.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments, but disagree with commenters regarding the potential negative effect of the final permitted fee structure on innovation. We also note that the value-added services permitted fee does permit a direct relationship between Certified API Developers and API Users. What is generally prohibited and what we noted presented “special effort” in the Proposed Rule were Certified API Developer practices that required an API Information Source to seek permission to use its own certified API technology from the Certified API Developer.
                    </P>
                    <P>
                        We reiterate that complying with the requirements of this permitted fee and the information blocking exception will generally 
                        <E T="03">not</E>
                         prevent an actor from making a reasonable profit in connection with the access, exchange, or use of EHI. To be responsive to comments, we have added a provision in § 171.404(a)(3)(i)(A) to clarify this point. This final provision states that certain permitted API fees (§ 170.404(a)(3)(ii) and § 170.404(a)(3)(iv)) may include fees that result in a reasonable profit margin in accordance with the Costs Exception (§ 171.302). We believe that the allowance of reasonable profits is necessary to incentivize innovation and allow innovators to earn returns on the investments they have made to develop, maintain, and update innovations that ultimately improve health care delivery and benefit patients. Our finalized approach to API fees strikes the appropriate balance of addressing the rent-seeking and exclusionary pricing practices noted by the commenters while enabling and supporting innovation.
                    </P>
                    <P>We also emphasize that a majority of the EHI has been generated and recorded in the course of furnishing health care services paid with public dollars through Federal programs, including Medicare and Medicaid, or directly subsidized through the tax preferences for employer-based insurance. Yet, this EHI is not readily available where and when it is needed. We believe the overwhelming benefits of publishing certified APIs that allow EHI from such technology to be accessed, exchanged, and used without special effort far outweigh the potential burden on Certified API Developers and API Information Sources.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested that ONC clarify whether API Data Suppliers would be allowed to recoup costs from API Users in light of the information blocking provisions. A few commenters expressed confusion that fees are addressed under the API Condition and Maintenance of Certification and information blocking. The commenters suggested that ONC address fees in one consolidated section.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment and refer readers to the information blocking section of this rule. We do not believe that a discussion of fees should be consolidated in one section for a couple of reasons. First, the information blocking provision has a much broader reach than the Condition and Maintenance of Certification requirements and regulates conduct of health IT developers of certified Health IT Modules, health care providers, health information networks, and health information exchanges. The Condition and Maintenance of Certification requirements only relate to conduct by health IT developers of certified Health IT Modules. Second, the API Condition of Certification covers a much narrower scope of potential fees, as the fees in this section are specific to certified API technology only while fees in the information blocking section generally relate to the access, exchange, or use of EHI regardless of the particular technology used.
                    </P>
                    <P>
                        We emphasize that we have finalized a provision in § 171.302(c) that if the actor is a health IT developer subject to the Condition of Certification requirements in § 170.402(a)(4) (Assurances), § 170.404 (API), or both, the actor must comply with all requirements of such conditions for all practices and at all relevant times. Under this provision, health IT developers of certified Health IT 
                        <PRTPAGE P="25762"/>
                        Modules subject to the API Condition of Certification requirements may not charge certain types of fees and are subject to more specific cost accountability provisions than apply generally under the Costs Exception. We explain in the Costs Exception that a failure of developers to comply with these additional requirements would impose impediments to consumer and other stakeholder access to EHI without special effort and would be suspect under the information blocking provision.
                    </P>
                    <HD SOURCE="HD3">vi. Openness and Pro-Competitive Conditions</HD>
                    <P>We proposed in 84 FR 7595 in § 170.404(a)(4) that an API Technology Supplier must grant API Data Providers the sole authority and autonomy to permit API Users to interact with the API technology deployed by the API Data Provider in a non-discriminatory manner; provide all reasonably necessary support and other services to enable the effective development, deployment, and use of API technology by API Data Providers and its API Users to access, exchange, and use EHI in production environments; not impose collateral terms or agreements that could interfere with the use of API technology; and provide reasonable notice prior to making changes to its API technology or terms and conditions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of commenters supported the proposed openness and pro-competitive conditions. Several commenters requested clarification about API Data Providers' rights and responsibilities when providing access to an application of a patient's choice. Specifically, they sought clarification on whether they can vet, deny, or limit access by applications that are using the API technology inappropriately. Another commenter proposed that app developers be required to obtain a business associate agreement (BAA) with providers prior to the application developer gaining access to a patient's EHI on behalf of a patient.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. Based on the support from commenters, we have finalized that a Certified API Developer must grant API Information Sources the independent ability to permit API Users to interact with the certified API technology deployed by the API Information Source in § 170.404(a)(4).
                    </P>
                    <P>
                        Under the HIPAA Privacy Rule, a business associate relationship exists if an entity creates, receives, maintains, or transmits ePHI on behalf of a covered entity (directly or through another business associate) to carry out the covered functions of the covered entity. HIPAA does not require a covered entity (
                        <E T="03">e.g.,</E>
                         API Information Source) or its business associate (
                        <E T="03">e.g.,</E>
                         API Technology Supplier) to enter into a business associate agreement with an app developer that does not create, receive, maintain, or transmit ePHI on behalf of or for the benefit of the covered entity (whether directly or through another business associate). However, if the app was developed to create, receive, maintain, or transmit ePHI on behalf of the covered entity (API Information Source), or was provided by or on behalf of the covered entity (directly or through its API Technology Supplier, acting as the covered entity's business associate), then a business associate agreement would be required.
                        <SU>106</SU>
                        <FTREF/>
                         In such cases, API Information Sources have the ability to conduct whatever “vetting” they deem necessary of entities (
                        <E T="03">e.g.,</E>
                         app developers) that would be their business associates under the HIPAA Rules before granting access and use of EHI to the entities. In this regard, covered entities must conduct necessary vetting in order to comply with the HIPAA Security Rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>106</SU>
                             
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access-right-health-apps-apis/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        For third-party applications chosen by individuals to facilitate their access to their EHI held by actors, there would not be a need for a BAA as discussed above. There would also generally not be a need for “vetting” on security grounds and such vetting actions otherwise would be an interference. Please see our discussion of “vetting” in the “
                        <E T="03">Interference Versus Education When an Individual Chooses Technology to Facilitate Access”</E>
                         discussion in the Information Blocking section of the preamble (Section VIII). We also refer readers to our discussion of “vetting” versus verifying an app developer's authenticity under the API Condition of Certification later in this section of the preamble.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarification about the types of business relationships permitted between API Technology Suppliers and API Users and requested examples of permitted activities and responsibilities under each role. These comments expressed concern about prohibiting API Technology Suppliers from being able to form direct relationships with API Users for the purpose of joint development and commercialization of their products. Other commenters requested clarifications about relationships that existed prior to the involvement of an API Data Provider.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. Based on the general support, we have finalized in § 170.404(a)(4)(i)(A) that a Certified API Developer must provide certified API technology to API Information Sources on terms that are no less favorable than it provides to itself and its own customers, suppliers, partners, and other persons with whom it has a business relationship. Additionally, we have finalized in § 170.404(a)(4)(i)(B) that the terms on which a Certified API Developer provides certified API technology must be based on objective and verifiable criteria that are uniformly applied to all substantially similar or similarly situated classes of persons and requests. Furthermore, we have finalized in § 170.404(a)(4)(i)(C) that a Certified API Developer must not offer different terms or services on the basis of: Competition or potential for competition and revenue or other value the other party receiving the services may receive from using the certified API technology. We note that we slightly modified the finalized requirements in § 170.404(a)(4)(i) based on the revised definitions finalized in § 170.404(c). We clarify that this rule does not prohibit Certified API Developers from forming business relationships with API Users. To the degree that a Certified API Developer seeks to charge an API User for particular services associated with its certified API technology, it would need to do so pursuant to the “value-added services” permitted fee.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested clarification about how “the sole authority and autonomy to unilaterally permit connections to their health IT through certified API technology” applies to application registration. Specifically, they asked whether API Users are required to register once with the API Technology Supplier, or several times with each instance of API technology deployed by API Data Providers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We refer commenters to § 170.315(g)(10)(iii) for the application registration requirements for Health IT Modules presented for certification. In general, we do not prescribe the registration paradigm that Certified API Developers create for themselves and their customers. Thus, in different scenarios, an API User may only be required to register once with an Certified API Developer, or several times with each instance of a § 170.315(g)(10)-certified Health IT Module deployed by an API Information Source. When it comes to apps that focus on the “launch-ehr” “SMART on FHIR Core Capability” from the 
                        <PRTPAGE P="25763"/>
                        implementation specification adopted in 170.215(a)(3), such an approach will be tightly integrated with the Health IT Modules deployed by API Information Sources. Because of the tight integration between API Information Sources and Health IT Modules, registration for these apps could more often fall to the API Information Source. When it comes to apps that enable patient access, registration could be handled centrally by Certified API Developers or in a distributed manner with each API Information Source, especially in cases where API Information Sources take full responsibility for administering their § 170.315(g)(10)-certified Health IT Modules.
                    </P>
                    <P>Regarding “the sole authority and autonomy to unilaterally permit connections to their health IT through certified API technology,” we have finalized in 170.404(a)(4)(ii)(A) that Certified API Developer must have and, upon request, must grant to API Information Sources and API Users all rights that may be reasonably necessary to (1) access and use certified API technology in a production environment; (2) develop products and services that are designed to interact with the Certified API Developer's API technology; and (3) market, offer, and distribute products and services associated with the Certified API Developer's certified API technology.</P>
                    <P>Additionally, we have finalized in § 170.404(a)(4)(ii)(B) that a Certified API Developer must not condition any of the rights described in § 170.404(a)(4)(ii)(A) on: (1) Receiving a fee, including but not limited to a license fee, royalty, or revenue-sharing arrangement; (2) agreeing to not compete; (3) agreeing to deal exclusively with the Certified API Developer; (4) Obtaining additional services that are not related to the certified API technology; (5) sharing intellectual property with the Certified API Developer; (6) meeting any Certified API Developer-specific testing or certification requirements; and (7) providing the Certified API Developer or technology with reciprocal access to application data. We slightly modified the conditions from the Proposed Rule for what we finalized in § 170.404(a)(4)(ii)(B) for clarity, and amended terms to the revised definitions finalized in § 170.404(c). Additionally, we clarify that while Certified API Developers are not permitted to condition the rights described in § 170.404(a)(4)(ii)(A) on receiving a fee, Certified API Developers are permitted to charge fees compliant with the permitted fees described in § 170.404(a)(3). We also clarify that “meeting any Certified API Developer-specific testing or certification requirements” would include preconditions like registering and testing in a testing environment prior to moving to production, and meeting Certified API Developer-created certification requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concern about software applications maintaining compatibility when upgrading API technology, and highlighted the importance of adopting backwards-compatible standards.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We share the concern expressed by commenters. We specifically consider features of standards like backwards compatibility when proposing and finalizing testing and certification requirements for the Program. As mentioned above, we have finalized the standard adopted in § 170.215(a)(1) as the base standard for the certification criterion adopted in § 170.315(g)(10) Standardized API for Patient and Population Services. We note that the standard adopted in § 170.215(a)(1) includes many FHIR resources that need to retain their compatibility over time, which will help as upgrades to newer standards occur. Additionally, we have finalized in § 170.404(a)(4)(iii) the service and support obligations required by a Certified API Developer, including the requirements that a Certified API Developer must provide all support and other services reasonably necessary to enable the effective development, deployment, and use of certified API technology by API Information Sources and API Users in production environments. These include requirements for changes and updates to API technology finalized in § 170.404(a)(4)(iii)(A), where Certified API Developers must make reasonable efforts to maintain the compatibility of its certified API technology and to otherwise avoid disrupting the use of certified API technology in production environments, and requirements for changes to terms and conditions finalized in § 170.404(a)(4)(iii)(B), where Certified API Developers must provide notice and reasonable opportunity for its API Information Source customers and registered API Users to update their applications to preserve compatibility with API technology and to comply with applicable terms and conditions.
                    </P>
                    <HD SOURCE="HD3">e. API Maintenance of Certification Requirements</HD>
                    <HD SOURCE="HD3">i. Authenticity Verification</HD>
                    <P>We proposed in 84 FR 7486 in § 170.404(a)(2)(ii)(C) to permit API Technology Suppliers to verify the authenticity of application developers, limited to a duration of no greater than five business days of receipt of a request to register an application developer's software with the API technology. We noted the authenticity verification process would need to be objective, apply to the application developer and not their software, and be the same for all application developers. We sought comment in 84 FR 7486 on factors that would enable registration with minimal barriers, including options and associated trade-offs. Additionally, we sought comment at 84 FR 7486 on other timing considerations for application developer authenticity verification.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters asked for a longer timeframe to complete the authenticity verification process of application developers. Some commenters asked to extend the authenticity verification timeframe to ten business days. Commenters suggested adding “and any receipt of any additional requested information needed in order to verify the developer's authenticity” to “within five business days of receipt of an application developer's request to register their software application with the API technology provider's authorization server.”
                    </P>
                    <P>Commenters suggested various methods for verifying the authenticity of application developers and applications, including by proposing required registration information, or required attestation to model privacy guidelines or industry best practices. Other commenters suggested various approaches for verifying application developers and applications, including by working with industry to establish a verification body, privacy and security trust or certification framework, and other more detailed recommendations. Several commenters suggested requiring application developers to attest to providing a model privacy notice to patients. Commenters suggested mandating terms and conditions and consent requirements as part of the registration process.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate feedback from commenters. To improve the organization of these Condition and Maintenance of Certification requirements, we moved the requirements proposed in § 170.404(a)(2)(ii)(C) to the finalized § 170.404(b)(1)(i) under the combined § 170.404(b)(1), “Authenticity verification and registration for production use.” We accept commenters' requests to establish a longer time period for this permitted, but not required, process to verify the authenticity of application developers 
                        <PRTPAGE P="25764"/>
                        who seek to register their software application for use with the Certified API Developer's certified API technology. We have adopted ten business days as the timeframe by which this process would need to be completed and as a result find it unnecessary to add the text contemplating a back and forth between the Certified API Developer and API User. We recommend that Certified API Developers who elect to institute a verification process implement a process that is as automated as possible to ensure they remain in compliance with our final policy. Given that we combined authenticity verification and registration for production use in one requirement finalized in § 170.404(b)(1), we reduced the scope of these requirements to Certified API Developers with a Health IT Module certified to the certification criterion adopted in § 170.315(g)(10) to remain consistent with the scope of applicability of registration for production use from the Proposed Rule.
                    </P>
                    <P>
                        We also note that authenticity verifications would likely occur more frequently for patient-facing applications that are not sponsored by API Information Sources. We anticipate that an API Information Source (
                        <E T="03">e.g.,</E>
                         a health care organization) that is a HIPAA covered entity would vet and enter into a HIPAA business associate agreement with a provider-facing application developer prior to using the application within their internal technical enterprise. In comparison, a patient-facing application is likely to connect to an API Information Source's resource server using a public service base URL of a § 170.315(g)(10)-certified Health IT Module in service to the patient's HIPAA Privacy Rule right of access (45 CFR 164.524) or based on a patient's HIPAA authorization (45 CFR 164.508) without first establishing a relationship with the API Information Source. For patient-facing applications, and to the comments suggesting we require various modes of attestation to privacy guidelines in such contexts, we refer commenters to the information blocking provisions in section VIII for a discussion of permitted behaviors regarding privacy attestations.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters suggested including a warning by the API Data Provider that the application developer selected by the patient or patient-designee is untrusted.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. An API Information Source would not be prohibited from showing a warning to patients as part of the patient authorization for an application to receive their EHI from an API Information Source. This could include a warning that an application attempting to access data on behalf of a patient is untrusted. We refer commenters to the information blocking provisions in section VIII for additional information about providing warnings to patients.
                    </P>
                    <HD SOURCE="HD3">ii. Registration for Production Use</HD>
                    <P>We proposed in 84 FR 7494 in § 170.404(b)(1) to require API Technology Suppliers to register and enable all applications for production use within one business day of completing its verification of an application developer's authenticity.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters generally supported the proposed registration requirements. Most commenters suggested extending the registration timeframe to five business days.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback from commenters. We have reorganized this section of the regulation text for readability by combining “Authenticity verification” with “Registration for production use” under the heading “Authenticity verification and registration for production use” in § 170.404(b)(1). We accepted the recommendation from commenters to extend the registration timeline and have finalized in § 170.404(b)(2)(ii) a requirement for Certified API Developers with Health IT Modules certified to the certification criterion finalized in § 170.315(g)(10) to register and enable all applications for production use within five business days of completing its verification of an application developer's authenticity pursuant to requirements finalized in § 170.404(b)(1)(i).
                    </P>
                    <HD SOURCE="HD3">iii. Service Base URL Publication</HD>
                    <P>We proposed in 84 FR 7595 in § 170.404(b)(2) to require an API Technology Supplier to support the publication of service base URLs for all of its customers, and make such information publicly available, in a computable format, at no charge.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A majority of commenters supported the proposal requiring API Technology Suppliers to publish service base URLs for all of its customers. Several commenters recommended the creation of a single, publicly available repository to maintain all client endpoints. Some stakeholders recommended ONC require additional facility information be published with the service base URL. Commenters who disagreed with this proposal stated that health IT developers cannot publish client information without their consent, and that API Data Providers should have the sole authority to publish their endpoints.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters on their feedback on our proposal requiring a Certified API Developer to publish service base URLs for all of its customers. The public availability and easy accessibility of this information is a central necessity to assuring the use of certified API technology without special effort, particularly for patient-facing applications. We agree with the points made by commenters on the need for a single or multiple publicly available repositories that maintain provider service base URLs. We encourage industry to coalesce around the development of a public resource from which all stakeholders could benefit. We believe this would help scale and enhance the ease with which service base URLs could be obtained and used. While we support the concept of repositories for service base URLs, we do not believe that creating a requirement under the Program is the appropriate mechanism to foster industry support around this concept at this time.
                    </P>
                    <P>
                        We acknowledge that stakeholders expressed concern about Certified API Developers publishing client service base URLs and revised our approach to focus on service base URLs necessary to support patient access. We anticipate that many services related to certified API technology will be developed and made available and do not believe it is appropriate to burden Certified API Developers with publishing all service base URLs for these services for all of their customers. We considered several options, including requiring Certified API Developers to publish service base URLs for only those API Information Source customers for whom they manage/host an authorization server centrally. However, we determined that alternative options would not meet our policy interests and would lead to unnecessarily complex and burdensome approaches and would not achieve the Cures Act's goals of enabling EHI to be accessed, exchanged, and used without special effort. Additionally, we considered requiring that all Certified API Developers with certified API technology, that is, health IT developers with a Health IT Module certified to § 170.315(g)(7) through (10), meet this requirement. However, we determined that it would be more beneficial to allow health IT developers to focus energy and resources on upgrading their technology to the certification criterion finalized in § 170.315(g)(10). Therefore, we have finalized in § 170.404(b)(2) that a Certified API Developer must publish service base URLs for all Health IT 
                        <PRTPAGE P="25765"/>
                        Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI. We further require that a Certified API Developer must publicly publish service base URLs for all customers in a machine-readable format at no charge regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source. We note our focus for this criterion on “service base URLs for Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their EHI.” We believe that Certified API Developers will have adequate relationships with API Information Sources in the process of providing Health IT Modules certified to § 170.315(g)(10) and will be able to collect and publish all service base URLs that support patient access on behalf of their customers. Furthermore, we note that API Information Sources would be obligated to share such service base URLs with Certified API Developers to avoid violating the Technical Interference Information Blocking provisions as discussed further in section VIII. Certified API Developers must make available appropriately scoped service base URLs that can be used by patients to access their EHI for Health IT Modules certified to § 170.315(g)(10).
                    </P>
                    <HD SOURCE="HD3">iv. Providing (g)(10)-Certified APIs to API Data Providers</HD>
                    <P>We proposed in 84 FR 7494 in § 170.404(b)(3) that an API Technology Supplier with Health IT Modules previously certified to § 170.315(g)(8) must provide all API Data Providers Health IT Modules certified to § 170.315(g)(10) within 24 months of this final rule's effective date.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of comments received urged ONC to extend the timeline beyond the 24 months proposed. Many commenters requested separate timelines for developers and providers. Several commenters recommended 36 months. Some commenters offered alternatives ideas for timelines, including a stepwise approach, or ONC only determining technical timelines, and allowing CMS to cover provider timelines. Only a few commenters encouraged faster adoption.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' feedback on our proposal. Given the reduced scope of the overall updates required by this final rule, our belief that the industry is well-prepared to meet this certification criterion's requirements once the final rule is published, and the Cure's Act expectation that secure, standards-based APIs would be made available in a timely manner, we have retained a 24 month compliance timeline, which will start from the publication date of the final rule. At that point, it will be approximately five years since the Cures Act's passage and we believe its implementation should not be delayed any further. We also remind stakeholders that this is within 24 months of this rule's publication compliance date for supplying all API Information Sources with Health IT Modules certified to § 170.315(g)(10) enables Certified API Developers (based on their client base and IT architecture) to determine the most appropriate timeline for development, testing, certification, and product release cycles. Thus, we have finalized in § 170.404(b)(3) that a Certified API Developer with certified API technology previously certified to the certification criterion at § 170.315(g)(8) must provide all API Information Sources with such certified API technology deployed with certified API technology certified to the certification criterion in § 170.315(g)(10) within 24 months of the publication date of the final rule.
                    </P>
                    <HD SOURCE="HD3">v. Compliance for Existing Certified API Technology</HD>
                    <P>We proposed in 84 FR 7486 that API Technology Suppliers with Health IT Modules certified to § 170.315(g)(7), (8), or (9) must revise their existing API documentation within six months from the final rule's effective date.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters supported the requirement to revise existing API documentation within six months of the final rule's effective date. Others requested more time to allow documentation and all other websites to come into alignment before enforcement of this Condition of Certification requirement. One commenter requested clarification on which documentation requires revision within the six-month timeframe.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In order to align the API Condition of Certification requirements policies, we have broadened the scope of the provision finalized in § 170.404(b)(4) to apply to all API Condition of Certification requirements finalized in § 170.404(a), including § 170.404(a)(1) through (4). Given the change of scope, we renamed this section to “Compliance for existing certified API technology.” We considered commenters' request for more time, but given the already delayed effective date of Part 170 we believed the proposed time of six months sufficient to enable Certified API Developers to become compliant with the Condition of Certification requirements finalized in § 170.404(a). This additional time provides Certified API Developers with Health IT Modules already certified to § 170.315(g)(7), (8), or (9) a total of eight months from the final rule's publication to update their policies and documentation to comply with the requirements finalized in § 170.404(a). We did not allow a longer time period than six months in § 170.404(b)(4) due to the fact that we have finalized our proposal in § 170.404(b)(3) to require Certified API Developers with Health IT Modules previously certified to the certification criterion in 170.315(g)(8) to provide § 170.315(g)(10)-certified APIs to API Information Sources within 24 months of final rule's publication date. These policies finalized in § 170.404(b)(4) provide API Information Sources with Health IT Modules certified to § 170.315(g)(8) with 18 months of updated documentation before the new requirements finalized in § 170.404(b)(3) become effective. Setting a more delayed compliance date than the one finalized in § 170.404(b)(4) would have unreasonably delayed and ultimately diminished the benefits of the Program requirements we have finalized in this rule. In summary, we finalized in § 170.404(b)(4) that Certified API Developers with Health IT Modules certified to § 170.315(g)(7), (8), or (9) must comply with § 170.404(a) no later than six months after this final rule is published in the 
                        <E T="04">Federal Register</E>
                        , including by revising their existing business and technical API documentation and making such documentation available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps.
                    </P>
                    <HD SOURCE="HD3">5. Real World Testing</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>107</SU>
                        <FTREF/>
                         in the type of setting in which such technology would be marketed. As discussed in the Proposed Rule (84 FR 7495), 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 
                        <PRTPAGE P="25766"/>
                        of a health IT's certification. Real world testing should assess that the certified health IT is meeting the intended use case(s) of the certification criteria to which it is certified within the workflows, system architectures, and type(s) of care setting(s) for which it is marketed (advertised, promoted, or sold).
                    </P>
                    <FTNT>
                        <P>
                            <SU>107</SU>
                             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 the purpose of this Condition of Certification requirement, in § 170.405(a), we proposed (84 FR 7495) that successful real world testing means:</P>
                    <P>• The certified health IT continues to be compliant to the full scope of the certification criteria to which it is certified, including the required technical standards and vocabulary codes sets;</P>
                    <P>• The certified health IT is exchanging electronic health information in the care and practice settings for which it is intended for use; and</P>
                    <P>• Electronic health information is received by and used in the certified health IT.</P>
                    <P>To fully implement the real world testing Condition of Certification requirement, we proposed Maintenance of Certification requirements that would require health IT developers to submit publicly available prospective annual real world testing plans and retrospective annual real world testing results for the certification criteria focused on interoperability to which each of its Health IT Modules is certified (84 FR 7496).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments on the whole support the establishment of a robust process of real world testing. Several commenters expressed concerns regarding the quality and usability of health IT. Specifically, commenters indicated that issues related to health IT usability may be contributing to clinician burn-out or impacting patient safety, noting that they therefore strongly support the inclusion of robust real world testing requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all comments, and have finalized real world testing Condition and Maintenance of Certification requirements in § 170.405(a) and (b) as proposed, with minor adjustments to due dates and clarifications of several points in response to specific comments as discussed below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters indicated that additional clarification of the real world testing requirements would make these Condition and Maintenance of Certification requirements less burdensome to implement. These commenters specifically sought additional guidance around the expectations for an appropriate testing plan and method of execution. One commenter recommended that ONC provide more guidance around what care settings must be covered by test plans, and establish a minimum number of settings and test sites that are applicable for certified Health IT Modules.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In response to comments requesting additional guidance around expectations and acceptable methods for real world testing, we provide below additional discussion, explanation, and illustrative examples. At this time, we have decided not to establish a minimum number of settings or minimum percentage or fraction of production instances of the developer's applicable certified Health IT Modules that must be included in the developer's annual real world testing activities. While health IT developers are not required to test their certified health IT in each and every setting in which it is intended for use, we would expect a developer's real world testing plan to address each type of clinical setting for which their health IT is marketed. Developers must address in their real world testing plans their choice of care and/or practice settings to test and provide a justification for their chosen approach. We also remind developers that although we are not requiring testing in every setting for which the certified health IT is marketed, we encourage real world testing in as many specific settings as feasible within each type of setting for which the certified health IT is marketed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed a view that there has been too much focus on the export capabilities of systems and not enough attention paid to providers being able to ingest data received in standardized formats—such as the Continuity of Care Document (CCD) standard—from other providers, including other providers who use the same developer's Health IT Modules certified to produce exports in conformance with the standards.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The interoperability focused criteria listed in § 170.405(a) include required capabilities for receiving and incorporating data in accordance with referenced standards and implementation specifications adopted by the Secretary in part 170 subpart B. We believe this appropriately aligns requirements for real world testing of Health IT Modules' ability to ingest data with the capabilities their certifications address.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter recommended that, for real world testing of Health IT Modules certified to the API criterion, the final rule require health IT developers to provide a testing environment (or “developer sandbox”) and require the use of a testing platform and test scripts that validate the ability of the API to meet the underlying requirements for the version of FHIR® to which Health IT Module(s) are certified, any applicable FHIR® profiles, and implementation guides.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed in the Proposed Rule (84 FR 7496), we believe health IT developers are in the best position to design and facilitate implementation of real world testing approaches that balance the burdens of this statutory requirement with its intended assurances that certified health IT as deployed in the types of clinical settings for which it is marketed (advertised, promoted, or sold) continues to meet the Program requirements, including but not limited to interoperability performance, applicable under the certification it holds. While we recognize that testing environments can be useful for a variety of purposes, and would not generally discourage developers from offering test platforms specific to their products or participating in the development and use of open-source testing platforms, the purpose of real world testing is to demonstrate that Health IT Modules continue to perform in conformance to their certification when and as they are deployed in production environments supporting the types of clinical settings for which the Health IT Modules are marketed. Thus, real patient data and real production environments will in most cases best meet that need and should be first considered when developing real world testing plans. Mandating creation or use of testing environments for real world testing would compete for developers' time and effort with the focus on innovative ways to best serve the purpose of the real world testing Conditions and Maintenance of Certification requirements at the least burden on their customers and end users. We have therefore not required health IT developers to provide a testing environment (or “developer sandbox”) nor have we required the use of a testing platform or test scripts in order to satisfy real world testing Condition and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that ONC be mindful of the burdens this testing could place on health care providers in terms of time and cost and take all necessary steps to minimize such burdens. Commenters specifically stated real world testing would require significant work by providers for whom, in the commenters' stated view, there is no incentive to 
                        <PRTPAGE P="25767"/>
                        participate in real world testing. Some commenters specifically recommended that HHS incentivize providers to participate, stating that without providers' participation, this proposal would become an untenable requirement. One commenter requested HHS clarify whether a developer would be permitted to compensate its customers for the time the customer spends supporting the developer's real world testing activities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback noting the potential for health IT developers' real world testing activities to impose burden on providers. We do appreciate the importance of recognizing that providers engage directly and actively in various types of activities supporting advancement of health IT. The fact that many of these activities could be included in robust real world testing regimes suggests that we should provide developers with extensive flexibility to develop innovative real world testing plans. We have therefore built into our real world testing policy flexibility that offers the developer a substantial opportunity to design real world testing approaches that minimize burden and fully optimize value of the real world testing activities and results to current and prospective customers. We do not believe that HHS incentives to providers participating in real world testing would be the most effective means of alleviating burdens on health care providers specifically attributable to developers' real world testing activities. Rather, the flexibility of our policy allows for, and encourages, developers to approach real world testing in an innovative mode so that they can maximize efficiency and minimize burden of real world testing for both the developer and its customers. A wide range of practical strategies are available for developers to potentially consider in creating such optimized solutions for real world testing of their specific health IT with their particular customer base. Examples of this range of practical strategies include, but are not necessarily limited to: Avoiding some activities that satisfy only the real world testing Maintenance of Certification requirements by including in its overall real world testing plans the testing typically associated with confirming functionality of new installations and upgrades of their software; and innovating methods of measuring products' performance in real time use through system metadata and/or feedback from health information networks and other exchange partners of their customers.
                    </P>
                    <P>
                        In response to the recommendation that developers be allowed to compensate their customers for participating in the developer's real world testing activities, we note that nothing in our proposed or finalized policy under part 170 would prohibit that. In the event a developer concludes that its real world testing approach imposes on its customers directly participating in real world testing activities a burden that the developer would like to offset for those customers, we would not discourage the developer from considering whether there may be opportunities within the bounds of other applicable laws or regulations for developers of certified health IT to offer customers some types of burden-offsetting compensation or other incentive for real world testing participation. Analysis, interpretation, or changes to such other law or regulation is outside the scope of this particular rulemaking action. Moreover, outside the rulemaking process, developers should be aware that ONC is not in a position to provide general guidance on Federal laws specific to compensation arrangements or advice specific to any particular circumstances or contemplated conduct related to developers compensating providers for participating in developers' real world testing activities. However, if developers or providers may be contemplating a potential compensation arrangement related to offsetting providers' cost or burden of engagement in developers' real world testing, we offer as a point of information that one publicly stated purpose of the HHS Office of the Inspector General advisory opinion process is to provide meaningful advice about of the applicability of the anti-kickback statute or other OIG sanction statutes in specific factual situations.
                        <SU>108</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>108</SU>
                             For more information about HHS Office of the Inspector General advisory opinions and advisory opinion process, please visit: 
                            <E T="03">https://oig.hhs.gov/compliance/advisory-opinions/index.asp</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that developers with small customer bases will have smaller pools of participants willing to undergo a lengthy process which will require significant resources and suggested developers submit results from a more limited scope of testing only every three years.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We reiterate that the policy we have finalized includes substantial flexibility for developers to assess how to meet the real world testing Condition and Maintenance of Certification requirements in a way that appropriately minimizes burden on the current users of their certified health IT.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter expressed concern that health care providers might be unwilling to use health IT that had not yet been certified, and that this could make real world testing of Health IT Modules prior to certification impractical.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In our Proposed Rule (84 FR 7429), we proposed in § 170.405(a) to limit the applicability of this Condition of Certification to health IT developers with Health IT Modules that are certified to one or more 2015 Edition certification criteria focused on interoperability and data exchange. We also proposed that the real world testing Condition of Certification would be met through meeting the real world testing Maintenance of Certification requirements in § 170.405(b). We have finalized this proposal as proposed. Thus, the real world testing Condition and Maintenance of Certification requirements do not mandate testing real world use of a Health IT Module in actual production environments before it is certified.
                    </P>
                    <HD SOURCE="HD3">a. Unit of Analysis at Which Testing Requirements Apply</HD>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested confirmation if real world testing is required per CHPL listing, per product, or per company.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The real world testing Condition and Maintenance of Certification requirements apply to each developer that has at least one Health IT Module certified to at least one of the interoperability and exchange focused criteria listed in § 170.405(a), because Condition and Maintenance of Certification requirements apply to the developer of certified health IT. However, each developer of certified health IT to which the real world testing Condition and Maintenance of Certification requirements apply must conduct real world testing for each criterion within the scope of real world testing (§ 170.405(a)) to which each developer presents for certification a Health IT Module that is part of a health IT product to be listed on the CHPL are certified. A health IT developer with multiple products that are listed on the CHPL and that include one or more Health IT Module(s) certified to one or more of the criteria listed in § 170.405(a) need only submit one real world testing plan, and one real world testing results report, for any given annual cycle of real world testing, but the real world testing plan and results report must address each of the developer's products that is listed on the CHPL. Health IT developers with multiple health IT products that may include the same Health IT Module(s) certified to one or 
                        <PRTPAGE P="25768"/>
                        more of the criteria listed in 170.405(a) have discretion to design their real world testing plans in a way that efficiently tests a combination of products that include Health IT Modules certified criteria listed in § 170.405(a) so long as testing plans and results are traceable to specific certified Health IT Modules and each criterion to which the Health IT Module(s) are certified, and address the types of settings for which the products are marketed. Because the purpose of real world testing is to test health IT products as they are deployed in production, developers of health IT products deployed through the cloud who offer their products for multiple types of clinical settings will be required to test the same capability for those different types of settings even if it uses a single instance of the deployed capability to serve all of those types of settings.
                    </P>
                    <HD SOURCE="HD3">b. Applicability of Real World Testing Condition and Maintenance of Certification Requirements</HD>
                    <P>We proposed (84 FR 7495) to limit the applicability of the real world testing Condition of Certification requirement to health IT developers with Health IT Modules certified to one or more of the certification criteria focused on interoperability and data exchange or availability listed in (then-proposed) § 170.405(a):</P>
                    <P>• The care coordination criteria in § 170.315(b);</P>
                    <P>• The clinical quality measures (CQMs) criteria in § 170.315(c)(1) through (c)(3);</P>
                    <P>• The “view, download, and transmit to 3rd party” criterion in § 170.315(e)(1);</P>
                    <P>• The public health criteria in § 170.315(f);</P>
                    <P>• The application programming interface criteria in § 170.315(g)(7) through (g)(10); and</P>
                    <P>• The transport methods and other protocols criteria in § 170.315(h).</P>
                    <P>We solicited comment on whether to also include the “patient health information capture” certification criteria in § 170.315(e)(3), including the value of real world testing these functionalities compared to the benefit for interoperability and exchange (84 FR 7496). We also solicited comment on whether any other 2015 Edition certification criteria should be included or removed from the applicability list (to be codified at 170.405(a)) for this Condition of Certification requirement.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The vast majority of commenters addressing this proposal were in support of the specific criteria proposed to be within the scope of real world testing and expressed agreement that required testing should be limited to Health IT Modules certified to one or more of the certification criteria listed in § 170.405(a) as proposed.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all feedback received. The list of criteria to which real world testing Condition and Maintenance of Certification requirements apply is finalized in § 170.405(a) as proposed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment supporting and two comments opposing the addition of patient health information capture criterion in § 170.315(e)(3) to the scope of real world testing. One commenter specifically recommended against including the patient health information capture criterion in § 170.315(e)(3) in real world testing because of the significant variability in how health IT certified to this criterion is implemented. They stated that this variability in the real world could make cross-implementation comparisons difficult, and stated that testing for this criterion could present a particular challenge based on difficulty they anticipated would be encountered in securing needed engagement from patients as well as the exchange partners who would presumably receive the data as a result of the patient using the “transmit” functionality. Commenters opposed to addition of this criterion to the real world testing Condition and Maintenance of Certification requirements also stated this addition would add cost to the developer which would then flow down to end users and be burdensome to clinician practices.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         On balance, the comments received do not support expansion of the scope of real world testing requirements to include the patient health information capture criterion in § 170.315(e)(3) at this time. In developing the proposed list of criteria to which real world testing Condition and Maintenance of Certification requirements would apply, we concluded an initial focus on those particular criteria would strike an appropriate balance between the magnitude of the challenge represented by the new real world testing requirements and the potential benefits of their broader application. The concerns raised by the commenters recommending against adding the patient health information capture criterion in § 170.315(e)(3) to the scope of real world testing requirements at this time, combined with other comments more generally recommending against a broader scope at this time, tend to support the conclusion that the scope we proposed strikes an appropriately practical balance until we and the industry have benefit of experience and innovation in real world testing. Thus, the finalized list of criteria to which real world testing requirements apply (§ 170.405(a)) does not include the patient health information capture criterion in § 170.315(e)(3).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters suggested expanding the scope of real world testing requirements to include the proposed “EHI export” criterion in § 170.315(b)(10).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the confirmation that commenters supported inclusion of the “EHI export” criterion in § 170.315(b)(10) alongside the rest of the care coordination criteria in § 170.315(b). We have finalized the criteria listed in § 170.405(a) including, as proposed, all criteria within § 170.315(b).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed an opinion that the initial scope of criteria is more expansive than the commenter would suggest for an introductory set, and asked that fewer criteria be required for the initial rollout of real world testing, delaying application of the requirement to more interoperability focused criteria until experience has been amassed with real world testing for a narrower selection of criteria than we had proposed.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Noting that the majority of comments received were supportive of the scope as proposed, we also balance suggestions such as that offered by this commenter against the Program's needs and the purpose of the real world testing Condition and Maintenance of Certification requirements. We do not believe it would be in the best interest of the Program or the health care providers and patients who rely on certified health IT to meet their needs for interoperable health IT to narrow the applicability of the real world testing Condition and Maintenance of Certification requirements further than we proposed. We have, therefore, finalized the criteria listed in § 170.405(a) as proposed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters advocated expanding the scope of the real world testing requirement to include select functionally-based “clinical” criteria within § 170.315(a) that are included in the base EHR definition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As explained in the Proposed Rule (84 FR 7495), we did not propose to include in the scope of real world testing functionally-based criteria, administrative criteria, or other criteria that do not focus on interoperability and exchange or availability of data. The “clinical” certification criteria in § 170.315(a) were noted in the Proposed Rule as an 
                        <PRTPAGE P="25769"/>
                        example of criteria not proposed because they require only that the health IT enable the provider to record, change, and access specific types of data within the Health IT Module being certified (or within a product that includes the Health IT Module being certified to the particular criteria). However, real world testing of health IT's ability to exchange the types of data these clinical criteria reference is addressed through the inclusion of the USCDI in the interoperability-focused criteria listed in § 170.405(a) as proposed, which is finalized as proposed. In order to successfully exchange interoperable EHI, the health IT must be able to access it, and in order to incorporate a type of data, the health IT must be able to record it.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of comments received specifically referencing the proposed inclusion of public health criteria in the real world testing requirement in § 170.405(a) support the importance and inclusion of the public health criteria in the scope of real world testing requirements. One commenter questioned the inclusion of the public health criteria in § 170.315(f), stating the commenter's perception that extensive variation between registries would make this a challenging functionality to demonstrate.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Variations in system configurations across different public health agencies' infrastructures may suggest different real world testing strategies may be most appropriate, or most relevant to customers, compared to what might be the case for some other criteria within the scope of real world testing. However, as noted below about testing tools, we are aware of a wide variety of resources and opportunities to test real world interoperability performance of Health IT Modules certified to the public health criteria in § 170.315(f). Because interoperability performance in actual production environments is an important feature of health IT certified to the public health criteria in § 170.315(f), and noting the support for its inclusion expressed by most commenters, and we have determined that the most appropriate course is to finalize the inclusion of the public health criteria in§ 170.315(f) in the scope of real world testing in § 170.405(a).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that some of the criteria proposed for inclusion in § 170.405(a) be re-examined because they do not include all three of the characteristics our Proposed Rule described as being demonstrated through real world testing. Examples offered included that some criteria proposed for inclusion in § 170.405(a) require exporting but do not require receipt and use of electronic health information by the certified health IT.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' bringing to our attention that additional discussion about the requirements would be helpful to the community. For the criteria proposed and finalized in the real world testing scope in § 170.405(a), such real world testing needs to address the interoperability characteristics and all other functionalities and capabilities applicable based on the specific criteria to which the Health IT Module is certified. For example, even if a Health IT Module is not certified to any criterion that specifically requires it to demonstrate, in order to be certified, that the Health IT Module has the capability to incorporate and use data received directly from sources outside the production environment in which it is deployed, that Health IT Module will still need to demonstrate conformance to the full scope of each criterion to which it is certified. This includes, though it is not limited to, the technical standards and vocabulary codes sets included in each criterion to which it certified.
                    </P>
                    <HD SOURCE="HD3">c. Testing Plans, Methods, and Results Reporting</HD>
                    <P>We proposed (84 FR 7496) that a health IT developers must submit an annual real world testing plan to its ONC-ACB via a publicly accessible hyperlink no later than December 15, of each calendar year for each of its certified Health IT Modules that include certification criteria specified for this Condition of Certification. We proposed (84 FR 7497) that a health IT developer must submit an annual real world testing plan to its ONC-ACB via a publicly accessible hyperlink no later than January 31, of each calendar year for the preceding calendar year's real world testing.</P>
                    <P>We proposed that the real world testing plan, which will be required to be available to ONC and the public via the CHPL no later than December 15 of each year once this final rule is effective, will need to address the health IT developer's real world testing that will be conducted the upcoming calendar year and must include, for each of the certification criteria in scope for real world testing in § 170.405(a) and each Health IT Module certified to one or more of these criteria (84 FR 7496):</P>
                    <P>• The testing method(s)/methodology(ies) that will be used to demonstrate real world interoperability, including a mandatory focus on scenario- and use case-focused testing;</P>
                    <P>
                        • The care and practice setting(s) that will be tested for real world interoperability, including conformance to the full scope of the certification criteria requirements, and an explanation for the health IT developer's choice of care setting(s) to test; 
                        <SU>109</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>109</SU>
                             We do not specifically define or limit the care settings and leave it to the health IT developer to determine. As an example, health IT developers can consider categories, including but not limited to, those used in the EHR Incentive Programs (
                            <E T="03">https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/UserGuide_QNetHospitalObjectivesCQMs.pdf</E>
                            ); long-term and post-acute care; pediatrics; behavioral health; and small, rural, and underserved settings.
                        </P>
                    </FTNT>
                    <P>• The timeline and plans for voluntary updates to standards and implementation specifications that ONC has approved (further discussed below);</P>
                    <P>• A schedule of key real world testing milestones;</P>
                    <P>• A description of the expected outcomes of real world testing;</P>
                    <P>• At least one measurement/metric associated with the real world testing for each certification in scope; and</P>
                    <P>• A justification for the health IT developer's real world testing approach.</P>
                    <P>We sought comment (84 FR 7497) on whether we should specify a minimum “core” set of metrics/measurements and examples of suggested metrics/measurements as well as on the timing of required real world testing results reporting. We also invited comment on the annual frequency and timing of required real world testing results reporting.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Most comments received supported the proposed requirement for Health IT Modules to undergo real world testing. In addition, commenters indicated that real world testing should occur on a regular basis to ensure various types of changes in the Health IT Modules or production environments have not affected functionality required by the certification. Several commenters recommended development of more specific minimum requirements for test plans and measurement of results. They further recommended that ONC provide additional guidance about what will constitute a minimally acceptable testing plan with explicit content depicting the minimum requirements for each component of the testing plan.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. As discussed in the Proposed Rule and above, we believe health IT developers are in the best position to design and facilitate implementation of real world testing approaches that balance the burdens of this statutory requirement with its intended assurances that certified health 
                        <PRTPAGE P="25770"/>
                        IT meets Program requirements, including interoperability performance, applicable under the certification it holds. We have therefore finalized requirements in § 170.405(b)(1) designed to avoid the risk of a “one size fits all” set of testing tools (discussed at 84 FR 7496) that might not fully address the concerns raised or provide the assurances of interoperability performance sought across the various types of care settings. By establishing in § 170.405(b)(1)(iii) the topics and considerations every developer must address in its required real world testing plan but not specifying how they must address these required aspects we have provided health IT developers with a requirement that at the same time provides them with the flexibility to develop and implement successful real world testing plans that will best balance burden and value for the customers of each of their products. The ONC-ACBs will be responsible for assessing real world testing plans and results reports for completeness in comparison to what § 171.405(b)(1) requires the plan and results reports to include or address, but will otherwise not be formally evaluating the testing approach for quality as a testing approach. We note for clarity that while ONC-ACB's will not be judging a developer's real world testing approaches as planned or as executed, the contents of a developer's publicly available real world testing results could be used by an ONC-ACB as part of its ongoing surveillance of certified health IT. Additionally, we have finalized our proposed requirement in § 170.405(a) and (b) that requires developers subject to the real world testing Condition and Maintenance of Certification requirements (see § 170.405(b)(2)(i)) who discover in the course of their real world testing any non-conformities with the standards, functionalities, or other requirements of any certification criterion under the Program, to address these non-conformities in order for their Health IT Modules to remain certified. This requirement will apply in the same manner to Health IT Modules certified under the SVAP flexibility in § 170.405(b)(8) or (9) as to Health IT Modules not certified under the SVAP flexibility. Thus, developers who discover non-conformity to any Program requirement(s) will be required to report those non-conformities to their ONC-ACB(s). In order to provide a clear threshold for determining whether a developer has acted on this requirement in a timely manner, we have finalized the requirement to report non-conformities within 30 days of discovering them (see § 170.405(b)(2)(i)). We believe 30 days is an appropriate timeframe to allow developers the opportunity to gather all facts and report to their ONC-ACBs the details and nature of the non-conformity. Furthermore, we believe more than the 30 days would extend beyond the timeframe by which a non-conformity should be investigated by an ONC-ACB and corrective action implemented, if necessary.
                    </P>
                    <P>
                        We are aware that by choosing not to specify particular methods, tools, or checklists of activities that must be included in real world testing, and providing instead extensive flexibility for developers to select tools and design overall methodologies based on their knowledge of their products and customers, we are asking developers to apply innovation and problem solving skills to their real world testing. We believe that the alternative of developing a catalog of detailed specifications and checklists, as some commenters suggested, would be undesirably complex, less supportive of ongoing innovation in the market, and not ultimately less burdensome for developers or their customers. As we have noted in the context of prior Program rulemaking actions, we often make additional information resources and non-binding guidance regarding real world testing available through familiar communications channels, such as the 
                        <E T="03">HealthIT.gov</E>
                         website.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns about the burden of real world testing in specific reference to ONC-ACB processes for in-the-field surveillance of certified products' continued conformance to applicable certification criteria. Some comments raised concerns about the burden that could be placed on developers' customers should developers choose to rely heavily on the procedures used by ONC-ACBs for randomized or reactive in-the-field surveillance. Some comments indicated concern that ONC would expect, encourage, or view more favorably real world testing approaches that rely heavily or exclusively on use of ONC-ACB in-the-field surveillance protocols.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the Proposed Rule, we stated that “developers may consider working with an ONC-ACB and have the ONC-ACB oversee the execution of the health IT developer's real world testing plans, which could include in-the-field surveillance per § 170.556, as an acceptable approach to meet the requirements of the real world testing Condition of Certification” requirement (84 FR 7497). Having considered all comments received, we have decided not to finalize the flexibility for developers to use ONC-ACBs' in-the-field surveillance as part of the developer's real world testing plan. We do not believe that use or replication of methods or protocols used by ONC-ACBs for in-the-field surveillance of certified Health IT Modules would be the most effective or the least burdensome approach available to health IT developers and are concerned accepting real world testing approaches that rely on ONC-ACB in-the-field surveillance could slow rather than accelerate development of more innovative approaches to real world testing. We are also concerned that inclusion of ONC-ACB execution of in-the-field surveillance within a developer's real world testing approach could lead to confusion as to whether the organization that is an ONC-ACB was applying in-the-field surveillance protocols in its capacity as an ONC-ACB as part of its oversight responsibilities on behalf of ONC or in its private capacity on behalf of the health IT developer. We believe it is important, to protect HIPAA covered health care providers and other HIPAA covered entities and their business associates from inadvertently violating requirements related to disclosure of health information, to maintain a clear distinction of when an organization that is an ONC-ACB is acting in the ONC-ACB capacity and when it is acting in its private capacity. We note and emphasize this because, in the event a developer may choose to engage services in support of developing or implementing the developer's real world testing plans from an organization or entity that also happens to be an ONC-ACB, all activities undertaken by the organization or entity to develop, execute, or support the development or execution of the developer's real world testing plan would be activities outside the ONC-ACB role. In such circumstances, the organization that is an ONC-ACB would be acting in a separate, private capacity. Note that an organization providing such private services that involve ePHI would likely be characterized under the HIPAA Rules as a business associate to the health care provider and subject to the HIPAA Rules. The oversight authorities attached to its ONC-ACB role would not apply to the organization's requests to gain access to health care provider facilities or to EHI for purposes of providing these separate support services to health IT developers for conduct of the developers' real world testing.
                        <PRTPAGE P="25771"/>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters sought confirmation that a test server could be used for real world testing instead of a production environment, given the permissible use of synthetic data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         After considering the totality of comments received, we have decided to finalize that a test server could be used for real world testing and provide the flexibility included in the Proposed Rule that allows for real world testing to occur in a production setting using real patient data in accordance with applicable laws as well as in an environment that mirrors a specific production environment used in a type of clinical setting for which the health IT is marketed. We have also decided to finalize the flexibility for the developer to use synthetic patient data in lieu of or in addition to real patient data in real or simulated/test scenarios executed in environments that mirror production environments where the health IT is deployed. However, we emphasize that the purpose of real world testing is to demonstrate that the Health IT Module(s) work as expected in real-life clinical settings. We note, as a point of potential interest for such consideration, that real world testing plans that meet the Program requirement might include observation or measurement of the health IT's interoperability performance while actual scenarios and use cases are executed by end users on real patient data in actual operational contexts. If a developer chooses to use synthetic data, non-production (mirrored) environments, or a combination of real and synthetic data or production and mirrored environments, to complete any portion of their annual real world testing requirements, the developer must include in their real world testing plan and results submissions a specific explanation justifying how the synthetic data, mirrored environment, or both are appropriate and adequate to meet the real world testing requirement(s) for which they will be or were used.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters sought confirmation that a product serving multiple care settings could complete a single test relevant to all settings and ask ONC to provide a list of eligible care settings for reference.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The finalized real world testing Condition and Maintenance of Certification requirements include testing each criterion listed in § 170.405(a) to which any Health IT Module(s) within the product are certified, and testing in each type of setting to which it is marketed. To satisfy these Condition and Maintenance of Certification requirements as finalized, a single testing plan, protocol, or approach must address all the types of settings to which the product, with all its included Health IT Module(s), is marketed and do so with traceability to each Health IT Module of its real world performance in each type of setting for which it is marketed. We believe it is possible to construct a real world use scenario or use case that tests more than one type of setting applicable to the Health IT Module, and confirm that a developer is not required to develop unnecessarily or artificially separate scenarios or use cases across multiple types of settings to which a given developer markets its applicable Health IT Module(s). With respect to the types of settings required to be addressed by a given developer's plan, we do not believe that additional specification is necessary because we believe each developer is well situated to know for what types of settings the developer (or its authorized resellers) has marketed, is marketing, or intends to market its Health IT Modules. For purposes of this Condition and Maintenance of Certification requirement as finalized, there is no exclusion for settings or health care provider types based on their inclusion or lack of inclusion in, or eligibility or ineligibility for, and particular Federal health care program or initiative. Therefore, the types of settings eligible to be addressed in a developer's real world testing plan for a given year include all those to which product(s) including one or more Health IT Modules certified to one or more of the criteria listed at § 170.405(a) as of August 31 of the year in which that specific annual real world testing plan is due have been or are marketed when the real world testing plan is submitted, and/or the types of settings for which the developer anticipates marketing such product(s) in time to include them in a specific year's real world testing activities.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested ONC ensure that real world testing requirements do not create infrastructure for testing of public health transactions without public health involvement. Several commenters noted that public health organizations and many public health agencies already offer resources and processes used in onboarding processes for public health reporting connections and suggested these resources and processes could be used more broadly to test health IT's real world performance on public health interoperability criteria rather than requiring creation of new or different tools.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We would tend to agree that relying for specific use cases on testing infrastructures developed without appropriate involvement of key participants in the use case would not be an optimal approach. Also, we reiterate that we encourage developers to consider a variety of options and approaches before finalizing their annual real world testing plans. We would encourage developers to consider the real world testing potential of resources, tooling, and infrastructure already offered by public health organizations and agencies before embarking on efforts to develop additional tooling. We also note that, for the interoperability-focused public health criteria, alternatives that would avoid both overuse of simulation environments and asking public health agencies to engage in work unique to developers' real world testing plans might include structured observation and measurement of interoperability performance in actual public health data reporting/exchange as well as the testing ordinarily conducted for onboarding/confirming connectivity of newly deployed/upgraded implementations to public health data exchange infrastructures.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed support of requiring the use of metrics/measurements for real world testing. One commenter stated that ONC should not allow just one measurement to suffice for real world testing of interoperability of a Health IT Module. Several commenters recommended ONC include a description of “measurement,” provide clarity on the role of measurement, and provide a “sample” or suggested set of metrics/measurements to help foster alignment of reporting around meaningful common metrics/measurements across developers. Some commenters recommended ONC identify a core set of metrics/measures that developers would be required to include, or from which developers would be required to select specific metrics/measures to include, in their real world testing plans. Other commenters advocated against developers being required to submit testing results for a minimum “core” set of general metrics, providing the rationale that not all metrics will be available to all systems uniformly and suggesting that many metrics are retained in the provider's locally integrated production systems and unavailable to the developer of any given Module(s) without considerable effort to retrieve the data. One commenter recommended requiring that each developer's real world test plan include measures addressing all of the domains of the NQF report: 
                        <PRTPAGE P="25772"/>
                        <E T="03">Measurement Framework to Assess Nationwide Progress Related to Interoperable Health Information Exchange to Support the National Quality Strategy.</E>
                        <SU>110</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>110</SU>
                             
                            <E T="03">https://www.qualityforum.org/Projects/i-m/Interoperability_2016-2017/Key_Informant_Summary_Report.aspx</E>
                             (last accessed 12/17/2019).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         The comments on real world testing did not show clear, widespread support for any specific subset of available metrics as a “core” set or catalog that a significant portion of the affected communities (health IT developers, health care providers, and public health agencies) would generally agree should be consistently used across all developers' real world testing plans. Thus, we have finalized the real world testing plan requirements (see § 170.405(b)(1)(iii) and real world testing results reporting requirements (see § 170.405(b)(2)(ii)) without identifying a minimum set of measures that must be used or a catalog of suggested measures from which a developer would be expected to choose in constructing its real world testing plans. We reiterate that each developer must choose a measurement approach, including at least one measurement/metric per applicable criterion, for use in each year's real world testing and explain the selection and relevance of its selected measures/metrics within its justification for its real world testing approach in that year's plan and results report.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments were received on the frequency and timing of real world testing. One commenter stated the policy should not require annual testing if the capability certified for a given criterion remains unchanged year to year, offering the example that if a Health IT Module is certified for both § 170.315(b)(1) and (b)(2) and the developer is planning to release material updates to the capabilities specific to § 170.315(b)(1), but not make any material changes specific to the Module's certification to § 170.315(b)(2), this commenter would prefer that the Health IT Module would need to submit a testing plan and subsequent results addressing only the § 170.315(b)(1) criterion for the year the change is made. Another commenter expressed skepticism regarding the value of annual real world testing requirements, expressing a preference for an approach that developers would, after an initial cycle of post-certification real world testing of a Health IT Module, be required to re-test only when updating to National Coordinator-approved newer versions of adopted standards included in applicable criteria or when making major functional updates to the certified Health IT Module. One commenter who was overall not supportive of the real world testing requirement stated that developers would need a two-year cycle instead of a one-year cycle in order to adequately demonstrate compliance with full functionality testing. One commenter specifically expressed support for the annual frequency and timing of required real world testing results reporting.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenters for their feedback regarding the frequency and timing of real world testing. We have finalized the requirement for annual testing in § 170.405(b)(1). Ongoing annual testing is needed to ensure that Health IT Module(s) continue to perform as intended in the types of settings where patients and health care providers continue to rely on it to meet their interoperability needs.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed support of the proposed real world testing plan requirements and requested we strengthen this provision to require that developers test their products within each clinical specialty to which the technology would be marketed. One commenter requested that we define with more particularity what is expected of developers during the testing to account for the differing conditions under which Health IT Modules are deployed, and how for example, the system works particular conditions like server degradation. Several other commenters suggested we provide a standardized template for use in developing test plans. Commenters described a template would include all required testing elements and promote greater consistency in the way the test plans are written by the various developers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         For reasons stated in the Proposed Rule (84 FR 7496) and above, we do not believe a centrally developed or standardized approach for real world testing plans is the most appropriate solution at this time. By centrally mandating or endorsing a single template in the interest of consistently formatted documentation, we are concerned that we might inadvertently discourage innovation in both testing approaches and their communication to the customer community. What the plan must include or address for each applicable criterion to which the developer's Health IT Module(s) are certified is outlined in § 170.405(b)(1)(iii), as finalized by this rule. We believe the plan requirements finalized in the plan requirements in § 170.405(b) are specific enough to ensure the plans can be completed by developers and effectively reviewed for completeness by ONC-ACBs, and that both the substance and clarity or efficacy of presentation can both be examined and considered by any interested parties—from health care providers to informatics and interoperability researchers. Because individual circumstances and needs may vary even within the same type of setting or clinician specialty, it would be not be possible at this time to define a real world testing regime that eliminated all of the variability developers may have in implementing their real world testing plans.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter sought clarification on the total minimum number of metrics required for a developer's real world testing plan to be considered complete and in compliance with the requirement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         A developer's real world testing plan must include at least one metric for each applicable certification criteria. To ensure that we are providing clear guidance, we offer the following illustrative example: A developer with one Health IT Module that is certified to five criteria would need to include in its real world testing plan at least one specific measurement/metric associated with the real world testing for each of those five criteria. Depending on the specific criteria and the developer's real world testing approach, this could call for up to five different measurements/metrics, or could be addressed with fewer different measurements/metrics but a specific measurement/metric would need to be identified/attributed within the plan to each of the applicable certification criteria.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters stated concerns regarding our mandatory focus on scenario- and use case-focused testing. One commenter expressed a view that this would be expensive and time consuming, stating that this expense limits scenario- and use case-focused testing in the number of settings that can realistically be tested in any given year. One commenter noted that as more settings are tested, fewer scenarios can be run per setting. Two commenters sought more information on the mandatory scenario- and use case-focused testing that will be required, recommending that Health Information Service Providers (HISPs) be able to attest to the relevant use cases and provide the proper evidence of testing associated to those scenarios.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In light of comments received, we can see how our use of terms that are also used in the context of ONC-ATL laboratory or ONC-ACB surveillance testing, and our reference in one instance to in-the-field 
                        <PRTPAGE P="25773"/>
                        surveillance, could have led to an inference that our use of these terms implied we would expect to see the same or similar testing protocols used in real world testing. However, we did not propose that real world testing would require developers to set up and execute artificial scenarios or activities solely for purposes of testing. In fact, we do 
                        <E T="03">not</E>
                         encourage use of the laboratory testing or ONC-ACB in-the-field surveillance protocols to conduct real world testing, as those particular test methods, tools, and surveillance protocols were not designed and should not be relied upon for real world testing. The testing methods/methodologies need to address realistic scenarios, use cases, and workflows associated with interoperability, and we do expect developers to consider such factors as the size of the organization that production systems support, the type of organization and setting, the number of patient records and users, system components and integrations, and the volume and types of data exchange in planning for real world testing.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed agreement that the developer is best situated to determine the most effective real world testing plan for their products. One commenter requested developers be allowed to work together with their customers to define what real world tests are.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The requirements we proposed and finalized provide developers the opportunity to identify, potentially in partnership with their customers, the real-life scenarios, use cases, and work flows applicable to the customer's day-to-day use of the Health IT Module(s) to meet their interoperability needs in their production environments.
                    </P>
                    <HD SOURCE="HD3">d. Submission Dates</HD>
                    <P>We proposed that a health IT developer must submit an annual real world testing plan to its ONC-ACB via a publicly accessible hyperlink for availability to ONC and the public no later than December 15, of each calendar year, and that the plan must address all of its Health IT Modules certified to the 2015 Edition certification criteria listed in proposed in § 170.405(a) and (84 FR 7496). We proposed requiring that prior to submission to the ONC-ACB, the plan will need to be approved by a health IT developer authorized representative capable of binding the health IT developer for execution of the plan and include the representative's contact information. We proposed that the plan due in any given year will need to include all health IT certified to the 2015 Edition through August 31 of that year (in other words, the August 31 that immediately preceded the December 15 due date).</P>
                    <P>We further proposed that a health IT developer would submit annual real world testing results to their ONC-ACBs via a publicly accessible hyperlink no later than January 31 of each calendar year for the real world testing conducted in the preceding calendar year (84 FR 7497). We proposed that real world testing results for each certification criterion listed in § 170.405(a) would be required to address the elements required in the previous year's testing plan, describe the outcomes of real world testing with any challenges encountered, and provide at least one measurement or metric associated with the real world testing.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concerns that the annual real world testing plan due date falls in December, noting that in addition to multiple holidays widely celebrated in the U.S., December can be a busy time for many health IT developers due to various year-end requirements and necessary preparations to support customers' quality measurement data submissions for CMS programs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We understand the commenters' concern that the proposed real world testing plan publication due date falls in the preparatory run-up to year-end deadlines, including for many developers completing preparations to support their customers' successful clinical quality measurement data submission during CMS program windows that typically open on the first Federal business day in January. In consideration of comments received, we have made edits to the phrasing of the CFR text in § 170.405(b) to convey with more precise clarity that under the policy we have finalized, the developer is required to submit its real world testing plans so that the ONC-ACB can conduct its completeness review and publish the plan hyperlink on CHPL no later than December 15 of each year. This allows for the ONC-ACB and developer to identify and agree on the date by which the developer will actually submit its plan to the ONC-ACB, which could be well in advance of December. One practical implication of the single-deadline feature of the policy as proposed is that in order for the plans to be submitted to ONC and made publicly available by the single deadline, the ONC-ACB's requirement to review plans for completeness per Program requirements will in many cases mean that the ONC-ACB will need the developer to submit the plan to the ONC-ACB in advance of the single deadline. We have finalized the December 15 due date for real world testing plan publication on CHPL as proposed. We have also made clarifying edits to the finalized regulation text (see § 170.405(b)(1)) in comparison to the proposed text to more explicitly recognize the practical implication that the developers' and ONC-ACBs' responsibility for a single publication date for the plans means that the plan must be submitted by the developer to the ONC-ACB on a date agreed between them that allows for publication by the deadline. We encourage developers and ONC-ACBs to consider allowing at least one calendar month so that the December 15 due date for ONC-ACBs' publication of real world testing plans will be consistently met. We also note that nothing in § 170.405 as finalized precludes a developer and ONC-ACB from agreeing on the developer submitting its annual real world testing plan to the ONC-ACB more than one month prior to December 15. We have finalized the single plan publication deadline as proposed.
                    </P>
                    <P>We did not receive comments specific to August 31 as the annual date when a Health IT Module must be certified by in order to be required to be included in the real world testing plan due that year. We have finalized this aspect of our policy as proposed in § 170.405(b)(1)(ii). Thus, developers can submit their real world testing plans as early as September 1 and on a rolling basis thereafter for products in scope for the following year, which also addresses commenter concerns.</P>
                    <P>We did not receive comments specific to this point, but have removed from § 170.405(b) as finalized the language that would have specifically required the initial submission of the plan to the ONC-ACB by the developer must be by a publicly accessible hyperlink. While this remains an option, and could be the most efficient one for developers and ONC-ACBs in many instances, we believe this is an unnecessarily limiting specification of the manner of interaction between developers and ONC-ACBs in these instances. The URL or hyperlink in CHPL will not be published on CHPL until the ONC-ACB takes action to publish it, and the ONC-ACB is required to review the plan and ensure it is complete before publishing the plan link on CHPL.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received some comments that appeared to construe our intent to be that real world testing for all Health IT Modules certified as of August 31 of a given year would need to be planned, conducted, and reported within five months of that date. Comments that appeared to be based on this interpretation also expressed 
                        <PRTPAGE P="25774"/>
                        concern that this would be too much to accomplish on such an annual schedule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We proposed that each developer's annual real world testing plan required to be published by December 15 of a given year would need to address all of the developer's Health IT Modules certified to criteria listed in § 170.405(a) as of August 31 of that year (84 FR 7496). We also proposed that this annual real world testing plan would pertain to real world testing activities to be conducted in the year following the December 15 plan publication due date. In light of comments received, we can see how we might have been more precise in how we stated that the annual results report would be due early in the year following the year in which the testing it reported was conducted. The full cycle of real world testing for a given year was never specifically proposed to be contained within a single year, considering that the plan is due in the year prior and the results report was proposed to be due in the year following the one in which a given annual round of real world testing activity occurs.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments raised concerns that the January 31 publication deadline might not leave enough time for developers who do not or cannot complete their annual testing activities until late in the testing year to submit their results reports, and ONC-ACBs complete their required reviews, prior to the publication deadline. One commenter raised a specific concern that the proposed January 31 due date for real world testing results falls in the submission window for several CMS programs for which developers' customers need to submit their clinical quality measurement data for the preceding year. One commenter recommended leveraging the existing quarterly update attestation process and asking developers to conduct real world testing on those items identified as major changes.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As with the plan due date, the practical implication of this proposal is that each developer will need to submit their results reports to their ONC-ACB sufficiently in advance of the due date for publication for the ONC-ACB to be able to complete its pre-publication responsibilities for all of the results reports and still publish no later than that due date. In theory, this means that in some cases developers could complete their real world testing relatively early in a given testing year and submit their results report for that year before the CMS submission window for that year's measurement data even opens for the developer's customers. However, considering the comments received, we do recognize it is possible developers may for various reasons not be able to complete their annual real world testing activities until fairly late in any given testing (calendar) year. We also recognize that the data submission window for CMS programs can be a busy time for developers, and would not wish to disadvantage newer or smaller developers who may not have separate resources available to finalize a report of real world testing not concluded until late in the testing year while simultaneously supporting customers' data submissions. In light of these comments, we have decided to finalize a deadline for publication on the CHPL of the publicly accessible hyperlink to developers' report of real world testing conducted in the prior year at March 15 of each year (see § 170.405(b)(2)(ii)). This finalized date gives an additional six weeks for finalization and submission by developers compared to the date originally proposed. It also implements a single deadline, to which the developers and ONC-ACBs are mutually accountable, in parallel to the annual real world testing plan submission requirement in § 170.405(b)(1). We believe this strikes an appropriate balance between timely availability of annual real world testing results and recognition that some developers may need to devote a substantial amount of focus to the CMS quality measures data submission windows at the beginning of each year. Although we have opted not to mandate developers submit their results reports to their ONC-ACBs by a date providing a minimum required lead time for ONC-ACBs' required review of the report, we would suggest that ONC-ACBs and developers consider the potential merits of allowing at least one calendar month between the developer's initial submission of their real world testing results report to the ONC-ACB and the March 15 publication deadline.
                    </P>
                    <HD SOURCE="HD3">e. Real World Testing Pilot Year</HD>
                    <P>
                        We acknowledged in the Proposed Rule that a subsequent final rule for that may not provide sufficient time for health IT developers to develop and submit plans for a full year of real world testing in 2020 (84 FR 7497). Therefore, we indicated in the Proposed Rule that we expected to provide an appropriate period of time for developers to submit their plans, and potentially treat 2020 as a “pilot” year for real world testing. We expected that the pilot testing of real world testing would match up to the fullest extent practicable with our proposed real world testing requirements (
                        <E T="03">e.g.,</E>
                         same criteria but for a shorter duration and without the same consequences for noncompliance). We welcomed comments on this potential approach.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of comments specifically addressing this point were in support of 2020 being treated as a pilot year. One commenter agreed that deferring the implementation or constructing a pilot year for the Program would be appropriate and stated their belief that 2020 may be too early even to conduct a pilot.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their thoughts on potential piloting of real world testing and the timing of initiating real world testing requirements. In consideration of the timing of the final rule, we have decided not to finalize 2020 as a pilot year since developers will now have the majority of calendar year 2020 to develop a prospective plan for real world testing that would begin in 2021. However, we recognize that this first “performance” year of real world testing in 2021 presents unique challenges with respect to the development of initial plans, and we fully intend to approach both the submission of initial plans and submission of retrospective testing results for those plans (
                        <E T="03">i.e.,</E>
                         2021 real world testing results) as learning experiences for developers that can be used to inform future iterations of real world test plans. As noted in the proposed rule (84 FR 7497), the due date for the first annual real world testing plan would be finalized based in part on the timing of the final rule. Because this final rule is publishing well in advance of the December 15 annual due date for publication of developers' plans of real world testing activities to be conducted in the following year, we have concluded it is reasonable to require the first annual real world testing plan be published via a publicly accessible hyperlink on the CHPL no later than December 15, 2020. This initial real world testing plan must address any and all of the developer's Health IT Modules that hold a current, valid certificate under the Program as of August 31, 2020. The real world testing plan due to be published in December 2020, will need to address the real world testing activities that will occur during calendar year 2021. The report of results for this initial (2021) annual real world test cycle will be due to be published on the CHPL no later than March 15, 2022.
                    </P>
                    <HD SOURCE="HD3">f. Health IT Modules Certified But Not Yet Deployed</HD>
                    <P>
                        We proposed (84 FR 7497) that even if a health IT developer does not have customers or has not deployed their 
                        <PRTPAGE P="25775"/>
                        certified Health IT Module(s) at the time the real world testing plan is due, the health IT developer would still need to submit a plan that prospectively addresses its plans for real world testing that would occur in the coming year for those Health IT Modules that had been certified on or before August 31 of the calendar year in which the plan is due (the calendar year immediately preceding the calendar year during which testing addressed by any given annual real world testing plan will take place). If a health IT developer has not yet deployed their certified Health IT Module to any real world users when the annual real world testing results are due for that module, we proposed that the developer would need to report as such to meet the proposed Maintenance of Certification requirement.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments on this proposal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized this proposal. Any Health IT Module certified to at least one criterion within the scope of real world testing as of August 31 of a given year must be addressed by its developer's real world testing plan for the subsequent year that must be published via publicly accessible hyperlink on the CHPL by the December 15 due date (see § 170.405(a)). This requirement applies regardless of whether that Health IT Module is in actual real world use prior to December 15 (or the earlier date by which the developer and ONC-ACB agree the developer will submit its annual real world testing plan to the ONC-ACB to ensure the developer and ONC-ACB meet single, December 15, deadline for the plan to have been reviewed for completeness and published on CHPL). To ensure precise clarity about the effect of the August 31 reference date for purposes of real world testing requirements, we reiterate that if a developer has at least one Health IT Module certified to at least any one criterion within the real world testing scope of applicability as of August 31 of a given year, the real world testing Condition and Maintenance of Certification requirements apply to that developer and the developer must submit an annual real world testing plan for that year, addressing each of their Health IT Module(s) certified to any (one or more) criteria listed in § 170.405(a) and that plan must meet the requirements in § 170.405(b)(1)(iii) for each module and criterion. Only developers who have no Health IT Module(s) certified to any criterion within the real world testing scope of applicability as of August 31 of a given year need not submit a real world testing plan that year and would not be required to perform real world testing in the subsequent year.
                    </P>
                    <HD SOURCE="HD3">g. Standards Version Advancement Process (SVAP)</HD>
                    <P>
                        As discussed in the Proposed Rule (84 FR 7497), as newer versions 
                        <SU>111</SU>
                        <FTREF/>
                         become available for adopted standards and implementation specifications included in the certification criteria subject to the real world testing Condition and Maintenance of Certification requirements, we believe that a health IT developer's ability to conduct ongoing maintenance on its certified Health IT Module(s) to incorporate these newer versions of Secretary-adopted standards and implementation specifications (“standards”) is essential to support interoperability in the real world. Updated versions of standards reflect insights gained from real-world implementation and use. They also reflect industry stakeholders' interests to improve the capacity, capability, and clarity of such standards to meet new, innovative business needs, which earlier standards versions cannot support. Therefore, as part of the real world testing Condition of Certification, we proposed a Maintenance of Certification flexibility that we refer to as the Standards Version Advancement Process (SVAP).
                        <SU>112</SU>
                        <FTREF/>
                         This flexibility would permit health IT developers to voluntarily use in their certified Health IT Modules newer versions of adopted standards so long as certain conditions are met. As we stated in the Proposed Rule, these conditions are not limited to but notably include successful real world testing of the Health IT Module using the new version(s) subsequent to the inclusion of these newer standards and implementation specification versions in the Health IT Module's certification. We proposed to establish the SVAP not only to meet the Cures Act's goals for interoperability, but also in response to the continuous stakeholder feedback that ONC has received through prior rulemakings and engagements, which requested that ONC establish a predictable and timely approach within the Program to keep pace with the industry's standards development efforts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>111</SU>
                             We note that standards developing organizations and consensus standards bodies use various nomenclature, such as “versions” or “releases,” to identify updates to standards and implementation specifications.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>112</SU>
                             Regulation text implementing the real world testing Condition and Maintenance of Certification requirement was proposed in § 170.405, including but not limited to SVAP-specific provisions proposed in § 170.405(b)(5). The SVAP-specific provisions have now been finalized in § 170.405(b)(8) and (9) (see section VII.B.5.g of this final rule).
                        </P>
                    </FTNT>
                    <P>
                        The SVAP we proposed, with corresponding proposed revisions for §§ 170.500 and 170.555, introduces two types of administrative flexibility for health IT developers participating in the Program (84 FR 7498). First, for those health IT developers with existing certified Health IT Module(s), such Health IT Modules could be upgraded to a new version of an adopted standard within the scope of the certification and have support for that updated version of the standard reflected on the Health IT Module's certificate so long as: Such version was approved by the National Coordinator for use in the Program; and the developer satisfied all requirements of the SVAP including demonstration of conformance through an acceptable means (84 FR 7498 through 7500). For purposes of the SVAP as applied to updates to Health IT Modules with certificates to criteria listed in § 170.405(a) that include prior version(s) 
                        <SU>113</SU>
                        <FTREF/>
                         of the standards, acceptable means of demonstrating conformance include but are not necessarily limited to self-declaration of conformance, as proposed in 84 FR 7499 and finalized in this final rule. Second, for those health IT developers presenting health IT for certification to a criterion listed in § 170.405(a), a National Coordinator-approved newer version of a standard included in one of these criteria could be used in lieu of or in addition to the version of that standard incorporated by reference in § 170.299 (84 FR 7498). However, for purposes of the SVAP as applied to health IT that is presented for certification to any criterion listed in § 170.405(a), developer self-declaration is an acceptable means of demonstrating conformance 
                        <E T="03">only</E>
                         where there is not yet another conformance method available that can be validly used for that version of that standard (84 FR 7499 through 7500). The regulation text codifying requirements for health IT developers to avail themselves of each of the proposed types of administrative flexibility was proposed (84 FR 7595 through 7596) in § 170.405(b)(5). Corresponding revisions to § 170.550 and § 170.555 were proposed in 84 FR 7598.
                    </P>
                    <FTNT>
                        <P>
                            <SU>113</SU>
                             Prior versions for this purpose could include those incorporated by reference in § 170.299, National Coordinator approved newer versions, or a mix of such versions for any or all of the standards adopted by the Secretary in subpart B of part 170 that are included in a given criterion.
                        </P>
                    </FTNT>
                    <P>
                        We proposed that the SVAP would be available only for National Coordinator-approved newer versions of standards and implementation specifications (“standards”) that have already been 
                        <PRTPAGE P="25776"/>
                        adopted into the Program by the Secretary through rulemaking in accordance with applicable law including the Administrative Procedures Act (5 U.S.C. 553) and sections 3001 and 3004 of the Public Health Service Act (PHSA) (42 U.S.C. 300jj-1 and 42 U.S.C. 300jj-11) (84 FR 7498). We have finalized this aspect of the standards version advancement flexibility as proposed. Under current law and the finalized SVAP flexibility, a standard must be initially 
                        <E T="03">adopted</E>
                         by the Secretary through rulemaking before the National Coordinator can 
                        <E T="03">approve</E>
                         the use of newer updated versions of that standard in the Program.
                    </P>
                    <P>We also proposed that a health IT developer would be able to choose which of the updated standards versions approved by the National Coordinator for use in certification to include in its updated certified Health IT Module and would be able to do so on an itemized basis (84 FR 7499).</P>
                    <P>We stated in the Proposed Rule that we welcomed comments on any and all aspects of our proposed SVAP as an option available to developers through maintenance requirements as part of the real world testing Condition and Maintenance of Certification requirements (84 FR 7500). We also invited comments on our proposal to allow in conjunction with this maintenance flexibility the opportunity for developers to elect to present health IT for initial testing and certification either to more advanced versions or to the prior adopted versions of the standards included in regulatory text as of the date the Health IT Modules are presented for certification.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Comments were strongly supportive of the SVAP. Several commenters recommended the description of this process include recognition of the fact that developers and systems might need to maintain operational support for previously adopted versions of standards to avoid potential adverse effects on data access, exchange, and use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the SVAP in § 170.405(b)(8) and (9) to provide the flexibility for which stakeholders' comments expressed support. This flexibility includes the option for a Health IT Module to be certified to the standards versions incorporated by reference in § 170.299 and/or one or more National Coordinator-approved updated versions of standards included in the criteria listed in § 170.405(a). Thus, once the National Coordinator has approved for use in the Program more advanced version(s) of any standard(s) applicable to any of the criteria listed in § 170.405(a), a health IT developer will have flexibility to choose on an itemized basis which of the National Coordinator-approved updated standards versions they wish to have included in their Health IT Module certification(s). Using the SVAP flexibility does not require a developer cease supporting prior version releases of standards referenced by applicable certification criteria.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concerns about the effect of an uneven pace of advanced version implementation across health IT developers and products within and outside the Program. Several of these commenters recommended that, as developers voluntarily seek to support newer versions of standards and specifications through the SVAP, they also be required to maintain support for the adopted version of the standard listed in the Code of Federal Regulations (45 CFR part 170, subpart B) for the applicable criteria until HHS conducts rulemaking that would require all certified health IT upgrade to the newer version of the standard and sunset older versions of the standard from the Program on a mandatory, coordinated timeline.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do recognize the importance of ensuring that updated versions of standards are approved and available for use in the Program only when such use is consistent with the Program's purposes. We do not anticipate that the National Coordinator would approve a newer version of a standard for use in the Program where that is inconsistent with the Program's purposes, notably including the maintenance and advancement of interoperability. Moreover, we believe there is substantial value in allowing for the market to, in effect, sunset obsolete standards versions at its own pace unless a hard cutover (or other highly coordinated nationwide timeline for abandoning older versions) would be necessary to sustain functional interoperability. The SVAP flexibility simply allows for a developer to choose to work with their ONC-ACB to obtain certification, or to modify the scope of the of Health IT Module's certification, to reflect that the Health IT Module as certified includes: The version of each adopted standard that is incorporated by reference in § 170.299; or a specific National Coordinator-approved updated version of each applicable standard; or a National Coordinator-approved updated version for each of one or more applicable standard(s); or multiple version(s) of any one or more adopted standard(s). Previously, developers were free to upgrade certified Health IT Modules to support newer versions of adopted standards, but only in addition to the version(s) of those standards incorporated by reference in § 170.299. In our experience, newer versions render prior versions obsolete on a more rapid pace for some standards than for others and more rapidly than the versions incorporated by reference in regulations could be updated. Prior feedback had indicated that being required to maintain support for the version of a standard that is incorporated by reference in § 170.299 solely for the purpose of maintaining regulatory compliance under the Program represented a burden without commensurate value in cases where customers' operational interoperability needs could be met only by use of newer version(s) of particular adopted standards than the versions listed in the regulations. The SVAP is designed to eliminate that burden and simultaneously provide, through inclusion of support for advanced standards versions within a Health IT Module's certification, enhanced assurance to users that Health IT Modules supporting National Coordinator-approved newer versions of standards under the SVAP flexibility continue to meet all of the requirements of the criteria to which the Health IT Module is certified.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters requested clarification on how the proposed Standards Version Advancement Process would align with expansion of the USCDI, or whether the USCDI will be versioned through the SVAP. Some commenters expressed an opinion that the USCDI expansion process should not be executed or allowed via the SVAP and instead require rulemaking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed in section IV.B.1, we have adopted the USCDI as a standard in § 170.213 and incorporated USCDI v1 by reference in § 170.299(n)(5). For purposes of the SVAP, the USCDI will be treated like any other standard. This means that health IT when presented for certification to any one or more criteria referencing § 170.213 will be required to support USCDI v1 or a later version, with SVAP providing flexibility for developers to choose whether to support later versions of USCDI that the National Coordinator may approve for use in the Program in lieu of or in complement to USCDI v1. Developers and will not be required to support newer versions of the USCDI standard instead of USCDI v1 until such time as § 170.213 and § 170.299 are updated. However, developers may voluntary choose to use the SVAP flexibility to voluntarily upgrade certified Health IT 
                        <PRTPAGE P="25777"/>
                        Modules, or to seek certification of their health IT, to newer version release(s) of the USCDI if such release(s) have been approved by the National Coordinator for use under the Program. As with any other standard relevant to the SVAP flexibility, we would anticipate that the National Coordinator would not approve for voluntary use under the Program an updated version of any standard that would render Health IT Module(s) using it incapable of exchanging EHI with other technology certified under the Program to other version(s) of the standard. We also note that, although HHS is the steward of the USCDI standard, we have not at this time foreclosed the possibility that we could publish a newer update of the USCDI that the National Coordinator would not immediately approve for developers' voluntary use under the Program via the SVAP flexibility. We recognize a potential that expanding the USCDI to include additional data classes in future versions could lead to Health IT Modules certified to these more advanced versions of USCDI being able to access, use, and exchange more data classes than Health IT Modules certified only to earlier versions of the USCDI. However, the technology certified to National Coordinator-approved newer versions of the USCDI would be capable of exchanging the data classes included in prior version(s) of the standard. Thus, the flexibility maintains interoperability while allowing those who need additional data classes to be fully supported by certified health IT in their access, exchange, and use of these additional data classes and not forcing other users of certified health IT (who do not yet need to access, exchange, or use such additional data classes) to update their health IT. We therefore believe that allowing for expansion of data for which certified Health IT Modules can support interoperability at a pace driven by the market's progress in standards development and demand for interoperability is an important benefit of the SVAP flexibility.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated the SVAP would be more effective for electronic prescribing if it could be used to allow voluntary adoption of a new version of the NCPDP SCRIPT standard by prescribers, pharmacies, and Part D prescription drug plans without CMS rulemaking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         CMS is solely responsible for Medicare Part D program regulations and other policies, including its required e-prescribing standards and standards versions. In the future, the SVAP flexibility could enable developers to have the certifications of their Health IT Modules to e-prescribing criteria updated to reflect conformance of the Health IT Modules to newer versions of adopted standards that might be required by CMS Part D program or other HHS regulatory requirements before we could update the version(s) of e-prescribing standards incorporated by reference in § 170.299. This approach would avoid the need for CMS or ONC to go through joint rulemaking in order maintain programmatic alignment.
                    </P>
                    <HD SOURCE="HD3">h. Updating Already Certified Health IT Leveraging SVAP Flexibility</HD>
                    <P>
                        We proposed that in instances where a health IT developer has certified a Health IT Module, including but not limited to instances where its customers are already using the certified Health IT Module, if the developer intends to update pursuant to the SVAP election, the developer will be required to provide advance notice to all affected customers and its ONC-ACB: (a) Expressing its intent to update the software to newer versions of the standard approved by the National Coordinator through the SVAP; (b) the developer's expectations for how the update will affect interoperability of the affected Health IT Module as it is used in the real world; and (c) whether the developer intends to continue to support the certificate for the existing Health IT Module version for some period of time and how long, or if the existing version of the Health IT Module certified to prior version(s) of applicable standards will be deprecated (
                        <E T="03">e.g.,</E>
                         that the developer will stop supporting the earlier version of the module and request to have the certificate withdrawn) (84 FR 7498). The notice would be required to be provided sufficiently in advance of the developer establishing its planned timeframe for implementation of the upgrade to the more advanced standard(s) version(s) in order to offer customers reasonable opportunity to ask questions and plan for the update. We requested public comment on the minimum time prior to an anticipated implementation of an updated standard or implementation specification version update that should be considered reasonable for purposes of allowing customers, especially health care providers using the Health IT Module in their health care delivery operations, to adequately plan for potential implications of the update for their operations and their exchange relationships. We also requested comments on specific certification criteria, standards, characteristics of the certified Health IT Module or its implementation (such as locally hosted by the customer using it versus software-as-a-service type of implementation), or specific types or characteristics of customers that could affect the minimum advance notice that should be considered reasonable across variations in these factors (84 FR 7499).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Only a few commenters offered thoughts specifically on the minimum time prior to an anticipated implementation of an updated standard or implementation specification version update that should be considered reasonable. Several of these commenters noted that different market segments and provider types vary in their willingness or ability to upgrade to new software versions. One comment submission indicated two months would be a reasonable minimum time prior to implementation of an updated standard for their customers to be notified. Another commenter observed that the minimum timeframe prior to an anticipated implementation of an updated standard is two to four years.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The comments received comport with our prior understanding that the minimum advance notice needed to offer customers reasonable opportunity to ask questions and plan for the update or modification of Health IT Modules the customers are using or have purchased and scheduled for deployment varies across different circumstances. We have, therefore, decided to finalize the advance notice requirement as proposed. The regulation text for this requirement is finalized in § 170.405(b)(8)(i). Thus, a developer choosing to take advantage of the SVAP flexibility must provide notice to its customers sufficiently in advance of the developer's anticipated timeframe for implementation of the update to the newer version(s) of applicable standard(s) to offer customers reasonable opportunity to ask questions and plan for the update. We note for clarity that we intend to apply a reasonableness standard to evaluating adequacy of advance notice timeframes for particular version updates in their specific factual contexts, prioritizing the perspective of a reasonable person in the situation of the developer's customers because this requirement is intended to protect the interests of those customers. We would anticipate that proactive engagement between the developers and their customers would result in mutually agreeable timeframes and obviate the need for us to assess reasonableness in at least the vast majority, and ideally the totality, of instances where developers choose to use the SVAP flexibility.
                        <PRTPAGE P="25778"/>
                    </P>
                    <HD SOURCE="HD3">i. Health IT Modules Presented for Certification Leveraging SVAP Flexibility</HD>
                    <P>In instances where a health IT developer presents health IT for certification to a criterion listed in § 170.405(a) to which the health IT is not already certified, we proposed that the health IT developer would be permitted to use National Coordinator-approved newer versions of any or all of the standards included in the criterion, instead of or in combination with the versions of these standards incorporated by reference in § 170.299. In such circumstances, a health IT developer would be able to choose which National Coordinator-approved standard version(s) it seeks to include in a new or updated certified Health IT Module and would be able to do so on an itemized basis. To enable this flexibility for developers seeking certification, we proposed to amend ONC-ACB Principles of Proper Conduct (PoPC) to require ONC-ACBs offer certification to National Coordinator-approved newer versions of standards and provide the ability for ONC-ACBs to accept a developer self-declaration of conformity as to the use, implementation, and conformance to a newer version of a standard (including but not limited to implementation specifications) as sufficient demonstration of conformance in circumstances where the National Coordinator has approved a version update of a standard for use in certification but no testing tool is yet available to test to the newer version (84 FR 7501).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters supported the proposal to allow for both updates to existing certifications of Health IT Modules and newly sought certifications to applicable criteria to follow a process of self-declaration where approved test tools are not yet available to support conformance validation of the pertinent National Coordinator-approved newer version of a standard. A few commenters requested we clarify how developers can demonstrate conformance when a newer version of a standard is available for use under this process but does not yet have testing tools available under the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We proposed (84 FR 7456) and have finalized modifications in § 170.523(h) to permit ONC-ACBs to certify Health IT Modules that the ONC-ACB has evaluated for conformance with certification criteria without first passing through an ONC-ATL. As finalized, § 170.523(h)(2) provides that an ONC-ACB may certify a Health IT Module that has been evaluated by it for compliance with a conformance method approved by the National Coordinator. This provides flexibility for the National Coordinator to approve a conformance method other than ONC-ATL testing, for evaluating conformance where the National Coordinator has approved a version update of a standard for use in certification but an associated testing tool is not yet updated to test to the newer version. We have also made edits to the text in § 170.405(b) as finalized in comparison to the text included in the Proposed Rule to make more immediately clear which specific requirements apply when developers choose to take advantage of the SVAP flexibility for updating Health IT Modules already certified to a criterion listed in § 170.405(a) and which specific requirements apply when developers choose to leverage the flexibility when presenting Health IT Modules for certification to a criterion listed in § 170.405(a).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended HHS give health IT developers' flexibility to choose which standards to advance through this process and not obligate them to update to all possible standards at once.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the Proposed Rule, we noted (84 FR 7497) that a health IT developer would be able to choose which National Coordinator-approved standard version(s) it seeks to include in a new or updated certified Health IT Module and would be able to do so on an itemized basis. Under the finalized SVAP flexibility in § 170.405(b)(9), health IT developers are permitted to choose to use National Coordinator-approved version(s) or the version incorporated by reference in § 170.299 or both for any standard(s) included in applicable criteria it seeks to use in its certified Health IT Module(s) on an itemized, standard-by-standard basis at the developer's discretion.
                    </P>
                    <P>In the Proposed Rule, the regulation text for all SVAP requirements was proposed to be codified in § 170.405(b)(5). The SVAP requirements, as finalized, are codified in § 170.405(b)(8) and (9). We decided to codify the finalized SVAP requirements in separate paragraphs because it complements other wording changes to the finalized regulation text that we made to make more immediately clear on the face of the regulation which specific requirements (§ 170.405(b)(8)) apply when developers choose to take advantage of the SVAP flexibility for updating Health IT Modules already certified to a criterion listed in § 170.405(a) and which specific requirements (§ 170.405(b)(9)) apply when developers choose to leverage the flexibility when presenting Health IT Modules for certification to a criterion listed in § 170.405(a).</P>
                    <HD SOURCE="HD3">j. Requirements Associated With All Health IT Modules Certified Leveraging SVAP</HD>
                    <P>As outlined in the Proposed Rule (84 FR 7499), in all cases, regardless of whether a health IT developer is updating an existing certified Health IT Module or presenting a new Health IT Module for certification to new versions of adopted standards approved by the National Coordinator through the Standards Version Advancement Process, we proposed that any developer choosing to take advantage of the proposed flexibility would need to:</P>
                    <P>• Ensure its mandatory disclosures in § 170.523(k)(1) appropriately reflect its use of any National Coordinator-approved newer versions of adopted standards; and</P>
                    <P>• Address and adhere to all Program requirements—including but not limited to Conditions of Certification and Maintenance of Certification requirements—that are applicable to its certified Health IT Modules regardless of whether those Health IT Modules were certified to the adopted standards found in 45 CFR part 170 or National Coordinator-approved newer version(s) of the adopted standard(s).</P>
                    <P>For example, as we proposed, a developer would need to ensure that its real world testing plan and actual real world testing include the National Coordinator-approved newer versions of standards to which it is claiming conformance, beginning with the plan for and real world testing conducted in the year immediately following the first year the developer's applicable Health IT Module(s) were, as of August 31, certified to the National Coordinator-approved newer versions of standards.</P>
                    <P>
                        Under the policies outlined in the Proposed Rule, developers would be held accountable for maintaining all applicable certified Health IT Modules in conformance with any National Coordinator-approved newer versions of standards and implementation specifications that they voluntarily elect to use in their certified health IT under the real world testing Condition and Maintenance of Certification requirements proposed in § 170.405, the attestations Condition and Maintenance of Certification requirements proposed in § 170.406, and through ONC-ACB surveillance applying to certificates that include National Coordinator-approved updated versions as it does to those that do not. We also included discussion indicating our intent that developers would be accountable for correcting 
                        <PRTPAGE P="25779"/>
                        non-conformities with certification criteria that were discovered in real world testing of a Health IT Module certified using National Coordinator-approved newer versions. Under the proposed policies, prompt corrective action would be required by a developer discovering such non-conformity through real world testing, in similar manner as a developer would be accountable for correcting non-conformities discovered through real world testing of Health IT Modules certified using only the versions of Secretary-adopted standards that are incorporated by reference in § 170.299, or through other Program means.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive specific comments on these general requirements and details of the relationship between the proposed SVAP and other proposed Program enhancements or existing accountability mechanisms.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized these details of our SVAP policies as proposed.
                    </P>
                    <P>We stated in the Proposed Rule that we anticipate providing ONC-ACBs (and/or health IT developers) with a means to attribute information on Health IT Modules' support for National Coordinator-approved updated versions of standards to the listings on the CHPL for the Health IT Modules the ONC-ACB has certified, and proposed to require in the PoPC for ONC-ACBs that they are ultimately responsible for this information being made publicly available on the CHPL (84 FR 7501). We requested public comment on any additional information about updated standards versions that may be beneficial to have listed with certified Health IT Modules on the CHPL.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended ONC provide a method on the ONC CHPL for documenting the dot version/release associated with the new standard version implementation and clarify the ONC-ACBs reporting timeline for these types of standard version updates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for the feedback, which will help to inform our internal deliberations about future operational planning.
                    </P>
                    <HD SOURCE="HD3">k. Advanced Version Approval for SVAP</HD>
                    <P>The Proposed Rule (84 FR 7500) included discussion of how, after a standard has been adopted through notice and comment rulemaking, ONC anticipated undertaking an open and transparent process to timely ascertain whether a more recent version of any standard or implementation specification that the Secretary as adopted in part 170 should be approved for developers' voluntary use under the Program. We requested commenters' input on our anticipated approach to standards and implementation specification advanced version approval as outlined in the Proposed Rule.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concerns that appeared to suggest an understanding that the SVAP would be used to adopt new standards into the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As stated in the Proposed Rule, the SVAP flexibility can only be used for newer (sometimes known as “updated”) versions of standards and implementation specifications that the Secretary has already adopted through notice-and-comment rulemaking.
                        <SU>114</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>114</SU>
                             As also noted in the Proposed Rule, this policy considers the substance of a standard and not whether its name or version naming and identification track remains unchanged over time, as standards developing organizations and processes may apply different naming or identification methods from one version to another of the same standards or implementation specifications. For more information on version naming and identification tracks for standards and implementation specifications, please see the Proposed Rule (84 FR 7500).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter urged that in order to be considered for approval for voluntary use under the Program the full details of a version of a standard should be required to be publicly available online by the start of opportunity for public review and discussion of the list of versions under consideration.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. Although specifics of operational processes are outside the scope of this rule, we wish to reassure all stakeholders that we do appreciate the value of ensuring public dialogue around such matters as consideration of standards versions for potential voluntary use in the program is appropriately supported by availability of relevant information. As we operationalize support for finalized policies including the SVAP, we plan to provide ample public outreach and communications through channels familiar to affected stakeholders—including but not limited to ONC's 
                        <E T="03">HealthIT.gov</E>
                         website.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested various potential features or processes that could be used in ascertaining whether a more recent version of any standard or implementation specification that the Secretary as adopted in part 170 should be approved by the National Coordinator for developers' voluntary use under the Program. We also received several comments regarding potential uses of information from the standards review and approval processes or the SVAP flexibility itself to inform assessments of various aspects of the health IT ecosystem such as the maturity and uptake of specific standards versions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Although addressing their substance is outside the scope of this final rule, we appreciate these responses to our call for comments. This information will help to inform our deliberations about future program policies and operations.
                    </P>
                    <HD SOURCE="HD3">l. Real World Testing Principles of Proper Conduct for ONC-ACBs</HD>
                    <P>We proposed to include a new PoPC for ONC-ACBs in § 170.523(p) that would require ONC-ACBs to review and confirm that applicable health IT developers submit real world testing plans and results in accordance with our proposals (84 FR 7501). The proposed requirement was that the ONC-ACBs review the plans for completeness. Once completeness is confirmed, we proposed that ONC-ACBs would provide the plans to ONC and make them publicly available by December 15 of each year (see § 170.523(p)(1) and (3) in 84 FR 7598). We proposed that for the reasons discussed above in context of developer requirements, we have finalized (in § 170.405(b)(1)) December 15 of each year as the due date for the annual real world testing plans. We proposed in § 170.523(p)(2) that the ONC-ACB would “review and confirm that applicable health IT developers submit real world testing results in accordance with § 70.405(b)(2).” And in § 170.523(p)(3) we proposed that the ONC-ACBs would be required to submit real world testing results by April 1 of each year to ONC for public availability (84 FR 7598).</P>
                    <P>
                        <E T="03">Comments.</E>
                         The only comments received relevant to these PoPC proposals were about due dates, and were summarized above in context of the § 170.405 requirements applicable to developers (see section VII.B.5.d 
                        <E T="03">Submission Dates,</E>
                         in this final rule).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters again for their feedback on this proposal and have finalized the PoPC (170.523(p)(1)-(3)) as proposed, with the exception of having adjusted in § 170.523(p)(3) the annual due date for publication of developers' real world testing results reports on CHPL from the proposed April 1 to the finalized March 15 date.
                    </P>
                    <P>
                        Because we proposed to allow health IT developers to implement National Coordinator-approved newer versions of adopted standards and implementation specifications in certified Health IT 
                        <PRTPAGE P="25780"/>
                        Modules, we proposed two requirements to ensure the public has knowledge and ONC-ACBs can maintain appropriate oversight and surveillance of the version of a standard that certified health IT meets. First, we proposed to revise the PoPCs in § 170.523(m) to add subparagraph (4) requiring ONC-ACBs to aggregate, no less than quarterly, all updates successfully made to use newer versions of adopted standards in certified health IT per the requirements for developers choosing to take advantage of the SVAP flexibility. This would ensure that ONC is aware of the version of a standard that certified health IT meets for the purposes of Program administration. Second, we proposed, that a developer that chooses to avail itself of the SVAP flexibility must address its use of newer versions of adopted standards in its real world testing plans and results.
                    </P>
                    <P>We sought comment on the proposed additions to the PoPC for ONC-ACBs. More specifically, we sought comment on whether ONC-ACBs should be required to perform an evaluation beyond a completeness check for the real world testing plans and results and the value versus the burden of such an endeavor.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on this proposal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The substance of the requirement is finalized as proposed, though, we have made clarifying edits to the way in which the PoPC amendments are organized and phrased. The requirement proposed in § 170.523(m)(4) (84 FR 7599) has been re-designated in § 170.523(m)(5). In the finalized § 170.523(m)(5), we have revised the citation to the SVAP requirements because they were proposed in § 170.405(b)(5) but are finalized in § 170.405(b)(8) and (9). The wording of requirement finalized in § 170.523(m)(5) was modified in comparison to that proposed in 84 FR 7599 to make clear that ONC-ACBs are required to report on all certifications of Health IT Modules to National Coordinator-approved newer versions of Secretary-adopted standards, both those updated to include newer versions of adopted standards and those of Health IT Modules first presented for certification using newer versions of adopted standards. Another modification to the finalized regulation text in § 170.523(m)(5) in comparison with that proposed clarifies that ONC-ACBs are permitted to obtain the quarterly record of successful use in certified Health IT Modules of newer versions of adopted standards from the ONC-ACB's records of certification activity. We believe this clarification is important to ensure the regulation text finalized in § 170.523(m)(5) cannot be misconstrued as precluding use of such records as the data source for this requirement.
                    </P>
                    <P>
                        In complement to the above requirements to ensure transparency for the public and end users, we proposed in § 170.523(t) a new PoPC for ONC-ACBs requiring them to ensure that developers seeking to take advantage of the SVAP flexibility in § 170.405(b) comply with the applicable requirements, and that the ONC-ACB both retain records of the timing and content of developers' required 
                        <SU>115</SU>
                        <FTREF/>
                         notices and ensure each notice is timely and publicly accessible, and easily located via the CHPL through attribution of the notice to the certified Health IT Modules to which it applies.
                        <SU>116</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>115</SU>
                             The advance notice requirement that was proposed in § 170.405(b)(5)(i) and that is now finalized in § 170.405(b)(8)(i) remains specific to developers leveraging SVAP flexibility to update Health IT Modules with existing certifications.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>116</SU>
                             We note for clarity that whether a copy of the content is hosted on CHPL, made available via a publicly accessible hyperlink provided by the developer, or another mechanism or method that may emerge as a more advanced and efficient technical approach to achieving this same goal is an operational detail and does not need to be defined in rulemaking.
                        </P>
                    </FTNT>
                    <P>We note that in the proposed regulation text in § 170.523(t) as published in 84 FR 7598, there was an editorial error. The editorial error was in title in § 170.523(t) as published in 84 FR 7598, which read “Standards Voluntary Advancement Process” instead of “Standards Version Advancement Process,” although the proposed introductory text correctly referenced “Standards Version Advancement Process.”</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive public comment on the proposed paragraph (t) or its addition to § 170.523.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized § 170.523(t) with a revised title more consistent with the finalized titles of paragraphs (8) and (9) in § 170.405(b), and a revised citation to § 170.405. The citation to § 170.405 was revised because the SVAP requirements 170.523(t) references were proposed in § 170.405(b)(5) but have been finalized in § 170.405(b)(8) and (9). The substance of the PoPC requirement in § 170.523(t) is finalized as proposed.
                    </P>
                    <HD SOURCE="HD3">m. Health IT Module Certification &amp; Certification to Newer Versions of Certain Standards</HD>
                    <P>We proposed to add in § 170.550, Health IT Module certification, a new paragraph (e), which would require that ONC-ACBs must provide an option for certification of Health IT Modules to any one or more of the criteria referenced in § 170.405(a) based on newer versions of standards included in the criteria which have been approved by the National Coordinator for use in certification through the Standards Version Advancement Process (84 FR 7598).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no public comments on this proposed addition to § 170.550 to accommodate the SVAP flexibility.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the substance of § 170.550(e) as proposed. We have modified the regulatory text finalized in § 170.550(e) in comparison with that proposed in 84 FR 7598 by adding a header. The finalized paragraph reads: “
                        <E T="03">Standards Updates.</E>
                         ONC-ACBs must provide an option for certification of Health IT Modules to any one or more of the criteria referenced in § 170.405(a) based on newer versions of standards included in the criteria which have been approved by the National Coordinator for use in certification.”
                    </P>
                    <P>We proposed to revise § 170.555(b)(1) to accommodate the SVAP flexibility. The revised text in § 170.555(b)(1) as proposed (84 FR 7598) read: ONC-ACBs are not required to certify Complete EHRs and/or Health IT Module(s) according to newer versions of standards adopted and named in subpart B of this part, unless: (i) The National Coordinator identifies a newer version through the Standards Version Advancement Process and a health IT developer voluntarily elects to seek certification of its health IT in accordance with § 170.405(b)(5); or (ii) The new version is incorporated by reference in § 170.299.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive public comments on revising paragraph (b)(1) of § 170.555 to accommodate the SVAP flexibility.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the substance of this revision as proposed. However, we have struck “Complete EHRs and/or” from the text finalized in § 170.555(b)(1) consistent with our finalizing the removal from 45 CFR part 170 of references to “Complete EHRs” in conjunction with the removal of the 2014 Edition (as discussed in section III.B.2 of this final rule). We have clarified the text in § 170.555(b)(1) as finalized to use the word “approves” in place of “identifies,” consistent with our phrasing and terminology throughout the preamble of this final rule and finalized regulation text implementing the SVAP flexibility. We have replaced “under the Standards Version Advancement Process” with “for use in certification” because we 
                        <PRTPAGE P="25781"/>
                        believe this wording prevents potential confusion about whether the term “Standards Version Advancement Process” refers to the administrative flexibility established in § 170.405(b)(8) and (9) or to the National Coordinator's approach to approving versions for use in the Program. We have also revised the citation to § 170.405(b) in the finalized text in § 170.555 because the SVAP provisions proposed in § 170.405(b)(5) have been finalized in § 170.405(b)(8) and (9).
                    </P>
                    <HD SOURCE="HD3">6. Attestations</HD>
                    <P>The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, provide to the Secretary an attestation to all of the Conditions of Certification requirements specified in PHSA § 3001(c)(5)(D), except for the “EHR reporting criteria submission” Condition of Certification requirement in § 3001(c)(5)(D)(vii). We proposed to implement the Cures Act by requiring health IT developers to attest, as applicable, to compliance with the Conditions and Maintenance of Certification requirements proposed in §§ 170.401 through 170.405.</P>
                    <P>
                        We proposed that, as a Maintenance of Certification requirement for the “attestations” Condition of Certification requirement under § 170.406(b), health IT developers would need to submit their attestations every 6 months (
                        <E T="03">i.e.,</E>
                         semiannually). We proposed to provide a 14-day attestation period twice a year. For health IT developers presenting Health IT Modules for certification for the first time under the Program, we proposed that they would be required to submit an attestation at the time of certification and also comply with the semiannual attestation periods. As stated in the Proposed Rule, we would publicize and prompt developers to complete their attestation during the required attestation periods. We also proposed to provide a method for health IT developers to indicate their compliance, noncompliance with, or the inapplicability of each Condition and Maintenance of Certification requirement as it applies to all of their health IT certified under the Program for each attestation period. Last, we proposed to provide health IT developers the flexibility to specify noncompliance per certified Health IT Module, if necessary. We noted, however, that any noncompliance with the proposed Conditions and Maintenance of Certification requirements, including the “attestations” Conditions and Maintenance of Certification requirements, would be subject to ONC direct review, corrective action, and enforcement procedures under the Program.
                    </P>
                    <P>We welcomed comments on the proposed attestations Condition and Maintenance of Certification requirements, including the appropriate frequency and timing of attestations. We also welcomed comments on the proposed responsibilities for ONC-ACBs related to the attestations of Condition and Maintenance of Certification requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments supporting the “attestations” Condition and Maintenance of Certification requirements. Commenters generally agreed that health IT developers should attest that they are complying with all the required Conditions and Maintenance of Certification requirements. A few commenters were concerned that the Condition of Certification requirements set up unreasonable expectations that health IT developers attest to statements that are subject to interpretation and are ambiguous, and that developers should be able to articulate how their software and businesses meet the expectations.
                    </P>
                    <P>
                        We also received comments suggesting ways to reduce burden for health IT developers. Some commenters suggested less frequent attestation periods ranging from once a year to every two years as a means for reducing burden on health IT developers. Another commenter suggested that we send reminders to health IT developers when an attestation(s) needs renewal. One commenter recommended that we include a specific deadline at the middle and end of each year for attestations in lieu of the proposed predefined 14-day attestation window. Another commenter recommended that attestations should only be sent electronically as any other process of reporting (
                        <E T="03">e.g.,</E>
                         written letter) would be onerous on all parties.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and have adopted in § 170.406 the “attestations” Conditions and Maintenance of Certification requirement with revisions discussed below. These revisions should both provide clarity for compliance and reduce burden.
                    </P>
                    <P>Health IT developers will be attesting to the Conditions of Certification that are statutory requirements under section 4002 of the Cures Act. This final rule also addresses concerns of ambiguity and interpretation by revising the Conditions and Maintenance of Certification requirements and the information blocking provision, which is a Condition of Certification in § 170.401. We have also revised § 170.406 to provide further clarity on the applicability of each of the Conditions and Maintenance of Certification requirements to health IT developers for the purposes of attestation. For example, all health IT developers under the Program would attest to the “information blocking” Condition of Certification requirement (§ 170.401), while only health IT developers that have health IT certified to the “API” certification criteria (§ 170.315(g)(7)-(10)) would be required to attest to the “API” Condition of Certification and Maintenance requirements (§ 170.404). We have also revised the “attestations” Conditions and Maintenance of Certification requirements in § 170.406 to clearly reflect that all attestations must be approved and submitted by an officer, employee, or other representative the health IT developer has authorized to make a binding attestation(s) on behalf of the health IT developer. This provides regulatory clarity for health IT developers as to their responsibility under the attestation provisions (§ 170.406).</P>
                    <P>A requirement of attestation every 6 months properly balances the need to support enforcement actions with the attestation burden placed on developers. In this regard, allegations of inappropriate actions and non-compliance by health IT developers with Program requirements and the information blocking provision can be more readily cross-referenced against their attestations for enforcement purposes comparative to a one-year or two-year attestation period. Based on the efficient methods we are establishing for attestation as described below, we believe that we have implemented this statutory requirement for health IT developers in ways that will reduce the compliance burden for them. We also refer readers to section VII.D of this preamble for discussion of ONC direct review, corrective action, and enforcement procedures for the Conditions and Maintenance of Certification requirements under the Program.</P>
                    <P>
                        We recognize comments expressing concerns on the potential burden placed on health IT developers to attest semiannually. The process we plan to implement for providing attestations should minimize burden on health IT developers. To further minimize potential burden on health IT developers, we have revised the proposed 14-day attestation window to extend the window to 30 days. In other words, health IT developers will be able to submit their attestations within a 
                        <PRTPAGE P="25782"/>
                        designated 30-day window twice a year for purposes of compliance. To note, in accordance with § 170.406(b), the first attestation window will begin April 1, 2021. This attestation period will cover the time period from the effective date of the final rule through March 31, 2021. This irregular time period is due to the publication of the final rule. Subsequently, a regular 6-month period will commence with the attestation window for the 6-month period opening on October 1, 2021 (attesting for the period of April 1 through September 30). We have also revised the Conditions and Maintenance of Certification requirements to reflect that all health IT developers under the Program would adhere to a similar semiannual attestation schedule, rather than new health IT developers also attesting at the time of certification. We believe this is more practical, less burdensome for health IT developers and ONC-ACBs, and creates less confusion as to what actions and statements a health IT developer is attesting to (
                        <E T="03">i.e.,</E>
                         for past actions under the Program).
                    </P>
                    <P>As stated in the Proposed Rule, we plan to implement several other means to minimize burden. First, we plan to publicize and prompt developers to complete their attestation during the required attestation periods. Second, as proposed in the Proposed Rule, we will provide a method for health IT developers to indicate their compliance, noncompliance, or the inapplicability of each Condition and Maintenance of Certification requirement as it applies to all or each of their Health IT Modules certified under the Program for each attestation period. Third, to clarify our proposal and respond to the comment recommending electronic submission, we note ONC-ACBs have discretion to specify the format and may choose to require electronic submission. In addition, to support electronic submission, we will provide a web-based form and method for health IT developers to submit attestations in an efficient manner for ONC-ACBs' review.</P>
                    <HD SOURCE="HD3">ONC-ACB Responsibilities</HD>
                    <P>We proposed that attestations would be submitted to ONC-ACBs and reviewed in accordance with § 170.523(q) as a means for ONC-ACBs to monitor health IT developers for compliance with Program requirements. ONC-ACBs would be required to share the attestations with ONC. ONC would then make the attestations publicly available through the CHPL. The other responsibility we proposed in § 170.550(l) was that before issuing a certification, an ONC-ACB would need to ensure that the health IT developer of the Health IT Module has met its responsibilities related to the Conditions and Maintenance of Certification requirements as solely evidenced by its attestation. For example, if a health IT developer with an active certification under the Program provided noncompliant designations in their attestation but was already participating in a corrective action plan (CAP) under ONC direct review to resolve the noncompliance, certification would be able to proceed while the issue is being resolved.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on the specific responsibilities of ONC-ACBs when collecting and submitting attestations to ONC, including instances of an attestation indicating non-conformity and the lack of a submission of an attestation by a health IT developer.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input and have finalized as proposed. We refer readers to section VII.D for further discussion of ONC direct review, corrective action, and enforcement procedures for the Conditions and Maintenance of Certification requirements under the Program, including the roles of ONC-ACBs in enforcement of the Conditions and Maintenance of Certification requirements.
                    </P>
                    <HD SOURCE="HD3">7. EHR Reporting Criteria Submission</HD>
                    <P>As stated in the Proposed Rule, the Cures Act specifies that health IT developers shall be required, as a Condition and Maintenance of Certification requirement under the Program, to submit certain information to satisfy the reporting criteria on certified health IT in accordance with the EHR Reporting Program requirements established under section 3009A of the PHSA, as added by section 4002 of the Cures Act. We have not yet established an EHR Reporting Program. Once ONC establishes such an EHR Reporting Program, we will undertake future rulemaking to propose and implement the associated Condition and Maintenance of Certification requirement(s) for health IT developers.</P>
                    <HD SOURCE="HD2">C. Compliance</HD>
                    <P>The Maintenance of Certification requirements discussed above do not necessarily define all the outcomes necessary to meet the Conditions of Certification. Rather, they provide preliminary or baseline evidence toward measuring whether a Condition of Certification requirement is being met. Thus, ONC could determine that a Condition of Certification requirement is not being met through reasons other than the Maintenance of Certification requirements. For example, meeting the Maintenance of Certification requirement that requires a health IT developer to not establish or enforce any contract or agreement that contravenes the Communications Condition of Certification requirement does not excuse a health IT developer from meeting all the requirements specified in the Communications Condition of Certification requirement. This is analogous to clarifications ONC has previously provided about certification criteria requirements whereby testing prior to certification sometimes only tests a subset of the full criterion's intended functions and scope. However, for compliance and surveillance purposes, we have stated that ONC and its ONC-ACBs will examine whether the certified health IT meets the full scope of the certification criterion rather than the subset of functions it was tested against (80 FR 62709 and 62710).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to compliance with Maintenance of Certification requirements as related to meeting Conditions of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We continue to maintain our position that Maintenance of Certification requirements do not define all of the outcomes necessary to meet the Conditions of Certification requirements. Thus, while complying with Maintenance of Certification requirements will provide evidence toward measuring whether a Condition of Certification requirement is being met, reasons beyond the Maintenance of Certification requirements could result in ONC determining that a Condition of Certification requirement has not been met.
                    </P>
                    <HD SOURCE="HD2">D. Enforcement</HD>
                    <P>
                        The Cures Act affirms ONC's role in using certification to improve health IT's capabilities for the access, use, and exchange of EHI. The Cures Act provides this affirmation through expanded certification authority for ONC to establish Conditions and Maintenance of Certification requirements for health IT developers that go beyond the certified health IT itself. 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). Furthermore 
                        <PRTPAGE P="25783"/>
                        and equally important, section 4002 of the Cures Act provides that the Secretary of HHS may encourage compliance with the Conditions and Maintenance of Certification requirements and take action to discourage noncompliance. Given these considerations, we proposed a general enforcement framework outlining a corrective action process for ONC to review potential or known instances where a Condition or Maintenance of Certification requirement has not been or is not being met by a health IT developer under the Program, including the requirement for a health IT developer to attest to meeting the Conditions and Maintenance of Certification requirements.
                    </P>
                    <HD SOURCE="HD3">1. ONC Direct Review of the Conditions and Maintenance of Certification Requirements</HD>
                    <P>Historically we utilized the processes previously established for ONC direct review of certified health IT in the ONC Health IT Certification Program: Enhanced Oversight and Accountability Act (EOA) final rule (81 FR 72404), and as codified in §§ 170.580 and 170.581, to address non-conformities with Program requirements. For multiple reasons, we proposed in 84 FR 7503 to utilize substantially the same processes for the enforcement of the Conditions and Maintenance of Certification requirements. 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 are familiar with the ONC direct review provisions as they were established by the EOA final rule in October 2016. Third, §§ 170.580 and 170.581 have provided thorough and transparent processes for working with health IT developers through notice and corrective action to remedy Program non-conformities. Last, the direct review framework has provided equitable opportunities for health IT developers to respond to ONC actions and appeal certain ONC determinations.</P>
                    <P>As further discussed below, we have finalized our proposed approach to utilize the processes previously established and codified in §§ 170.580 and 170.581 for ONC direct review of certified health IT for the enforcement of the Conditions and Maintenance of Certification requirements, along with our proposed revisions to these processes in order to properly incorporate enforcement of these requirements. We note that the Information Blocking Condition of Certification (§ 170.401) and the related Assurances Condition of Certification requirement (§ 170.402(a)(1)) have a delayed enforcement date of 6 months after date of publication of the final rule.</P>
                    <HD SOURCE="HD3">2. Review and Enforcement Only by ONC</HD>
                    <P>We proposed in 84 FR 7503 to retain use of the term “direct review” as previously adopted in the EOA final rule to continue to distinguish actions ONC takes to directly review certified health IT or health IT developers' actions from actions taken by an ONC-ACB to review certified health IT under surveillance. We proposed, however, that ONC would be the sole party responsible for enforcing compliance with the Conditions and Maintenance of Certification requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments requesting clarification that ONC-ACBs are not responsible for enforcement of the Conditions and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized this review and enforcement approach in §§ 170.580(a)(1) and 170.580(a)(2)(iii) as proposed above. We clarify that ONC-ACBs are not responsible for enforcement of the Conditions and Maintenance of Certification requirements. Under finalized § 170.523(s), and as further discussed later in this section, ONC-ACBs 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. ONC-ACBs also address non-conformities with technical and other Program requirements through surveillance and by working with health IT developers through corrective action plans.
                    </P>
                    <HD SOURCE="HD3">3. Review Processes</HD>
                    <P>As discussed above, we proposed to utilize the processes previously established and codified in §§ 170.580 and 170.581 for ONC's direct review and enforcement of the Conditions and Maintenance of Certification requirements, along with certain proposed revisions and additions to these processes to properly incorporate enforcement of these requirements and effectuate congressional intent conveyed through the Cures Act.</P>
                    <HD SOURCE="HD3">a. Initiating Review and Health IT Developer Notice</HD>
                    <P>We proposed in 84 FR 7503 to fully incorporate the review of compliance with the Conditions and Maintenance of Certification requirements into the provisions of § 170.580(a) and (b). We proposed in § 170.580(a)(2)(iii) that if ONC has a reasonable belief that a health IT developer has not complied with a Condition or Maintenance of Certification requirement, then it may initiate direct review. Similarly, we proposed in § 170.580(b)(1) and (2) that ONC may issue the health IT developer a notice of potential non-conformity or notice of non-conformity and provide the health IT developer an opportunity to respond with an explanation and written documentation, including any information ONC requests.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment that ONC should communicate with a representative sample of users of a health IT product when enforcing the Conditions and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment. We are committed to consistent and thorough enforcement of the Conditions and Maintenance of Certification requirements and review of complaints of noncompliance. Our goal is to work with developers to remedy any noncompliance in a timely manner. During the course of our review of a potential noncompliance, we may communicate with users of the health IT, as appropriate. We have finalized this approach regarding initiation of review and health IT developer notice in §§ 170.580(a)(2)(iii) and 170.580(b) as proposed.
                    </P>
                    <HD SOURCE="HD3">i. Complaint Resolution</HD>
                    <P>In the Proposed Rule, we noted and recommended in 84 FR 7503 that customers and end users first work with their health IT developers to resolve any issues of potential noncompliance with the Conditions and Maintenance of Certification requirements. We proposed that if the issue cannot be resolved, the end user should contact the ONC-ACB for assessment. However, as discussed above and in section VII.D.5 below, the ONC-ACB purview for certified health IT generally applies to certified capabilities and limited requirements of developer business practices. We proposed that if neither of these pathways resolves the issue, end users may want to provide feedback to ONC via the Health IT Feedback Form.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment recommending that we require complaints regarding developer compliance with Conditions and 
                        <PRTPAGE P="25784"/>
                        Maintenance of Certification requirements go directly to ONC rather than to an ONC-ACB. Another commenter requested that we provide guidance regarding how to report issues related to developer compliance.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized in § 170.580 our proposed approach regarding complaint resolution as described above, which is guided by prior Program experience.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that we adopt a self-disclosure mechanism for health IT developers to report any non-conformity with the Program and enable such self-disclosure to offer health IT developers regulatory protection.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and strongly encourage self-disclosure by developers, which health IT developers currently do under the Program. We note that currently there are methods by which health IT developers may communicate with ONC-ACBs and/or ONC, and it is our longstanding policy to work with health IT developers to correct non-conformities. While we believe this approach works well, consistent with Executive Order 13892, we are considering whether it would be appropriate to adopt additional procedures that further encourage self-reporting of non-conformities and voluntary information sharing, as well as procedures to provide pre-enforcement rulings to health IT developers who make inquiries regarding their compliance with regulatory requirements.
                    </P>
                    <HD SOURCE="HD3">ii. Method of Correspondence With Health IT Developers</HD>
                    <P>Section 170.505 states that correspondence and communication with ONC or the National Coordinator shall be conducted by email, unless otherwise necessary or specified. We noted in the Proposed Rule in 84 FR 7503 that in the EOA final rule we signaled our intent to send notices of potential non-conformity, non-conformity, suspension, proposed termination, and termination via certified mail (81 FR 72429). However, we proposed to follow § 170.505 for correspondence regarding direct review of noncompliance with the Conditions and Maintenance of Certification requirements.</P>
                    <P>
                        As discussed in the Proposed Rule, the type and extent of review by ONC could vary significantly based on the complexity and severity of each fact pattern. For instance, ONC may be able to address certain noncompliance with the Conditions and Maintenance of Certification requirements quickly and with minimal effort (
                        <E T="03">e.g.,</E>
                         failure to make public a documentation hyperlink), while other situations may be more complex and require additional time and effort (
                        <E T="03">e.g.,</E>
                         violation of API fee prohibitions). Considering this wide range of potential noncompliance with the Conditions and Maintenance of Certification requirements, we proposed that ONC retain discretion to decide, on a case-by-case basis, when to go beyond the provisions of § 170.505 to use means other than email in providing notices and correspondence for noncompliance with the Conditions and Maintenance of Certification requirements.
                    </P>
                    <P>We solicited comment on the nature and types of noncompliance with the Conditions and Maintenance of Certification requirements that ONC should consider in determining the method of correspondence. We also solicited comment on whether the type of notice should determine the method of correspondence. More specifically, we solicited comment on whether certain types of notices under direct review should be considered more critical than others, thus requiring a specific method of correspondence.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments regarding the proposed method of correspondence with health IT developers. Some commenters stressed that time-sensitive notifications should not be sent via email, with one commenter noting that ONC should use certified mail, with a copy to a designated notice recipient, for notices of potential noncompliance and noncompliance with the Conditions and Maintenance of Certification requirements. Other commenters suggested that ONC should use both email and certified mail for notices regarding initiation of direct review, potential non-conformity, non-conformity, suspension, proposed termination, and termination. One commenter recommended ONC acknowledge receipt of communications received.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' support of our proposals, as well as the constructive suggestions. We have finalized our proposal to use the provisions in § 170.505 for correspondence regarding noncompliance with the Conditions and Maintenance of Certification requirements, with minor revisions. While we agree with commenters that there may be situations when sending notice only via email would not be adequate, such situations would be contingent on the circumstances as described in the Proposed Rule. Therefore, we have revised the regulation text of § 170.505 to specify some of those considerations. These considerations include, but are not limited to, whether: The party requests use of correspondence beyond email; the party has responded via email to our communications; we have sufficient information from the party to ensure appropriate delivery of such notice; and, importantly, the alleged violation of a Condition or Maintenance of Certification requirement or other Program requirement within ONC's purview under § 170.580 indicates a serious violation of the Program with potential consequences of suspension, certification termination, or a certification ban.
                    </P>
                    <P>We did not propose any requirements regarding acknowledgment of receipt, and we have finalized our proposed approach to utilize the processes previously established and codified in §§ 170.580 and 170.581 for ONC direct review of certified health IT for the enforcement of the Conditions and Maintenance of Certification requirements, which include response requirements already codified in §§ 170.580 and 170.581.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter requested clarification on ONC's timeframe for responding to health IT developers during direct review. Another commenter requested clarity on investigation timelines generally.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized our proposed approach to utilize the processes previously established and currently codified in §§ 170.580 and 170.581 for ONC's direct review and enforcement of the Conditions and Maintenance of Certification requirements, which include specific response timeframes throughout the direct review process. We refer commenters to §§ 170.580 and 170.581 for the timeframes applicable to the various steps in the direct review process. We also clarify that proposed termination and suspension are excluded from ONC's direct review process for the Conditions and Maintenance of Certification requirements, so any timeframes related to proposed termination and suspension do not apply.
                    </P>
                    <HD SOURCE="HD3">b. Relationship With ONC-ACBs and ONC-ATLs</HD>
                    <P>
                        Section 170.580(a)(3) outlines ONC direct review in relation to the roles of ONC-ACBs and ONC-ATLs, which we proposed to revise to incorporate the Conditions and Maintenance of Certification requirements. In the Proposed Rule in 84 FR 7507, we provided situational examples in section VII.D.5 “Effect on Existing Program Requirements and Processes” 
                        <PRTPAGE P="25785"/>
                        regarding ONC direct review and the role of an ONC-ACB. As finalized in the EOA final rule and per § 170.580(a)(3)(v), we stressed that 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 (81 FR 72427 and 72428).
                    </P>
                    <P>We did not receive comments on this specific aspect of the proposed rule and have finalized the relationship with ONC-ACBs and ONC-ATLs in § 170.580(a)(3) as proposed.</P>
                    <HD SOURCE="HD3">c. Records Access</HD>
                    <P>
                        We proposed in 84 FR 7504 to revise § 170.580(b)(3) to ensure that ONC, or third parties acting on its behalf, have access to the information necessary to enforce the Conditions and Maintenance of Certification requirements. As specified in § 170.580(b)(1)(ii)(A)(
                        <E T="03">2</E>
                        ), (b)(2)(ii)(A)(
                        <E T="03">2</E>
                        ) and (b)(3), in response to a notice of potential non-conformity or notice of non-conformity, ONC must be granted access to, and have the ability to share within HHS, with other Federal agencies, and with appropriate entities, all of a health IT developers' records and technology related to the development, testing, certification, implementation, maintenance, and use of its certified health IT, and any complaint records related to the certified health IT. “Complaint records” include, but are not limited to issue logs and help desk tickets (81 FR 72431). We proposed in 84 FR 7504 to supplement these requirements with a requirement that a health IT developer make available to ONC, and third parties acting on its behalf, records related to marketing and distribution, communications, contracts, and any other information relevant to compliance with any of the Conditions and Maintenance of Certification requirements or other Program requirements. If ONC determined that a health IT developer was not cooperative with the fact-finding process, we proposed ONC would have the ability to issue a certification ban and/or terminate a certificate (see § 170.581 discussed below and § 170.580(f)(1)(iii)(A)(
                        <E T="03">1</E>
                        )).
                    </P>
                    <P>We proposed in 84 FR 7504 that ONC would implement appropriate safeguards to ensure, to the extent permissible with Federal law, that any proprietary business information or trade secrets ONC may encounter by accessing the health IT developer's records, other information, or technology, would be kept confidential by ONC or any third parties working on behalf of ONC.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment recommending that ONC detail the procedural and technical safeguards in place to protect information submitted to ONC by a developer as part of direct review of compliance with a Conditions or Maintenance of Certification requirement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As we stated above, in the Proposed Rule, and in the EOA final rule (81 FR 72429), we will implement appropriate safeguards to ensure, to the extent permissible with Federal law, that any proprietary business information or trade secrets ONC may encounter by accessing the health IT developer's records, other information, or technology, will be kept confidential by ONC or any third parties working on behalf of ONC. We have finalized in § 170.580(b)(3) our approach regarding records access as proposed. Additionally, we have finalized our recommendation, stated in 84 FR 7504 in the Proposed Rule and the EOA final rule, that health IT developers clearly mark, as described in HHS Freedom of Information Act regulations at 45 CFR 5.65(c), any information they regard as trade secret or confidential prior to disclosing the information to ONC (81 FR 72431).
                    </P>
                    <HD SOURCE="HD3">d. Corrective Action</HD>
                    <P>
                        We proposed in 84 FR 7504 that if ONC determines that a health IT developer is noncompliant with a Condition or Maintenance of Certification requirement (
                        <E T="03">i.e.,</E>
                         a non-conformity), ONC would work with the health IT developer to establish a corrective action plan (CAP) to remedy the issue through the processes specified in § 170.580(b)(2)(ii)(A)(
                        <E T="03">4</E>
                        ) and (c). We noted that a health IT developer may be in noncompliance with more than one Condition or Maintenance of Certification requirement. In such cases, we proposed that ONC would follow the proposed compliance enforcement process for each Condition or Maintenance of Certification requirement accordingly, but may also require the health IT developer to address all violations in one CAP for efficiency of process. We also proposed, as we currently do with CAPs for certified health IT, to list health IT developers under a CAP on ONC's website.
                    </P>
                    <P>We did not receive any comments on this aspect of the Proposed Rule, and in § 170.580(c) we have finalized our proposals regarding corrective action as proposed (84 FR 7504).</P>
                    <HD SOURCE="HD3">e. Certification Ban and Termination</HD>
                    <P>We proposed in 84 FR 7504 that if a health IT developer under ONC direct review for noncompliance with a Condition or Maintenance of Certification requirement failed to work with ONC or was otherwise noncompliant with the requirements of the CAP and/or CAP process, ONC could issue a certification ban for the health IT developer (and its subsidiaries and successors). A certification ban, as it currently does for other matters under § 170.581, would prohibit future health IT by the health IT developer from being certified.</P>
                    <P>We proposed in 84 FR 7504 that ONC would also consider termination of the certificate(s) of the affected Health IT Module(s) should the health IT developer fail to work with ONC or is otherwise noncompliant with the requirements of the CAP and/or CAP process. We proposed that ONC may consider termination if there is a nexus between the developer's actions or business practices in relation to the Conditions and Maintenance of Certification requirements and the functionality of the affected certified Health IT Module(s). For example, as discussed in the Proposed Rule, ONC may determine that a health IT developer is violating a Condition of Certification requirement due to a clause in its contracts that prevents its users from sharing or discussing technological impediments to information exchange. In this example, the health IT developer's conduct would violate the Communications Condition of Certification requirement that we have finalized in § 170.403. If the same conduct were also found to impair the functionality of the certified Health IT Module (such as by preventing the proper use of certified capabilities for the exchange of EHI), ONC may determine that a nexus exists between the developer's business practices and the functionality of the certified Health IT Module, and may consider termination of the certificate(s) of that particular Health IT Module under the proposed approach.</P>
                    <P>
                        We proposed this approach, which allows ONC to initiate a certification ban and/or certificate termination under certain circumstances, to ensure that health IT developers are acting in accordance with the Conditions and Maintenance of Certification requirements. However, we stressed that our first and foremost priority is to work with health IT developers to remedy any noncompliance with Conditions and Maintenance of Certification requirements through a corrective action process before taking further action. This emphasizes ONC's desire to promote and support health IT developer compliance with the 
                        <PRTPAGE P="25786"/>
                        Conditions and Maintenance of Certification requirements, and ensure that certified health IT is compliant with Program requirements, in order to foster an environment where EHI is exchanged in an interoperable way.
                    </P>
                    <P>We proposed in 84 FR 7505 that in considering whether termination of a Health IT Module's certificate(s) and/or a certification ban is appropriate, ONC would consider factors including, but not limited to: Whether the health IT developer has previously been found in noncompliance with the Conditions and Maintenance of Certification or other Program requirements; the severity and pervasiveness of the noncompliance, including the effect of the noncompliance on widespread interoperability and health information exchange; the extent to which the health IT developer cooperates with ONC to review the noncompliance; the extent of potential negative impact on providers who may seek to use the certified health IT to participate in CMS programs; and whether termination and/or a certification ban is necessary to ensure the integrity of the certification process.</P>
                    <P>
                        In the Proposed Rule, we noted in 84 FR 7505 that, as found in § 170.580(f)(2), ONC would provide notice of the termination to the health IT developer, including providing an explanation for, information supporting, and consequences of, the termination, as well as instructions for appealing the termination. We proposed to add substantially similar notice provisions to § 170.581 for certification bans issued under ONC direct review for noncompliance with the Conditions and Maintenance of Certification requirements. These provisions would also include instructions for requesting reinstatement. In this regard, in 84 FR 7505 we proposed to apply the current reinstatement procedures under § 170.581 to certification bans resulting from noncompliance with the Conditions and Maintenance of Certification requirements, but with an additional requirement that the health IT developer has resolved the noncompliance with the Condition or Maintenance of Certification requirement. In sum, we proposed that a health IT developer could seek ONC's approval to re-enter the Program and have the certification ban lifted if it demonstrates that it has resolved the noncompliance with the Condition or Maintenance of Certification requirement, and ONC is satisfied that all affected customers have been provided appropriate remediation. We sought comment on whether ONC should impose a minimum time period for a certification ban, such as when a health IT developer is noncompliant with a Condition or Maintenance of Certification requirement more than once (
                        <E T="03">e.g.,</E>
                         a minimum six months for two instances, a minimum of one year for three instances). We also sought comment on whether additional factors should be considered for a certification ban and/or termination of a health IT developer's certified health IT.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments regarding a minimum ban length for repeat offenders. A couple of the commenters recommended ONC establish a minimum ban and agreed with ONC's examples listed above. Other commenters stated that a minimum ban would not be appropriate, with one commenter stating that a minimum ban could have unintended consequences and another commenter stating that it would be better if the length of the ban was determined situationally.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the provisions regarding termination and certification ban in §§ 170.580 and 170.581 as proposed. We have not established a minimum ban length for repeat offenders, as a reinstatement process has been established in § 170.581(d) that affords ONC the discretion to determine whether a developer has demonstrated appropriate remediation to all customers affected by the certificate termination, certificate withdrawal, or noncompliance with a Condition or Maintenance of Certification requirement. Section 170.581(d)(4) allows ONC to grant reinstatement into the Program if ONC is satisfied with a health IT developer's demonstration of appropriate remediation, and ONC may consider any and all factors, including past bans, that may affect ONC's decision to grant reinstatement into the Program.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments expressing concern for how physicians using products whose developer has been banned would be impacted with respect to payment programs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and clarify that the health IT products of a health IT developer under a certification ban (not certificate termination) would still be considered certified. This means that those products would still be available for use by providers participating in programs requiring the use of certified health IT. However, while under a ban, a health IT developer could not make updates to the certification of those products. This means that access to new certified functionalities within a health IT developer's products would be limited. If the certification status of a product may impact health care providers that are users of that product for HHS program participation, ONC would continue to support HHS and other Federal and State partners, such as CMS, to help identify and make available appropriate remedies for users of terminated certified health IT. This would include supporting policies to mitigate negative impacts on providers, such as the availability of hardship exceptions for the Promoting Interoperability (PI) Programs for hospitals as mandated by section 4002(b)(1)(A) and (b)(2) of the 21st Century Cures Act and finalized by CMS in the FY 2018 Inpatient Prospective Payment System final rule (80 FR 38488 through 38490).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment that ONC should add a fine as part of the enforcement of the Conditions and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment, but ONC does not have the authority to add a monetary fine as part of the enforcement of the Conditions and Maintenance of Certification requirements. We note, however, that health IT developers are subject to civil monetary penalties (CMPs) if they engage in information blocking, and that a health IT developer must not take any action that constitutes information blocking as a Condition of Certification requirement (§ 170.401).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that certification bans apply not only to health IT developers who are noncompliant, but also to the individual management representatives involved, and that account migration review plans be required as an aspect of enforcement in order to address issues around creation of new legal entities in response to a certification ban.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and note that certification bans affect health IT developers participating in the Program, their subsidiaries, and their successors (81 FR 72443). We do not have the authority to regulate or enforce against individual management representatives, though we believe the certification ban's reach is an appropriate and sufficient incentive for health IT developers to resolve any noncompliance and meet all required conditions. As stated previously, we are utilizing processes previously established for ONC direct review of certified health IT for the enforcement of the Conditions and Maintenance of Certification requirements, which we believe are familiar to health IT developers and provide a transparent process for working with health IT 
                        <PRTPAGE P="25787"/>
                        developers to remedy instances of noncompliance.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern that there is no process for measuring the severity of a finding of noncompliance, and ONC's proposed enforcement approach would allow for banning of all of a health IT developer's certified health IT based on a finding of noncompliance. The commenter requested that the final rule specify circumstances that could lead to this serious result.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment and clarify that, as proposed, if a health IT developer under ONC direct review for noncompliance with a Condition of Certification requirement failed to work with ONC to correct the noncompliance, or was noncompliant with the requirements of the CAP, ONC could issue a certification ban. However, we stress that our priority is to first work with health IT developers to correct any noncompliance with the Conditions and Maintenance of Certification requirements through corrective action. As stated in the Proposed Rule in 84 FR 7505, factors we would consider prior to issuing a certification ban, or termination of a Health IT Module's certificate, include whether the health IT developer has previously been found in noncompliance with the Conditions and Maintenance of Certification requirements or other Program requirements; the severity and pervasiveness of the noncompliance; cooperation on the part of the health IT developer during ONC review; potential negative impact on providers participating in CMS programs; and whether termination and/or a certification ban is necessary to ensure the integrity of the certification process.
                    </P>
                    <P>We clarify that while under a CAP or surveillance by ONC or an ONC-ACB, in the event a health IT developer's approach to remedy a non-conformity and/or to meet Program requirements is to withdraw their current certificate(s) for replacement with a new certificate issued by the ONC-ACB to reflect a new scope, they will not be subject to a certification ban. We note that any open non-conformities will be transferred to the newly issued certificate(s) and must still be resolved by the health IT developer. Similarly, when an ONC-ACB issues a new certificate to reflect 2015 Edition changes, and must withdraw a health IT developer's current certificate to do so, the health IT developer will not be subject to a certification ban if the developer is currently under a CAP or has health IT with open non-conformities.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that in instances of information blocking, the termination of a Health IT Module's certificate or issuance of a certification ban should not occur until the health IT developer has had the opportunity to respond to the charge of information blocking and appeal the finding.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As stated previously, we have finalized in §§ 170.580 and 170.581 our proposed approach to utilize the processes previously established for ONC direct review of certified health IT for the enforcement of the Conditions and Maintenance of Certification requirements. These processes are open and transparent, and they provide an opportunity for health IT developers to remedy instances of noncompliance through corrective action. We again stress that it is our priority to first work with health IT developers to correct any noncompliance with the Conditions and Maintenance of Certification requirements through corrective action. We believe these processes provide ample opportunity for a health IT developer to respond to and address information blocking prior to issuance of a certification ban or termination of a Health IT Module's certificate.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment stating that the final rule should provide for an emergency remedy when the blocking of information places an individual at risk of immediate harm.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Our current process for direct review enables ONC to respond appropriately in the case of certified health IT that may be causing or contributing to conditions that present a serious risk to public health or safety (§§ 170.580(a)(2)(i) and 170.580(d)(1)). We also refer readers to the information blocking section in this final rule (section VIII of preamble and Part 171) for a detailed discussion regarding the information blocking provision and the exceptions to the information blocking definition, including those designed to prevent harm to patients and others.
                    </P>
                    <HD SOURCE="HD3">f. Appeal</HD>
                    <P>We proposed in 84 FR 7505 that a health IT developer would have an opportunity to appeal an ONC determination to issue a certification ban and/or certificate termination resulting from noncompliance with a Condition or Maintenance of Certification requirement. We proposed to follow the processes specified in § 170.580(g). As such, we proposed to revise § 170.580(g) to incorporate ONC direct review of compliance with the Conditions and Maintenance of Certification requirements.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a number of comments generally supporting our proposal to utilize the Appeals processes in our enforcement of compliance with the Condition or Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments expressing support for our proposal and have finalized our proposal and proposed revisions to § 170.580(g) to incorporate ONC direct review of compliance with the Conditions and Maintenance of Certification requirements.
                    </P>
                    <HD SOURCE="HD3">g. Suspension</HD>
                    <P>
                        We proposed in 84 FR 7506 to not apply the suspension processes under § 170.580 to our review of compliance with the Conditions and Maintenance of Certification requirements. Section 170.580 includes a process for suspending the certification of a Health IT Module at any time if ONC has a reasonable belief that the certified health IT may present a serious risk to public health and safety. While this will remain the case for certified health IT under ONC direct review (
                        <E T="03">i.e.,</E>
                         suspension of certification is always available under ONC direct review when the certified health IT presents a serious risk to public health and safety), we do not believe such circumstances would apply to noncompliance with the Conditions or Maintenance of Certification requirements. Further, we believe the more streamlined processes proposed for addressing noncompliance with Conditions and Maintenance of Certification requirements alleviates the need to proceed through a suspension process.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a number of comments generally supporting our proposal not to include Suspension in our enforcement of compliance with the Condition or Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments expressing support for our proposal and have finalized our proposal as proposed.
                    </P>
                    <HD SOURCE="HD3">h. Proposed Termination</HD>
                    <P>
                        We proposed in 84 FR 7506 to not include an intermediate step between a developer failing to take appropriate and timely corrective action and termination of a certified Health IT Module's certificate called “proposed termination” (
                        <E T="03">see</E>
                         § 170.580(e) and 81 FR 72437)). Rather, as discussed above, ONC may proceed directly to issuing a certification ban or notice of termination if it determines a certification ban and/or certificate termination are appropriate per the considerations 
                        <PRTPAGE P="25788"/>
                        discussed above. The Conditions and Maintenance of Certification requirements focus on developer business practices and actions for which, as previously discussed, noncompliance is likely to undermine the integrity of the Program and impede widespread interoperability and information exchange. As such, we stated that it is appropriate and consistent with the Cures Act to proceed immediately to a certification ban and/or termination of the affected Health IT Module's certificate(s) if a developer does not take appropriate and timely corrective action. A certification ban and/or termination serves as an appropriate disincentive for noncompliance with the Conditions and Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a number of comments generally supporting our proposal not to include Proposed Termination in our enforcement of compliance with the Condition or Maintenance of Certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments expressing support for our proposal and have finalized our proposal as proposed.
                    </P>
                    <HD SOURCE="HD3">4. Public Listing of Certification Ban and Termination</HD>
                    <P>We proposed in 84 FR 7506 to publicly list on ONC's website health IT developers and certified Health IT Modules that are subject to a certification ban and/or have been terminated, respectively, for noncompliance with a Condition or Maintenance of Certification requirement or for reasons already specified in § 170.581. We take this same approach for health IT with terminated certifications (see 81 FR 72438). Public listing serves to discourage noncompliance with Conditions and Maintenance of Certification and other Program requirements, while encouraging cooperation with ONC and ONC-ACBs and remediation of non-conformities. It also serves to provide notice to all ONC-ATLs, ONC-ACBs, public and private programs requiring the use of certified health IT, and consumers of certified health IT of the status of certified health IT and health IT developers operating under the Program. We sought comment on this proposal, including input on the appropriate period of time to list health IT developers and affected certified Health IT Modules on healthit.gov.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several recommendations that we should enable indefinite posting of certification bans and certificate terminations, including a comment recommending that the public listing show the start and end date of bans that were lifted. We also received one comment recommending that ONC differentiate reinstated developers on the public listing. We also received one comment that there should be an option for a ban to be lifted once the developer comes into compliance.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Responsive to comments and in order to support transparency, we have decided not to set a time limit for listings on the Certified Health IT Product List (CHPL) and to also provide the start and end dates of bans that were lifted. We clarify that the CHPL provides transparency regarding certified health IT listings, including historical non-conformities assessed through surveillance, even after the non-conformity is resolved. This approach to historical transparency is applied to certification bans as well. We also clarify that a certification ban can be lifted as long as the developer has resolved the noncompliance and met all required conditions. We refer readers to § 170.581 for details about the certification ban and reinstatement processes.
                    </P>
                    <HD SOURCE="HD3">5. Effect on Existing Program Requirements and Processes</HD>
                    <P>
                        The Cures Act introduced new Conditions and Maintenance of Certification requirements that encompass technical and functional requirements of health IT and new actions and business practice requirements for health IT developers, which we proposed to adopt in subpart D of Part 170. The pre-Cures Act structure and requirements of the Program provide processes to enforce compliance with technical and functional requirements of certified health IT, and to a more limited extent, requirements for the business practices of health IT developers (
                        <E T="03">see, e.g.,</E>
                         45 CFR 170.523(k)(1)) under subparts C (Certification Criteria for Health Information Technology) and E (ONC Health IT Certification Program) of Part 170. ONC-ACBs are required to perform surveillance on certified Health IT Modules and may investigate reported allegations of non-conformities with Program requirements under subparts A, B, C, and E, with the ultimate goal of working with the health IT developer to correct the non-conformity. Under certain circumstances, such as unsafe conditions or impediments to ONC-ACB oversight, ONC may directly review certified health IT to determine whether it conforms to the requirements of the Program (
                        <E T="03">see</E>
                         § 170.580 and the EOA final rule at 81 FR 72404). These avenues for investigating non-conformities with certified Health IT Modules will continue to exist under the Program and generally focus on functionality and performance of certified health IT, or on more limited requirements of business practices of health IT developers found in subparts A, B, C and E of Part 170, respectively. Thus, there may be instances where one or more Condition or Maintenance of Certification requirement is not being or has not been met that also relate to certified Health IT Module non-conformities under subparts A, B, C and E. We proposed that under these situations, ONC could in parallel implement both sets of processes—existing processes to investigate Health IT Module non-conformities and the proposed process to enforce compliance with the Conditions and Maintenance of Certification requirements. We stressed, however, that under the proposed enforcement approach, only ONC would have the ability to determine whether a Condition or Maintenance of Certification requirement per subpart D has been or is being met.
                    </P>
                    <P>We proposed to delineate the scope of an ONC-ACB's requirements to perform surveillance on certified Health IT Modules as related only to the requirements of subparts A, B, C and E of Part 170. Given our proposed approach that would authorize solely ONC to determine whether a Conditions or Maintenance of Certification requirement per subpart D has been or is being met, we proposed in 84 FR 7506 to add a new PoPC for ONC-ACBs in § 170.523(s) that would require ONC-ACBs to report to ONC, no later than a week after becoming aware, any information that could inform whether ONC should exercise direct review for noncompliance with a Condition or Maintenance of Certification requirement or any matter within the scope of ONC direct review. We did not receive specific comments on this section of the Proposed Rule and have finalized this approach regarding delineation of the review activities of ONC and ONC-ACBs in §§ 170.580 and 170.581 as proposed.</P>
                    <HD SOURCE="HD3">6. Coordination With the Office of the Inspector General</HD>
                    <P>
                        We clarified in the Proposed Rule in 84 FR 7507 that the enforcement approach would apply only to ONC's administration of the Conditions and Maintenance of Certification requirements and other requirements under the Program, but it would not apply to other agencies or offices that have independent authority to investigate and take enforcement action 
                        <PRTPAGE P="25789"/>
                        against a health IT developer of certified health IT. Notably, section 3022(b)(1)(A)(ii) of the PHSA, as added by the Cures Act, authorizes the OIG to investigate claims that a health IT developer of certified health IT has engaged in information blocking, which is defined by section 3022(a)(1) of the PHSA as subject to reasonable and necessary activities identified by the Secretary as exceptions to the definition as proposed in part 171 (see section VIII.D of this final rule). Additionally, section 3022(b)(1)(A)(i) authorizes OIG to investigate claims that a health IT developer of certified health IT has submitted a false attestation under the Condition of Certification requirement which is described at section 3001(c)(5)(D)(vi) of the Cures Act. We emphasized that ONC's and OIG's respective authorities under the Cures Act (and in general) are independent and that either or both offices may exercise those authorities at any time.
                    </P>
                    <P>We noted, however, that ONC and OIG may coordinate their respective information blocking activities, as appropriate, such as by sharing information about claims or suggestions of possible information blocking or false attestations (including violations of Conditions and Maintenance of Certification requirements that may indicate that a developer has falsely attested to meeting a Condition or Maintenance of Certification requirement). Therefore, we proposed in 84 FR 7507 that we may coordinate our review of a claim of information blocking with OIG or defer to OIG to lead a review of a claim of information blocking. In addition, we proposed that we may rely on OIG's findings to form the basis of a direct review action.</P>
                    <P>
                        <E T="03">Comments.</E>
                         The majority of comments received supported the general enforcement approach proposed by ONC. We did receive one comment recommending that we use a process similar to OCR's enforcement of the HIPAA Rules and centralize enforcement of patient and provider rights with respect to privacy and access to EHI. Additionally, we received several comments seeking clarification regarding ONC's coordination with OIG and one expressing concern about the potential for a developer to be under review by both OIG and ONC for the same conduct.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We welcome the many comments in support of our proposed enforcement approach. We also appreciate the comment regarding using processes similar to OCR and centralizing enforcement of privacy and access rights. We agree that it is crucial that we develop clear processes for reporting and investigating claims of potential information blocking. To that end, ONC and OIG are actively coordinating on establishing referral policies and procedures to ensure the timely and appropriate flow of information related to information blocking complaints. We also note that the information blocking section of this final rule (part 171) has a delayed compliance date of 6 months after date of publication of the final rule.
                    </P>
                    <P>OIG and ONC are also coordinating timing of the effective date of this final rule and the start of information blocking enforcement and enforcement of the Conditions of Certification related to information blocking (§ 170.401, § 170.404(a)(1), and § 170.406(a)(1)). We are providing the following information on timing for actors regulated by the information blocking provision. Enforcement of information blocking civil monetary penalties (CMP) in section 3022(b)(2)(A) of the PHSA will not begin until established by future notice and comment rulemaking by OIG. As a result, actors would not be subject to penalties until CMP rules are final. At a minimum, the timeframe for enforcement would not begin sooner than the compliance date of the information blocking provision and will depend on when the CMP rules are final. Discretion will be exercised such that conduct that occurs before that time will not be subject to the information blocking CMPs. Individuals and entities are subject to the information blocking regulations and must comply with this rule as of the compliance date of this provision.</P>
                    <P>The Cures Act directs the National Coordinator to implement a standardized process for the public to submit reports on claims of health information blocking. ONC intends to implement and evolve this complaint process by building on existing mechanisms, including the current ONC complaint process. We requested comment in the Proposed Rule on ways to adapt our current complaint process for claims of information blocking and refer readers to section VIII.F of this final rule for a more detailed discussion of the complaint process for claims of information blocking. OIG also has the ability to receive and review complaints directly from the public. This ensures that there is no “wrong door” by which a complainant can submit information. OIG will provide training to allow their investigators to identify information blocking allegations as part of their other fraud and abuse investigations. Additionally, as part of their continued efforts to implement the information blocking authorities, OIG will establish policies and procedures for reviewing and triaging complaints. We will continue to work with OIG to establish coordinated and aligned procedures and reviews of information blocking complaints as envisioned by the Cures Act. We also emphasize that in order to promote effective enforcement, the information blocking provision of the Cures Act empowers OIG to investigate claims of information blocking and provides referral processes to facilitate coordination with other relevant agencies, including ONC, OCR, and the Federal Trade Commission (FTC). Future notice and comment rulemaking by OIG will provide more additional detail regarding information blocking enforcement.</P>
                    <P>We clarify that there could be situations when a health IT developer of certified health IT's practices could be reviewed by both ONC and OIG because ONC and OIG have separate and distinct enforcement authority regarding claims of information blocking. We explained in the Proposed Rule that ONC has statutory authority to enforce the Information Blocking Condition and Maintenance of Certification requirements (§ 170.401) and that ONC would enforce the Conditions of Certification requirements through the direct review process. OIG has investigatory authority for the information blocking provision (42 U.S.C. 300jj-52(b)), which may lead to the issuance of (CMPs) for information blocking conducted by health IT developers of certified health IT, health information networks, and health information exchanges. OIG may also investigate health care providers for information blocking, which could result in health care providers being subject to appropriate disincentives. In addition, OIG may investigate false attestations by health IT developers participating in the Program. Since ONC's and OIG's respective authorities with regard to information blocking under the Cures Act (and in general) are independent, it is necessary that either or both offices may exercise those authorities at any time.</P>
                    <P>
                        However, we emphasize, as we explained above in the Proposed Rule, that we anticipate that ONC and OIG will coordinate their respective information blocking activities, as appropriate, such as by sharing information about claims or suggestions of possible information blocking or false attestations (including violations of Conditions and Maintenance of Certification requirements that may indicate that a developer has falsely attested to meeting a Condition or Maintenance of Certification 
                        <PRTPAGE P="25790"/>
                        requirement). Therefore, we have finalized in § 170.580(a)(4) the proposed approach that will allow us to coordinate our review of a claim of information blocking with the OIG, or defer to OIG to lead a review of a claim of information blocking. In addition, the finalized approach will allow ONC to rely on OIG findings to form the basis of a direct review action.
                    </P>
                    <HD SOURCE="HD3">7. Applicability of Conditions and Maintenance of Certification Requirements for Self-Developers</HD>
                    <P>The HHS regulation that established the Program, “Establishment of the Permanent Certification Program for Health Information Technology” (76 FR 1261), addresses self-developers and describes the concept of “self-developed” as referring to a Complete EHR or EHR Health IT Module designed, created, or modified by an entity that assumed the total costs for testing and certification and that will be the primary user of the health IT (76 FR 1300 and 1301). While we proposed in 84 FR 7508 in the “Enforcement” section of the Proposed Rule that all general Conditions and Maintenance of Certification requirements apply to such developers, we also sought comment on which aspects of the Conditions and Maintenance of Certification requirements may not be applicable to self-developers.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received one comment that self-developers should not be permitted to rely on the exception available under the “Communications” Condition of Certification requirement that allows developers to place limited restrictions on the communications of their employees who are using their products.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the comment that self-developers should not be allowed to restrict the communications of users of their product who are also employees. We have revised the language of the “Communications” Condition of Certification requirement in § 170.403(a)(2)(ii)(A)(
                        <E T="03">2</E>
                        ) to clarify that the limited prohibitions developers may place on employees under the Condition of Certification requirement cannot be placed on users of the developers' products who also happen to be employees or contractors of the developer. Overall, we intend to hold self-developers to all Conditions and Maintenance of Certification requirements of health IT developers, as applicable based on the health IT certified.
                    </P>
                    <HD SOURCE="HD1">VIII. Information Blocking</HD>
                    <HD SOURCE="HD2">A. Statutory Basis</HD>
                    <P>Section 4004 of the Cures Act added section 3022 of the Public Health Service Act (PHSA) (42 U.S.C. 300jj-52, “the information blocking provision”). Section 3022(a)(1) of the PHSA defines practices that constitute information blocking when engaged in by a health care provider, or a health information technology developer, exchange, or network. Section 3022(a)(3) authorizes the Secretary to identify, through notice and comment rulemaking, reasonable and necessary activities that do not constitute information blocking for purposes of the definition set forth in section 3022(a)(1). We proposed in the Proposed Rule to establish exceptions to the information blocking definition, each of which would define certain activities that would not constitute information blocking for purposes of section 3022(a)(1) of the PHSA because they are reasonable and necessary to further the ultimate policy goals of the information blocking provision. We also proposed to interpret or define certain statutory terms and concepts that are ambiguous, incomplete, or provide the Secretary with discretion, and that we believe are necessary to carry out the Secretary's rulemaking responsibilities under section 3022(a)(3) (84 FR 7522).</P>
                    <HD SOURCE="HD2">B. Legislative Background and Policy Considerations</HD>
                    <P>In the Proposed Rule, we outlined the purpose of the information blocking provision and related policy and practical considerations that we considered in identifying the reasonable and necessary activities that we proposed as exceptions to the information blocking definition (84 FR 7508).</P>
                    <HD SOURCE="HD3">1. Purpose of the Information Blocking Provision</HD>
                    <P>We explained in the Proposed Rule that the information blocking provision was enacted in response to concerns that some individuals and entities are engaging in practices that unreasonably limit the availability and use of electronic health information (EHI) for authorized and permitted purposes. These practices undermine public and private sector investments in the nation's health IT infrastructure, and frustrate efforts to use modern technologies to improve health care quality and efficiency, accelerate research and innovation, and provide greater value and choice to health care consumers (84 FR 7508).</P>
                    <P>
                        We emphasized that the nature and extent of information blocking has come into sharp focus in recent years. In 2015, at the request of Congress, we submitted a Report on Health Information Blocking 
                        <SU>117</SU>
                        <FTREF/>
                         (“Information Blocking Congressional Report”), in which we commented on the then-current state of technology and of health IT and health care markets. Notably, we observed that prevailing market conditions create incentives for some individuals and entities to exercise control over EHI in ways that limit its availability and use (84 FR 7508).
                    </P>
                    <FTNT>
                        <P>
                            <SU>117</SU>
                             ONC, Report to Congress on Health Information Blocking (Apr. 2015), 
                            <E T="03">https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf</E>
                             [hereinafter “Information Blocking Congressional Report”].
                        </P>
                    </FTNT>
                    <P>We noted that we have continued to receive complaints and reports of information blocking from patients, clinicians, health care executives, payers, app developers and other technology companies, registries and health information exchanges, professional and trade associations, and many other stakeholders. We noted that ONC has listened to and reviewed these complaints and reports, consulted with stakeholders, and solicited input from our Federal partners in order to inform our proposed information blocking policies. Stakeholders described discriminatory pricing policies that have the obvious purpose and effect of excluding competitors from the use of interoperability elements. Many industry stakeholders who shared their perspectives with us in listening sessions, including several health IT developers of certified health IT, condemned these practices and urged us to swiftly address them. We highlighted that our engagement with stakeholders confirmed that, despite significant public and private sector efforts to improve interoperability and data accessibility, adverse incentives remain and continue to undermine progress toward a more connected health system (84 FR 7508).</P>
                    <P>Based on these economic realities and our first-hand experience working with the health IT industry and stakeholders, in the Information Blocking Congressional Report, we concluded that information blocking is a serious problem, and recommended that Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices (84 FR 7508).</P>
                    <P>
                        We noted in the Proposed Rule that recent empirical and economic research further underscores the intractability of this problem and its harmful effects. In a national survey of health information organizations, half of respondents reported that EHR developers routinely 
                        <PRTPAGE P="25791"/>
                        engage in information blocking, and a quarter of respondents reported that hospitals and health systems routinely do so. The survey reported that perceived motivations for such conduct included, for EHR vendors, maximizing short-term revenue and competing for new clients, and for hospitals and health systems, strengthening their competitive position relative to other hospitals and health systems.
                        <SU>118</SU>
                        <FTREF/>
                         We noted that other research suggests that these practices weaken competition among health care providers by limiting patient mobility, encouraging consolidation, and creating barriers to entry for developers of new and innovative applications (also referred to as “apps”) and technologies that enable more effective uses of clinical data to improve population health and the patient experience 
                        <SU>119</SU>
                        <FTREF/>
                         (84 FR 7508).
                    </P>
                    <FTNT>
                        <P>
                            <SU>118</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Julia Adler-Milstein and Eric Pfeifer, 
                            <E T="03">Information Blocking: Is It Occurring And What Policy Strategies Can Address It?,</E>
                             95 Milbank Quarterly 117, 124-25 (Mar. 2017), 
                            <E T="03">available at</E>
                              
                            <E T="03">http://onlinelibrary.wiley.com/doi/10.1111/1468-0009.12247/full</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>119</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Martin Gaynor, Farzad Mostashari, and Paul B. Ginsburg, 
                            <E T="03">Making Health Care Markets Work: Competition Policy for Health Care,</E>
                             16-17 (Apr. 2017), 
                            <E T="03">available at</E>
                              
                            <E T="03">&gt;https://www.brookings.edu/research/making-health-care-markets-work-competition-policy-for-health-care/</E>
                            ; Diego A. Martinez et al., 
                            <E T="03">A Strategic Gaming Model For Health Information Exchange Markets,</E>
                             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, 
                            <E T="03">A Sustainable Business Model for Health Information Exchange Platforms: The Solution to Interoperability in Healthcare IT</E>
                             (2015), 
                            <E T="03">available at</E>
                              
                            <E T="03">http://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-</E>
                             exchange-yaraghi; Thomas C. Tsai &amp; Ashish K. Jha, 
                            <E T="03">Hospital Consolidation, Competition, and Quality: Is Bigger Necessarily Better?,</E>
                             312 J. AM. MED. ASSOC. 29, 29 (2014).
                        </P>
                    </FTNT>
                    <P>We explained in the Proposed Rule that the information blocking provision provides a comprehensive response to these concerns. The information blocking provision defines and creates possible penalties and disincentives for information blocking in broad terms, while working to deter the entire spectrum of practices that unnecessarily impede the flow of EHI or its use to improve health and the delivery of care. The information blocking provision applies to the conduct of health care providers and health IT developers, exchanges, and networks, and seeks to deter information blocking through civil monetary penalties and disincentives for violations. Additionally, developers of health IT certified under the Program are prohibited from information blocking under 3001(c)(5)(D)(i) of the PHSA (84 FR 7509).</P>
                    <P>The information blocking provision authorizes the HHS Office of Inspector General (OIG) to investigate claims of information blocking and provides for referral processes to facilitate coordination among Federal agencies, including ONC, the HHS Office for Civil Rights (OCR), and the Federal Trade Commission (FTC). The information blocking provision also provides for a process for the public to submit reports on claims of information blocking as well as confidentiality protections to encourage and facilitate the reporting of information blocking. Enforcement of the information blocking provision is buttressed by section 3001(c)(5)(D)(i) and (vi) of the PHSA, which requires the Secretary to establish as a Condition and Maintenance of Certification requirement under the Program that health IT developers do not take any action that constitutes information blocking and require such developers to attest that they have not engaged in such conduct (84 FR 7509).</P>
                    <HD SOURCE="HD3">2. Policy Considerations and Approach to Information Blocking</HD>
                    <P>We explained in the Proposed Rule that the information blocking provision encompasses a broad range of potential practices in order to ensure that individuals and entities that engage in information blocking are held accountable. However, we explained that it is possible that some activities that are innocuous, or even beneficial, could technically implicate the information blocking provision. Given the possibility of these activities, section 3022(a)(3) of the PHSA requires the Secretary, through rulemaking, to identify reasonable and necessary activities that do not constitute information blocking. We refer to such reasonable and necessary activities identified by the Secretary as “exceptions” to the information blocking provision. The information blocking provision also excludes from the definition of information blocking those practices that are required by law (section 3022(a)(1) of the PHSA) and clarifies certain other practices that would either not be considered information blocking or penalized (sections 3022(a)(6) and (7) of the PHSA) (84 FR 7509).</P>
                    <P>In considering potential exceptions to the information blocking provision, we strove to balance a number of policy and practical considerations. To minimize compliance and other burdens for stakeholders, we explained that we were seeking to promote clear, predictable, and administrable policies. In addition, we emphasized our intention to implement the information blocking provision in a way that would be sensitive to legitimate practical challenges that may prevent access to, exchange, or use of EHI in certain situations. We also explained our goal to accommodate practices that, while they may inhibit access, exchange, or use of EHI, are reasonable and necessary to advance other compelling policy interests, such as preventing harm to patients and others, promoting the privacy and security of EHI, and promoting competition and consumer welfare (84 FR 7509).</P>
                    <P>At the same time, we explained that we sought to provide a comprehensive response to the information blocking problem. Information blocking can occur through a variety of business, technical, and organizational practices that can be difficult to detect and that are constantly changing as technology and industry conditions evolve. The statute responds to these challenges by defining information blocking broadly and in a manner that allows for careful consideration of relevant facts and circumstances in individual cases.</P>
                    <P>Accordingly, we proposed in the Proposed Rule to establish certain defined exceptions to the information blocking provision as a way to identify reasonable and necessary activities that do not constitute information blocking as required by section 3022(a)(3) of the PHSA. We proposed that these exceptions would be subject to strict conditions and would apply three overarching policy criteria. First, each exception would be limited to certain activities that are both reasonable and necessary. These reasonable and necessary activities include: Promoting public confidence in the health IT infrastructure by supporting the privacy and security of EHI and protecting patient safety; and promoting competition and innovation in health IT and its use to provide health care services to consumers. Second, we noted that each exception addresses a significant risk that regulated individuals and entities will not engage in these reasonable and necessary activities because of uncertainty regarding the breadth or applicability of the information blocking provision. Third, we explained that each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to protect and does not extend protection to other activities or practices that could raise information blocking concerns (84 FR 7509).</P>
                    <HD SOURCE="HD3">3. General Comments Regarding Information Blocking Exceptions</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters expressed support for the proposed 
                        <PRTPAGE P="25792"/>
                        information blocking exceptions overall. Some commenters stated that information blocking is a widespread problem and perhaps the greatest barrier to interoperability, and supported our approach to addressing information blocking.
                    </P>
                    <P>
                        While most commenters supported our policy goals regarding information blocking, others questioned whether our policies would have detrimental consequences to the industry given the breadth of the definitions, ambiguity of the expectations, and narrowness of the proposed exceptions. Another commenter stated that the proposed information blocking exceptions are too vague and that an alternative approach is necessary to reduce confusion. The commenter stated that we should align the information blocking requirements with the certified capabilities of health IT developers, and that information blocking should be evaluated through the lens of access, exchange, and use of the USCDI. One commenter suggested that our information blocking policies be more patient-focused as offered by the Individual Health Record
                        <E T="51">TM</E>
                         (IHR) Model.
                        <SU>120</SU>
                        <FTREF/>
                         A few commenters requested clarification on how each of the exceptions would be arbitrated, and requested that we provide additional examples of actions that may fall within each exception.
                    </P>
                    <FTNT>
                        <P>
                            <SU>120</SU>
                             The IHR is a digital tool that provides an all-in-one record of an individual's health, enabling a person and their care team to help improve collaboration and care.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support expressed by many commenters. This final rule maintains the general direction of the Proposed Rule regarding information blocking but focuses the scope of certain terms, while also addressing the reasonable and necessary activities that would qualify for an exception under the information blocking provision. As an example, we have focused the scope of the EHI and Health Information Network (HIN) definitions and have included a new exception in this final rule, the Content and Manner Exception (§ 171.301). We appreciate the comment regarding the IHR Model, but have determined that the best approach to support interoperability and the access, exchange, and use of EHI is through the policies finalized in this final rule, which are patient-focused. For instance, the Fees Exception (§ 171.302), which allows certain fees to be charged, does not apply to a fee based in any part on the electronic access (as such term is defined in § 171.302(d)) of an individual's EHI by the individual, their personal representative, or another person or entity designated by the individual. We emphasize that an actor's practice of charging an individual, their personal representative, or another person or entity designated by the individual for electronic access to the individual's EHI would be inherently suspect under an information blocking review.
                    </P>
                    <P>We continue to receive complaints and reports alleging information blocking from a wide range of stakeholders. ONC has listened to and reviewed these complaints and reports, consulted with stakeholders, solicited input from our Federal partners, and reviewed public comments received in response to the Proposed Rule in order to inform our information blocking policies. We look forward to ongoing collaboration with public and private sector partners as we implement the information blocking provision of this final rule. To note, we have provided clarifications and additional examples throughout this final rule.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Numerous commenters expressed concern over the proposed effective date of the information blocking policies. Commenters stated that imposing stringent new mandates with an overly aggressive implementation timeframe could be counterproductive by increasing administrative and financial burdens on physician practices, threatening the security of health information, and potentially compromising patient safety. Several provider organizations requested an enforcement “grace period” after the new information blocking requirements take effect to allow providers sufficient time to understand the requirements and implement new procedures to be compliant before any disincentives would be applied. Specifically, commenters recommended that OIG not take any enforcement action for a period of 18 months or two years after the effective date of the final rule. Several commenters recommended a period of enforcement discretion of no less than five years during which OIG would require corrective action plans instead of imposing penalties for information blocking. One commenter also recommended that we “grandfather” any economic arrangements that exist two years from date of the final rule.
                    </P>
                    <P>We did not receive any comments on the proposed § 171.101, Applicability, which stated that this part applies to health care providers, health IT developers of certified health IT, health information exchanges, and health information networks, as those terms are defined in § 171.102.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. Taking these comments into consideration, we have delayed the compliance date of the information blocking section of this rule (45 CFR part 171). The compliance date for the information blocking section of this final rule will be six months after the publication date of this final rule in the 
                        <E T="04">Federal Register</E>
                        . This six-month delayed compliance date was established to provide actors with time to thoroughly read and understand the final rule and educate their workforce in order to apply the exceptions in an appropriate manner. We also note that the finalized definition of information blocking (§ 171.103)) and the new Content and Manner Exception (§ 171.301(a)) reduce the scope of the EHI definition for the first 18 months after the compliance date of the information blocking section of this final rule to the EHI identified by the data elements represented in the USCDI. Therefore, in addition to the information blocking section's compliance date being six months after publication, actors will have an additional 18 months to gain experience applying the exceptions with just the EHI identified by the data elements represented in the USCDI as compared to the full scope of EHI, which would apply thereafter.
                    </P>
                    <P>
                        During this combined period of 24 months, we strongly encourage actors to apply the exceptions to 
                        <E T="03">all</E>
                         EHI as if the scope were not limited to EHI identified by the data elements represented in the USCDI. However, given the initial scope of EHI identified in the information blocking definition in § 171.103 and the Content and Manner Exception in § 171.103, if an actor did not, in the first 24 months from this final rule's publication date, enable access, exchange, or use of data outside the USCDI, or did not appropriately apply an exception to data outside the USCDI, such practice or error would not be considered information blocking because that data would not be considered “EHI” during that time period.
                    </P>
                    <P>We have also delayed the compliance date of the Information Blocking Condition of Certification requirement in § 170.401 and the Assurances Condition of Certification requirement in § 170.402(a)(1). We also note that under 45 CFR part 171, we have focused the scope of the EHI definition and have revised the seven proposed exceptions in a manner that is clear, actionable, and likely to reduce perceived burden.</P>
                    <P>
                        OIG and ONC are coordinating timing of the compliance date of the information blocking section of this 
                        <PRTPAGE P="25793"/>
                        final rule (45 CFR part 171) and the start of information blocking enforcement. We are providing the following information on timing for actors. Enforcement of information blocking civil monetary penalties (CMP) in section 3022(b)(2)(A) of the PHSA will not begin until established by future notice and comment rulemaking by OIG. As a result, actors would not be subject to penalties until CMP rules are final. At a minimum, the timeframe for enforcement would not begin sooner than the compliance date of the information blocking section of this final rule (45 CFR part 171) and will depend on when the CMP rules are final. Discretion will be exercised such that conduct that occurs before that time will not be subject to information blocking CMP.
                    </P>
                    <P>We have finalized § 171.101 with an additional paragraph to codify the compliance date for the information blocking section of this final rule (45 CFR part 171). Section 171.101(b) states that health care providers, health IT developers of certified health IT, health information exchanges, and health information networks must comply with this part on and after November 2, 2020.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that we develop training and educational materials on the information blocking provision. Commenters specifically stated that we should work with other agencies (including CMS, OIG, FTC and OCR) to develop and widely disseminate comprehensive informational materials, such as sub-regulatory guidance and frequently asked questions about what constitutes information blocking. Some commenters recommended we work with OIG to ensure that enforcement focuses on education rather than penalties against non-malicious information blockers. A few commenters suggested that we offer an opportunity for stakeholders to seek advisory opinions from OIG to clarify what constitutes information blocking, or that we create a formal advisory committee on information blocking. Other commenters requested that heath care providers be provided an opportunity to cure an alleged violation and an opportunity to appeal the alleged violation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback, including their suggestions for establishing a formal advisory committee. While we do not plan to establish an advisory committee, we plan to engage in multiple efforts to educate stakeholders. We intend to provide educational resources such as infographics, fact sheets, webinars, and other forms of educational materials and outreach based on needs identified. We emphasize that the final rule details our information blocking policies, and these educational materials are intended to educate stakeholders on our final policies established in the final rule. We are also actively coordinating with OIG and have provided OIG with comments we received on the Proposed Rule related to information blocking investigations and enforcement. Future notice and comment rulemaking by OIG will provide additional detail regarding information blocking enforcement.
                    </P>
                    <HD SOURCE="HD2">C. Relevant Statutory Terms and Provisions</HD>
                    <P>In the Proposed Rule, we included regulation text to codify the definition of information blocking in § 171.103. We discussed how we proposed to interpret certain aspects of the information blocking provision that we believe are ambiguous, incomplete, or that provided the Secretary with discretion. We proposed to define or interpret certain terms or concepts that are present in the statute and, in a few instances, to establish new regulatory terms or definitions that we believe are necessary to implement the directive in section 3022(a)(3) of the PHSA to identify reasonable and necessary activities that do not constitute information blocking. We explained that our goal in interpreting the statute and defining relevant terms is to provide greater clarity concerning the types of practices that could implicate the information blocking provision and, relatedly, to more effectively communicate the applicability and scope of the exceptions (84 FR 7509).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on the codification of the proposed definition of information blocking in § 171.103.
                    </P>
                    <P>As discussed in more detail in section VIII.C.3, we received many comments expressing concerns regarding the breadth of the proposed EHI definition and requesting flexibility in the implementation of the information blocking provision. Many commenters stated that it would be difficult for actors to provide the full scope of EHI as it was proposed to be defined, particularly as soon as the final rule was published. Some commenters opined that we were trying to do too much too fast. Commenters requested that we provide flexibility for actors to adjust to the scope of the EHI definition, as well as the exceptions. Commenters asserted that such an approach would permit them to adapt their processes, technologies, and systems to enable the access, exchange, and use of EHI as required by the Cures Act and this final rule. Some commenters suggested that EHI under the information blocking provision should be limited to ePHI as defined in 45 CFR 160.103, while others requested that ONC consider constraining the EHI covered by the information blocking provision to only the data included in the USCDI.</P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the proposed definition of information blocking in § 171.103 with the addition of paragraph (b). This new paragraph states that until May 2, 2022—which is 18 months after the 6-month delayed compliance date for part 171 (a total of 24 months after the publication date of this final rule)—EHI for purposes of part 171 is limited to the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) standard adopted in § 170.213. This addition aligns with the content condition within the Content and Manner Exception, which states that for up to May 2, 2022, an actor must respond to a request to access, exchange, or use EHI with, at a minimum, the EHI identified by the data elements represented in the USCDI standard adopted in § 170.213 (see § 171.301(a)(1)).
                    </P>
                    <P>
                        This incremental expansion of the access, exchange, and use of EHI in both the information blocking definition (§ 171.103) and Content and Manner Exception (§ 171.301) responds to commenters' concerns regarding the breadth of health information actors are required to share and the concern about the pace at which we are implementing the information blocking provision. By using USCDI as the baseline of EHI for 18 months after the compliance date of the information blocking section of this final rule (45 CFR part 171),
                        <SU>121</SU>
                        <FTREF/>
                         we have created a transparent, predictable starting point for sharing the types of EHI that is understood by the regulated community and more readily available for access, exchange, and use. In addition, health IT that has been certified to the 2015 Edition “CCDS” certification criteria will be able to immediately and readily produce almost all of the data elements identified in the USCDI. Furthermore, most, if not all, of such health IT already supports recording USCDI data elements and most HIEs/HINs are routinely exchanging such data elements. Further those developers maintaining certification over the 18-month period from the compliance date of the information blocking section of this 
                        <PRTPAGE P="25794"/>
                        final rule (45 CFR part 171) will be in the process of updating their certified health IT to produce all of the data elements specified in the USCDI, including being certified to the new standardized application programming interface (API) criterion (§ 170.315(g)(10)) and API Condition of Certification (§ 170.404).
                    </P>
                    <FTNT>
                        <P>
                            <SU>121</SU>
                             The compliance date for the information blocking section of this final rule (45 CFR part 171) is six months after the publication date of the final rule.
                        </P>
                    </FTNT>
                    <P>We believe the 18-month delay will provide actors with adequate time to prepare for the sharing of all EHI and sunset any non-compliant technology, while providing a clear deadline for when all EHI must be available for access, exchange, and use. During this time period, actors can gain awareness, experience, and comfort with the information blocking provision and exceptions without being required to apply the information blocking exceptions to all EHI as it is defined in § 171.102 (see section VIII.C.3). We expect actors to use this 18-month delay from the compliance date of the information blocking section of this final rule (45 CFR part 171) (in addition to the 6-month period from the publication date of this final rule to the information blocking compliance date) to practice applying the exceptions to real-life situations and to update their processes, technologies, and systems to adapt to the new information blocking requirements. We believe actors will benefit from learning how to respond to requests for all EHI and applying the exceptions during the 18-month delay.</P>
                    <P>Further, this approach will ensure that the application of the information blocking provision is equitable across actors during the 18-month time period. For instance, if we had required actors to respond to a request to access, exchange, or use EHI during this 18-month time period with all EHI that the actor is able to provide, then actors who are able to provide more EHI would carry a heavier burden than actors who were only able to provide the data elements specified in the USCDI. Nonetheless, and as discussed above, we encourage actors to respond to requests for access, exchange, or use of EHI with as much EHI as possible in order to promote interoperability and to practice applying the exceptions.</P>
                    <P>
                        We have included language regarding this incremental expansion of the access, exchange, and use of EHI in 
                        <E T="03">both</E>
                         the information blocking definition (§ 171.103) and Content and Manner Exception (§ 171.301) in order to ensure that the 18-month delay is uniformly applied in the broad circumstances when requestors request access, exchange, or use of EHI as well as in situations when an actor seeks to satisfy the Content and Manner Exception by fulfilling a request to access, exchange, or use EHI in an alternative manner than the manner requested. This approach will ensure that the requisite content to be included in an actor's response to a request to access, exchange, or use EHI during the 18-month period is clear and consistent throughout our information blocking policies.
                    </P>
                    <HD SOURCE="HD3">1. “Required by Law”</HD>
                    <P>With regard to the statute's exclusion of practices that are “required by law” from the definition of information blocking, we emphasized in the Proposed Rule that “required by law” refers specifically to interferences with access, exchange, or use of EHI that are explicitly required by State or Federal law. By carving out practices that are “required by law,” the statute acknowledged that there are laws that advance important policy interests and objectives by restricting access, exchange, and use of EHI, and that practices that follow such laws should not be considered information blocking (84 FR 7509).</P>
                    <P>We noted in the Proposed Rule that for the purpose of developing an exception for reasonable and necessary privacy-protective practices, we distinguished between interferences that are “required by law” and those engaged in pursuant to a privacy law, but which are not “required by law.” (The former does not fall within the definition of information blocking, but the latter may implicate the information blocking provision and an exception may be necessary (84 FR 7510)).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments requesting additional clarity regarding the meaning and scope of “required by law” within the information blocking provision.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the feedback. We clarify that our references to Federal and State law include statutes, regulations, court orders, and binding administrative decisions or settlements, such as (at the Federal level) those from the FTC or the Equal Employment Opportunity Commission (EEOC). We further note that “required by law” would include tribal laws, as applicable. For a detailed discussion of the application of “required by law” in the context of the Privacy Exception, please see section VIII.D.1.b.
                    </P>
                    <HD SOURCE="HD3">2. Health Care Providers, Health IT Developers, Exchanges, and Networks</HD>
                    <P>We explained in the Proposed Rule that section 3022(a)(1) of the PHSA, in defining information blocking, refers to four classes of individuals and entities that may engage in information blocking and which include: Health care providers, health IT developers, networks, and exchanges. We proposed in the Proposed Rule to adopt definitions of these terms to provide clarity regarding the types of individuals and entities to whom the information blocking provision applies (84 FR 7510). We noted that, for convenience and to avoid repetition in the preamble, we typically refer to these individuals and entities covered by the information blocking provision as “actors” unless it is relevant or useful to refer to the specific type of individual or entity. That is, when the term “actor” appears in the preamble, it means a health care provider, health IT developer, health information exchange, or health information network. We proposed to codify this definition of “actor” in § 171.102.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on this general approach to use the term “actors” throughout the rule for clarity or the proposed definition of “actor” in § 171.102. We note that we did receive comments about the definitions of the four categories of actors, which are discussed below.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized this approach and the definition of “actor” in § 171.102 as proposed.
                    </P>
                    <HD SOURCE="HD3">a. Health Care Providers</HD>
                    <P>We identified in the Proposed Rule that the term “health care provider” is defined in section 3000(3) of the PHSA (84 FR 7510). We proposed to adopt this definition for purposes of section 3022 of the PHSA (that is, for purposes of information blocking) when defining “health care provider” in § 171.102. We noted that the PHSA definition is different from the definition of “health care provider” under the HIPAA Rules. We further stated that we were considering adjusting the information blocking definition of “health care provider” to cover all individuals and entities covered by the HIPAA Rules “health care provider” definition in 45 CFR 160.103. We sought comment on whether such an approach would be justified, and encouraged commenters to specify reasons why doing so might be necessary to ensure that the information blocking provision applies to all health care providers that might engage in information blocking.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A significant number of commenters were in favor of using the definition of health care provider used in the HIPAA Rules. However, other commenters asserted that doing so would exceed the scope intended by the Cures Act. Some commenters requested exclusions or a “phased-in” approach 
                        <PRTPAGE P="25795"/>
                        for the requirements for State agencies, institutions, public health departments, ambulatory surgical centers, and other small providers due to their limited resources or limited access to health IT. Other commenters suggested limiting the application of the information blocking provisions only to those health care providers using certified health IT though some commenters also opposed such a limitation. Some commenters suggested including additional categories such as medical device manufacturers and community-based organizations that address social determinants of health (
                        <E T="03">e.g.,</E>
                         access to food, housing, and transportation).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have retained in this final rule the definition of “health care provider” as set forth in section 3000(3) of the PHSA as proposed. The definitions listed in section 3000 of the PHSA apply “[i]n this title,” which refers to Title XXX of the PHSA. Section 3022 of the PHSA is included in Title XXX. We note that the last clause of the health care provider definition in section 3000(3) of the PHSA gives the Secretary discretion to expand the definition to any other category determined to be appropriate by the Secretary. We will consider whether the definition should be expanded in the future if the scope of health care providers subject to the information blocking provision does not appear to be broad enough in practice to ensure that the information blocking provision applies to all health care providers that might engage in information blocking.
                    </P>
                    <P>With respect to the requested exclusions or a “phased-in” approach for certain types of entities, we do not believe that this is necessary due to the addition of paragraph (b) within the information blocking definition in § 171.103 and the new Content and Manner Exception in § 171.310. Section 171.103(b) states that until May 2, 2022—which is 18 months after the compliance date of the information blocking section of this final rule (part 171)—EHI for purposes of part 171 is limited to the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) standard adopted in § 170.213 (see the discussion in section VIII.C). Similarly, the Content and Manner Exception allows actors to make available a limited set of EHI (the USCDI) during the first 18 months after the six-month delayed compliance date for part 171 (a total of 24 months after publication of this final rule). This approach, as well as the Infeasibility Exception, will address concerns about certain actors having limited resources or limited access to health IT.</P>
                    <P>The health care provider definition and resources we have made available provide clarity and examples of the types of individuals and entities covered by the definition. To this point, medical device manufacturers and community-based organizations, as described by commenters, generally would not meet the health care provider definition unless they are also a type of individual or entity identified in the definition.</P>
                    <HD SOURCE="HD3">b. Health IT Developers of Certified Health IT</HD>
                    <P>Section 3022(a)(1)(B) of the PHSA defines information blocking, in part, by reference to the conduct of health information technology developers. In the Proposed Rule (84 FR 7510), we explained that, because title XXX of the PHSA does not define “health information technology developer,” we interpreted section 3022(a)(1)(B) in light of the specific authority provided to OIG in section 3022(b)(1)(A) and (b)(2). We noted that section 3022(b)(2) discusses developers, networks, and exchanges by referencing any individual or entity described in section 3022(b)(1)(A) or (C). Section 3022(b)(1)(A) states, in relevant part, that OIG may investigate any claim that a health information technology developer of certified health information technology or other entity offering certified health information technology engaged in information blocking.</P>
                    <P>
                        We believe it is reasonable to interpret these sections together to mean that the information blocking provision extends to individuals 
                        <E T="03">or</E>
                         entities that develop 
                        <E T="03">or</E>
                         offer certified health IT. That the individual or entity must develop or offer 
                        <E T="03">certified</E>
                         health IT, we explained, is further supported by section 3022(a)(7) of the PHSA—which refers to developers' responsibilities to meet the requirements of certification—and section 4002 of the Cures Act—which identifies information blocking as a Condition of Certification. Consistent with this, we proposed a definition of “health IT developer of certified health IT” in § 171.102 (84 FR 7601) and an interpretation of the use of “health information technology developer” in section 3022 of the PHSA that would apply to part 171 only, and would not apply (84 FR 7511) to the implementation of any other section of the PHSA 
                        <SU>122</SU>
                        <FTREF/>
                         or the Cures Act, such as section 4005(c)(1) of the Cures Act.
                    </P>
                    <FTNT>
                        <P>
                            <SU>122</SU>
                             Because part 171 is referenced by part 170 subpart D, the definition and interpretation are relevant to developers' obligations to meet Condition and Maintenance of Certification Requirements.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Limiting the Definition of Health IT Developer to Developers of Certified Health IT</HD>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters suggested broadening the definition of “health IT developers” to include all developers of health IT, whether or not any of their products include Health IT Module(s) certified under ONC's Health IT Certification Program. Several of these commenters expressed concern that developers of only non-certified health IT would, under our proposed definition, be able to continue to block patients from accessing or directing their EHI to third parties of their choice. A majority of these commenters expressed concerns that an information blocking prohibition limited to developers who participate in the ONC Health IT Certification Program (also referred to as “the Program”) will result in an uneven playing field for developers who participate in the Program in comparison to those who do not participate in the Program. Some commenters suggested that this could motivate developers to avoid or withdraw from the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe that “health information technology developer” as used in PHSA section 3022(a)(1)(B) should be interpreted in light of the specific authority provided to OIG in section 3022(b)(1)(A) and (b)(2). Section (b)(1)(A) states, in relevant part, that OIG may investigate any claim that a health information technology developer of certified health information technology or other entity offering certified health information technology engaged in information blocking. We recognize that health IT developers that are not developers of certified health IT could engage in conduct meeting the definition of information blocking in section 3022(a) of the PHSA. However, the statute places health IT developers of certified health IT on different footing than other developers of health IT with respect to information blocking enforcement. A broader definition of “health IT developer” in § 171.102 would not change the scope or effect of section 3022(b)(1)(A) and (b)(2) of the PHSA.
                    </P>
                    <P>
                        We acknowledge that the information blocking provision may change some health IT developers' assessments of whether participation in the voluntary ONC Health IT Certification Program is the right decision for their health IT products and customers. However, we believe the value certification offers to the health IT developers' customers, such as health care providers, is substantially enhanced by both the information blocking provision and the 
                        <PRTPAGE P="25796"/>
                        enhancements to certification called for in PHSA section 3001(c)(5)(D). We believe the benefit that certification offers health IT developers' customers will continue to weigh in favor of the developers obtaining and maintaining certification of their products. For example, the Promoting Interoperability Programs (formerly known as the Medicare and Medicaid EHR Incentive Programs) continue to require use of Certified EHR Technology (CERHT), which makes certification important for developers seeking to market certain types of health IT (notably including, but not limited to, that within the “Base EHR” definition in § 170.102) to eligible clinicians, eligible hospitals, and critical access hospitals (CAHs).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended alternative approaches to interpreting the Cures Act, to justify broadening the definition of “health IT developer” in 45 CFR 171.102 to include all developers of any products within the definition of “health information technology” in section 3000 of the PHSA. These commenters offered a variety of rationales, including consideration of information that would have been available to Congress at the time the Cures Act was enacted, as the basis for inferring that Congress did not intend to limit the scope of the information blocking provision to developers that participate in the voluntary ONC Health IT Certification Program. Some commenters stated the phrasing of the Cures Act's information blocking provision appeared to exclude health IT developers that do not participate in our Program and recommended that we address what some comments described as a potential enforcement gap by broadening the regulatory definition of “health IT developer” in 45 CFR 171.102, although they did not identify a specific statutory basis for closing what their comments described as a gap or drafting issue in the statute. One commenter asked that we work with Congress to expand the definition of health IT developer beyond those with at least one product that is or that includes at least one Health IT Module certified under the Program.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As explained in the Proposed Rule and in the immediately preceding response to comments, we believe that “health information technology developer” as used in PHSA section 3022(a)(1)(B) should be interpreted in light of the specific authority provided to OIG in section 3022(b)(1)(A) and (b)(2). Our interpretation is that the individual or entity must develop or offer 
                        <E T="03">certified</E>
                         health IT to be considered a health IT developer covered by the information blocking provision, which is further supported by PHSA sections 3022(a)(7) and 3001(c)(5)(D). Section 3022(a)(7) refers to developers' responsibilities to meet the requirements of certification, and section 3001(c)(5)(D) identifies as a Condition of Certification that a health IT developer not engage in information blocking. Moreover, PHSA § 3022 does not specifically address all of the types of individuals and entities (such as health plans and claims data clearinghouses) that could or currently do engage in practices that might otherwise meet the definition of information blocking in PHSA § 3022(a).
                    </P>
                    <HD SOURCE="HD3">Applicability of Information Blocking Provision to Non-Certified Health IT Products of a Developer of Certified Health IT</HD>
                    <P>
                        <E T="03">Comments.</E>
                         On the whole, the majority of comments supported defining “health IT developer” in a manner that includes all health IT products developed or offered by developers who have at least one Health IT Module certified under the Program. However, multiple comments, predominantly from the perspective of developers of certified health IT, recommended that we limit the definition of “health IT developers of certified health IT” in § 171.102 so that it would encompass only the developers' conduct specific to their certified health IT products. Commenters advocating this more limited definition stated that these developers' non-certified health IT products would be competing against similar products of developers who are not subject to the information blocking provision.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Cures Act does not prescribe that only practices involving certified health IT may implicate PHSA section 3022(a). If Congress had intended to limit the application of section 3022 of the PHSA to practices involving certified health IT, we believe PHSA section 3022 would have included language that tied enforcement of that section to the operation or performance of health IT products that include one or more Health IT Module(s) certified under the Program. Instead, PHSA section 3022(b)(1)(A) provides that the HHS Inspector General may investigate under PHSA section 3022 any claim that “a health information technology developer of certified health information technology or other entity offering certified health information technology—submitted a false attestation under section 3001(c)(5)(D)(vii); or engaged in information blocking.” Similarly, neither subparagraph (B) of PHSA section 3022(b)(1), specific to claims that a health care provider engaged in information blocking, nor subparagraph (C), specific to claims that health information exchanges (HIEs) or health information networks (HINs) engaged in information blocking, includes language limiting the Inspector General to investigating claims tied to these actors' use of certified health IT.
                    </P>
                    <P>Moreover, our observation is that the customers of health IT developers of certified health IT seldom, if ever, rely solely on Health IT Modules certified under the Program to meet their needs to access, exchange, and use EHI. A developer's health IT product suite that a hospital, clinician office practice, or other health care provider uses (and colloquially references) as its “EHR system” will typically include a wide variety of functions, services, components, and combinations thereof. Even where such a health IT product suite meets the definition of “Certified EHR Technology” for purposes of participation in the Promoting Interoperability Programs, there is no guarantee that every part of the overall product suite will meet the requirements of at least one certification criterion adopted by the Secretary. In fact, typically only a subset of the functions, services, components, and combinations thereof within the overall product suite will meet the requirements of at least one certification criterion adopted by the Secretary and be Health IT Modules certified under the Program.</P>
                    <P>
                        If we were to interpret the information blocking provision as applying only to the certified Health IT Modules within a developer's product suite(s), we are concerned the developers' customers might too easily presume, based on the developer's participation in the ONC Health IT Certification Program, that the developer will not engage in information blocking with respect to any of the EHI that the customer uses of the developer's product suite(s) to access, exchange, or use. Moreover, limiting our definition of “health IT developer of certified health IT” for purposes of part 171 to only the subset of an individual or entity's products that are, or that specifically include, Health IT Modules certified under our Program could encourage developers to split various functions, services, or combinations thereof into multiple products so that they could more easily or broadly avoid accountability for engaging in practices otherwise meeting the definition of information blocking in § 171.103 with respect to various pieces of their product suite(s) rather than 
                        <PRTPAGE P="25797"/>
                        composing products in response to customers' needs and preferences.
                    </P>
                    <P>
                        We do not believe this outcome would be in the best interest of patients, health care providers, or other customers of health IT developers of certified health IT. Thus, while acknowledging that our definition of “health IT developer of certified health IT” in specific may, like the information blocking provision in general, change some health IT developers' assessments of whether participation in the voluntary ONC Health IT Certification Program is the right decision for their health IT products and customers, we believe the definition we have finalized offers necessary assurance to purchasers and users that a health IT developer that has chosen to participate in the Program can be held accountable under part 170 subpart D 
                        <E T="03">and</E>
                         under part 171 should that developer also engage in any conduct meeting the definition of information blocking in § 171.103.
                    </P>
                    <HD SOURCE="HD3">Duration of Health IT Developer of Certified Health IT Status</HD>
                    <P>We proposed that “health IT developer of certified health IT” would mean an individual or entity that develops or offers health information technology (as that term is defined in 42 U.S.C. 300jj(5)) and which had, at the time it engaged in a practice that is the subject of an information blocking claim, health information technology (one or more) certified under the ONC Health IT Certification Program. We proposed (84 FR 7511) that the term “information blocking claim” within this definition should be read broadly to encompass any statement of information blocking or potential information blocking. We also noted in the Proposed Rule that “claims” of information blocking within this definition would not be limited, in any way, to a specific form, format, or submission approach or process.</P>
                    <P>We stated in the Proposed Rule that we were also considering additional approaches to help ensure developers and offerors of certified health IT remain subject to the information blocking provision for an appropriate period of time after leaving the Program. While encouraging commenters to identify alternative approaches for identifying when a developer or offeror should, and when they should no longer, be subject to the information blocking provision, we requested comment on whether one of two specific approaches would best achieve our policy goal of ensuring that health IT developers of certified health IT will face consequences under the information blocking provision if they engage in information blocking in connection with EHI that was stored or controlled by the developer or offeror while they were participating in the Program. One such approach would have defined “health IT developer of certified health IT” as including developers and offerors of certified health IT that continue to store EHI that was previously stored in health IT certified in the Program. The other would have continued to define a developer or offeror of health IT as a “health IT developer of certified health IT” for purposes of part 171 for an appropriate period of time, such as one year, after the developer or offeror left the Program (no longer had any Health IT Modules certified under part 170).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments in support of defining “health IT developer of certified health IT” in a way that would include developers and offerors who have left the Program so long as they continue to store or control EHI that had been stored in or by their health IT products while the products were, or included one or more, Health IT Module(s) certified in the Program. We also received several comments recommending developers of certified health IT remain subject to the information blocking provision for a period of time after leaving the Program. A couple of commenters recommended a hybrid approach that would include individuals and entities in the definition of “health IT developer of certified health IT” while they continue to store EHI that had been stored in certified health IT 
                        <E T="03">or</E>
                         for a reasonable period of time after they ceased participating in the Program, whichever is longer.
                    </P>
                    <P>One reason commenters stated in support of extending the definition of “health IT developer of certified health IT” beyond the time a developer ceased participating in the program was that in commenters' view this could help former customers access the EHI that the customers need to provide the best care for patients and that they had contracted with a developer to manage while the developer had certified health IT. Some commenters stated that the need for customers to ensure their contracts with Program-participating developers include provisions for retrieval of the EHI upon termination or conclusion of the contract would be eliminated if the period of time during which the “health IT developer of certified health IT” definition applied extended beyond the date a developer leaves the Program. Other comments recommended against developers remaining subject to the information blocking provision after leaving the Program, citing concerns such as burden.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. We have finalized in § 171.102 that a “health IT developer of certified health IT” for purposes of part 171 means an individual or entity, other than a health care provider that self-develops health IT for its own use, that develops or offers health information technology (as that term is defined in 42 U.S.C. 300jj(5)) and which has, at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified under a program for the voluntary certification of health information technology that is kept or recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health IT Certification Program). This definition will ensure conduct a developer or offeror engages in while it has any health IT product certified under the Program will be within the definition of “health IT developer of certified health IT” for purposes of part 171.
                    </P>
                    <P>We have not extended the definition of “health IT developer of certified health IT” beyond the date on which a developer or offeror no longer has any health IT certified under the Program. It may be that extending duration of “health IT developer of certified health IT” status beyond the date on which a developer or offeror stops participating in the Program could help motivate such a developer or offeror to better support transfers of EHI in their custody if their customers choose to switch products because of the developer's withdrawal from the Program. However, we believe that ensuring continuity of access to patients' EHI is an essential consideration in the process of selecting and contracting for health IT. All transitions between different health IT products will require transfer of EHI between those products. Planning for this transfer is, as a practical matter, integral to a successful transition between products that ensures continuity of access to EHI essential to safe, well-coordinated patient care. We are not persuaded that any of the alternative approaches to duration of “health IT developers of certified health IT” status could eliminate the need for health care providers and other customers of “health IT developers of certified health IT” to ensure their health IT planning and contracting provides for appropriate transfer(s) of data at the conclusion or termination of any particular contract.</P>
                    <P>
                        We also note that in the market for certified Health IT Modules today, many of the customers of health IT developers 
                        <PRTPAGE P="25798"/>
                        or offerors are HIPAA-covered entities (such as health care providers) or HIPAA business associates (BAs) (such as health information exchanges or clinical data registries) with whom covered entities contract for particular services. In such cases, the HIPAA Rules generally require that a HIPAA covered entity (or BA) enter into a business associate agreement (BAA) that requires that the BA (or subcontractor BA) return or destroy the PHI after the termination of its service as a BA (or subcontractor BA). Because a contract for health IT products or services, and any associated BAA, could extend beyond a developer or offeror's departure from the ONC Health IT Certification Program, we believe such contracts and agreements provide an appropriate mechanism for customers to guard against a health IT developer or offeror who has left the Program refusing to relinquish EHI. We note further that limiting the definition of “health IT developer of certified health IT” to the time period during which the individual or entity has at least one Health IT Module certified under the Program would not require claims of information blocking to come to our attention during that same period. We have finalized the definition as proposed, with modification to its wording that is discussed below.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter suggested that the definition of “information blocking claim” should not include any “potential information blocking,” but instead should be evaluated with facts and evidence necessary to support a verifiable claim.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not propose to define in regulation “information blocking claim.” We did note in the preamble to the Proposed Rule that for purposes of the definition of “health IT developer of certified health IT” proposed in § 171.102, claims of information blocking would not be limited, in any way, to a specific form, format, or submission process (84 FR 7511). In the definition of “health IT developer of certified health IT” finalized in § 171.102, we have retained reference to the time at which the individual or entity that develops or offers certified health IT engages in a practice that is the subject of an information blocking claim so that it is immediately clear on the face of the regulation text that the claim need not be brought while the developer still has certified health IT. If a health IT developer of certified health IT engages in a practice that is within the definition of information blocking in § 171.103 while they remain in the Program, that health IT developer cannot avoid applicability of the information blocking provision to those practices by simply leaving the Program before any claim(s) about the practice may come to light. Our reference to claims of information blocking in the finalized definition of “health IT developer of certified health IT” is not intended to imply that any actor whose conduct is the subject of a claim of information blocking that is received by HHS necessarily will be found to have engaged in conduct meeting the definition of information blocking in § 171.103 or that is otherwise contrary to requirements of the ONC Health IT Certification Program (such as the Condition and Maintenance of Certification requirements established in subpart D of part 170).
                        <SU>123</SU>
                        <FTREF/>
                         If subject to an investigation, each practice that implicates the information blocking provision and does not meet an exception would be analyzed on a case-by-case basis to evaluate, for example, whether it rises to the level of an interference, and whether the actor acted with the requisite intent.
                    </P>
                    <FTNT>
                        <P>
                            <SU>123</SU>
                             Section 3022(b) of the PHSA authorizes the HHS Office of the Inspector General to investigate claims of information blocking. Simultaneously, ONC has responsibility for assessing developers' compliance with requirements of the ONC Health IT Certification Program. Coordination between ONC and OIG in our respective roles is discussed in section VII.D.3 of this preamble.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Developers and Offerors of Certified Health IT</HD>
                    <P>We stated in the proposed rule that within the definition of “health IT developer of certified health IT” for purposes of part 171, we interpret an “individual or entity that develops the certified health IT” as the individual or entity that is legally responsible for the certification status of the health IT, which would be the individual or entity that entered into a binding agreement that resulted in the certification status of the health IT under the Program or, if such rights are transferred, the individual or entity that holds the rights to the certified health IT (84 FR 7511). We also stated that an “individual or entity that offers certified health IT” would include an individual or entity that under any arrangement makes certified health IT available for purchase or license. We requested comment on both of these interpretations, and whether there are particular types of arrangements under which certified health IT is “offered” in which the offeror should not be considered a “health IT developer of certified health IT” for the purposes of the information blocking provision.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several comments questioned the inclusion of offerors of certified health IT who do not themselves develop the health IT in the definition of “health IT developer of certified health IT.” Some commenters recommended the exclusion of offerors who do not modify or configure the health IT in question. Some commenters advocated treating entities that include other developers' certified health IT in the health IT products or services they offer, but do not themselves develop certified health IT, as being outside the definition of “health IT developer of certified health IT.” Commenters stated that these offerors do not themselves develop the certified health IT and thus do not control its design. Commenters also stated that the products offered by some of these offerors (such as clinical data registries which may be certified to clinical quality measurement and measure reporting criteria) are not primary sources of patients' EHI, and that offerors of health IT that is not a primary source of EHI should be excluded from the definition of health IT developer of certified health IT. One commenter specifically recommended excluding from the definition individuals and entities that offer under their own brand, but do not modify or configure, certified health IT developed by others. These commenters suggested that this is desirable in order to hold developers accountable for information blocking conduct in the course of development.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Including both developers and other offerors in the definition of “health IT developer of certified health IT” is consistent with the policy goal of holding all entities who could, as a developer or offeror, engage in information blocking accountable for their practices that are within the definition of information blocking in § 171.103. PHSA section 3022(b)(1)(A) expressly references both “a health information technology developer of certified health information technology” and “other entity offering certified health information technology” in the context of authority to investigate claims of information blocking. As stated in the Proposed Rule (84 FR 7510), we interpret PHSA section 3022(a)(1)(B) in light of the specific authority provided to OIG in PHSA section 3022(b)(1)(A) and (b)(2).
                    </P>
                    <P>
                        We interpret these sections together as the basis for applicability of the information blocking provision to individuals or entities that develop or offer certified health IT. We refer commenters concerned about holding offerors that do not develop, modify, or configure health IT accountable for the conduct of others to PHSA section 3022(a)(6), which states that the term “information blocking,” with respect to 
                        <PRTPAGE P="25799"/>
                        an individual or entity, shall not include an act or practice other than an act or practice committed by such individual or entity. Where the individual or entity that develops health IT is different from the individual or entity that offers certified health IT, each such individual or entity would have the potential to engage in various practices within the definition of information blocking in PHSA section 3022(a) and 45 CFR 171.103, and we believe each should be accountable for their own conduct. Actors who are not primary generators of EHI or who may hold only a few data classes or elements for any given patient (as would be the case for examples specifically cited by commenters), could nevertheless engage in conduct that constitutes information blocking as defined in § 171.103 with respect to that EHI they do hold or control. We therefore see no reason to exclude them from the definition of health IT developer of certified health IT. To do so would not be consistent with the policy goal of addressing the problem of information blocking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended that public health agencies that develop and/or offer health IT products and services, such as those related to syndromic surveillance and immunization registries, be excluded from the definition of health IT developer in § 171.102.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe the vast majority of public health agencies would remain outside of our definition of “health IT developer of certified health IT” finalized in § 171.102. The “public health” certification criteria within the ONC Health IT Certification Program are applicable to the health IT that health care providers would use to exchange information with public health information infrastructure. These criteria are not applicable to the public health information reporting or exchange infrastructure itself.
                    </P>
                    <HD SOURCE="HD3">Treatment of “Self-Developers” of Certified Health IT</HD>
                    <P>
                        We stated in the proposed rule (84 FR 7511) that a “self-developer” of certified health IT, as the term has been used in the ONC Health IT Certification Program (Program) and described in section VII.D.7 of the Proposed Rule (84 FR 7507), section VII.D.7 of this preamble, and previous rulemaking,
                        <SU>124</SU>
                        <FTREF/>
                         would be treated as a health care provider for the purposes of information blocking because our description of a self-developer for Program purposes 
                        <SU>125</SU>
                        <FTREF/>
                         would mean that they would not be supplying or offering their certified health IT to other entities (84 FR 7511 and 7512). We stated in the Proposed Rule that self-developers would still be subject to the proposed Conditions and Maintenance of Certification requirements because they have health IT certified under the Program (
                        <E T="03">see also</E>
                         section VII.D.7 of the Proposed Rule (84 FR 7507) and section VII.D.7 of this preamble). We requested comments on our treatment of “self-developers” for information blocking purposes and whether there are other factors we should consider.
                    </P>
                    <FTNT>
                        <P>
                            <SU>124</SU>
                             The final rule establishing ONC's Permanent Certification Program, “Establishment of the Permanent Certification for Health Information” (76 FR 1261), addresses self-developers.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>125</SU>
                             The language in the final rule establishing ONC's Permanent Certification Program describes the concept of “self-developed” as referring to a complete EHR or EHR Module designed, created, or modified by an entity that assumed the total costs for testing and certification and that will be the primary user of the health IT (76 FR 1300).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A number of comments expressed support of treating “self-developer” health care providers who do not supply or offer their certified health IT to other entities as health care providers for purposes of information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' input. The definition of “health IT developer of certified health IT” that we have finalized in § 171.102 expressly excludes health care providers who self-develop health IT for their own use. However, we remind health care providers who may be considering or are embarking on self-development of certified Health IT Modules that “self-developers” 
                        <E T="03">are</E>
                         subject to certain Condition and Maintenance of Certification requirements finalized in subpart D of part 170. These requirements include, though they are not limited to, providing assurances and attestations that they will not, have not, and do not engage in conduct constituting information blocking.
                    </P>
                    <P>For purposes of the definition of “health IT developer of certified health IT,” we interpret “a health care provider that self-develops health IT for its own use” to mean that the health care provider is responsible for the certification status of the Health IT Module(s) and is the primary user of the Health IT Module(s). Moreover, we interpret “a health care provider that self-develops health IT for its own use” to mean that the health care provider does not offer the health IT to other entities on a commercial basis or otherwise. This interpretation rests on our established concept of “self-developed” certified Health IT Modules. In this context, it is important to note that some use of a self-developer's health IT may be made accessible to individuals or entities other than the self-developer and its employees without that availability being interpreted as offering or supplying the health IT to other entities in a manner inconsistent with the concept of “self-developer.” For example, if a hospital were to self-develop an EHR system, we would not consider inclusion in that system of certain functionalities or features—such as APIs or patient portals—to be offering or supplying the hospital's self-developed health IT to other entities. We would also not interpret as offering or supplying the self-developed health IT to other entities the issuance of login credentials allowing licensed health care professionals who are in independent practice to use the hospital's EHR to furnish and document care to patients in the hospital. Keeping in the hospital's EHR a comprehensive record of a patient's care during an admission is a practice we view as reasonable and it typically requires that all the professionals who furnish care to patients in the hospital be able to use the hospital's EHR system. It is also customary practice amongst hospitals that purchase commercially marketed health IT, as well as those that self-develop their health IT, to enable health care professionals in independent practice who furnish care in the hospital to use the EHR in connection to furnishing and documenting that care. Clinician portals made available to facilitate independent licensed health care professionals furnishing and/or documenting care to patients in the hospital would also not be interpreted as negating the hospital's “self-developer” status. However, if a health care provider responsible for the certification status of any Health IT Module(s) were to offer or supply those Health IT Module(s), separately or integrated into a larger product or software suite, to other entities for those entities' use in their own independent operations, that would be inconsistent with the concept of the health care provider self-developing health IT for its own use.</P>
                    <P>
                        In deciding to exclude health care providers who self-develop health IT for their own use from the definition of “health IT developer of certified health IT” finalized in § 171.102, we rely substantially on our Program experience that self-developed certified health IT currently represents a small, and diminishing, share of the Health IT Modules certified under our Program. We also note that we may consider amending this definition in future 
                        <PRTPAGE P="25800"/>
                        rulemaking in response to changing market conditions. For example, the market might evolve in ways that would increase risk of abuse of this exclusion of health care providers who self-develop certified health IT from the application of the § 171.103 definition of “information blocking” to their conduct as a developer of health IT. In such circumstances, we might contemplate appropriate revisions to the definition of “health IT developer of certified health IT” for purposes of part 171.
                    </P>
                    <HD SOURCE="HD3">Summary of Finalized Policy: Definition of Health IT Developer of Certified Health IT</HD>
                    <P>
                        In § 171.102, we have finalized that “
                        <E T="03">health IT developer of certified health IT”</E>
                         means an individual or entity, other than a health care provider that self-develops health IT for its own use, that develops or offers health information technology (as that term is defined in 42 U.S.C. 300jj(5)) and which has, at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified under a program for the voluntary certification of health information technology that is kept or recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health IT Certification Program). This is substantially the definition we proposed (84 FR 7601), but with minor modifications to its text.
                    </P>
                    <P>We have added to this finalized definition “other than a health care provider that self-develops health IT for its own use,” so that this feature of the proposed definition which we stated in the Proposed Rule's preamble (84 FR 7511) is immediately clear on the face of the regulation text itself. We also replaced the proposed phrasing “health information technology (one or more) certified” (84 FR 7601) with “one or more Health IT Modules certified” because it is more consistent with our Program terminology. We also replaced “under the ONC Health IT Certification Program” from the proposed phrasing with the finalized “under a program for the voluntary certification of health information technology that is kept or recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health IT Certification Program).” Currently, we keep a single Program that we refer to as the ONC Health IT Certification Program. For purposes of precision, we decided to refer to the statutory basis for the Program, and indicate parenthetically the manner in which we currently reference it.</P>
                    <P>We interpret “individual or entity that develops” certified health IT as the individual or entity that is legally responsible for the certification status of the health IT, which would be the individual or entity that entered into a binding agreement that resulted in the certification status of the health IT under the Program or, if such rights are transferred, the individual or entity that holds the rights to the certified health IT. As we clarified in the final rule “ONC Health IT Certification Program: Enhanced Oversight and Accountability” (81 FR 72404), the consequences under 45 CFR part 170 for a developer's having had one or more of its products' certification terminated apply to developers, their subsidiaries, and their successors (81 FR 72443).</P>
                    <P>For purposes of part 171 and the information blocking provision, we interpret an entity that has health IT to include not only the entity that entered into a binding agreement that resulted in the certification status of the health IT under the Program, but also its subsidiaries, and its successors. The facts and circumstances of a particular case may determine which individual(s) or entity (or entities) are culpable and whether enforcement against particular individual(s), the developer entity, a successor in rights to the health IT, the developer or successor's subsidiary, or a parent entity will be pursued. Similarly, use of the word “individual” in this context does not limit responsibility for practices of an entity that develops or offers health IT to the particular natural person(s) who may have signed binding agreement(s) that resulted in the certification status of the health IT under the Program. Depending on the nature of the organization, the person who signs the binding agreement that results in the certification status may be different from the person who determines the fees, the person who implements the health IT, and the person who sets the overall business strategy for the company. The facts and circumstances of each case may determine who the culpable individual or individual(s) are and whether enforcement against the entity or against specific individual(s) will be pursued.</P>
                    <P>As stated in the Proposed Rule, for purposes of this definition, a developer or offeror of a single certified health IT product that has had its certification suspended will still be considered to have certified health IT (84 FR 7511).</P>
                    <HD SOURCE="HD3">c. Health Information Networks and Health Information Exchanges</HD>
                    <P>The terms “network” and “exchange” are not defined in the information blocking provision or in any other relevant statutory provisions. We proposed to define these terms in a way that does not assume the application or use of certain technologies and is flexible enough to apply to the full range and diversity of exchanges and networks that exist today and that may arise in the future.</P>
                    <P>We stated that in considering the most appropriate way to define these terms, we examined how they are used throughout the Cures Act and the HITECH Act. Additionally, we considered dictionary and industry definitions of “network” and “exchange.” While the terms have varied usage and meaning in different industry contexts, we noted that certain concepts are common and were incorporated into the proposed definitions.</P>
                    <HD SOURCE="HD3">Health Information Network</HD>
                    <P>We proposed a functional definition of “health information network” (HIN) that focused on the role of these actors in the health information ecosystem. We stated that the defining attribute of a HIN is that it enables, facilitates, or controls the movement of information between or among different individuals or entities that are unaffiliated. Therefore, we proposed that two parties are affiliated if one has the power to control the other, or if both parties are under the common control or ownership of a common owner. We noted that a significant implication of the definition is that a health care provider or other entity that enables, facilitates, or controls the movement of EHI within its own organization, or between or among its affiliated entities, is not a HIN in connection with that movement of information for the purposes of the HIN definition.</P>
                    <P>We proposed that an actor could be considered a HIN if it performs any one or any combination of the following activities. First, the actor would be a HIN if it were to determine, oversee, administer, control, or substantially influence policies or agreements that define the business, operational, technical, or other conditions or requirements that enable or facilitate the access, exchange, or use of EHI between or among two or more unaffiliated individuals or entities. Second, an actor would be a HIN if it were to provide, manage, control, or substantially influence any technology or service that enables or facilitates the access, exchange, or use of EHI between or among two or more unaffiliated individuals or entities.</P>
                    <P>
                        We noted that, typically, a HIN will influence the sharing of EHI between many unaffiliated individuals or entities. However, we did not propose to establish any minimum number of 
                        <PRTPAGE P="25801"/>
                        parties or “nodes” beyond the requirement that there be some actual or contemplated access, exchange, or use of information between or among at least two unaffiliated individuals or entities that is enabled, facilitated, or controlled by the HIN. We stated that any further limitation would be artificial and would not capture the full range of entities that should be considered networks under the information blocking provision. We clarified that any individual or entity that enables, facilitates, or controls the access, exchange, or use of EHI between or among only itself and another unaffiliated individual or entity would not be considered a HIN in connection with the movement of that EHI (although that movement of EHI may still be regulated under the information blocking provision on the basis that the individual or entity is a health care provider or health IT developer of certified health IT). To be a HIN, we emphasized that the individual or entity would need to be enabling, facilitating, or controlling the access, exchange, or use of EHI between or among two or more 
                        <E T="03">other</E>
                         individuals or entities that were not affiliated with it.
                    </P>
                    <P>We provided multiple examples to illustrate how the proposed definition would operate. An entity is established within a state for the purpose of improving the movement of EHI between the health care providers operating in that state. The entity identifies standards relating to security and offers terms and conditions to be entered into by health care providers wishing to participate in the network. The entity offering (and then overseeing and administering) the terms and conditions for participation in the network would be considered a HIN for the purpose of the information blocking provision. We noted that there is no need for a separate entity to be created in order for that entity to be considered a HIN. To illustrate, we stated that a health system that “administers” business and operational agreements for facilitating the exchange of EHI that are adhered to by unaffiliated family practices and specialist clinicians in order to streamline referrals between those practices and specialists would likely be considered a HIN.</P>
                    <P>
                        We noted that the proposed definition would also encompass an individual or entity that does not directly enable, facilitate, or control the movement of information, but nonetheless exercises 
                        <E T="03">control or substantial influence</E>
                         over the policies, technology, or services of a network. In particular, we stated that there may be an individual or entity that relies on another entity—such as an entity specifically created for the purpose of managing a network—for policies and technology, but nevertheless dictates the movement of EHI over that network. As an example, a large health care provider could decide to lead an effort to establish a network that facilitates the movement of EHI between a group of smaller health care providers (as well as the large health care provider) and through the technology of health IT developers. To achieve this outcome, the large health care provider, together with some of the participants, could create a new entity that administers the network's policies and technology.
                    </P>
                    <P>In this scenario, we noted that the large health care provider would come within the functional definition of a HIN and could be held accountable for the conduct of the network if the large health care provider used its control or substantial influence over the new entity—either in a legal sense, such as via its control over the governance or management of the entity, or in a less formal sense, such as if the large health care provider prescribed a policy to be adopted—to interfere with the access, exchange, or use of EHI. We clarified that the large health care provider in this example would be treated as a health care provider when utilizing the network to move EHI via the network's policies, technology, or services, but would be considered a HIN in connection with the practices of the network over which the large health care provider exercises control or substantial influence.</P>
                    <P>We sought comment on the proposed definition of a HIN. In particular, we requested comment on whether the proposed definition was broad enough (or too broad) to cover the full range of individuals and entities that could be considered HINs within the meaning of the information blocking provision. Additionally, we specifically requested comment on whether the proposed definition would effectuate our policy goal of defining this term in a way that does not assume particular technologies or arrangements and was flexible enough to accommodate changes in these and other conditions.</P>
                    <P>We note that we summarize and respond to the comments received on the HIN definition below with the comments received on the health information exchange definition (HIE) due to the overlap in the comments received and our responses.</P>
                    <HD SOURCE="HD3">Health Information Exchange</HD>
                    <P>We proposed to define a “health information exchange” (HIE) as an individual or entity that enables access, exchange, or use of EHI primarily between or among a particular class of individuals or entities or for a limited set of purposes. We noted that our research and experience in working with exchanges drove the proposed definition of this term. We stated that HIEs would include, but were not limited to, regional health information organizations (RHIOs), State health information exchanges (State HIEs), and other types of organizations, entities, or arrangements that enable EHI to be accessed, exchanged, or used between or among particular types of parties or for particular purposes. As an example, we noted an HIE might facilitate or enable the access, exchange, or use of EHI exclusively within a regional area (such as a RHIO), or for a limited scope of participants and purposes (such as a clinical data registry or an exchange established by a hospital-physician organization to facilitate Admission, Discharge, and Transfer (ADT) alerting). We further noted that HIEs may be established under Federal or State laws or regulations but may also be established for specific health care or business purposes or use cases. We also mentioned that if an HIE facilitates the access, exchange, or use of EHI for more than a narrowly defined set of purposes, then it may be both an HIE and a HIN.</P>
                    <P>We sought comment on the proposed HIE definition and encouraged commenters to consider whether the proposed definition was broad enough (or too broad) to cover the full range of individuals and entities that could be considered exchanges within the meaning of the information blocking provision, and whether the proposed definition was sufficiently flexible to accommodate changing technological and other conditions.</P>
                    <HD SOURCE="HD3">Comments on the HIN and HIE Definitions</HD>
                    <P>As mentioned above, we received substantially similar comments on both proposed definitions. Based on those comments and our approach to the final definition for these terms, we have combined our comment summary and response for the proposed definitions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters suggested that the definitions of HIN and HIE should be combined because confusion could arise in trying to distinguish between the two terms. Commenters asserted that these definitions are used to describe entities that perform the same or similar functions. Some commenters expressed support for the broad functional definitions of HIE and HIN, while others expressed concern that many organizations could be unintentionally 
                        <PRTPAGE P="25802"/>
                        covered by the proposed definitions due to the broad scope of the definitions as proposed.
                    </P>
                    <P>Many commenters suggested excluding certain individuals and entities from the HIE and/or HIN definitions, while other commenters noted such an approach could significantly limit the application of the information blocking provision. Proposed exclusions offered by commenters included, but were not limited to: Health plans, payers, health care providers, business associates, accountable care organizations, health care clearinghouses, public health agencies, research organizations, clinical data registries, certified health information technology providers, software developers, mobile app providers, cloud storage vendors, internet service providers, and patient or consumer focused social media.</P>
                    <P>Some commenters suggested limiting the types of activities and/or the purposes for those activities that might be necessary to be considered a HIN or HIE.</P>
                    <P>Commenters also raised concerns with particular language in the proposed HIN definition, noting that the term “substantially influences” was vague and that we should remove “individual” from the definitions as commenters could not foresee an individual acting as a HIN or HIE.</P>
                    <P>
                        <E T="03">Response.</E>
                         The definitions of HIN and HIE in the Proposed Rule achieved a key goal which was to solicit feedback from a wide array of stakeholders that might be considered HINs or HIEs under the proposed definition, including on whether the definitions were too broad or not broad enough. We have adopted a modified definition in this final rule to address much of the feedback without expressly excluding any specific type of entity, which we believe would be unwieldy to appropriately administer and, more importantly, in conflict with our overarching approach to include any individual or entity that performs certain functional activities as outlined in the Proposed Rule.
                    </P>
                    <P>
                        Foremost, in this final rule, we are combining the definitions of HIN and HIE to create one functional definition that applies to both statutory terms in order to clarify the types of individuals and entities that would be covered. This approach is consistent with statements we made in the Proposed Rule noting that a HIE could also be an HIN. In addition, section 3022 of the PHSA often groups these two terms together, and as we noted previously, does not define them. This approach will also eliminate stakeholder confusion as expressed by commenters and respond to commenters who asserted the terms refer to entities performing the same function. To this point, we have found numerous associations and publications referring to entities that perform the same or similar functions that we have specified in the HIN/HIE definition as HINs, HIEs, and regional health information organizations (RHIOs).
                        <SU>126</SU>
                        <FTREF/>
                         We have finalized under § 171.102 that a 
                        <E T="03">health information network or health information exchange</E>
                         means an individual or entity that determines, controls, or has the discretion to administer any requirement, policy, or agreement that permits, enables, or requires the use of any technology or services for access, exchange, or use of EHI: (1) Among more than two unaffiliated individuals or entities (other than the individual or entity to which this definition might apply) that are enabled to exchange with each other; and (2) that is for a treatment, payment, or health care operations purpose, as such terms are defined in 45 CFR 164.501 regardless of whether such individuals or entities are subject to the requirements of 45 CFR parts 160 and 164.
                    </P>
                    <FTNT>
                        <P>
                            <SU>126</SU>
                             
                            <E T="03">See</E>
                             HIMSS FAQ, Health Information Exchange: A catch-all phrase for all health information exchange, including Regional Health Information Organizations (RHIOs), Quality Information Organizations (QIOs), Agency for Healthcare Research and Quality (AHRQ)-funded communities and private exchanges, 
                            <E T="03">https://protect2.fireeye.com/url?k=7d5b6f82-210e6652-7d5b5ebd-0cc47a6a52de-fe4abdcde0e54deb&amp;u=https://www.himss.org/library/health-information-exchange/FAQ</E>
                            ; AHIMA, “An HIE is the electronic movement of health-related information among organizations according to nationally recognized standards. HIE is also sometimes referred to as a health information network (HIN)”, 
                            <E T="03">http://bok.ahima.org/PdfView?oid=104129</E>
                            ; SHIEC Member List, SHIEC is the trade association of HIEs, called the Strategic 
                            <E T="03">Health Information Exchange</E>
                             collaborative, which has 17 members with “network” in their name, 
                            <E T="03">https://protect2.fireeye.com/url?k=f84ddacd-a418d31d-f84debf2-0cc47a6a52de-8424832df6e921dc&amp;u=https://strategichie.com/membership/member-list/</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        In consideration of comments, we also narrowed the definition in three ways. First, the types of actions (
                        <E T="03">e.g.,</E>
                         manages or facilitates) that would be necessary for an actor to meet the definition of HIN or HIE were reduced. This includes removing the “substantially influences” element of the proposed definition of HIN to address concerns about possible ambiguity. Second, we have revised the definition to specify that to be a HIN or HIE there must be exchange among more than two unaffiliated individuals or entities besides the HIN/HIE that are enabled to exchange with each other. This revision ensures that the definition does not unintentionally cover what are essentially bilateral exchanges in which the intermediary is simply performing a service on behalf of one entity in providing EHI to another or multiple entities and no actual exchange is taking place among all entities (
                        <E T="03">e.g.,</E>
                         acting as an intermediary between two entities where the first sends non-standardized data to be converted by the intermediary into standardized data for the receiving entity). To be clear, to be enabled, the parties must have the ability and discretion to exchange with each other under the policies, agreements, technology, and/or services. Third, we focused the definition on three activities: Treatment, payment, and health care operations, as each are defined in the HIPAA Rules (45 CFR 164.501). The activities described by the terms treatment, payment and health care operations were selected for multiple reasons. Many, but not all, individuals and entities that would meet the definition of HIN/HIE for information blocking purposes will be familiar with these terms because they currently function as a covered entity or business associate under the HIPAA Rules. Last, this approach serves to ensure that certain unintended individuals and entities are not covered by the definition, which we discuss in more detail below.
                    </P>
                    <P>
                        Two important points about the definition require clarification. First, the reference to the three types of activities does 
                        <E T="03">not</E>
                         limit the application of the HIN/HIE definition to individuals or entities that are covered entities or business associates (as defined in HIPAA). For example, if three unaffiliated entities exchanging information were health care providers that were not HIPAA covered entities, their exchange of information for treatment purposes through a HIN or HIE would qualify for this element of the definition even though the HIN/HIE would not be a business associate to any of the providers. We expect such situations to be rare, but they may occur. Second, the three activities serve as elements of the definition such that if an individual or entity meets them, then the individual or entity would be considered a HIN/HIE under the information blocking regulations for any practice they conducted while functioning as a HIN/HIE. To illustrate, if a HIN/HIE was exchanging EHI on behalf of a health care provider for treatment purposes, but denied an individual access to their EHI available in the HIN/HIE, then the HIN/HIE would be considered a HIN/HIE under the circumstances for the purposes of information blocking. Having said this, the HIN/HIE may not have “interfered 
                        <PRTPAGE P="25803"/>
                        with” the individual's access to their EHI depending on the terms of the HIN/HIE's business associate agreements with the participating covered entities or for other reasons such as the EHI could not be disclosed by law or the HIN/HIE met an exception under the information blocking provision. To be clear, the HIN/HIE definition is only applicable to the circumstances of an information blocking claim. For example, a health care provider that may have ownership of a HIN/HIE, would not be considered a HIN/HIE, but instead a “health care provider” with respect to situations that involve their behavior as a health care provider, such as denying another health care provider's ability to access, exchange, or use EHI for treatment purposes or denying an individual's access to their EHI via the health care provider's patient portal.
                    </P>
                    <P>With respect to suggestions to exclude specific types of entities, we believe that the Cures Act goals of supporting greater interoperability, access, exchange, and use of EHI are best advanced by a functional definition without specific exclusions. We note, however, that the narrower definition of HIN/HIE in this final rule should clearly exclude entities that might have been included under the proposed definitions, such as social networks, internet service providers, and technology that solely facilitates the exchange of information among patients and family members. The definition in this final rule continues to focus on the functional activity of the individual or entity in question and not on any title or classification of the person or entity.</P>
                    <P>The reference to “individual” was maintained in the final rule because the Cures Act states that penalties apply to any individual or entity that is a developer, network, or exchange (see section 3022(b)(2)(A) of the PHSA).</P>
                    <HD SOURCE="HD3">3. Electronic Health Information</HD>
                    <P>
                        In the Proposed Rule, we noted that the information blocking definition applies to 
                        <E T="03">electronic</E>
                         health information (EHI) (section 3022(a)(1) of the PHSA). We further noted that while section 3000(4) of the PHSA by reference to section 1171(4) of the Social Security Act defines “health information,” EHI is not specifically defined in the Cures Act, PHSA, HITECH Act, or other relevant statutes. Therefore, we proposed to include the definition of EHI in § 171.102 and define it to mean (84 FR 7513):
                    </P>
                    <P>(i) Electronic protected health information; and</P>
                    <P>(ii) any other information that—</P>
                    <P>• is transmitted by or maintained in electronic media, as defined in 45 CFR 160.103;</P>
                    <P>• identifies the individual, or with respect to which there is a reasonable basis to believe the information can be used to identify the individual; and</P>
                    <P>• relates to the past, present, or future health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual (84 FR 7513).</P>
                    <P>We explained in the Proposed Rule that this definition of EHI includes, but is not limited to: Electronic protected health information and health information that is created or received by a health care provider and those operating on their behalf; health plan; health care clearinghouse; public health authority; employer; life insurer; school; or university. In addition, we clarified that under our proposed definition, EHI includes, but is not limited to, electronic protected health information (ePHI) as defined in 45 CFR 160.103. We noted that EHI may also be provided, directly from an individual, or from technology that the individual has elected to use, to an actor covered by the information blocking provisions. We also proposed that EHI does not include health information that is de-identified consistent with the requirements of 45 CFR 164.514(b) (84 FR 7513).</P>
                    <P>We clarified that the EHI definition provides for an expansive set of health information, which could include information on an individual's health insurance eligibility and benefits, billing for health care services, and payment information for services to be provided or already provided, which may include price information (84 FR 7513).</P>
                    <P>We generally requested comment on this proposed definition as well as on whether the exclusion of health information that is de-identified consistent with the requirements of 45 CFR 164.514(b). We also sought comment on the parameters and implications of including price information within the scope of EHI for purposes of information blocking (84 FR 7513).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters were strongly supportive of the proposed EHI definition, stating that it covers the breadth of EHI that should be addressed within the regulation. Conversely, many other commenters, including health care providers and health IT developers, contended that the definition was overly broad and vague. They expressed concern about their ability to know what health information they must make available for access, exchange, and use for the purposes of complying with the information blocking provision. Some other commenters posited that they could be put in a situation of having to separate EHI from PHI for compliance purposes, noting this would be extremely burdensome. Many commenters stated simply trying to determine what constitutes EHI for compliance purposes would be extremely burdensome and costly.
                    </P>
                    <P>Commenters offered various options for narrowing the scope of the EHI definition. Many commenters suggested that EHI should only be electronic protected health information (ePHI) as defined under the HIPAA Rules. Some of these commenters specifically recommended that the EHI definition be limited to align with the definition of a designated record set under HIPAA. A few commenters stated that EHI should be limited to observational health information as described in the Proposed Rule (84 FR 7516). Commenters also recommended that the EHI definition be limited to only standardized health information, with some commenters recommending that EHI be specifically limited to information that meets the USCDI standard.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments and agree that actors should not have to separate ePHI from EHI in order to comply with both the HIPAA Rules and the information blocking provision. It is also important for actors to clearly understand what health information should be available for access, exchange, and use. To address these concerns, we have focused the EHI definition at this time on terms that are used in the HIPAA Rules and that are widely understood in the health care industry as well as on a set of health information that is currently collected, maintained, and made available for access, exchange, and use by actors. By doing so, we believe we have eliminated any perceived burden and actors will be in a situation that will permit them to readily and continually comply with the information blocking provision. While we understand that some commenters supported the EHI definition as proposed or included alternative definitions in their comments, we believe that, for the above reasons, the EHI definition we have codified in regulation through this final rule will enable effective implementation.
                    </P>
                    <P>
                        We have defined EHI (§ 171.102) to mean electronic protected health information (ePHI) as the term is defined for HIPAA in 45 CFR 160.103 to the extent that the ePHI would be included in a designated record set as defined in 45 CFR 164.501 (other than 
                        <PRTPAGE P="25804"/>
                        psychotherapy notes as defined in 45 CFR 164.501 or information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding), regardless of whether the group of records are used or maintained by or for a covered entity as defined in 45 CFR 160.103. The ePHI definition in 45 CFR 160.103 incorporates the definitions in that section for protected health information and electronic media. Although the definition of designated record set refers to records maintained by or for a covered entity, the EHI definition has been finalized to apply to groups of records (as they are included in the designated record set) regardless of whether they are maintained by or for a covered entity (
                        <E T="03">e.g.,</E>
                         a developer of certified health IT, a health information network, a health information exchange, or even a health care provider that may not be a covered entity or may not be acting as a business associate of a covered entity).
                    </P>
                    <P>
                        We did not focus the EHI definition finalized in this final rule on observational health information (OHI) as described in the Proposed Rule (84 FR 7516) for multiple reasons. We did not and cannot not at this time define OHI concretely. The use of OHI as a definition would also not align with our above stated goals to provide alignment with the HIPAA Rules and ease of implementation for actors. We also did not focus the EHI definition solely on the data identified in the USCDI standard. We are strong supporters of interoperability and standards-based access and exchange. To this point, the ONC Health IT Certification Program (Program) supports standards-based interoperability through the adoption of standards and the certification of health IT to those standards. In this respect, we have made the USCDI a 
                        <E T="03">baseline</E>
                         set of data that certified health IT must be able to make available for access and exchange (see section IV.B.1 of this preamble). However, this set of EHI is too limiting in terms of what actors are capable of making available in both the near and long term as is evident by compliance with HIPAA's right of access regulatory provision in 45 CFR 164.524.
                    </P>
                    <P>To be further responsive to commenters expressing compliance concerns about the EHI definition, we have established a new “Content and Manner” exception in this final rule (§ 171.301) that will provide actors time to adjust to the new information blocking paradigm and make EHI available for access, exchange, and use. The new exception permits an actor to provide, at a minimum, a limited set of EHI comprised of the data elements included in the USCDI for access, exchange, and use during the first 18 months after the compliance date of the information blocking provisions (24 months after publication of this final rule). The data elements represented in the USCDI represent an even more focused set of data than the finalized EHI definition (§ 171.102). We refer readers to section VIII.D.2.a of this final rule for further discussion of this new exception.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters argued both for and against the inclusion of price information in the EHI definition. Commenters that argued for the inclusion of price information stated that it was well within the meaning of the term health information found in the PHSA. Many of these commenters argued that the availability of this type of information would be helpful to patients in selecting and obtaining health care. Commenters also contended that the availability of price information would increase competition and reduce health care costs. Conversely, other commenters made various arguments for not including price information within the definition of EHI. Some of these commenters asserted that price information was not within the scope of health information as specified in section 3022 of the PHSA because Congress did not specifically include it. Commenters also asserted that price information is too vague and lacks standardization to be clearly understood and made available for access, exchange, and use. Other commenters contended that disclosing price information would violate trade secret laws and would harm competitive pricing by health plans.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The EHI definition codified through this final rule does not expressly include or exclude price information. However, to the extent that ePHI includes price information and is included in a designated record set, it would be considered EHI. This approach is intended to assure that the current scope of EHI for purposes of information blocking is aligned with the definitions of ePHI and designated record set under the HIPAA Rules, with limited exceptions.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters specifically questioned whether algorithms or processes that create EHI, or the clinical interpretation or relevancy of the results of the algorithms or processes, would be considered EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The EHI definition codified through this final rule does not expressly include or exclude algorithms or processes that create EHI, or the clinical interpretation or relevancy of the results of the algorithms or processes. However, any such information would be considered EHI if it was ePHI included in the designated record set (such as the inclusion of the clinical interpretation of an algorithm's results in an individual's clinical note). Like with price information, this approach is intended to ensure that the current scope of EHI for purposes of information blocking is aligned with the definitions of ePHI and designated record set under the HIPAA Rules, with limited exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters supported the position that health information which is de-identified in accordance with HIPAA regulations should not be considered EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree that health information that is de-identified consistent with the requirements of 45 CFR 164.514(b) should not be included in EHI. It is not, however, necessary to specifically exclude such de-identified information from the EHI definition because information that does not identify an individual, and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual, is not individually identifiable information, so it would not be EHI (
                        <E T="03">see</E>
                         45 CFR 164.514(a)). To note, once PHI has been de-identified, it is no longer considered to be PHI. So, such information would not be considered EHI by definition (see 45 CFR 164.514 (b)).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter viewed the proposed EHI definition as overly restrictive by requiring EHI to be individually identifiable.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The EHI definition codified through this final rule retains the core requirement that the health information be individually identifiable in order to be consistent with HIPAA and general health care industry practice regarding use and disclosure of health information.
                    </P>
                    <HD SOURCE="HD3">4. Price Information—Request for Information</HD>
                    <P>In the Proposed Rule, we requested comment on the technical, operational, legal, cultural, environmental, and other challenges to creating price transparency within health care, and posed multiple specific questions for commenters to consider (84 FR 7513 and 7514).</P>
                    <P>
                        We received over 1,000 comments regarding price information and price transparency in response to our request, which included recommendations from the HITAC. We thanks commenters for their comments and have shared this 
                        <PRTPAGE P="25805"/>
                        feedback with appropriate Department partners.
                    </P>
                    <HD SOURCE="HD3">5. Interests Promoted by the Information Blocking Provision</HD>
                    <HD SOURCE="HD3">a. Access, Exchange, and Use of EHI</HD>
                    <P>
                        We stated in the Proposed Rule that the information blocking provision promotes the ability to 
                        <E T="03">access, exchange, and use</E>
                         EHI, consistent with the requirements of applicable law. We interpreted the terms “access,” “exchange,” and “use” broadly, consistent with their generally understood meaning in the health IT industry and their function and context in the information blocking provision (84 FR 7514).
                    </P>
                    <P>We explained in the Proposed Rule that the concepts of access, exchange, and use are closely related: EHI cannot be used unless it can be accessed, and this often requires that the EHI be exchanged among different individuals or entities and through various technological means. Moreover, the technological and other means necessary to facilitate appropriate access and exchange of EHI vary significantly depending on the purpose for which the information will be used. We stated that this explanation is consistent with the way these terms are employed in the information blocking provision and in other relevant statutory provisions. Noting, for example, that section 3022(a)(2) of the PHSA contemplates a broad range of purposes for which EHI may be accessed, exchanged, and used—from treatment, care delivery, and other permitted purposes, to exporting complete information sets and transitioning between health IT systems, to supporting innovations and advancements in health information access, exchange, and use.</P>
                    <P>In addition, we stated in the Proposed Rule that we considered how the terms access, exchange, and use have been defined or used in existing regulations and other relevant health IT industry contexts. We explained that, while those definitions have specialized meanings and are not controlling for the purposes of information blocking, they are instructive insofar as they illustrate the breadth with which these terms have been understood in other contexts. We noted that the HIPAA Security Rule defines “access” as the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource (45 CFR 164.304). Last, we noted that the HIPAA Privacy Rule defines the term “use,” which includes the sharing, employment, application, utilization, examination, or analysis of individually identifiable health information within an entity that maintains the information (45 CFR 160.103).</P>
                    <P>We stated that the types of access, exchange, and use described above would be promoted under the information blocking provision, as would other types of access, exchange, or use not specifically contemplated in these or other regulations.</P>
                    <P>
                        We emphasized in the Proposed Rule the interrelated nature of the definitions and proposed to define these terms in § 171.102. For example, the definition of “use” that we proposed includes the ability to read, write, modify, manipulate, or apply EHI to accomplish a desired outcome or to achieve a desired purpose, while “access” is defined as the ability or means necessary to make EHI available for 
                        <E T="03">use.</E>
                         As such, we specified that the interference with “access” would include, for example, an interference that prevented a health care provider from writing EHI to its health IT or from modifying EHI stored in health IT, whether by the provider itself or by, or via, a third-party app. We encouraged comment on these definitions. In particular, we asked commenters to consider whether these definitions are broad enough to cover all of the potential purposes for which EHI may be needed and ways in which it could conceivably be used, now and in the future.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters supported our proposed definitions of “access,” “exchange,” and “use,” based on our broad interpretation of the definitions, which they stated supports interoperability. Several health IT developers and developer organizations stated that the definition of “access” was overly broad. They suggested that we clarify and narrow the scope of our proposed definition of “access.” One commenter specifically suggested that we clarify that “access” need not be provided through a direct interface. Some commenters suggested that we remove the proposed language regarding “any and all source systems.”
                    </P>
                    <P>Some commenters expressed concern that the proposed definition of “exchange” is overly broad. Other commenters requested additional clarity regarding the scope of the definition. One commenter suggested that we clarify the meaning of “transmission” within the definition.</P>
                    <P>Some health care providers and provider organizations stated that our proposed definition of “use” was overly broad. Some commenters suggested that we look to more established definitions of “use,” such as HIPAA. Other commenters suggested that the proposed definition would inappropriately increase administrative burden.</P>
                    <P>
                        <E T="03">Response.</E>
                         We have revised these definitions in response to comments. These revisions do not narrow the scope of the definitions in regard to their intended interpretation and purpose in supporting interoperability and the goals of the information blocking provision. We believe, however, the revisions and their explanations below will provide the necessary clarifications for stakeholders to properly implement and comply with the terms.
                    </P>
                    <HD SOURCE="HD3">Access</HD>
                    <P>
                        We have finalized the definition of “access” as “the ability or means necessary to make EHI available for exchange, use, or both” (§ 171.102). This final definition improves on the proposed definition (see 84 FR 7601) in a couple of ways. First, it makes clear that “access” is the ability or means necessary to make EHI available not only for “use,” but also for “exchange” or both (the proposed definition only included “for use”). This modification will provide clarity because, as we noted in the Proposed Rule, these terms are interrelated and EHI cannot be exchanged 
                        <E T="03">or</E>
                         used if it is inaccessible. Second, to be responsive to comments and in order to promote additional clarity in the definition, we have removed “including the ability to securely and efficiently locate and retrieve information from any and all source systems in which the information may be recorded or maintained” from the definition. This language was exemplary and resulted in some confusion among stakeholders. Last, we clarify that the definition of “access” is not limited to direct interfaces, which we believe is evident by the final definition.
                    </P>
                    <HD SOURCE="HD3">Exchange</HD>
                    <P>
                        We have finalized the definition of “exchange” as “the ability for electronic health information to be transmitted between and among different technologies, systems, platforms, or networks.” As with the finalized “access” definition, we have maintained the general scope of the proposed definition while modifying the definition for clarity. First, we removed “securely and efficiently” as proposed descriptors of the way that EHI is to be transmitted under the definition. While we continue to advocate for and promote secure and efficient exchange, we do not think this descriptive language is necessary within the definition of “exchange” because “exchange” for the purposes of the information blocking provision can 
                        <PRTPAGE P="25806"/>
                        occur regardless of whether the transaction is “secure” or “efficient.” Our intent with this definition was never to exclude unsecure or “inefficient” exchanges from the definition or enforcement of the information blocking provision because the exchange of EHI was not secure or “inefficient,” so we have removed this extraneous language. We also refer stakeholders to the information blocking exceptions included in this final rule that discuss how EHI may be transmitted and the importance of security as it relates to the access, exchange, and use of EHI.
                    </P>
                    <P>
                        Second, we have removed the provision at the end of the proposed definition, that in order for “exchange” to occur, it must be “in a manner that allows the information to be accessed and used.” This language was potentially confusing because the manner of transmittal is not a necessary component of the “exchange” definition. If EHI is exchanged but is done so in way that does not permit the use of the EHI, then that practice may implicate the information blocking provision because the “use” of the EHI is being prevented. Further, to be responsive to comments, we emphasize that “transmitted” within the definition is 
                        <E T="03">not</E>
                         limited to a one-way transmission, but instead is inclusive of 
                        <E T="03">all</E>
                         forms of transmission such as bi-directional and network-based transmission. We note this as a point of clarification, as it was always our intent that “transmission” would be interpreted this way.
                    </P>
                    <HD SOURCE="HD3">Use</HD>
                    <P>We have finalized “use” to mean “the ability for EHI, once accessed or exchanged, to be understood and acted upon.” Put another way, “use” is an individual or entity's ability to do something with the EHI once it has been accessed or exchanged. We believe this final definition is more concise and clear than the proposed definition—“the ability of health IT or a user of health IT to access relevant EHI; to comprehend the structure, content, and meaning of the information; and to read, write, modify, manipulate, or apply the information to accomplish a desired outcome or to achieve a desired purpose” (84 FR 7602). Again, we emphasize the general scope and meaning of the definition is the same as proposed as explained below.</P>
                    <P>First, we have removed language that is more appropriately used as examples in this preamble. For instance, the use of the word “understood” in the final definition encompasses the ability to comprehend various things such the structure, content, and meaning of the information from the proposed definition. However, we clarify that “understood” just like the proposed term “comprehend” does not mean the ability to understand the clinical significance or relevance of the EHI. For example, if an ambulatory provider received patient EHI from a hospital that included a risk score, the concept of “use” does not require the hospital to provide additional resources to interpret the score nor would the tool or technology needed to interpret the information be considered an interoperability element because its sole purpose is clinical interpretation.</P>
                    <P>Similarly to “understood,” “acted upon” within the final definition encompasses the ability to read, write, modify, manipulate, or apply the information from the proposed definition. We also clarify that “use” is bi-directional (to note, we also clarified above in the “exchange” discussion that “exchange” is bi-directional). Thus, an actor's practice could implicate the information blocking provision not only if the actor's practice interferes with the requestor's ability to read the EHI (one-way), but also if the actor's practice interferes with the requestor's ability to write the EHI (bi-directional) back to a health IT system.</P>
                    <P>We note that the ability “to access relevant EHI” from the proposed definition will fall under the “access” definition, particularly in light of the modifications we have made to the “access” definition discussed above. Last, we note that we have removed the requirement from the final definition that it would only be considered “use” if the action were “to accomplish a desired outcome or to achieve a desired purpose.” We do not believe this language is necessary because the ultimate purpose of the “use” of the EHI is not relevant to the definition of “use.”</P>
                    <P>We appreciate the comments suggesting that we look to more established definitions of “use,” such as that within the HIPAA Privacy Rule. We did consider adopting the HIPAA Privacy Rule definition, but ultimately decided that our finalized definition is more appropriate and easier to understand within the information blocking context. We also appreciate the comments suggesting that the proposed definition would inappropriately increase administrative burden; however, we do not believe there is a basis for such assertion, particularly with the clarifications we have provided and the focusing of the EHI definition.</P>
                    <HD SOURCE="HD3">b. Interoperability Elements</HD>
                    <P>
                        We proposed to use the term “interoperability element” to refer to any means by which EHI can be accessed, exchanged, or used. We proposed that the means of accessing, exchanging, and using EHI is not limited to functional elements and technical information but also encompasses technologies, services, policies, and other conditions 
                        <SU>127</SU>
                        <FTREF/>
                         necessary to support the many potential uses of EHI. Because of the evolving nature of technology and the diversity of privacy and other laws and regulations, institutional arrangements, and policies that govern the sharing of EHI, we did not provide an exhaustive list of interoperability elements in the Proposed Rule. We requested comment on the proposed definition.
                    </P>
                    <FTNT>
                        <P>
                            <SU>127</SU>
                             
                            <E T="03">See</E>
                             ONC, Connecting Health and Care for the Nation: A Shared Nationwide Interoperability Roadmap at x-xi, 
                            <E T="03">https://www.healthit.gov/topic/interoperability/interoperability-roadmap</E>
                             (Oct. 2015) [hereinafter “Interoperability Roadmap”].
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters supported the proposed definition, noting that the breadth and scope of the definition is appropriate. Some commenters requested clarifications and modifications regarding aspects of the proposed definition. A few commenters requested that we clarify whether specific functionalities and technologies, such as certified Health IT Modules and proprietary APIs, would be considered interoperability elements. A commenter requested, within the context of the Licensing Exception (§ 171.303), clarification regarding whether interoperability elements are limited to those elements to which an actor can lawfully confer rights or licenses without the agreement of a third party. A few commenters stated that the definition should exclude underlying substantive content or health facts because such content is not a potential means by which EHI may be accessed, exchanged, or used. One of those commenters also requested that we clarify that legally required data tags are excluded from the “interoperability element” definition. A commenter suggested that we clarify that whether a functionality is considered an interoperability element should be determined without regard to whether it can be protected under copyright or patent law. One commenter requested additional examples of interoperability elements. Another commenter requested clarification regarding the meaning of “transmit” within the definition.
                    </P>
                    <P>
                        Some commenters stated that the definition is too broad and should be narrowed. A couple of commenters 
                        <PRTPAGE P="25807"/>
                        stated that the definition is confusing and ambiguous. A few commenters noted that we should focus the definition on specific elements that are currently certified and/or are employed to support interoperability through existing standards and requirements that enable the exchange of EHI in a usable fashion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' support of the proposed definition, as well as the comments that requested clarifications and suggested improvements to the definition. We have streamlined the definition, with the intent of maintaining a broad definition of interoperability elements, and leveraged other regulatory and industry terms to add clarity. We have finalized the definition of “interoperability element” to mean hardware, software, integrated technologies or related licenses, technical information, privileges, rights, intellectual property, upgrades, or services that: (1) May be necessary to access, exchange, or use EHI; and (2) is controlled by the actor, which includes the ability to confer all rights and authorizations necessary to use the element to enable the access, exchange, or use of EHI.
                    </P>
                    <P>While this definition remains broad, it is confined by changes we have made to other parts of the information blocking section. Specifically, the more focused definitions of “electronic health information” and “access,” “exchange,” or “use” will result in a smaller scope of interoperability elements, as defined above, being necessary to enable access, exchange, or use of EHI. Further, under the Content and Manner Exception (§ 171.301), we establish that an actor is not required to respond to a request to access, exchange, or use EHI in the manner requested if the actor would be required to license its IP (which could constitute an interoperability element) and cannot reach agreeable terms for the license with the requestor (§ 171.301(b)(1)(i)(B)). This means that actors who do not want to license their interoperability elements will not be required to do so if they are able to respond in an alternative manner in accordance with § 171.301(b)(2).</P>
                    <P>
                        We believe the above definition improves on the proposed definition in multiple ways. First, while preserving the meaning described in the Proposed Rule that would constitute an interoperability element (
                        <E T="03">i.e.,</E>
                         hardware, software, technical information, technology, service, license, right, privilege), we have removed descriptive language and examples from the regulation text. Such language did not add clarity, as it was not exhaustive as noted in the regulation text, which included the language: “Any other means by which electronic health information may be accessed, exchanged, or used.” The removal of this language makes the definition clearer and more concise. We note that we provide examples of “interoperability elements” in the discussion below.
                    </P>
                    <P>Second, we leveraged the definition of “health information technology” from title XXX of the PHSA (specifically, section 3000(5) of the PHSA), as added by title XIII of the HITECH Act. The Cures Act amended title XXX of the PHSA to establish the information blocking provision in section 3022 of the PHSA. Section 3000(5) of 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.” We emphasize that this definition includes intellectual property.</P>
                    <P>When we drafted the Proposed Rule, we chose to use the term “interoperability element” to describe the means necessary to access, exchange, or use EHI instead of “health IT” because we believed that defining a new term (interoperability element) would allow us to tailor and focus the definition to the specific issue of information blocking. However, after further reflection and review of stakeholder comments—specifically those requesting additional clarity regarding the definition of “interoperability element”—we believe a better approach is to leverage the definition of “health information technology” from section 3000(5) of the PHSA because that definition provides the statutory basis for the types of technology, services, functionality necessary to support interoperability, including the access, exchange, and use of EHI. We believe this approach of leveraging an established, statutory definition will promote transparency and clarify ONC's expectations for regulated actors.</P>
                    <P>
                        As such, we have added “integrated technologies,” “intellectual property,” and “upgrades” from the PHSA definition into our definition of interoperability element. These additions will strengthen the “interoperability element” definition by explicitly identifying types of interoperability elements that 
                        <E T="03">would have been covered</E>
                         by our proposed definition, but were not called out in the proposed definition (these types of interoperability elements would have been covered by the provision in the proposed definition that an interoperability element could be any other means by which EHI may be accessed, exchanged, or used). We chose not to substitute the PHSA health information technology definition in its entirety for the “interoperability element” definition in this final rule because some aspects do not fit within the “interoperability element” definition. For instance, the concept of “packaged solutions” is undefined and would not add clarity to the interoperability element definition. Thus, we believe this approach will achieve our goal of establishing a definition of interoperability element that is tailored for the information blocking context.
                    </P>
                    <P>
                        Last, we have clarified within the definition that a requisite component of an interoperability element is that it is 
                        <E T="03">controlled by the actor.</E>
                         As used in the interoperability element definition, controlled by the actor includes the ability to confer all rights and authorizations necessary to use the element to enable the access, exchange, or use of EHI. In order to make this point clear, we have added and finalized paragraph (2) within the interoperability element definition (see § 171.102). Thus, if an actor could not confer a right or authorization necessary to use the interoperability element to enable the access, exchange, or use of electronic health information, (
                        <E T="03">e.g.,</E>
                         by way of sub-license or assignment), the actor would not have the requisite “control” under the “interoperability element” definition. This clarification reinforces our position that our rule does not require or encourage actors to infringe on IP rights.
                    </P>
                    <P>
                        We appreciate the comments that asked that we specify whether specific functionalities and technologies, such as certified Health IT Modules and proprietary APIs, would be considered interoperability elements. We clarify that most certified Health IT Modules and proprietary APIs would be considered interoperability elements under the interoperability element definition. We also clarify that the underlying substantive content or health facts are not considered interoperability elements because substantive content and health facts are not a 
                        <E T="03">means</E>
                         by which EHI is accessed, exchanged, or used. Regarding legally required data tags, we would need additional information concerning the specific data tag to determine whether it could constitute an interoperability element. 
                        <PRTPAGE P="25808"/>
                        Generally, data tags would likely be considered technical information under the “interoperability element” definition, but such data tags would need to be necessary to access, exchange, or use EHI to be considered an interoperability element.
                    </P>
                    <P>A determination regarding whether a functionality is considered an interoperability element will be determined without regard to whether it is protected under copyright or patent law. In fact, the finalized definition of interoperability element includes “licenses” and “intellectual property.” We have also established an exception to information blocking that supports the licensing of intellectual property. Thus, we make clear that functionalities generally covered by copyright, patent, or other such laws can be interoperability elements.</P>
                    <P>In response to the commenter who requested additional examples of interoperability elements, we provide the following non-exhaustive list of examples:</P>
                    <P>• Functional elements of health IT that could be used to access, exchange, or use EHI for any purpose, including information exchanged or maintained in disparate media, information systems, or by HINs/HIEs;</P>
                    <P>• Technical information that describes the functional elements of technology, such as a standard, specification, protocol, data model, or schema, that would be required to use a functional element of a certain technology, including for the purpose of developing compatible technologies that incorporate or use the functional elements;</P>
                    <P>• System resources, technical infrastructure, or HIN/HIE elements that are required to enable the use of a compatible technology in production environments; or</P>
                    <P>• Licenses, rights, or privileges that may be required to commercially offer and distribute compatible technologies and make them available for use in production environments.</P>
                    <P>
                        We appreciate the comments requesting that we clarify and narrow the “interoperability element” definition. As discussed above, we believe the revised definition addresses commenters' concerns regarding the clarity of the definition. Responsive to commenters, the final definition is also narrower than the proposed definition, as we have removed the proposed provision that an interoperability element could be 
                        <E T="03">any other means</E>
                         by which EHI may be accessed, exchanged, or used (see 84 FR 7602).
                    </P>
                    <P>We have decided not to focus the definition on certified elements or existing standards or requirements because such a narrowed focus would unduly limit the definition, interoperability, and the access, exchange, and use of EHI. The finalized definition reflects that there are countless means by which EHI may be accessed, exchanged, or used that are not certified or standardized. We note that the new Content and Manner Exception (§ 171.301) supports certified and standards-based exchange as suggested by the commenter. We refer readers to VIII.D.2.a of this preamble for a discussion of that exception.</P>
                    <P>We note that we have removed the term “transmit” from the regulatory text because it no longer fit in the context of other changes made to the definition.</P>
                    <HD SOURCE="HD3">6. Practices That May Implicate the Information Blocking Provision</HD>
                    <P>
                        To meet the definition of information blocking under section 3022(a) of the PHSA, a practice must be 
                        <E T="03">likely to interfere with, prevent, or materially discourage</E>
                         the access, exchange, or use of EHI. In this section and elsewhere in the Proposed Rule, we discussed various types of hypothetical practices that 
                        <E T="03">could</E>
                         implicate the information blocking provision. We did this to illustrate the scope of the information blocking provision and to explain our interpretation of various statutory concepts. However, we stressed that the types of practices discussed in the preamble of the Proposed Rule are illustrative and not exhaustive and that many other types of practices could also implicate the provision. We emphasized that the fact that we did not identify or discuss a particular type of practice did not imply that it is less serious than those that were discussed in the preamble. Indeed, we explained in the Proposed Rule that because information blocking may take many forms, it is not possible to anticipate or catalog all potential types of practices that may raise information blocking concerns.
                    </P>
                    <P>We emphasized that any analysis of information blocking necessarily requires a careful consideration of the individual facts and circumstances, including whether the practice was required by law, whether the actor had the requisite knowledge, and whether an exception applies. A practice that seemingly meets the statutory definition of information blocking would not be information blocking if it was required by law, if one or more elements of the definition were not met, or if it was covered by one of the exceptions for reasonable and necessary activities.</P>
                    <P>In accordance with section 3022(a)(3) of the PHSA, we proposed in the Proposed Rule to establish exceptions to the information blocking provision for certain reasonable and necessary activities. We proposed that if an actor can establish that an exception applies to each practice for which a claim of information blocking has been made, including that the actor satisfied all applicable conditions of the exception at all relevant times, then the practice would not constitute information blocking.</P>
                    <P>
                        <E T="03">Comments.</E>
                         There was broad support from commenters regarding the categories of practices identified in the Proposed Rule that may implicate the information blocking provision, as well as the non-exhaustive list of specific examples provided in the Proposed Rule to assist with compliance. Commenters noted that the illustrative examples provided were helpful in providing further clarity on the scope of the information blocking provision. Many commenters noted that considerable barriers continue to obstruct both provider and patient access to patient data and our approach to the information blocking provision can increase access to this data.
                    </P>
                    <P>
                        Several commenters suggested the need for a comprehensive inventory or repository of examples, including examples of information blocking conduct that have been submitted to ONC. Many commenters suggested specific clarifications and modifications to the examples provided in the Proposed Rule in the sections below, as well as additional examples for inclusion in the final rule, such as additional examples applicable to specific contexts (
                        <E T="03">e.g.,</E>
                         imaging providers, and pharmacies) or specific practices (
                        <E T="03">e.g.,</E>
                         practices involving clinical data registries and pharmacogenomics).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support and feedback. We have not revised the examples provided in the Proposed Rule because we believe they are clear, accurate, and helpful to readers. To be responsive to commenters who requested additional examples be added to the final rule, we have added examples in the discussion of “Limiting or Restricting the Interoperability of Health IT” in section VIII.C.6.c.ii. as well as additional examples within the preamble discussion for the exceptions. We used commenters' suggestions to help inform these examples and highlight important use cases and circumstances that required additional clarification. We emphasize that these listed examples are illustrative, but not exhaustive.
                    </P>
                    <P>
                        We also clarify that when we say that the actor must satisfy all applicable conditions of the exception at 
                        <E T="03">
                            all 
                            <PRTPAGE P="25809"/>
                            relevant times
                        </E>
                         to meet each exception, 
                        <E T="03">all relevant times</E>
                         means any time when an actor's practice relates to the access, exchange, or use of EHI.
                    </P>
                    <HD SOURCE="HD3">a. Prevention, Material Discouragement, and Other Interference</HD>
                    <P>We explained in the Proposed Rule that the information blocking provision and its enforcement subsection do not define the terms “interfere with,” “prevent,” and “materially discourage,” and use these terms collectively and without differentiation. Based on our interpretation of the information blocking provision and the ordinary meanings of these terms in the context of EHI, we interpreted these terms to not be mutually exclusive. Instead, prevention and material discouragement may be understood as types of interference, and that use of these terms in the statute to define information blocking illustrates the desire to reach all practices that an actor knows, or should know, are likely to prevent, materially discourage, or otherwise interfere with the access, exchange, or use of EHI. Consistent with this understanding, we used the terms “interfere with” and “interference” as inclusive of prevention and material discouragement.</P>
                    <P>We explained that interference could take many forms. In addition to the prevention or material discouragement of access, exchange, or use, we stated that interference could include practices that increase the cost, complexity, or other burdens associated with accessing, exchanging, or using EHI. Interference could also include practices that limit the utility, efficacy, or value of EHI that is accessed, exchanged, or used, such as by diminishing the integrity, quality, completeness, or timeliness of the data. Relatedly, to avoid potential ambiguity and clearly communicate the full range of potential practices that could implicate the information blocking provision, we proposed to codify a definition of “interfere with” in § 171.102, consistent with our interpretation set forth above (84 FR 7516).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments on our proposed definition of “interfere with.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the definition of “interfere with” (also referred to as “interference”) in § 171.102 as proposed, but with a modification to remove the phrase “access, exchange, or use of electronic health information” from the definition. We removed this language because it was not necessary in the definition, and to avoid duplication, as we often say in the preamble of this final rule that “a practice interferes with access, exchange or use of EHI.” We also note that we received many comments requesting clarification of whether certain practices would constitute interference with the access, exchange, and use of EHI, and thus implicate the information blocking provision. We address these comments in section VIII.C.6.c (Examples of Practices Likely to Interfere with the Access, Exchange or Use of EHI) below.
                    </P>
                    <HD SOURCE="HD3">b. Likelihood of Interference</HD>
                    <P>
                        We noted in the Proposed Rule that the information blocking provision is preventative in nature. That is, the information blocking provision proscribes practices that are 
                        <E T="03">likely</E>
                         to interfere with (including preventing or materially discouraging) access, exchange, or use of EHI—whether or not such harm materializes. By including both the likely and the actual effects of a practice, the information blocking provision encourages individuals and entities to avoid engaging in practices that undermine interoperability, and to proactively promote access, exchange, and use of EHI.
                    </P>
                    <P>We explained that a practice would satisfy the information blocking provision's “likelihood” requirement if, under the circumstances, there is a reasonably foreseeable risk that the practice will interfere with access, exchange, or use of EHI. We explained that a policy or practice that limits timely access to information in an appropriate electronic format creates a reasonably foreseeable likelihood of interfering with the use of the information.</P>
                    <P>We noted that whether the risk of interference is reasonably foreseeable will depend on the particular facts and circumstances attending the practice or practices at issue. Because of the number and diversity of potential practices, and the fact that different practices will present varying risks of interfering with access, exchange, or use of EHI, we did not attempt to anticipate all of the potential ways in which the information blocking provision could be implicated. Nevertheless, to assist with compliance, we clarified certain circumstances in which, based on our experience, a practice will almost always be likely to interfere with access, exchange, or use of EHI. We cautioned that the situations listed are not exhaustive and that other circumstances may also give rise to a very high likelihood of interference under the information blocking provision. We noted that in each case, the totality of the circumstances should be evaluated as to whether a practice is likely to constitute information blocking.</P>
                    <P>In the Proposed Rule, we stated that we believe that information blocking concerns are especially pronounced when the conduct at issue has the potential to interfere with the access, exchange, or use of EHI that is created or maintained during the practice of medicine or the delivery of health care services to patients, which we referred to collectively as “observational health information” (84 FR 7516 and7517). We received a few comments seeking clarification regarding our use of the term “observational health information” or that we provide a regulatory definition for the term.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received some comments requesting clarification regarding the meaning of “timely” access in the discussion in the Proposed Rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have not established a set timeframe for what “timely” access means because there is so much variability regarding what “timely” will mean based on the specific facts and circumstances, and particularly with regard to the broad scope of health IT being discussed. We emphasize that whether access is considered timely will be determined based on the specific facts and circumstances. We refer readers to the discussion in section VIII.C.6.c. on “Limiting or Restricting the Interoperability of Health IT” where we discuss how slowing or delaying access, exchange, or use of EHI could be considered information blocking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any additional comments regarding out interpretation of the information blocking provision's “likelihood” requirement discussed above.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized our interpretation as described above.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments requesting clarification regarding the meaning of “observational health information” as used in the Proposed Rule.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed earlier in section VIII.C.3, after consideration of concerns raised by commenters, we have not finalized the definition of EHI as proposed. Instead, we have finalized a more focused definition of EHI. Because we have finalized a definition of EHI with a more focused scope than proposed, we no longer believe our proposed approach regarding observational health information is necessary. Accordingly, we are not using the term “observational health information” in this final rule. We refer readers to section VIII.C.3. for further discussion of the definition of EHI.
                        <PRTPAGE P="25810"/>
                    </P>
                    <HD SOURCE="HD3">i. Purposes for Which Information May Be Needed</HD>
                    <P>We explained in the Proposed Rule that the information blocking provision will almost always be implicated when a practice interferes with access, exchange, or use of EHI for certain purposes, including but not limited to:</P>
                    <P>
                        • Providing patients with access to their EHI and the ability to exchange and use it without special effort (
                        <E T="03">see</E>
                         section VII.B.4).
                    </P>
                    <P>• Ensuring that health care professionals, care givers, and other authorized persons have the EHI they need, when and where they need it, to make treatment decisions and effectively coordinate and manage patient care and can use the EHI they may receive from other sources.</P>
                    <P>• Ensuring that payers and other entities that purchase health care services can obtain the information they need to effectively assess clinical value and promote transparency concerning the quality and costs of health care services.</P>
                    <P>• Ensuring that health care providers can access, exchange, and use EHI for quality improvement and population health management activities.</P>
                    <P>• Supporting access, exchange, and use of EHI for patient safety and public health purposes.</P>
                    <P>We emphasized that the need to ensure that EHI is readily available and usable for these purposes is paramount. Therefore, practices that increase the cost, difficulty, or other burdens of accessing, exchanging, or using EHI for these purposes would almost always implicate the information blocking provision. We stressed that individuals and entities that develop health IT or have a role in making these technologies and services available should consider the impact of their actions and take steps to support interoperability and avoid impeding the availability or use of EHI (84 FR 7517).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments of the discussion above.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Consistent with the Proposed Rule, in this final rule we continue to emphasize that practices that interfere with the access, exchange, or use of EHI for the purposes listed in this section and that do not meet any of the final exceptions will almost always implicate the information blocking provision and will be inherently suspect. These practices may jeopardize the core functions of the health care system that require the access, exchange, or use of EHI. We believe there are few, if any, legitimate reasons for an actor to interfere with the use of EHI in the context of these purposes.
                    </P>
                    <P>We specifically emphasize that practices that involve an actor charging an individual a fee to access, exchange, or use their EHI would be inherently suspect, as discussed in more detail in the Fees Exception (section VIII.D.2.b), as there are few, if any, legitimate reasons for an actor to charge an individual for access to their EHI.</P>
                    <HD SOURCE="HD3">ii. Control Over Essential Interoperability Elements; Other Circumstances of Reliance or Dependence</HD>
                    <P>We explained in the Proposed Rule that an actor may have substantial control over one or more interoperability elements that provide the only reasonable means of accessing, exchanging, or using EHI for a particular purpose. We noted that, in these circumstances, any practice by the actor that could impede the use of the interoperability elements—or that could unnecessarily increase the cost or other burden of using the elements—would almost always implicate the information blocking provision.</P>
                    <P>
                        We explained that the situation described above is most likely when customers or users are dependent on an actor's technology or services, which can occur for any number of reasons. For example, technological dependence may arise from legal or commercial relations, such as a health care provider's reliance on its EHR developer to ensure that EHI managed on its behalf is accessible and usable when it is needed. Relatedly, most EHI is currently stored in EHRs and other source systems that use proprietary data models or formats. Knowledge of the data models, formats, or other relevant technical information (
                        <E T="03">e.g.,</E>
                         proprietary APIs) is necessary to understand the data and make efficient use of it in other applications and technologies. Because this information is routinely treated as confidential or proprietary, the developer's cooperation is required to enable uses of the EHI that go beyond the capabilities provided by the developer's technology. This includes the capability to export complete information sets and to migrate data in the event that a user decides to switch to a different technology.
                    </P>
                    <P>We noted that separate from these contractual and intellectual property issues, users may become “locked in” to a particular technology, HIE, or HIN for financial or business reasons. For example, many health care providers have invested significant resources to adopt EHR technologies—including costs for deployment, customization, data migration, and training—and have tightly integrated these technologies into their information management strategies, clinical workflows, and business operations. As a result, they may be reluctant to switch to other technologies due to the significant cost and disruption this would entail.</P>
                    <P>
                        We explained that another important driver of technological dependence is the “network effects” of health IT adoption, which are amplified by reliance on technologies and approaches that are not standardized and do not enable seamless interoperability. Consequently, health care providers and other health IT users may gravitate towards and become reliant on the proprietary technologies, HIEs, or HINs that have been adopted by other individuals and entities with whom they have the greatest need to exchange EHI. We noted that these effects may be especially pronounced within particular products or geographic areas. For example, a HIN that facilitates certain types of exchange or transactions may be so widely adopted that it is a 
                        <E T="03">de facto</E>
                         industry standard. A similar phenomenon may occur within a particular geographic area once a critical mass of hospitals, physicians, or other providers adopt a particular EHR technology, HIE, or HIN.
                    </P>
                    <P>
                        We emphasized that in these and other analogous circumstances of reliance or dependence, there is a heightened risk that an actor's conduct will interfere with access, exchange, or use of EHI. To assist with compliance, we highlighted the following common scenarios, based on our outreach to stakeholders, in which actors exercise control over key interoperability elements.
                        <SU>128</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>128</SU>
                             As an important clarification, we note that control over interoperability elements may exist with or without the actor's ability to manipulate the price of the interoperability elements in the market.
                        </P>
                    </FTNT>
                    <P>Health IT developers of certified health IT that provide EHR systems or other technologies used to capture EHI at the point of care are in a unique position to control subsequent access to and use of that information.</P>
                    <P>• HINs and HIEs may be in a unique position to control the flow of information among particular persons or for particular purposes, especially if the HIN or HIE has achieved significant adoption in a particular geographic area or for a particular type of health information use case.</P>
                    <P>
                        • Similar control over EHI may be exercised by other entities, such as health IT developers of certified health IT, that supply or control proprietary technologies, platforms, or services that are widely adopted by a class of users or that are a “de facto standard” for 
                        <PRTPAGE P="25811"/>
                        certain types of EHI exchanges or transactions.
                    </P>
                    <P>• Health care providers within health systems and other entities that provide health IT platforms, infrastructure, or information sharing policies may have a degree of control over interoperability or the movement of data within a geographic area that is functionally equivalent to the control exercised by a dominant health IT developer, HIN, or HIE.</P>
                    <P>To avoid engaging in conduct that may be considered information blocking, actors with control over interoperability elements should be careful not to engage in practices that exclude persons from the use of those elements or create artificial costs or other impediments to their use.</P>
                    <P>We encouraged comment on these and other circumstances that may present an especially high likelihood that a practice will interfere with access, exchange, or use of EHI within the meaning of the information blocking provision.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters appreciated the examples provided and ONC's acknowledgement in the Proposed Rule that certain parties are in a unique position to control access, exchange, and use of EHI. Other commenters urged ONC to only hold accountable those parties that actually have control of the EHI or control of interoperability elements necessary to access, exchange, or use the EHI in question.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support. We stress that any analysis of whether an actor's practices constitute information blocking will depend on the particular facts and circumstances of the case, which may include an assessment of the actor's control over the EHI or interoperability elements necessary to access, exchange, or use the EHI in question, as applicable. A key element of information blocking is that the actor's practice is likely to interfere with an individual or entity's ability to access, exchange, or use EHI. Thus, we look at accountability through the lens of whether the actor is the individual or entity engaging in the practice.
                    </P>
                    <P>Regarding the comment that we should only hold accountable those parties that actually have control of the EHI or interoperability elements necessary to access, exchange, or use the EHI, we note that we have addressed this issue within preamble discussion concerning the definition of “interoperability element” (VIII.C.5.b), Infeasibility Exception (VIII.D.1.d), and Content and Manner Exception (VIII.D.2.a). We refer readers to those discussions.</P>
                    <HD SOURCE="HD3">c. Examples of Practices Likely To Interfere With Access, Exchange, or Use of EHI</HD>
                    <P>To further clarify the scope of the information blocking provision, we described in the Proposed Rule several types of practices that would be likely to interfere with access, exchange, or use of EHI. Those examples clarified and expanded on those set forth in section 3022(a)(2) of the PHSA.</P>
                    <P>Because information blocking can take many forms, we emphasized that the categories of practices described in the Proposed Rule were illustrative only and did not provide an exhaustive list or comprehensive description of practices that may implicate the information blocking provision and its penalties. We also reiterated that each case will turn on its unique facts. We noted that, for the categories of practices described in the Proposed Rule, we did not consider the applicability of any exceptions. We reiterate that the examples provided in the Proposed Rule were designed to provide greater clarity on the various types of hypothetical practices that could implicate the information blocking provision.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments requesting that we revise or clarify examples provided in the Proposed Rule in the following sections.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have not revised or clarified the majority of the examples for purposes of this final rule, and we believe the 
                        <E T="03">majority</E>
                         of the examples are still applicable. We note in the discussion below necessary clarifications concerning concepts expressed in some of the proposed examples. We refer readers to the Proposed Rule (84 FR 7518 through 7521) for a complete listing of the examples provided for each category of practices below.
                    </P>
                    <HD SOURCE="HD3">i. Restrictions on Access, Exchange, or Use</HD>
                    <P>We explained in the Proposed Rule that the information blocking provision establishes penalties, including civil monetary penalties, or requires appropriate disincentives, for practices that restrict access, exchange, or use of EHI for permissible purposes. We noted that one means by which actors may restrict access, exchange, or use of EHI is through formal restrictions. These may be expressed in contract or license terms, EHI sharing policies, organizational policies or procedures, or other instruments or documents that set forth requirements related to EHI or health IT. Additionally, in the absence of an express contractual restriction, an actor may achieve the same result by exercising intellectual property or other rights in ways that restrict access, exchange, or use (84 FR 7518).</P>
                    <P>We explained that access, exchange, or use of EHI can also be restricted in less formal ways. The information blocking provision may be implicated, for example, where an actor simply refuses to exchange or to facilitate the access or use of EHI, either as a general practice or in isolated instances. The refusal may be expressly stated or it may be implied from the actor's conduct, such as where the actor ignores requests to share EHI or provide interoperability elements; gives implausible reasons for not doing so; or insists on terms or conditions that are so objectively unreasonable that they amount to a refusal to provide access, exchange, or use of the EHI (84 FR 7518).</P>
                    <P>We emphasized that restrictions on access, exchange, or use that are required by law would not implicate the information blocking provision. Moreover, we recognized that some restrictions, while not required by law, may be reasonable and necessary for the privacy and security of individuals' EHI and noted that such practices may qualify for protection under an exception (84 FR 7519).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested that we clarify the types of contract and agreement terms that could implicate the information blocking provision beyond terms specifying fees and the licensing of intellectual property rights. Some commenters stated that “legacy EHR platforms” impede real time data flow between EHRs and the clinical workflow, including the use of third-party clinical decision support applications, through various contract terms. Many commenters also indicated that EHR developers place onerous contract terms on developers of applications that enable patient access to EHI through APIs. A few commenters asserted that a business associate (BA), as defined under the HIPAA Privacy Rule, should not be liable under the information blocking provision (or there should be an exception for information blocking) for not responding to or fulfilling requests for access, exchange, or use of EHI if such access, exchange, or use of EHI would violate the BA's business associate agreement (BAA).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We first clarify that all of the scenarios provided by the commenters might implicate the information blocking provision. We offer specific situations as follows where there might be an implication. As a first example, an actor (
                        <E T="03">e.g.,</E>
                         a health care provider that is a covered entity 
                        <PRTPAGE P="25812"/>
                        under HIPAA) may want to engage an entity for services (
                        <E T="03">e.g.,</E>
                         use of a clinical decision support application (“CDS App Developer”)) that require the CDS App Developer to enter into a BAA with the health care provider and, in order to gain access and use of the EHI held by another BA of the health care provider (
                        <E T="03">e.g.,</E>
                         EHR developer of certified health IT), the CDS App Developer is required by the EHR developer of certified health IT to enter into a contract to access its EHR technology. As a second example, an entity may offer an application that facilitates patients' access to their EHI through an API maintained by an actor (
                        <E T="03">e.g.,</E>
                         EHR developer of certified health IT) that is a BA of a health care provider that is a covered entity under HIPAA. As a third example, a health care provider may request EHI from an actor that is a BA of another health care provider under HIPAA, such as an EHR developer of certified health IT or HIN, that is contracted to make EHI available for treatment purposes.
                    </P>
                    <P>In response to comments and for the situations described above, we clarify that contracts and agreements can interfere with the access, exchange, and use of EHI through terms besides those that specify unreasonable fees and commercially unreasonable licensing terms (see sections VIII.D.2.b (Fees) and VIII.D.2.c (Licensing) for further discussion of unreasonable fees and commercially unreasonable licensing terms and associated exceptions to the information blocking provision). For instance, a contract may implicate the information blocking provision if it included unconscionable terms for the access, exchange, or use of EHI or licensing of an interoperability element, which could include, but not be limited to, requiring a software company that produced a patient access application to relinquish all IP rights to the actor or agreeing to indemnify the actor for acts beyond standard practice, such as gross negligence on part of the actor. Such terms may be problematic with regard to information blocking in situations involving unequal bargaining power related to accessing, exchanging, and using EHI.</P>
                    <HD SOURCE="HD3">Business Associate Agreements (BAAs)</HD>
                    <P>
                        We designed the final rule to operate in a manner consistent with the framework of the HIPAA Privacy Rule and other laws providing privacy rights for patients. Foremost, we do not require the disclosure of EHI in any way that would not already be permitted under the HIPAA Privacy Rule (or other Federal or State law). However, if an actor is 
                        <E T="03">permitted</E>
                         to provide access, exchange, or use of EHI under the HIPAA Privacy Rule (or any other law), then the information blocking provision would require that the actor provide that access, exchange, or use of EHI so long as the actor is not prohibited by law from doing so (assuming that no exception is available to the actor).
                    </P>
                    <P>
                        Under the HIPAA Privacy Rule, a BAA must contain the elements specified in 45 CFR 164.504(e), including a description of the permitted and required uses of PHI by the business associate, and provide that the business associate will not use or further disclose the protected health information other than as permitted or required by the contract or as required by law.
                        <SU>129</SU>
                        <FTREF/>
                         While the information blocking provision does not require actors to violate these agreements, a BAA or its associated service level agreements must not be used in a discriminatory manner by an actor to forbid or limit disclosures that otherwise would be permitted by the Privacy Rule. For example, a BAA entered into by one or more actors that permits access, exchange, or use of EHI by certain health care providers for treatment should generally not prohibit or limit the access, exchange, or use of the EHI for treatment by other health care providers of a patient.
                    </P>
                    <FTNT>
                        <P>
                            <SU>129</SU>
                             45 CFR 164.514(e)(3) limits the use and disclosure of a limited data set (LDS) to only the purposes of research, public health or health care operations. Some of the other restrictions on use and disclosure by a party that receives LDS Recipient are similar to those imposed by the HIPAA Rules on business associates so the discussion that follows generally applies to recipients of LDS and their data use agreements as well as to business associates (and their business associate agreements) to the extent of such similar provisions.
                        </P>
                    </FTNT>
                    <P>
                        To be clear, both the health care provider(s) who initiated the BAA and the BA who may be an actor under the information blocking provision (
                        <E T="03">e.g.,</E>
                         a health IT developer of certified health IT) would be subject to the information blocking provision in the instance described above. To illustrate the potential culpability of a BA, a BA with significant market power may have contractually prohibited or made it difficult for its covered entity customers to exchange EHI, maintained by the BA, with health care providers that use an EHR system of one of the BA's competitors. To determine whether there is information blocking, the actions and processes (
                        <E T="03">e.g.,</E>
                         negotiations) of the actors in reaching the BAA and associated service level agreements would need to be reviewed to determine whether there was any action taken by an actor that was likely to interfere with the access, exchange, or use of EHI, and whether the actor had the requisite intent. We further note that if the BA has an agreement with the covered entity to provide EHI to a third party that requests it and the BA refuses to provide the access, exchange, or use of EHI to a requestor in response to the request received by the CE, then the BA (who is also an actor under the information blocking provision) may have violated the information blocking provision unless an exception applied.
                    </P>
                    <HD SOURCE="HD3">Successors to Contractors and Agreements</HD>
                    <P>We note that there may be circumstances in which there is a successor to a contract or agreement when, for example, an actor goes out of business, a provider leaves a practice, or an actor engages in a merger or adopts a new corporate structure. If not handled appropriately, it is possible that information blocking could occur.</P>
                    <HD SOURCE="HD3">ii. Limiting or Restricting the Interoperability of Health IT</HD>
                    <P>We explained in the Proposed Rule that the information blocking provision includes practices that restrict the access, exchange, or use of EHI in various ways (see section 3022(a)(2) of the PHSA). These practices could include, for example, disabling or restricting the use of a capability that enables users to share EHI with users of other systems or to provide access to EHI to certain types of persons or for certain purposes that are legally permissible. In addition, the information blocking provision may be implicated where an actor configures or otherwise implements technology in ways that limit the types of data elements that can be exported or used from the technology. We noted that other practices that would be suspect include configuring capabilities in a way that removes important context, structure, or meaning from the EHI, or that makes the data less accurate, complete, or usable for important purposes for which it may be needed. Likewise, implementing capabilities in ways that create unnecessary delays or response times, or that otherwise limit the timeliness of EHI accessed or exchanged, may interfere with the access, exchange, and use of that information and therefore implicate the information blocking provision. We noted that any conclusions regarding such interference would be based on fact-finding specific to each case and would need to consider the applicability of the exceptions.</P>
                    <P>
                        We explained that the information blocking provision would be implicated if an actor were to deploy technological measures that limit or restrict the ability to reverse engineer the functional 
                        <PRTPAGE P="25813"/>
                        aspects of technology in order to develop means for extracting and using EHI maintained in the technology. We noted that this may include, for example, employing technological protection measures that, if circumvented, would trigger liability under the Digital Millennium Copyright Act (see 17 U.S.C. 1201) or other laws.
                    </P>
                    <HD SOURCE="HD3">Additional Examples</HD>
                    <P>In the context of ONC's certification rules, including certification criteria and Conditions and Maintenance of Certification requirements, we provide the following more explicit examples of actions by actors that would likely constitute information blocking.</P>
                    <P>The first example of a technical interference that restricts the interoperability of health IT relates to the publication of “FHIR service base URLs” (sometimes also referred to as “FHIR endpoints”). As discussed in the API Condition of Certification preamble (section VII.B.4), an API User needs to know a certified API technology's FHIR service base URL to interact with the certified API technology. This knowledge is foundational for the use of certified API technology without special effort. Therefore, a FHIR service base URL cannot be withheld by an actor as it (just like many other technical interfaces) is necessary to enable the access, exchange, and use of EHI. Notably, in the case of patients seeking access to their EHI, the public availability of FHIR service base URLs is an absolute necessity and without which the access, exchange, and use of EHI would be prevented. Thus, any action by an actor to restrict the public availability of URLs in support of patient access would be more than just likely to interfere with the access, exchange, or use of EHI; it would prevent such access, exchange, and use. Accordingly, as noted in § 170.404(b)(2), a Certified API Developer must publish FHIR service base URLs for certified API technology that can be used by patients to access their electronic health information.</P>
                    <P>
                        Consistent with this example, the above interpretation means that API Information Sources (
                        <E T="03">i.e.,</E>
                         health care providers) who locally manage their FHIR servers without Certified API Developer assistance cannot refuse to provide to Certified API Developers the FHIR service base URL(s) that is/are necessary for patients to use to access their EHI. Equally, pursuant to the Maintenance of Certification requirement finalized for Certified API Developers in § 170.404, they would be required to publish the FHIR service base URLs they centrally manage on behalf of API Information Sources. We also clarify that the public availability of FHIR service base URLs is a requirement that is scoped specifically to the context of patients' access to their EHI and is not intended to be interpreted as requiring all FHIR service base URLs to be made publicly available (
                        <E T="03">i.e.,</E>
                         FHIR service base URLs that are created and used among business partners would not need to be made publicly available).
                    </P>
                    <P>Along the same lines discussed in the example directly above, for a patient to be able to use an application of their choice with certified API technology, the software application will need to be “registered.” In that regard, as a second example, an actor's refusal to register a software application that enables a patient to access their EHI would effectively prevent its use given that registration is a technical prerequisite for software applications to be able to connect to certified API technology. As a result, such refusals in the context of patient access unless otherwise addressed in this rule would be highly suspect and likely to implicate information blocking. We note, however, for the first and second example that neither app registration nor the public availability of a FHIR service base URL means that an application will be able to access any EHI. On the contrary, the application would be unable to do so unless a patient authenticates themselves via an appropriate workflow or, in the case of a health care provider, the application is appropriately configured to work within the provider's IT infrastructure.</P>
                    <P>As a third example, there is often specific information that may be necessary for certain actors, in this case health care providers, to effectively access, exchange, and use EHI via their Certified EHR Technology and certified Health IT Modules. A health care provider's “direct address” is an example of this kind of information. If this information were not made known to a health care provider upon request, were inaccessible or hidden in a way that a health care provider could not identify (or find out) their own direct address, or were refused to be provided to a health care provider by a health IT developer with certified health IT, we would consider all such actions to be information blocking because knowledge of a direct address is necessary to fully engage in the exchange of EHI.</P>
                    <P>
                        As a last example, we note that, to the extent that a legal transfer of IP to an individual or entity that is not an actor is intended to facilitate circumvention of the information blocking provision, the 
                        <E T="03">transfer itself</E>
                         by an actor could be considered an interference with the access, exchange, or use of EHI.
                    </P>
                    <P>We note that we have added definitions of “API Information Source,” “API User,” “Certified API Developer,” and “certified API technology” to § 171.102. Each of those terms is defined as they are in § 170.404(c). We note that “API Information Source” replaced the proposed definition of “API Data Provider” and “Certified API Developer” replaced the proposed definition of “API Technology Supplier” in order to align with the terms used in § 170.404(c) (see the proposed terms in 84 FR 7601).</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested that we provide further clarity on whether slowing or delaying access, exchange, or use of EHI could be considered information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We clarify that slowing or delaying access, exchange, or use of EHI could constitute an “interference” and implicate the information blocking provision. We understand that some delays may be legitimate and inevitable due to factors such as limited legal, project management, and technical resources. Notwithstanding such understandable challenges, we are aware that some actors use and embellish legitimate challenges to create extended and unnecessary delays. For instance, an actor could have legitimate technical scoping and architecture questions regarding data integrations that require attention and take time to address. However, these scoping and architecture questions could constitute interference and implicate the information blocking provision if they are not necessary to enable access, exchange, or use of EHI and are being utilized as a delay tactic. When assessing such practices, facts indicating that an actor created extended or unnecessary delays may be evidence of an actor's intent. We expect actors to make good faith efforts to work through common and understandable challenges and limitations to enable requestors to access, exchange, and use EHI as quickly and efficiently as possible.
                    </P>
                    <HD SOURCE="HD3">iii. Impeding Innovations and Advancements in Access, Exchange, or Use or Health IT-Enabled Care Delivery</HD>
                    <P>
                        We explained in the Proposed Rule that the information blocking provision encompasses practices that create impediments to innovations and advancements to the access, exchange, and use of EHI, including care delivery enabled by health IT (section 3022(a)(2)(C)(ii) of the PHSA). Importantly, the information blocking provision may be implicated and 
                        <PRTPAGE P="25814"/>
                        penalties or appropriate disincentives may apply if an actor were to engage in exclusionary, discriminatory, or other practices that impede the development, dissemination, or use of interoperable technologies and services that enhance access, exchange, or use of EHI.
                    </P>
                    <P>We emphasized that, most acutely, the information blocking provision may be implicated if an actor were to refuse to license or allow the disclosure of interoperability elements to persons who require those elements to develop and provide interoperable technologies or services—including those that might complement or compete with the actor's own technology or services. The same would be true if the actor were to allow access to interoperability elements but were to restrict their use for these purposes. We provided a list of non-exhaustive examples to illustrate practices that would likely implicate the information blocking provision by interfering with access, exchange, or use of EHI (84 FR 7519 and 7520). We encourage readers to review those examples in the Proposed Rule, as they are still applicable.</P>
                    <P>We explained that, rather than restricting interoperability elements, an actor may insist on terms or conditions that are burdensome and discourage their use. These practices may implicate the information blocking provision as well. We have chosen not to include those examples in this final rule, but emphasize that they are still applicable and encourage readers to review the examples in the Proposed Rule (84 FR 7520).</P>
                    <P>We explained that the information blocking provision may also be implicated if an actor were to discourage efforts to develop or use interoperable technologies or services by exercising its influence over customers, users, or other persons, and we provided a non-exhaustive list of examples. We have chosen not to include those examples in this final rule, but emphasize that they are still applicable and encourage readers to review the examples in the Proposed Rule (84 FR 7520).We noted that similar concerns would arise were an actor to engage in discriminatory practices—such as imposing unnecessary and burdensome administrative, technical, contractual, or other requirements on certain persons or classes of persons—that interfere with access and exchange of EHI by frustrating or discouraging efforts to enable interoperability. We provided a list of non-exhaustive examples to illustrate some ways this could occur. We have chosen not to include those examples in this final rule, but emphasize that they are still applicable and encourage readers to review the examples in the Proposed Rule (84 FR 7520).</P>
                    <P>Not all instances of differential treatment would necessarily constitute a discriminatory practice that may implicate the information blocking provision. For example, we explained that different fee structures or other terms may reflect genuine differences in the cost, quality, or value of the EHI and the effort required to provide access, exchange, or use. We also noted that, in certain circumstances, it may be reasonable and necessary for an actor to restrict or impose reasonable and non-discriminatory terms or conditions on the use of interoperability elements, even though such practices could implicate the information blocking provision. For this reason, and as further explained in section VIII.D, we proposed to establish a narrow exception for licensing interoperability elements (see § 171.303) that would apply to these types of practices.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received some recommendations to describe specific scenarios when a refusal to license would be considered information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We note that for the purposes of the categories of practices described in the Proposed Rule (84 FR 7518 through 7521), we did not consider the applicability of any exceptions, and strongly encouraged readers to review the discussion of practices in this section in conjunction with the section on the exceptions (84 FR 7518). Regarding the specific comment above regarding licensing, we direct readers to our discussion of the Licensing Exception (section VIII.D.2.c.) for additional examples and a discussion of substantive conditions we have finalized for the licensing of interoperability elements under the exception.
                    </P>
                    <P>We note one important clarification that applies to all examples in the Proposed Rule concerning the licensing of interoperability elements. As clarified in the Licensing Exception preamble discussion, an actor will not implicate the information blocking provision in circumstances where the entity requesting to license or use the interoperability element is not seeking to use the interoperability element to interoperate with either the actor or the actor's customers in order for EHI to be accessed, exchanged, or used. In other words, if there is no nexus between a requestor's need to license an interoperability element and existing EHI, an actor's refusal to license the interoperability element altogether or in accordance with § 171.303 would not constitute an interference under the information blocking provision. We refer readers to the Licensing Exception preamble discussion in section VIII.D.2.c.</P>
                    <HD SOURCE="HD3">Interference Versus Education When an Individual Chooses Technology To Facilitate Access</HD>
                    <P>In the Proposed Rule, we stated that the information blocking provision would likely be implicated when an EHR developer of certified health IT requires third-party applications to be “vetted” for security before use but does not promptly conduct the vetting or conducts the vetting in a discriminatory or exclusionary manner (84 FR 7519). We also stated under the proposed “promoting the privacy of EHI” exception that when the consent or authorization of an individual was necessary for access, exchange, or use of EHI, to qualify for the exception, an actor must not have improperly encouraged or induced the individual to not provide the consent or authorization. We further stated that this does not mean that an actor cannot inform an individual about the advantages and disadvantages of exchanging EHI and any associated risks, so long as the information communicated is accurate and legitimate. However, we noted that an actor could not mislead an individual about the nature of the consent to be provided, dissuade individuals from providing consent in respect of disclosures to the actor's competitors, or impose onerous requirements to effectuate consent that were unnecessary and not required by law (84 FR 7531).</P>
                    <HD SOURCE="HD3">Overview of Comments</HD>
                    <P>Commenters expressed concerns that app developers not covered by the HIPAA Rules frequently do not provide patients (individuals) with clear terms of how their EHI will be subsequently used by the app developer once patients authorize (approve) the app to receive their EHI. These commenters, many of whom would be actors under the information blocking provision, expressed these concerns in comments recited below, while also requesting clarification about what steps they may take to assist individuals in protecting the privacy and security of their EHI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested that we clarify the extent of vetting that would be permitted by actors for third-party apps.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We first clarify that the example provided in the Proposed Rule and recited above was to illuminate practices, such as delaying access and 
                        <PRTPAGE P="25815"/>
                        discriminatory behavior, which could implicate the information blocking provision. “Vetting” in the example's context meant a determination regarding whether the app posed a security risk to the EHR developer's API, which may be the situation with a proprietary API. For certified API technology, which includes the use of OAuth2 among other security requirements in addition to its focus on “read-only”/responses to requests for EHI to be transmitted, there should be few, if any, security concerns about the risks posed by patient-facing apps to the disclosing actor's health IT systems (because the apps would only be permitted to receive EHI at the patient's direction). Thus, for third-party applications chosen by individuals to facilitate their access to their EHI held by actors, there would generally not be a need for “vetting” on security grounds and such vetting actions otherwise would be an interference. We refer readers to our discussion of “vetting” versus verifying an app developer's authenticity under the API Condition of Certification earlier in section VII.B.4 of this preamble. We do note, however, that actors, such as health care providers, have the ability to conduct whatever “vetting” they deem necessary of entities (
                        <E T="03">e.g.,</E>
                         app developers) that would be their business associates under HIPAA before granting access and use of EHI to the entities. In this regard, covered entities must conduct necessary vetting in order to comply with the HIPAA Security Rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters stated that the information blocking proposals would open the door for third-party apps (
                        <E T="03">e.g.,</E>
                         patient-facing apps) to access, exchange, and use copious amounts of patient data without providing patients with clear terms of use. Commenters stated that most individuals may be surprised when commercial application companies that are not subject to the HIPAA Rules shared health information obtained from a hospital or health plan, such as diagnoses, medications, or test results, in ways the HIPAA Rules would not permit. These commenters asserted that individuals would incorrectly blame the hospital or health plan if a third-party app developer sold their EHI or used it for marketing or other purposes. Additionally, the commenters contended that because the third-party apps and the third-party app developers are not subject to the HIPAA Rules, such developers may, through their apps' required terms of use, grant the developers the right to sell the EHI received or generated by the app without the individual's consent or could expose all of the individual's EHI without the individual's knowledge.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         This final rule supports an individual's ability to choose which third-party developer and app are best for receiving all or part of their EHI from a health care provider and to agree to clear and public terms of use on how that initial and ongoing engagement with the third-party developer and app occurs. As discussed in more detail below, this final rule also supports and strongly encourages providing individuals with information that will assist them in making the best choice for themselves in selecting a third-party application. We believe that allowing actors to provide additional information to individuals about apps will assist individuals as they choose apps to receive their EHI and such an approach is consistent with statements in the Proposed Rule recited above regarding informing individuals about the advantages and disadvantages of exchanging EHI and any associated risks. Individuals concerned about information privacy and security can gain a better understanding about how the third-party apps are using and storing their EHI, how individuals will be able to exercise any consent options, and more about what individuals are consenting to before they allow the app to receive their EHI.
                    </P>
                    <P>Practices that purport to educate patients about the privacy and security practices of applications and parties to whom a patient chooses to receive their EHI may be reviewed by OIG or ONC, as applicable, if there was a claim of information blocking. However, we believe it is unlikely these practices would interfere with the access, exchange, and use of EHI if they meet certain criteria. Foremost, the information provided by actors must focus on any current privacy and/or security risks posed by the technology or the third-party developer of the technology. Second, this information must be factually accurate, unbiased, objective, and not unfair or deceptive. Finally, the information must be provided in a non-discriminatory manner. For example, all third-party apps must be treated the same way in terms of whether or not information is provided to individuals about the privacy and security practices employed. To be clear, an actor may not prevent an individual from deciding to provide its EHI to a technology developer or app despite any risks noted regarding the app itself or the third-party developer.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that we require actors, including API technology suppliers, to verify the existence of a privacy notice for each application requesting registration by an API User (third-party app developer). Commenters also suggested that the privacy notices should be commensurate with ONC's Model Privacy Notice (MPN). One commenter recommended that all third-party developers should have to attest “yes” or “no” to having a privacy notice for each app it makes available for use/(for patients to use) to access EHI. The commenter asserted that requiring attestation would provide transparency about the existence or lack of privacy policies and practices and data uses and serve as a means to support enforcement of acts of deceptive or misleading conduct in relation to stated privacy policies and practices.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted above, an actor may provide factually accurate, objective, unbiased, fair, and non-discriminatory information about the third party or third-party app that an individual chooses to use to receive EHI on their behalf. And as also noted above, we strongly encourage actors to educate patients and individuals about the risks of providing other entities or parties access to their EHI. This type of education can be designed to inform the patient about the privacy and security practices of the third party and the third-party app, including whether the third-party developer has not acted in accordance with elements of its privacy policy. In this regard, we think there are many efficient and allowable ways of providing such education without such practices being considered or creating an interference under the information blocking provision, including those similar to the one suggested by the commenter.
                    </P>
                    <P>
                        For example, to the commenter's specific point, actors may establish processes where they notify a patient, call to a patient's attention, or display in advance (as part of the app authorization process with certified API technology) whether the third-party developer of the app that the patient is about to authorize to receive their EHI has attested in the positive or negative whether the third party's privacy policy and practices (including security practices such as whether the app encrypts the EHI) meet certain “best practices” set by the market for privacy policies and practices. We note that we identify 
                        <E T="03">minimum</E>
                         best practices for third-party privacy policies and practices below. This notification, would enable a patient to pause, consider this educational information provided by the actor, and decide whether to proceed with approving the 
                        <PRTPAGE P="25816"/>
                        app to receive their EHI or to stop mid-way in the process to do more research into the app or to pick a different app, in which case the patient would not approve the original app in question to receive their EHI. Understandably, in order for an actor to execute this kind of notification or attention grabbing process and to attribute certain app developer practices to educational insights provided to a patient in real-time, certain information may need to be collected by an actor in advance. Such information may include whether the app developer has a privacy notice, policies, or practices. Actors providing patients with educational information (a notice) could help patients better understand how their EHI may be used by the app and the third-party developer.
                    </P>
                    <P>While the ONC 2018 MPN is a voluntary, openly available resource designed to help developers clearly convey comprehensive information about their privacy and security policies and practices to their users, the privacy notice and practices of a third-party developer's app or personal health record does not have to be identical to the ONC's 2018 MPN. There may be other privacy policies and practices (including security practices) of third-party developers and apps that accomplish the same goals and even provide more information relevant to a user. At a minimum, as it relates to the above, all third-party privacy policies and practices should adhere to the following:</P>
                    <P>(1) The privacy policy is made publicly accessible at all times, including updated versions;</P>
                    <P>(2) The privacy policy is shared with all individuals that use the technology prior to the technology's receipt of EHI from an actor;</P>
                    <P>(3) The privacy policy is written in plain language and in a manner calculated to inform the individual who uses the technology;</P>
                    <P>(4) The privacy policy includes a statement of whether and how the individual's EHI may be accessed, exchanged, or used by any other person or other entity, including whether the individual's EHI may be sold at any time (including in the future); and</P>
                    <P>(5) The privacy policy includes a requirement for express consent from the individual before the individual's EHI is accessed, exchanged, or used, including receiving the individual's express consent before the individual's EHI is sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction).</P>
                    <P>We note that the market may set different and more stringent expectations for third-party privacy notices and practices than the above minimum. As described above and in the examples below, an actor may provide information or notice to the individual whose EHI is requested from the actor that the privacy policy that applies to the technology used to make the request does or does not meet the minimum privacy policy notice and practices outlined above.</P>
                    <P>
                        <E T="03">Example 1: Providing education to an individual of a third-party app developer's privacy and security policies and practices through an automated attestation and warning process.</E>
                    </P>
                    <P>An API User (third-party app developer) develops a software application (named “App-Y”) and registers it with the Certified API Developer's (developer of certified health IT) authorization server. During the registration process, the Certified API Developer requests, as a business associate and on behalf of a HIPAA covered entity, that the API User attest that for App-Y, the API User follows the privacy policies and practices outlined above. Given the “yes or no” choice, the API User attests “no.” The Certified API Developer completes App-Y's registration process and provides it with a client identifier. An individual seeks to use App-Y to obtain their EHI from the health care provider (covered entity) that is a customer of the Certified API Developer. The individual then opens App-Y on their smartphone and after authenticating themselves to their health care provider (covered entity), but prior to the app receiving the EHI from the health care provider, the patient is provided with an app authorization screen controlled by the health care provider.</P>
                    <P>
                        Using the certified API technology and the normal OAuth2 workflow the patient is asked by the health care provider via the app authorization screen whether they want to approve or reject App-Y's ability to receive their EHI via certified API technology. On the authorization screen, there is a “warning” from the health care provider that the application has not “attested” to having privacy policies and practices that adhere to the minimum policies and practices outlined above or to having other specified privacy 
                        <E T="03">and security</E>
                         policies. When presented with that warning, the patient has two choices: (1) Choose to ignore the warning and approve App-Y's ability to receive their EHI and App-Y receives the patient's PHI; or (2) reject App-Y's ability to receive their EHI, and the health care provider does not provide the patient's EHI to App-Y.
                    </P>
                    <P>
                        <E T="03">Example 2: Patient sending EHI using certified health IT capabilities provided by health IT developer.</E>
                    </P>
                    <P>An individual has made an appointment with a health care specialist for a second medical opinion. During the initial scheduling, the administrative staff requested that the individual bring all their prior health information to the specialist. The patient portal of the individual's primary care provider allows EHI to be transmitted to a third party using Direct protocol. The individual identifies a third-party app that is able to receive EHI using Direct protocol and creates an account with the app as well as obtain/create a “Direct address.” During the account creation process with the app, the individual reviews the “privacy policy” for the app. The third-party app also sends the individual a copy of the privacy policy via email once the individual completes the account creation process.</P>
                    <P>Subsequently, the individual logs into the primary care provider's portal to transmit her EHI to her direct address linked to her new account on the third-party app. Her provider uses certified health IT that is capable of sending EHI securely using Direct protocol to third-party organizations (including apps) with which they have exchanged trust anchors. It turns out, the health care provider has established prior trust with the third-party app and is able to send EHI to the application. To note, this health care provider may offer education, including a warning (notice), to the patient, as discussed above, if the provider is being directed by the patient to transmit their EHI to a recipient that is unknown to the provider.</P>
                    <P>Prior to sending the EHI, the portal provides a summary screen that provides the privacy policy “warning” about the third-party app. The patient reviews and accepts it. The provider's system/API technology sends EHI to her Direct address. The patient logs into her application and confirms that the EHI has been received.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters stated that, given the access to personal health information that patient-directed third-party apps are expected to have and the potential privacy risks they pose, a process should be implemented by the Federal Trade Commission (FTC) to vet apps for the adequacy of the consumer disclosures which should include the privacy and security of the information and secondary uses that should be permitted. A commenter suggested that the vetting process should be at the application and application developer 
                        <PRTPAGE P="25817"/>
                        level, and that the results of such vetting process should be made public in the form of an application “safe list.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The privacy practices of developers of patient-facing health IT products and services are typically regulated by the Federal Trade Commission Act (FTC Act). The FTC Act prohibits unfair or deceptive acts or practices in or affecting commerce (15 U.S.C. 45(a)(1)), but it does not prescribe specific privacy requirements. The FTC has authority to enforce the FTC Act's prohibition on deception, for example, by challenging deceptive statements made in privacy policies, user interfaces, FAQs, or other consumer-facing materials. The FTC could also, for example, challenge a particular use or disclosure of EHI as unfair if it causes or is likely to cause substantial injury to consumers that is not reasonably avoidable by consumers themselves and not outweighed by countervailing benefits to consumers or to competition (15 U.S.C. 45(n)). We will continue to work with our Federal partners, including the FTC, to assess education opportunities for consumers and app developers about the privacy and security of EHI collected, used, or received by health apps.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter recommended the development of a privacy framework regarding how health information should be shared and to empowering consumers; and it noted that it should be developed and matured in concert with the modernization of our nation's health IT infrastructure. They expressed that there are private sector and public-private examples of models that we should look to from both health care and other industries. They believed that the Proposed Rule does not, however, fully address patient and consumer privacy protections. They recommended that the Center for Medicare and Medicaid Services and ONC should work together with relevant agencies and departments and private-sector colleagues to develop a companion consumer privacy framework.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We are aware of various industry initiatives regarding a “privacy framework.” We have previously published the Nationwide Privacy and Security Framework for Electronic Exchange of Individually Identifiable Health Information; 
                        <SU>130</SU>
                        <FTREF/>
                         produced, in cooperation with the FTC, FDA, and OCR, the Mobile Health Apps Interactive Tool; 
                        <SU>131</SU>
                        <FTREF/>
                         and more recently published and developed the Privacy and Security Framework for Patient-Centered Outcomes Research (PCOR). This project developed tools and resources that address the many different types of data that can be used to conduct patient-centered outcomes research. The framework consists of two initiatives: The Legal and Ethical Architecture for PCOR Data (Architecture), which guides readers through the responsible use and protection of electronic health data for PCOR and The Patient Choice Technical Project which harmonized existing technical mechanisms to enable interoperable exchange of patient consent for basic and granular choice for research and treatment, payment, and health care operations. This project, which remains active, also identifies, tests and validates technical standards that support an individual's consent preferences.
                        <SU>132</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>130</SU>
                             
                            <E T="03">https://www.healthit.gov/sites/default/files/nationwide-ps-framework-5.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>131</SU>
                             
                            <E T="03">https://www.ftc.gov/tips-advice/business-center/guidance/mobile-health-apps-interactive-tool.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>132</SU>
                             
                            <E T="03">See</E>
                              
                            <E T="03">https://www.healthit.gov/topic/scientific-initiatives/pcor/privacy-and-security-framework-pcor-psp</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We will continue to monitor how individuals are educated about potential privacy and security risks of third-party apps and will continue to work with HHS OCR and industry stakeholders to further educate individuals as part of our implementation of section 4006 of the Cures Act. In this regard, we also encourage individuals to review consumer education materials related to protecting their EHI on our website at 
                        <E T="03">healthit.gov</E>
                         (“What You Can do to Protection Your Health Information”—
                        <E T="03">https://www.healthit.gov/topic/privacy-security/what-you-can-do-protect-your-health-information</E>
                        ; and “Health IT: How to Keep Your Health Information Privacy and Secure: Fact Sheet”—
                        <E T="03">https://www.healthit.gov/sites/default/files/how_to_keep_your_health_information_private_and_secure.pdf).</E>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concerns that if patients access their health data—some of which could contain family history and could be sensitive—through a smartphone, they should have a clear understanding of the potential uses of that data by third-party app suppliers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Under the HIPAA Privacy Rule, when a covered health care provider, in the course of treating an individual, collects or otherwise obtains an individual's family medical history, this information may become part of the individual's medical record (45 CFR 164.501 (definition of “Designated Record Set”). Thus, if the family medical history becomes part of the medical record, the individual/patient may exercise the rights under the HIPAA Privacy Rule, 45 CFR 164.524, to this information in the same fashion as any other information in the medical record, including the right of access. As discussed above, actors may educate patients of the risks related to providing other persons and entities with their EHI, including the various the types of EHI (
                        <E T="03">e.g.,</E>
                         family health history) that will be provided to an entity (
                        <E T="03">e.g.,</E>
                         third-party app) at the patient's request.
                    </P>
                    <HD SOURCE="HD3">iv. Rent-Seeking and Other Opportunistic Pricing Practices</HD>
                    <P>Certain practices that artificially increase the cost and expense associated with accessing, exchanging, and using EHI may implicate the information blocking provision. We emphasized in the Proposed Rule that such practices are plainly contrary to the information blocking provision and the concerns that motivated its enactment.</P>
                    <P>We explained that an actor may seek to extract profits or capture revenue streams that would be unobtainable without control of a technology or other interoperability elements that are necessary to enable or facilitate access, exchange, or use of EHI. Most EHI is currently stored in EHRs and other source systems that use proprietary data models or formats; this puts EHR developers (and other actors that control data models or standards) in a unique position to block access to (including the export and portability of) EHI for use in competing systems or applications or to charge rents for access to the basic technical information needed to accomplish the access, exchange, or use of EHI for these purposes. We emphasized that these information blocking concerns may be compounded to the extent that EHR developers do not disclose, in advance, the fees they will charge for interfaces, data export, data portability, and other interoperability-related services (see 80 FR 62719 through 62725; 80 FR 16880 through 16881). We noted that these concerns are not limited to EHR developers. Other actors who exercise substantial control over EHI or essential interoperability elements may engage in analogous behaviors that would implicate the information blocking provision (84 FR 7520).</P>
                    <P>
                        To illustrate, we provided a list of non-exhaustive examples that reflected some of the more common types of rent-seeking and opportunistic behaviors of which we were aware and that are likely to interfere with access, exchange, or use of EHI. Those examples are still applicable and we encourage readers to 
                        <PRTPAGE P="25818"/>
                        review the examples in the Proposed Rule (84 FR 7520 and 7521).
                    </P>
                    <P>The information blocking provision may be implicated by these and other practices by which an actor profits from its unreasonable control over EHI or interoperability elements without adding any efficiency to the health care system or serving any other pro-competitive purpose. However, we stressed that the reach of the information blocking provision is not limited to these types of practices. We interpreted the definition of information blocking to encompass any fee that materially discourages or otherwise imposes a material impediment to access, exchange, or use of EHI. We used the term “fee” in the broadest possible sense to refer to any present or future obligation to pay money or provide any other thing of value and proposed to include this definition in § 171.102. We noted that this scope may be broader than necessary to address genuine information blocking concerns and could unnecessarily diminish investment and innovation in interoperable technologies and services. Therefore, as further explained in section VIII.D, we proposed to create an exception that, subject to certain conditions, would permit the recovery of costs that are reasonably incurred to provide access, exchange, and use of EHI (84 FR 7521).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments specifically on our proposed definition of “fee.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the definition in § 171.102 as proposed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested additional examples and clarity on the types of rent-seeking and opportunistic pricing practices that would be likely to implicate the information blocking provision.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We refer readers to our discussion of the Fees Exception (section VIII.D.2.b.) for additional examples, as well as for a detailed discussion of fees that may and may not be charged under this exception.
                    </P>
                    <HD SOURCE="HD3">v. Non-Standard Implementation Practices</HD>
                    <P>We explained in the Proposed Rule that section 3022(a)(2)(B) of the PHSA states that information blocking may include implementing health IT in non-standard ways that substantially increase the complexity or burden of accessing, exchanging, or using EHI. In general, this type of interference is likely to occur when, despite the availability of generally accepted technical, policy, or other approaches that are suitable for achieving a particular implementation objective, an actor does not implement the standard, does not implement updates to the standard, or implements the standard in a way that materially deviates from its formal specifications. We noted that these practices lead to unnecessary complexity and burden, such as the additional cost and effort required to implement and maintain “point-to-point” connections, custom-built interfaces, and one-off trust agreements.</P>
                    <P>While each case will necessarily depend on its individual facts, and while we recognized that the development and adoption of standards across the health IT industry is an ongoing process, we explained that the information blocking provision would be implicated in at least two distinct sets of circumstances. First, we stated that information blocking may arise where an actor chooses not to adopt, or to materially deviate from, relevant standards, implementation specifications, and certification criteria adopted by the Secretary under section 3004 of the PHSA. Second, even where no federally adopted or identified standard exists, if a particular implementation approach has been broadly adopted in a relevant industry segment, deviations from that approach would be suspect unless strictly necessary to achieve substantial efficiencies.</P>
                    <P>To further illustrate these types of practices that may implicate the information blocking provision, we provided a list of non-exhaustive examples of conduct that would be likely to interfere with access, exchange, or use of EHI. We have chosen not to include those examples in this final rule, but emphasize that they are still applicable and encourage readers to review the examples in the Proposed Rule (84 FR 7521).</P>
                    <P>We explained that even where no standards exist for a particular purpose, actors should not design or implement health IT in non-standard ways that unnecessarily increase the costs, complexity, and other burdens of accessing, exchanging, or using EHI. We also noted that we were aware that some actors attribute certain non-standard implementations on legacy systems that the actor did not themselves design but which have to be integrated into the actor's health IT. We noted that such instances will be considered on a case-by-case basis.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested additional clarity on when non-standard based interoperability is permissible. Some commenters urged ONC to be careful and flexible in its interpretation of this information blocking practice given the complexities of health IT implementation, such as implementing newly adopted standards or requirements. One commenter highlighted the importance of being able to retain certain types of optionality, especially for specialized use cases. Other commenters expressed concern that considering non-standard implementation practices as likely to implicate the information blocking provision could have the unintended consequence of stymying innovative or novel technologies used in information exchange.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the commenters' suggestions. We emphasize that the problematic nature of non-standard design and implementation choices was identified by Congress in section 3022(a)(2)(B) of the PHSA, which states that information blocking may include implementing health IT in non-standard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using EHI. We continue to be concerned that these practices will lead to unnecessary complexity and burden related to the access, exchange, or use of EHI, and depending on the circumstances, we maintain that such practices would be likely to interfere with access, exchange, or use of EHI. We refer readers to the discussion of this topic in the Fees Exception (section VIII.D.2.b).
                    </P>
                    <P>We also agree, however, that we must give each case careful consideration and assess the individual facts and circumstances to determine whether such practices would be likely to interfere with access, exchange, or use of EHI.</P>
                    <HD SOURCE="HD3">7. Applicability of Exceptions</HD>
                    <HD SOURCE="HD3">a. Reasonable and Necessary Activities</HD>
                    <P>
                        Section 3022(a)(3) of the PHSA requires the Secretary to identify, through notice and comment rulemaking, reasonable and necessary 
                        <E T="03">activities</E>
                         that do not constitute information blocking for purposes of the definition in section 3022(a)(1). Section 3022(a)(1) of the PHSA defines information blocking by referring to 
                        <E T="03">practices</E>
                         likely to interfere with, prevent or materially discourage access, exchange or use of electronic health information. Based on this terminology used in the PHSA, we noted that conduct that implicates the information blocking provision and that does not fall within one of the exceptions or does not meet all conditions for an exception, would be considered a “practice.” Conduct that falls within an exception and meets all the applicable conditions for that exception would be considered 
                        <PRTPAGE P="25819"/>
                        an “activity.” We noted that the challenge with this distinction is that when examining conduct that is the subject of an information blocking claim—an actor's actions that are likely to interfere with access, exchange, or use of EHI—it can be illusory to distinguish, on its face, conduct that is a 
                        <E T="03">practice</E>
                         and conduct that is an 
                        <E T="03">activity.</E>
                         Indeed, conduct that implicates the information blocking provision but falls within an exception could nonetheless be considered information blocking if the actor has not satisfied the conditions applicable to that exception.
                    </P>
                    <P>Acknowledging the terminology used in the PHSA, we proposed to define “practice” in § 171.102 as one or more related acts or omissions by an actor.</P>
                    <P>
                        We also proposed to use the term “practice” throughout the Proposed Rule when we described conduct that is likely to interfere with, prevent, or materially discourage the access, exchange, or use of EHI, and clarify when describing the conduct at issue whether it is a practice that is information blocking, a practice that implicates the information blocking provision, or a practice that is reasonable and necessary and not information blocking (84 FR 7522). We stated that adopting the terminology of “activity” to describe conduct that may or may not be information blocking would be confusing and obfuscate our intent in certain circumstances. Consistent with this approach, when describing the exceptions in the final rule, we describe 
                        <E T="03">practices</E>
                         that, if all the applicable conditions are met, are reasonable and necessary and not information blocking.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments specifically on the distinction between “activities” and “practices” and our proposed definition and use of the term “practice.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the definition of “practice” in § 171.102 as “an act or omission by an actor.” This definition is a modification of the proposed definition, which was “one or more related acts or omissions by an actor.” We finalized this definition of “practice” in order to clarify that a practice need only be a single act or omission. This modification does not substantively change the proposed definition, as we included in the proposed definition that a “practice” 
                        <E T="03">could</E>
                         be one act or omission.
                    </P>
                    <P>
                        We have finalized the use of the term “practice,” rather than the term “activity,” to describe conduct that is likely to interfere with, prevent or materially discourage the access, exchange, or use of EHI. We have also finalized our approach that when identifying exceptions, we describe 
                        <E T="03">practices</E>
                         that, if all the applicable conditions are met, are reasonable and necessary and not information blocking.
                    </P>
                    <HD SOURCE="HD3">b. Treatment of Different Types of Actors</HD>
                    <P>We explained in the Proposed Rule that the proposed exceptions would apply to health care providers, health IT developers of certified health IT, HIEs, and HINs who engage in certain practices covered by an exception, provided that all applicable conditions of the exception are satisfied at all relevant times and for each practice for which the exception is sought. We noted that the exceptions are generally applicable to all actors. However, in some instances, we proposed conditions within an exception that apply to a particular type of actor.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters agreed that the exceptions should apply to all actors. A few commenters requested that ONC identify exceptions that apply to all actors and identify exceptions that only apply to select actors.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support for our approach to the exceptions, as well as the suggestion to restructure the exceptions. We continue to believe that the clearest and most equitable approach to the exceptions is to make all of the exceptions apply to all actors, as proposed. We have addressed the commenters' concerns by creating conditions within certain exceptions that apply to one or a subset of actors, as applicable.
                    </P>
                    <HD SOURCE="HD3">c. Establishing That Practices Meet the Conditions of an Exception</HD>
                    <P>We proposed that, in the event of an investigation of an information blocking complaint, an actor must demonstrate that an exception is applicable and that the actor met all relevant conditions of the exception at all relevant times and for each practice for which the exception is sought (84 FR 7522). We considered this allocation of proof to be a substantive condition of the proposed exceptions. As a practical matter, we proposed that actors are in the best position to demonstrate compliance with the conditions of the exceptions and to produce the detailed evidence necessary to demonstrate that compliance. We requested comment about the types of documentation and/or standardized methods that an actor may use to demonstrate compliance with the exception conditions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters requested clarification regarding the type and amount of documentation required to demonstrate that they have met an exception. In particular, many commenters noted that meeting the exceptions will substantially increase documentation burden and other administrative costs for actors. Commenters also noted that organizations may need to update, develop and/or implement policies and procedures focused on documenting compliance with information blocking exceptions. Many commenters requested that ONC develop and provide examples, templates, and guidance on the type of documentation that would be acceptable to support the conditions for each information blocking exception. Several commenters noted that the supporting documentation should clearly demonstrate why the actor qualifies for the exception, why the exception is required, and how all conditions of the exception are fulfilled. One commenter asked that we provide guidance on the appropriate storage method for this documentation, as this information may not be appropriate for the clinical record.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these thoughtful comments and suggestions. We have tailored the exceptions and provided significant detail within each exception to clearly explain what an actor must do to meet each exception. For each exception, we have proposed and finalized conditions that we believe can be consistently applied across a range of actors and practices and also further the goals of the information blocking provision. For some exceptions, this includes a writing or documentation requirement to demonstrate that the practice precisely meets all of the conditions to afford an actor the enhanced assurance an exception offers. Many of these conditions are related to other existing regulatory requirements that have similar documentation standards. For example, an actor's practice may meet the Security Exception at § 171.203 if it is consistent with an organizational security policy and that policy meets several requirements. We expect that many actors have existing organizational security policies based on the “Policy and procedures and documentation requirements” in the HIPAA Security Rule at 45 CFR 164.316. Consequently, the burden associated with meeting the documentation requirement in the Security Exception should be less if actors are already complying with the HIPAA Security Rule.
                    </P>
                    <P>
                        We encourage actors to voluntarily comply with an exception so that their practices do not meet the definition of information blocking and are not subject 
                        <PRTPAGE P="25820"/>
                        to information blocking enforcement. However, failure to meet an exception does not necessarily mean a practice meets the definition of information blocking. If subject to an investigation, each practice that implicates the information blocking provision and does not meet an exception would be analyzed on a case-by-case basis to evaluate, for example, whether it rises to the level of an interference, and whether the actor acted with the requisite intent.
                    </P>
                    <HD SOURCE="HD2">D. Exceptions to the Information Blocking Definition</HD>
                    <P>We proposed to establish seven exceptions to the information blocking provision. The exceptions would apply to certain practices that may technically meet the definition of information blocking but that are reasonable and necessary to further the underlying public policies of the information blocking provision. We appreciate that most actors will want to meet an exception to guarantee that their practice or practices do not meet the definition of information blocking and be subject to enforcement. The statute defines information blocking broadly and in a manner that allows for careful consideration of relevant facts and circumstances in individual cases, which includes analysis of an actor's intent and whether it meets the requisite knowledge standard.</P>
                    <P>The proposed exceptions were based on three related policy considerations. First, each exception was limited to certain activities that clearly advance the aims of the information blocking provision. These reasonable and necessary activities included providing appropriate protections to prevent harm to patients and others; promoting the privacy and security of EHI; promoting competition and innovation in health IT and its use to provide health care services to consumers, and to develop more efficient means of health care delivery; and allowing system downtime to implement upgrades, repairs, and other changes to health IT. Second, each proposed exception addressed a significant risk that regulated actors will not engage in these beneficial activities because of uncertainty concerning the breadth or applicability of the information blocking provision. Finally, each exception was subject to strict conditions to ensure that it was limited to activities that are reasonable and necessary.</P>
                    <P>We explained that the first three exceptions extended to certain activities that are reasonable and necessary to prevent harm to patients and others; promote the privacy of EHI; and promote the security of EHI, subject to strict conditions to prevent the exceptions from being misused. We discussed that without these exceptions, actors may be reluctant to engage in the reasonable and necessary activities and that this could erode trust in the health IT ecosystem and undermine efforts to provide access and facilitate the exchange and use of EHI for important purposes. We stressed that such a result would be contrary to the purpose of the information blocking provision and the broader policies of the Cures Act.</P>
                    <P>We explained that the next three exceptions addressed activities that are reasonable and necessary to promote competition and consumer welfare. First, we proposed to permit the recovery of certain types of reasonable costs incurred to provide technology and services that enable access to EHI and facilitate the exchange and use of that information, provided certain conditions are met. Second, we proposed to permit an actor to decline to provide access, exchange, or use of EHI in a manner that is infeasible, subject to a duty to provide a reasonable alternative. And third, we proposed an exception that would permit an actor to license interoperability elements on reasonable and non-discriminatory terms. We emphasized that the exceptions would be subject to strict conditions to ensure that they do not extend protection to practices that raise information blocking concerns.</P>
                    <P>The last exception recognized that it may be reasonable and necessary for actors to make health IT temporarily unavailable for the benefit of the overall performance of health IT. This exception would permit an actor to make the operation of health IT unavailable to implement upgrades, repairs, and other changes.</P>
                    <P>
                        As context for the proposed exceptions, we noted that addressing information blocking is critical for promoting competition and innovation in health IT and for the delivery of health care services to consumers. We noted that the information blocking provision itself expressly addresses practices that impede innovation and advancement in health information access, exchange, and use, including care delivery enabled by health IT (section 3022(a)(2)(C)(ii) of the PHSA). We also noted that health IT developers of certified health IT, HIEs, HINs, and, in some instances, health care providers, may 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.
                        <SU>133</SU>
                        <FTREF/>
                         More than this, we emphasized that information blocking may harm competition not just in health IT markets, but also in markets for health care services.
                        <SU>134</SU>
                        <FTREF/>
                         Dominant providers in these markets may leverage their control over technology to limit patient mobility and choice.
                        <SU>135</SU>
                        <FTREF/>
                         They may also pressure independent providers to adopt expensive, hospital-centric technologies that do not suit their workflows, limit their ability to share information with unaffiliated providers, and make it difficult to adopt or use alternative technologies that could offer greater efficiency and other benefits.
                        <SU>136</SU>
                        <FTREF/>
                         The technological dependence resulting from these practices can be a barrier to entry by would-be competitors. It can also make independent providers vulnerable to acquisition or induce them into exclusive arrangements that enhance the market power of incumbent providers while preventing the formation of clinically-integrated products and networks that offer more choice and better value to consumers and purchasers of health care services.
                    </P>
                    <FTNT>
                        <P>
                            <SU>133</SU>
                             
                            <E T="03">See also</E>
                             Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, 
                            <E T="03">Making Health Care Markets Work: Competition Policy for Health Care,</E>
                             16-17 (Apr. 2017), available at 
                            <E T="03">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>134</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Keynote Address of FTC Chairwoman Edith Ramirez, Antitrust in Healthcare Conference Arlington, VA (May 12, 2016),   available at 
                            <E T="03">https://www.ftc.gov/system/files/documents/public_statements/950143/160519antitrusthealthcarekeynote.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>135</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, 
                            <E T="03">Making Health Care Markets Work: Competition Policy for Health Care,</E>
                             16-17 (Apr. 2017), available at 
                            <E T="03">http://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>136</SU>
                             
                            <E T="03">See, e.g., Healthcare Research Firm Toughens Survey Standards as More CIOs Reap the Profits of Reselling</E>
                              
                            <E T="03">Vendor Software,</E>
                             Black Book, available at 
                            <E T="03">http://www.prweb.com/releases/2015/02/prweb12530856.htm</E>
                            ; Arthur Allen, 
                            <E T="03">Connecticut Law Bans EHR-linked Information Blocking,</E>
                             Politico.com (Oct. 29, 2015).
                        </P>
                    </FTNT>
                    <P>
                        We noted in the Proposed Rule that section 3022(a)(5) of the PHSA provides that the Secretary may consult with the Federal Trade Commission (FTC) in defining practices that do not constitute information blocking because they are necessary to promote competition and consumer welfare. We expressed appreciation for the expertise and informal technical assistance of FTC staff, which we took into consideration in developing the exceptions for recovering costs reasonably incurred, responding to requests that are infeasible, and licensing of interoperability elements on reasonable and non-discriminatory terms. We noted that the language in the Cures Act regarding information blocking is substantively and substantially different 
                        <PRTPAGE P="25821"/>
                        from the language and goals in the antitrust laws enforced by the FTC. We explained that we view the Cures Act as addressing conduct that may be considered permissible under the antitrust laws. On this basis, the Proposed Rule required that actors who control interoperability elements cooperate with individuals and entities that require those elements for the purpose of developing, disseminating, and enabling technologies and services that can interoperate with the actor's technology.
                    </P>
                    <P>We emphasized that ONC took this approach because we view patients as having an overwhelming interest in EHI about themselves. As such, access to EHI, and the EHI itself, should not be traded or sold by those actors who are custodians of EHI or who control its access, exchange, or use. We emphasized that such actors should not be able to charge fees for providing electronic access, exchange, or use of patients' EHI. We explained that the information blocking provision prohibits actors from interfering with the access, exchange, or use of EHI unless they are required to do so under an existing law or are covered by one of the exceptions detailed in this preamble. In addition, we explained that any remedy sought or action taken by HHS under the information blocking provision would be independent of the antitrust laws and would not prevent FTC or DOJ from taking action with regard to the same actor or conduct.</P>
                    <P>We proposed to include a provision in § 171.200 that addresses the availability and effect of exceptions.</P>
                    <P>We requested comment on the seven proposed exceptions, including whether they will achieve our stated policy goals.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments regarding each of the proposed exceptions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have responded to the comments regarding each exception in the preamble discussions for each exception. Overall, we have made modifications to the structure and scope of the proposed exceptions.
                    </P>
                    <P>In this final rule, we have restructured the proposed exceptions (proposed in §§ 171.201-207) and have added another exception for clarity. In addition, we have divided the exceptions into two categories: (1) Exceptions that involve not fulfilling requests to access, exchange, or use EHI, which are finalized in §§ 171.201-205; and (2) exceptions that involve procedures for fulfilling requests to access, exchange, or use EHI, which are finalized in §§ 171.301-303. We also changed the titles of the exceptions to questions for additional clarity. We believe this new structure will help actors better understand our expectations of them and enhance transparency around the exceptions.</P>
                    <P>We note that we use the term “fulfill” throughout the exceptions in the context of an actor “fulfilling” a request to access, exchange, or use EHI. This term is intended to reflect not just a response to a request to access, exchange, or use EHI, but also making the EHI available for the requested access, exchange, or use.</P>
                    <P>We have finalized the seven exceptions with modifications discussed below. Based on requests for comment we included in the Proposed Rule regarding the scope of the EHI definition (84 FR 7513) and the Infeasibility Exception (84 FR 7542 through 7544), we have also established a new exception in § 171.301 (referred to as the Content and Manner Exception) under section 3022(a)(3) of the PHSA as a means to identify reasonable and necessary activities that do not constitute information blocking. We discuss the details of the new Content and Manner Exception in section VIII.D.2.a of this preamble.</P>
                    <P>
                        We appreciate the FTC's comments on the Proposed Rule and the expertise and informal technical assistance provided by FTC staff for this final rule, which we took into consideration throughout our development of the final rule, including as it relates to the definitions of various terms in the final rule (
                        <E T="03">e.g.,</E>
                         the definitions of “electronic health information” and “health information network” (discussed above)) and the exceptions (
                        <E T="03">e.g.,</E>
                         the Infeasibility Exception, Fees Exception, and Licensing Exception; as well as the establishing of the new Content and Manner Exception).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on the provision in § 171.200.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized § 171.200 as proposed and have included an identical provision in § 171.300 that is applicable to Part C. This addition was necessary based on the new structure of the exceptions discussed above.
                    </P>
                    <P>1. Exceptions that involve not fulfilling requests to access, exchange, or use EHI</P>
                    <P>a. Preventing Harm Exception — When will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to prevent harm not be considered information blocking?</P>
                    <P>We proposed to establish an exception to the information blocking provision in § 171.201 that would apply to certain practices that are reasonable and necessary to prevent harm to a patient or another person. As discussed in the Proposed Rule's preamble (84 FR 7523 and 7524), this exception is intended to allow for the protection of patients and other particular persons against substantial risks of harm otherwise arising from the access, exchange, or use of EHI in defined circumstances. Strict conditions were proposed to prevent this exception from being misused.</P>
                    <P>
                        As explained in the Proposed Rule, we use the term “patient” to denote the context in which the threat of harm arises (84 FR 7523). That is, this exception has been designed to recognize practices taken for the benefit of recipients of health care — those individuals whose EHI is at issue — and other persons whose information may be recorded in that EHI or who may be at risk of harm because of the access, use, or exchange of the EHI. This use of the term “patient” in the Proposed Rule did 
                        <E T="03">not</E>
                         imply that practices to which the exception is applicable could be implemented only by the licensed health professionals with a clinician-patient relationship to the person whose EHI is affected by the practices.
                    </P>
                    <P>This exception was proposed to apply to practices when the actor engaging in a practice has a reasonable belief that the practice will directly and substantially reduce a risk of harm to the patient, and/or other particular individuals, that would otherwise arise from the particular access, exchange, or use of EHI affected by the practices. We proposed that actors including but not limited to health care providers would, consistent with conditions of the exception applicable to the circumstances in which the practices are used, be able to engage in practices recognized under this exception without the actor needing to have a clinician-patient relationship with any of the individuals at risk of harm.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Of more than ninety comment submissions specifically referencing the Preventing Harm Exception, half expressed overarching or general support for the exception. None of the comments specifically referencing this exception expressed opposition to the exception. Some commenters advocated broadening certain aspects of the proposed exception, as discussed in more detail below. Several other commenters expressed support for a relatively narrow exception, and a few of these commenters recommended that once the final rule is effective ONC should engage in monitoring to ensure the exception is not abused in practice. Many commenters requested 
                        <PRTPAGE P="25822"/>
                        clarification on specific points, or expressed concerns or suggested modifications to particular aspects of the exception, as will be discussed in more detail below.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the many thoughtful comments on the value of this exception, particular aspects of the proposed exception, and areas where we could streamline how we express the policy so it is easier to understand. Considering all of the comments received, we have decided to finalize the exception largely as proposed, with modifications to better align with HIPAA Rules as discussed below and to make the regulation text more easily understood. These revisions include modification of the title of § 171.201, from “Exception—Preventing Harm” (84 FR 7602) to “Preventing Harm Exception — When will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to prevent harm not be considered information blocking?” Throughout this preamble, we use “Preventing Harm Exception” as a short title for ease of reference to the exception that has been finalized in § 171.201.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several comments suggested broadening the scope of the exception to allow a broader array of actors to decide what might pose a risk of harm to a patient.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The finalized exception is, as we proposed it would be, available to any actor defined in § 171.102, provided that the actor's use of a practice for purposes of harm prevention meets the conditions in § 171.201. Only where practices are applied to a specific patient's EHI and based upon a determination of a risk of harm by a licensed health care professional in the exercise of professional judgment does this exception explicitly require the determination to have been made by a particular subset of actors within the definitions in § 171.102. In order to meet the risk of harm condition based on an individualized determination consistent with § 171.201(c)(1), the licensed health care professional who made the determination must have done so in context of a current or prior clinician-patient relationship with the patient whose EHI is affected by the determination.
                        <SU>137</SU>
                        <FTREF/>
                         However, other actors — such as other health care providers treating the same patient, or an HIE/HIN supporting access, exchange, or use of the patient's EHI — could rely on such a determination of a risk of harm. The actor's knowledge of a licensed health care professional's individualized determination (consistent with § 171.201(c)(1)) that access, exchange, or use posed a risk of a harm of a type consistent with § 171.201(d)(1), (2), or (3) (as applicable) could factor into a determination based on facts and circumstances known or reasonably believed by the actor (consistent with the condition finalized § 171.201(f)(2)).
                    </P>
                    <FTNT>
                        <P>
                            <SU>137</SU>
                             For purposes of this exception, we interpret “clinician-patient relationship” to include any therapeutic or relationship where the licensed health care professional has or at some point had some clinical responsibility for or to the patient within the professional's scope of practice. Thus, a clinician-patient relationship on which a qualifying individualized determination of risk of harm could be one of substantial duration over time or formed in the course of the first or only occasion on which the clinician furnishes or furnished professional services to the patient in any setting, including but not limited to telehealth.
                        </P>
                    </FTNT>
                    <P>An actor could also implement practices based on knowledge of an individualized determination of risk (§ 171.201(c)(1)) of harm of a type consistent with § 171.201(d)(1), (2), or (3) as applicable and based on an organizational policy (consistent with the condition finalized § 171.201(f)(1)). Thus, the exception is broad enough to cover all actors implementing practices that meet its conditions. We are finalizing this aspect of the exception as proposed, with clarifications to the regulation text to make it easier to understand what the specific conditions of the Preventing Harm Exception are and how they relate to one another.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A large number of commenters requested additional guidance in this final rule preamble or through other avenues. For example, some commenters requested sub-regulatory guidance and educational resource materials to further illustrate and help actors understand how the Preventing Harm Exception might apply or what it might require without a stakeholder needing to raise particular questions or hypothetical fact patterns.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         With the revisions we have made to this exception, we do not believe sub-regulatory guidance is necessary for actors who wish to avail themselves of this exception to understand the Preventing Harm Exception, its conditions, or to conform their practices to the conditions. We have made revisions to the regulation text to provide enhanced clarity, such as separately expressing each of its substantive conditions and incorporating granular alignment to 45 CFR 164.524(a)(3) harm standards. This final rule preamble provides additional information and feedback through discussion of the particular questions and suggestions posed by various commenters and this preamble's statements of finalized policy. We will also provide, in connection to this final rule, educational resources such as infographics, fact sheets, webinars, and other forms of educational materials and outreach. We emphasize, however, that we believe the final rule clearly describes our information blocking policies, and these educational materials are intended only to educate stakeholders on our final policies established in the final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters questioned whether “directly and substantially” may be a more stringent standard than is necessary for the reduction of risk of harm to a patient or to another person. A number of commenters indicated it could be difficult for actors to know where to draw the line between direct and indirect reductions of risk of harm, given the potential for reasonable minds to disagree on the extent to which a risk arises directly, as opposed to indirectly, from the EHI access, exchange, or use affected by a practice. Several commenters recommended, as an alternative, that the condition be that the actor have a reasonable belief the practice is “reasonably likely” to reduce a risk of harm.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         After considering comments received, we have finalized in § 171.201(a) that the actor must hold a reasonable belief that the practice “will substantially reduce” a risk of harm to a patient or another natural person. In comparison to the regulation text of this exception in the Proposed Rule (84 FR 7602), we have removed “directly” from the finalized text of § 171.201(a). We believe omitting “directly” from the finalized condition obviates concerns about actors' ability to determine whether the practice directly reduces a risk of harm that could itself arise indirectly. We have retained “substantially” in the finalized § 171.201(a) because we believe it is necessary to ensure this exception cannot be misused to justify practices that interfere with access, exchange, or use of EHI to achieve only a trivial or illusory reduction in risk of harm. By extension, we interpret a “substantial reduction” as necessarily implying that the risk intended to be reduced was itself substantial and not trivial or illusory.
                    </P>
                    <P>
                        We note that the harm standard under § 164.524(a)(3) of the HIPAA Rules includes that the access requested be “reasonably likely” to cause the type of harm described in the sub-paragraph applicable to a particular denial of access under § 164.524(a)(3). As discussed in context of the finalized type of harm condition (§ 171.201(d)), 
                        <PRTPAGE P="25823"/>
                        below, we have aligned the conditions of the Preventing Harm Exception finalized in § 171.201 to use the same harm standards as § 164.524(a)(3) in circumstances where both apply and in circumstances where only § 171.201 applies. In order to maintain alignment and consistency, we clarify that in circumstances where only § 171.201 applies, the risk of harm must also initially be at least “reasonably likely,” regardless of whether the risk of harm is consistent with subparagraph (1) or (2) of the type of risk condition finalized in § 171.201(c). To satisfy the reasonable belief condition finalized in § 171.201(a), the actor must reasonably believe their practices (that are likely to, or in fact do, interfere with otherwise permissible access, exchange, or use of EHI) will substantially reduce that likelihood of harm. Actors who are HIPAA covered entities or business associates have extensive experience in complying with § 164.524(a)(3). Therefore, we believe the belief standard finalized in § 171.201(a), combined with reliance on the harm standards used in § 164.524(a)(3), will address commenters' concerns about their ability to understand and apply the reasonable belief and type of harm conditions finalized under § 171.201.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters advocated closer alignment with the HIPAA Privacy Rule. Some commenters expressed concerns about our ability to maintain such alignment without interruption if this rule were to be finalized prior to any applicable potential updates to the HIPAA Privacy Rule pursuant to a proposed rule that HHS had publicly expressed an aim to publish in 2019. Some commenters specifically questioned whether “life or physical safety” would remain the standard for the type of harm cognizable under the Privacy Rule for denying an individual's right to access their own information. One commenter stated they had heard the Privacy Rule harm standard might be broadened to recognize additional types of harm, such as emotional or psychological harm, in circumstances where the Privacy Rule would currently recognize only danger to life or physical safety. A number of comments stated that the requirement for the risk to be to life or physical safety for all circumstances where this exception would apply would conflict with current Privacy Rule provisions applicable to individual or proxy access to PHI. A number of commenters recommended we revise the conditions for practices to be recognized under the Preventing Harm Exception so that harm cognizable under the Privacy Rule under particular circumstances would also be cognizable under § 171.201.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We understand commenters' concerns about inconsistency across this exception and the Privacy Rule. In particular, concerns that center on the fact that requiring in § 171.201 that the risk must be to the “life or physical safety” of the patient or another person in all circumstances where § 171.201 applies would have set a different harm standard than applies under § 164.524(a)(3) in particular circumstances where both §§ 171.201 and 164.524(a)(3) apply. Specifically, where § 164.524(a)(3)(ii) or (iii) apply, the reviewable grounds for denial of right of access include where a licensed health care professional has determined, in the exercise of professional judgment, that the access requested is likely to cause “substantial harm.” In contrast, a uniform application of the “life or physical safety” type of harm under § 171.201 would have applied the “life or physical safety” type of harm standard to practices that interfere with access, exchange, or use of EHI for purposes of § 171.201 even where § 164.524(a)(3)(ii) or (iii) would also apply and where § 164.524(a)(3)(ii) or (iii) would apply the “substantial harm” standard.
                    </P>
                    <P>In response to comments, we have reviewed the potential for conflict between § 171.201 requiring “life or physical safety” as the type of harm in circumstances where § 164.524(a)(3(ii) or (iii) also apply. We have determined that for particular types of circumstances where both §§ 171.201 and 164.524(a)(3) apply, the best approach is to apply under § 171.201 the exact same harm standard that each specific sub-paragraph of § 164.524(a)(3) applies in each of these types of circumstances. We believe that extending the application under § 171.201 of the specific harm standards in § 164.524(a)(3)(i) through (iii) to situations that are similar in significant respects to situations where each of these sub-paragraphs of § 165.524(a)(3) would apply, but where § 164.524(a)(3) does not apply, provides consistency that simplifies compliance for actors subject to both 45 CFR part 171 and 45 CFR part 164. Situations where § 171.201 could apply but where § 164.524(a)(3) would not apply include, but are not limited to, those where the actor's practice is likely to interfere with an individual or their legal representative's access, exchange, or use of the individual's EHI but not to the extent of failing to provide access (as the term is used in context of § 164.524) within the timeframe allowed under § 164.524.</P>
                    <P>
                        To make the alignment between the Preventing Harm Exception and the Privacy Rule clear, the final regulation text at § 171.201(d) cross-references the specific types of harm that would serve as grounds for denying an individual or their personal representative access to their PHI under the Privacy Rule (§ 164.524(a)(3)) in particular types of circumstances.
                        <SU>138</SU>
                        <FTREF/>
                         By cross-referencing to § 164.524(a)(3), we align the regulations to streamline compliance for actors. We also believe this approach will allow that alignment to remain in place if changes were to be made to § 164.524(a)(3) harm standards in the future.
                        <SU>139</SU>
                        <FTREF/>
                         In particular types of circumstances where both § 164.524(a)(3) and § 171.201 apply, the subparagraphs of finalized § 171.201(d) (the type of harm condition) cross-reference to the § 164.524(a)(3)(i), (ii), and (iii) harm standard that applies under § 171.201 in each of these types of circumstances. Moreover, where only § 171.201 applies to a practice where the type of risk is consistent with § 171.201(c)(1), the finalized subparagraphs of § 171.201(d) cross-reference and apply the harm standard that § 164.524(a)(3)(i), (ii), or (iii) would apply to denial of the individual's (§ 164.524) right of access to their own PHI, the individual or their representative's access to the PII of another person within that PHI, or the individual's personal representative's access to the individual's PHI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>138</SU>
                             Meeting the harm standard is necessary but not alone sufficient for a practice to be recognized as reasonable and necessary under this exception; all other conditions of the exception must also be met.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>139</SU>
                             Alignment between part 171 subpart B and § 164.524(a)(1) and (2) is discussed in Section VIII.D.2. We also acknowledge that it is possible some types of revision to 45 CFR part 164 could necessitate modifications to 45 CFR part 171 in the future.
                        </P>
                    </FTNT>
                    <P>
                        One example of a particular circumstance in which both § 164.524(a)(3) and § 171.201 would apply is where a health care provider (as defined in § 171.102) that is also a HIPAA covered entity (as defined in § 160.103) denies the patient's personal representative access to the patient's EHI based on a licensed health care professional's determination in the exercise of professional judgment (§ 171.201(c)(1)) that granting that personal representative access to the patient's EHI would pose a risk of substantial harm to the patient.
                        <SU>140</SU>
                        <FTREF/>
                         In 
                        <PRTPAGE P="25824"/>
                        this circumstance, the finalized § 171.201(d)(1), which cross-references the harm standard applicable under § 165.524(a)(3)(iii), applies. In this example situation, the qualifying determination of risk of harm (§ 171.201(c)(1)) is that 
                        <E T="03">any</E>
                         access (or exchange, or use) of the EHI by the personal representative is reasonably likely to cause harm consistent with the standard established in § 164.524(a)(3)(iii), and thus the health care professional, or another HIPAA covered entity or business associate with knowledge of the determination, could also deny a request by the representative to access the individual's ePHI under § 164.524(a)(iii).
                    </P>
                    <FTNT>
                        <P>
                            <SU>140</SU>
                             For purposes of how the § 171.201 requirements and cross-references to § 164.524 operate within this example, it makes no difference whether the health care provider acting on the individualized determination is the licensed health care professional who made the determination 
                            <PRTPAGE/>
                            consistent with § 171.201(c)(1), another licensed health care professional, or another type of health care provider (such as a hospital or skilled nursing facility).
                        </P>
                    </FTNT>
                    <P>
                        Under § 164.524(a)(iii), the harm must be a “substantial harm” to qualify for the denial of the patient's personal representative's request to access the patient's PHI. Similarly, both § 171.201 and § 164.524(a)(3) apply where an information blocking actor that is also a HIPAA covered entity, acting in reliance on a determination of risk of harm made by a licensed health care professional in the exercise of professional judgment, does not provide the patient or the patient's personal representative any access to information within the patient's EHI that references another person. In this type of circumstance, § 171.201(d)(2) by cross-reference to § 164.524(a)(3)(ii) applies the same “substantial harm” standard under § 171.201 that applies to the actor's denying the patient or their representative access to that information under § 164.524(a)(3)(ii).
                        <SU>141</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>141</SU>
                             Note that the “individual” and “access” have different meanings under 45 CFR 164.524 from those in 45 CFR part 171. Regarding an individual's right of access under 45 CFR 164.524, the term “access” should be understood in that HIPAA Privacy Rule context.
                        </P>
                    </FTNT>
                    <P>
                        In § 171.201(d)(1), (2), and (3), as finalized, we also apply the harm standards described in § 164.524(a)(3)(i), (ii), or (iii) to particular types of circumstances where § 164.524 does not apply, but that are similar with respect to whether it is the patient or their representative requesting access, and whether the access requested is to information within the patient's EHI that is another person's identifiable information. For example, § 171.201(d)(3) applies the harm standard described in § 164.524(a)(3)(i) where practices that are likely to interfere with a patient's access, exchange, or use 
                        <SU>142</SU>
                        <FTREF/>
                         of the patient's own EHI are implemented to substantially reduce a risk of harm arising from data that is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason (§ 171.201(c)(2)). Provided its conditions are met in full, the Preventing Harm Exception (§ 171.201) would apply to such practices as delaying access, exchange, or use, for the time necessary to correct the errors that would otherwise pose a risk of harm to the patient (or another person) that would be cognizable under § 164.524(a)(3)(i) if § 164.524(a)(3)(i) applied.
                        <SU>143</SU>
                        <FTREF/>
                         Such delays are not explicitly addressed under § 164.524(a)(3), which provides a maximum timeframe for disclosure of PHI to which patients have the right of access, and § 164.524(a)(3) does not expressly contemplate risks of harm arising from data issues as would be consistent with § 171.201(c)(2). By contrast, § 171.201 defines when a practice that is likely to, or does, interfere with the access, exchange, or use of EHI is excepted from the definition of information blocking in § 171.103 that applies to the actor engaged in the practice, and expressly applies where the actor can demonstrate a reasonable belief the practice will substantially reduce a risk of harm arising from data issues consistent with § 171.201(c)(2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>142</SU>
                             As the terms “access,” “exchange,” and “use” are defined in § 171.102.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>143</SU>
                             Note, again, that “access” has a different meaning in subpart E of 45 CFR part 164 than it does in 45 CFR part 171.
                        </P>
                    </FTNT>
                    <P>Because risks of harm arising from data that is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason (§ 171.201(c)(2)) would apply equally to an individual's or their representative's or their health care provider's access, exchange, or use of the patient's EHI, § 171.201(d)(4) applies the standard in § 164.524(a)(3)(i) to all of these circumstances. Thus, as § 164.524(a)(3)(i) stands at the time of publication of this final rule, the access, exchange, or use of the EHI affected by the practice must be reasonably likely to endanger the life or physical safety of the patient or another person were the practice not implemented. (Please see Table 3 for a crosswalk of the particular types of circumstances addressed by the subparagraphs under § 171.201(d) to the § 164.524 harm standard applicable to each type of circumstance.)</P>
                    <P>
                        The finalized regulatory text in § 171.201 is revised from the Proposed Rule to reflect this more granular and comprehensive alignment of harm standards across the two regulatory provisions. We believe this alignment achieves the level of granular cross-reference necessary and that is preferable to selecting only one of these standards to apply in all types of circumstances under § 171.201. We further note that the revised regulation text is consistent with our decision to completely align the EHI definition with the definition of ePHI within the designated record set.
                        <SU>144</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>144</SU>
                             See section VIII.C.3 of this preamble and the finalized definition of “electronic health information” in § 171.102.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters advocated for expanding the definition of harm that is contemplated under this exception to encompass psychological and/or emotional harm in addition to risks to life or physical safety, including but not limited to expanding the concept of individualized determinations of risk of harm by health care professionals. A few commenters specifically advocated recognizing the potential for financial, reputational, or social/cultural harms. A number of other commenters expressed a concern that broadening the exception to address additional types of potential harm could risk its being overused to withhold information from patients where available evidence does not indicate there is a risk. One commenter reported having observed that some clinicians express a belief that mere disclosure of health data directly to patients without the clinician's professional interpretation will routinely cause harm, despite what the commenter described as existing evidence to the contrary.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe it would be challenging to define an appropriate and unique standard for purposes of this exception for non-physical harms that all actors defined in § 171.102 could apply consistently and, most importantly, without unduly restricting patients' rights to access their health information. We also recognize, as discussed above, the practical utility of alignment with relevant Privacy Rule provisions. At this time, only danger to the individual's “life or physical safety” is recognized as grounds for denial of an individual's right of access under § 164.524(a)(3)(i). However, “substantial harm” is the standard applied under the Privacy Rule where the access denied is to information identifying another person (other than a health care provider) or where an individual's personal representative is denied access to the individual's PHI under § 164.524(a)(3)(ii) or (iii). To align with the relevant Privacy Rule provisions, the final regulation text (§ 171.201(d)(1) and 
                        <PRTPAGE P="25825"/>
                        (2)) references the same harm standards as the Privacy Rule uses where § 164.524(a)(3)(ii) or (iii) as well as § 171.201 applies, and in circumstances where § 164.524(a)(3) is not implicated but the actor's practice is both based on an individualized determination of harm (consistent with § 171.201(c)(1)) and likely to interfere with: (§ 171.201(d)(2)) a patient's or their legal representative's access, exchange, or use of information within their EHI that identifies another person (other than a health care provider); or (§ 171.201(d)(1)) the patient's legal representative's access, exchange, or use of the patient's EHI. The finalized § 171.201(d)(3) and (4) also re-use the familiar § 164.524(a)(3)(i) type of harm for the wide variety of circumstances where § 171.201 applies but the type of risk is consistent with § 171.201(c)(2) or the (otherwise legally permissible) access, exchange, or use of EHI with which the practice is likely to interfere is by someone other than the patient or their legal representative. Thus, the finalized § 171.201 does not establish a standard for non-physical harm that would be unique to the Preventing Harm Exception but instead recognizes “substantial harm” in circumstances where § 164.524(a)(3)(ii) or (iii) apply, and also applies this familiar type of harm in situations where neither § 164.524(a)(3)(ii) nor (iii) applies but where re-use of this same standard under § 171.201 is consistent with the goal of aligning the types of harm recognized under Preventing Harm Exception with the grounds for denying a right of access request under the Privacy Rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter specifically recommended allowing actors to rely on an individual's own subjective beliefs related to harm.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We interpret this comment as pertaining to the beliefs of the patient whose EHI would be affected by a practice. We appreciate this opportunity to explain that practices implemented to honor and apply the patient's expressed preferences regarding access, exchange, or use of their EHI are addressed by the Privacy Exception finalized in § 171.202.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters requested clarification of how the Preventing Harm Exception and its conditions might operate in situations involving minors where applicable State laws allow non-emancipated minors to independently consent to certain types of health care and provide for keeping records of such care confidential from the minor's parents/guardians. Several of these commenters specifically requested clarification about the operation of this exception where State law provides for minors to be able to consent to some or all types of health care but does not provide for or allow the minors to access their health records information at all, or in specific format(s).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' offering us the opportunity to reiterate that where a particular access, exchange, or use of EHI is prohibited by applicable Federal, State, or tribal law, an exception to the definition of information blocking is not needed. Nothing in part 171 calls for access, exchange, use, or other disclosure of EHI that is prohibited by other applicable law. If an actor simply cannot effectively segment EHI they could safely and permissibly share from EHI they are not permitted to share in a given requested format, the actor should refer to the exception for requests that are infeasible (§ 171.204). However, if the EHI they could legally disclose could be shared in a different manner than that initially requested but the different manner would support segmentation, then an actor should provide the EHI they can safely and legally share in the most appropriate manner consistent with the Content and Manner Exception (§ 171.301).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters specifically requested clarification as to the information blocking implications where State law and/or the organization's account provisioning process do not provide for minors to obtain the login credentials needed to access their own records through an electronic portal, which will often be the login credentials a patient would use to authorize an app to receive the records through the provider's API.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Where the actor does not have a reasonable belief that a practice interfering with minors' access to their own EHI will substantially reduce a risk of harm cognizable under this exception, the Preventing Harm Exception (§ 171.201) would not apply. This exception would also not apply where any person—whether adult, emancipated minor, or non-emancipated minor—is not able to provide adequate verification of their identity consistent with the actor's health information privacy or security protection policies. Actors should assess practices related to verifying the identity of a patient, or a legal representative of the patient, for consistency with the conditions of the Privacy Exception as finalized in § 171.202 and/or the Security Exception as finalized in § 171.203. Likewise, practices implemented to confirm a representative's legal authority to access or request or authorize access, exchange, or use of a minor's EHI on behalf of the minor, should be analyzed in the context of the Privacy Exception as finalized in § 171.202 and/or the Security Exception as finalized in § 171.203. Where otherwise applicable law prohibits a specific access, exchange, or use of information, an exception to part 171 is not necessary due to the exclusion of “required by law” practices from the statutory information blocking definition in section 3022 of the PHSA (as discussed in section VIII.C.1 of this preamble). However, where an actor simply lacks the technical capability to provide access, exchange, or use in a specific requested mechanism, format, or manner, we would encourage the actor to review its practices for consistency with the new Content and Manner Exception finalized in § 171.301 or the Infeasibility Exception finalized in § 171.204.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarification as to whether the Preventing Harm Exception would apply to 42 CFR part 2 data when it is not made available for access, exchange, or use because the patient did not consent to its access, exchange, or use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the opportunity to remedy any confusion that may have been caused by the Proposed Rule's use of an illustrative example (84 FR 7524) within which the requirement to withhold data subject to 42 CFR part 2 regulations rendered a particular access, exchange, or use of only a portion of the patient's EHI legally permissible. In the example, only those portions of the patient's EHI to which 42 CFR part 2 does not apply could be permissibly accessed, exchanged, or used. This example was intended only to illustrate that the mere fact that an actor has knowledge, possession, custody, or control of more EHI than the actor could legally share would not, itself, provide a basis for application of the Preventing Harm Exception to the actor's withholding of any of the EHI that the actor could legally share. When an actor that is subject to 42 CFR part 2 cannot honor a request for access, exchange, or use of data subject to 42 CFR part 2 specifically because the patient has not provided the consent that would be required by 42 CFR part 2 before the actor could disclose that specific data for access, exchange, or use, the Preventing Harm Exception (§ 171.201) would not apply. When an actor has 42 CFR part 2 data for a patient but does not believe it has documented the patient consent that is legally required before the actor can fulfill a request for 
                        <PRTPAGE P="25826"/>
                        access, exchange, or use of that data, the actor should refer instead to the Privacy Exception finalized in § 171.202. If the actor lacks the technical capability to effectively segment data that it can legally share from data that it cannot legally share, the actor should also consider the new Content and Manner Exception finalized in § 171.301 or the Infeasibility Exception finalized in § 171.204.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters noted that some State laws prohibit the release of specific information, such as results of particular diagnostic tests, to patients through electronic means (
                        <E T="03">e.g.,</E>
                         patient portals or APIs) until particular protocols have been completed. Commenters cited, as an example, State law mandates for initial communication of particular information to the patient by a health professional in real time. The commenters requested clarification of whether or how § 171.201 would apply in those circumstances.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As is the case with 42 CFR part 2 data that the patient has not consented to disclose, the exception finalized in § 171.201 would not apply in these particular types of circumstances. The information blocking definition proposed and finalized in § 171.103 does not include a practice that is likely to, or in fact does, interfere with the access, exchange, or use of EHI when the practice is required by law. If the actor lacks the technical capability to segment data at the level of granularity needed to withhold only those data points, elements, or classes that it is legally prohibited from disclosing in response to a particular request, the actor should consider the Content and Manner Exception finalized in § 171.301 or the Infeasibility Exception finalized in § 171.204.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended that we recognize under § 171.201 practices requiring patients to obtain their laboratory results information only through the ordering provider's EHR. Commenters stated that inaccurate display of such results is a safety risk and that other actors such as laboratories and HINs/HIEs may not have the technical capability to display the information accurately in a human-readable interface that would be in full compliance with regulatory requirements otherwise applicable to human-readable displays of laboratory results information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree that display of inaccurate values for laboratory results, or other clinical observations, could represent a safety risk. We do not believe it would be appropriate to broadly limit patients to obtaining their laboratory information only from providers that are (or that employ) professionals whose scope of practice allows them to order the tests. If a laboratory, or a HIN/HIE, has the data in an interoperable format to support its exchange across providers, but does not have the technical capability to appropriately display it for human readability (such as in a patient portal), then the laboratory, or HIN/HIE, should make the data available in the interoperable format to providers or patients who can then view the data using technology the provider or patient has chosen as appropriate to their needs. If any actor receives a request for data access, exchange, or use via a specific mechanism that the actor does not have the technical capability to support, the actor should consider the Content and Manner Exception finalized in § 171.301 or the Infeasibility Exception finalized in § 171.204.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested recognizing a new exception under the Preventing Harm Exception that would allow a health care provider who is also a research institution to require, as a condition of making EHI available for use in research, that the health care provider be a collaborator in that research. The commenter stated that institutions ensure accuracy in the way data is used and analyzed by requiring they participate in any research involving their patients' information so that they can explain for the research team any anomalies or other characteristics unique to their own institutions' data and collection methods. This commenter stated that disclosing EHI for research purposes when the research being conducted does not involve the health care provider disclosing the EHI could lead to misinterpreted outcomes based on flawed data that could have a negative impact on scientific discovery.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We considered this suggested expansion of the Preventing Harm Exception specifically in the context of the definition of “electronic health information” that we proposed, and the more focused definition of “electronic health information” that we have finalized.
                        <SU>145</SU>
                        <FTREF/>
                         The Preventing Harm Exception is intended to apply to practices an actor reasonably believes will substantially reduce a risk of harm (of a type cognizable under this exception) to particular person(s), such as a patient or a natural person in the patient's life or multiple patients whose EHI was corrupted or mismatched due to a technical failure of an actor's systems. The risk of potential harm described by the comment was specifically of misinterpretations of EHI leading to research findings that negatively impact scientific discovery. This risk is too far removed from a reasonable, and reasonably foreseeable, likelihood of cognizable harm to particular patients or other particular natural persons to fit within the intent of the Preventing Harm Exception finalized in § 171.201. Therefore, we did not modify the exception in response to this comment.
                    </P>
                    <FTNT>
                        <P>
                            <SU>145</SU>
                             We note that, although various types of research data and data sets may be or include “electronic health information” as defined in § 171.102, not all research data or data sets are or include data meeting this definition.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Finalized Belief and Harm Conditions for § 171.201</HD>
                    <P>
                        Having considered comments received on the belief and harm standards, we have finalized the exception at § 171.201 with modification, as discussed in responses to comments. These modifications simplify the belief standard, and more thoroughly and specifically align the harm standard applicable for this exception with either the Privacy Rule harm standard applicable under § 164.524(a)(3)(i) (in most circumstances) or the harm standard in § 164.524(a)(3)(ii) or (iii) (in particular circumstances). The harm standard in § 164.524(a)(3)(ii) or (iii) applies where both §§ 171.201 and 164.524(a)(3)(ii) or (iii) would apply, or in particular circumstances that are sufficiently similar as to be analogous to circumstances where both §§ 171.201 and 164.524(a)(3)(ii) or (iii) would apply.
                        <SU>146</SU>
                        <FTREF/>
                         Please reference the finalized § 171.201(a) for the regulatory text of the belief standard. Please reference the finalized §§ 171.201(d)(1)-(3) for regulatory text that establishes the specific § 164.524(a)(3) harm standard that applies in each of the three particular types of circumstances specific to patients and their representatives' access to the patient's EHI, and reference § 171.201(d)(4) for regulatory text establishing the specific § 164.524(a)(3) harm standard applicable in all other types of circumstances where § 171.201 applies.
                    </P>
                    <FTNT>
                        <P>
                            <SU>146</SU>
                             Please note that the Preventing Harm Exception will not normally apply where a patient or their representative may seek access to EHI that is excluded from the right of access under § 164.524(a)(1) or to which access may be denied on unreviewable grounds under § 164.524(a)(2). In circumstances where § 171.201 conditions are not met but an actor wishes to withhold EHI from an individual's right of access under § 164.524(a)(1) or (2), the actor should refer to the privacy exception (§ 171.202).
                        </P>
                    </FTNT>
                    <P>
                        The circumstances where both §§ 171.201 and 164.524(a)(3) would apply are where the practices do 
                        <PRTPAGE P="25827"/>
                        interfere with access, exchange, or use by the patient or their legal representative (who is their personal representative for purposes of § 164.524) of some or all of the patient's EHI to the point of denying access (as used in context of § 164.524) on grounds of a risk of harm determined on an individualized basis by a licensed health care professional in the exercise of professional judgment (§ 171.201(c)(1) as finalized). Circumstances where § 164.524(a)(3) is not implicated but that are analogous to circumstances where both §§ 164.524(a)(3) and 171.201 apply are those where the risk of harm is determined on an individualized basis consistent with finalized § 171.201(c)(1) and the practice does not entirely deny but is likely to, or does, interfere with the patient's or their legal representative's access, exchange, or use of the EHI that is otherwise legally permissible. (For example, the practice may result in delaying access, exchange, or use of the EHI but for less time than is permitted for granting of a right of access request under § 164.524.)
                    </P>
                    <P>
                        In a wide variety of circumstances where § 171.201 will apply, § 164.524 would not apply. Such circumstances include those where the access, exchange, or use of EHI with which the practice is likely to, or does, interfere is not related to right of access under the HIPAA Privacy Rule, such as access, exchange, or use of the patient's EHI by the patient's health care providers. Likewise, § 171.201 will apply but § 164.524(a)(3) will not apply when the risk of harm arises from data issues (§ 171.201(c)(2)) rather than having been determined on an individualized basis by a licensed health care professional (§ 171.201(c)(1)). In these circumstances where § 164.524 would not apply, and that are not analogous to circumstances where § 164.524(a)(3) would apply, § 171.201(d)(4) (type of harm condition) applies the harm standard that would be cognizable under § 164.524(a)(3)(i) so that the actor must reasonably believe the practice will reduce a risk otherwise posed to the life or physical safety of the patient or another natural person.
                        <SU>147</SU>
                        <FTREF/>
                         This provides, under § 171.201, consistency across this wide array of circumstances where § 164.524(a)(3) would not be implicated regardless of the extent of interference or length of delay the practice may pose to the access, exchange, or use of the EHI. Because the circumstances to which the finalized § 171.201(d)(4) applies include access, exchange, or use of the patient's EHI by health care providers furnishing services to the patient, we believe it is most appropriate to apply under § 171.201(d)(4) the same standard of harm that would apply to denying a patient access to the patient's EHI. This is consistent with our proposal (84 FR 7602) to require that practices likely to interfere with any access, use, or exchange of EHI would need to reduce a risk to the “life or physical safety” of a patient or another person to satisfy the conditions in § 171.201 and be excepted from the definition of information blocking in § 171.103. We have also clarified the regulation text so it is expressly clear on its face that the risk to be reduced must be one that would otherwise arise from the specific access, use, or exchange of EHI affected by the practice.
                    </P>
                    <FTNT>
                        <P>
                            <SU>147</SU>
                             Please note that although “individual” as defined in 45 CFR 169.103 is not limited to natural persons, the belief standard in the finalized § 171.201 is, consistent with the requirement that in most circumstances the risk of harm at issue must be to life or physical safety.
                        </P>
                    </FTNT>
                    <P>
                        Under § 164.524(a)(3)(i), a covered entity may deny an individual access to protected health information (PHI) about that individual in a designated record set only if a licensed health care professional in the exercise of professional judgment determines that releasing the information to them would endanger the life or physical safety of the individual or another person. Under § 171.201(d)(3), an actor 
                        <SU>148</SU>
                        <FTREF/>
                         may implement a practice that is likely to, or does, interfere with the patient's access, exchange, or use of their own EHI when the actor reasonably believes the practice will substantially reduce a risk of harm to life or physical safety of the patient or another person, regardless of whether that risk is determined on an individualized basis (§ 171.201(c)(1)) or arises from data that is known or reasonably suspected to be corrupt due to technical failure, erroneous for another reason, or misidentified or mismatched (§ 171.201(c)(2)).
                    </P>
                    <FTNT>
                        <P>
                            <SU>148</SU>
                             An actor could be any individual or entity meeting the definition of “health care provider,” “health IT developer of certified health IT” or “health information network or health information exchange” in § 171.102, and may or may not also be a HIPAA covered entity or business associate as defined in the HIPAA Rules.
                        </P>
                    </FTNT>
                    <P>
                        Under § 164.524(a)(3)(ii) and (iii), the standard of “substantial harm” applies where the individual or their representative are denied access to information in the individual's record that identifies another person (other than a health care provider), or an individual's personal representative is denied access to the individual's information. Thus, the type of harm standard applicable under § 171.201 will in most cases require that the actor's practice be based on a reasonable belief that the requested access, exchange, or use with which the practice is likely to or does interfere would otherwise endanger the “life or physical safety” of the patient or another person. However, the “substantial harm” standard included in § 164.524(a)(3)(ii) and (iii) would apply in specific circumstances as shown in Table 3. As discussed above, we have made this change to the finalized § 171.201 to align the harm standard applied by § 171.201 with the one applied by § 164.524(a)(3) where both would apply, and in analogous circumstances (as described above). As explained above, we revised the harm standard applicable in particular circumstances to avoid setting a higher threshold under § 171.201 for practices likely to interfere with access, exchange, or use 
                        <SU>149</SU>
                        <FTREF/>
                         of EHI than would be applicable to entirely denying access under § 164.524(a)(ii) or (iii) 
                        <SU>150</SU>
                        <FTREF/>
                         in the same circumstances. In the finalized § 171.201(d), we have applied the type of harm described in § 164.524(a)(ii) and (iii) to particular circumstances where § 164.524(a)(ii) and (iii) do not apply, but that are analogous to such circumstances, for the reasons stated in responses to comments above.
                    </P>
                    <FTNT>
                        <P>
                            <SU>149</SU>
                             As “access,” “exchange,” and “use” are defined in § 171.102.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>150</SU>
                             Please note that “access” has a different meaning under 45 CFR 164.524 than in 45 CFR part 171. Regarding an individual's right of access under 45 CFR 164.524, the term “access” should be understood in that HIPAA Privacy Rule context.
                        </P>
                    </FTNT>
                    <PRTPAGE P="25828"/>
                    <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s150,r150">
                        <TTITLE>Table 3—Mapping of Circumstances Under § 171.201(d) to Applicable Harm Standards</TTITLE>
                        <BOXHD>
                            <CHED H="1">Requirements under § 171.201(d) type of harm condition</CHED>
                            <CHED H="1">
                                Applicable harm standards 
                                <SU>151</SU>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">§ 171.201(d)(1)—where the practice interferes with access, exchange, or use of the patient's EHI by their legal representative and the practice is implemented pursuant to an individualized determination of risk of harm made by a licensed health care professional in the exercise of professional judgment (§ 171.201(c)(1))</ENT>
                            <ENT>
                                The harm of which the actor reasonably believes the practice will substantially reduce a risk must be the type of harm described in 45 CFR 164.524(a)(3)(iii), which is substantial harm to the individual or another person.
                                <SU>152</SU>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 171.201(d)(2)—where the practice interferes with the patient's or their legal representative's access to, use or exchange of information that references another natural person and the practice is implemented pursuant to an individualized determination of risk of harm made by a licensed health care professional in the exercise of professional judgment (§ 171.201(c)(1))</ENT>
                            <ENT>The harm of which the actor reasonably believes the practice will substantially reduce a risk must be the type of harm described in 45 CFR 164.524(a)(3)(ii), which is substantial harm to such other person.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 171.201(d)(3)—where the practice interferes with the patient's access, exchange, or use of their own EHI, regardless of whether the risk the practice is implemented to substantially reduce is determined on an individualized basis by a licensed health care professional in the exercise of professional judgment (§ 171.201(c)(1)) or arises from data that is known or reasonably suspected to be corrupt due to technical failure, erroneous for another reason, or misidentified or mismatched (§ 171.201(c)(2))</ENT>
                            <ENT>The harm of which the actor reasonably believes the practice will substantially reduce a risk must be the type of harm described in 45 CFR 164.524(a)(3)(i), which is a harm to the life or physical safety of the individual or another person.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 171.201(d)(4)—where the practice interferes with the patient's legal representative's otherwise legally permissible access, exchange, or use of the patient's EHI and the practice is implemented to reduce a risk arising from data that is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason (§ 171.201(c)(2))</ENT>
                            <ENT>The harm of which the actor reasonably believes the practice will substantially reduce a risk must be the type of harm described in 45 CFR 164.524(a)(3)(i), which is a harm to life or physical safety of the individual or another person.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">
                        Types of
                        <FTREF/>
                         Risk of Harm
                        <FTREF/>
                         to Patients Cognizable Under This Exception
                    </HD>
                    <FTNT>
                        <P>
                            <SU>151</SU>
                             Note that the “individual” and “access” have different meanings under 45 CFR 164.524 from those in 45 CFR part 171. Regarding an individual's right of access under 45 CFR 164.524, the term “access” should be understood in that HIPAA Privacy Rule context.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>152</SU>
                             Note that grounds for denial of an individual's right of access include that the access is reasonably likely to cause the harm identified in the particular subparagraph under § 164.524(a)(3). For purposes of 45 CFR part 171, we interpret that the stated type of harm must, to the best of the actor's knowledge and belief, be substantial, in absence of particular practice(s), in order for an actor to reasonably believe the practice(s) will substantially reduce that risk. We would interpret a reasonable likelihood of the described harm, as used under § 164.524(a)(3) to be a substantial risk for purposes of § 171.201.
                        </P>
                    </FTNT>
                    <P>We proposed (84 FR 7524) that to qualify for this exception, an actor's practice must respond to one or more type(s) of risk of harm cognizable under this exception. The three types of risk of harm that we proposed would satisfy the conditions of this exception are:</P>
                    <P>• Risks arising from corrupt or inaccurate data being recorded or incorporated in a patient's EHI;</P>
                    <P>• risks arising from misidentification of a patient or patient's EHI; and</P>
                    <P>• risks identified by a determination made by a licensed health care professional that a specific access or disclosure of EHI is reasonably likely to endanger the life or physical safety of the patient or another person.</P>
                    <P>We provided additional explanation and discussion of these types of risk of harm in the preamble of the proposed rule (84 FR 7524 and 7425). We also requested comment (84 FR 7525) on:</P>
                    <P>• Whether these categories of harm capture the full range of safety risks that might arise directly from accessing, exchanging, or using EHI; and</P>
                    <P>• Whether we should consider other types of patient safety risks related to data quality and integrity concerns or that may have a less proximate connection to EHI but that could provide a reasonable and necessary basis for an actor to restrict or otherwise impede access, exchange, or use of EHI in appropriate circumstances.</P>
                    <P>We will first discuss those comments that pertain to the cognizable types of risk of harm in general. Comments specific to each of the three types of risk of harm will be discussed separately, in the order they were presented in the Proposed Rule.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Overall, comments were supportive of the exception recognizing risks of harm arising from corrupt or misidentified information, and individualized determinations of risk of harm made by licensed health care professionals in the exercise of professional judgment. Numerous commenters requested clarification or additional information to help actors more effectively understand and efficiently document their risk determinations in connection to practices for which they would seek to claim that the Preventing Harm Exception applies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback received. In response to comments calling broadly for additional clarification or information, we have provided detailed responses to comments received. Where useful to enrich the discussion, some responses discuss hypothetical example situations that illustrate how a particular aspect of the exception would operate in such a situation.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some comments suggested that the determinations and the rationale for individualized determinations by health care professionals in the exercise of professional judgment should be documented in the electronic health record.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe documentation in the EHR, such as in appropriate notes field(s), may be a practical, efficient approach to documentation of determinations of risk of harm consistent with § 171.201 for some — perhaps many — licensed health care professionals. Therefore, we confirm that EHRs are considered an appropriate approach or method for the documenting, and for retaining documentation, of determinations of risk consistent with § 171.201(c)(1). We also note that much (perhaps all) of the information about the patient's individual circumstances that factors into the professional's determination of risk will most naturally and most often be documented in the EHR in the ordinary course of furnishing care to the patient. Nothing in § 171.201 would require duplicating information already captured in the EHR in a different form 
                        <PRTPAGE P="25829"/>
                        or format specific or unique to § 171.201, whether in the EHR or elsewhere. However, we also believe that there is substantial potential for variability in health care professionals' current methods for documenting risk factors and determinations.
                    </P>
                    <P>In addition, we do not believe it is necessary to require different or duplicate documentation of information that is already otherwise captured in reliable business records consistent with the HIPAA Privacy Rule and applicable State laws—including, but not limited to, laws protecting patient privacy or mandating provider reporting of particular types of abuse their patients may experience. Therefore, requiring via regulation that all health care professionals document their determination specifically in the EHR in order to satisfy this exception's conditions could impose an unnecessary burden on those who would like to conform their practices to this exception but currently take a different approach to documenting risk factors or to documenting individualized determinations of risk specific to access, exchange, or use of the patient's EHI by the patient or their legal representative(s). Thus, we have not finalized a requirement that licensed health care professionals must document in their EHR or in any other particular system(s) their individualized determinations of risk of harm in order for the determinations of risk to satisfy the risk of harm condition finalized in 171.201(c)(1).</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter noted that minors may not fully understand the implications of downloading and sharing their EHI, which represents a different type of risk than the three discussed in the Proposed Rule. The commenter advocated for health care providers to have discretion to impose restrictions on non-emancipated minors' ability to access their EHI through an API.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not modify the Preventing Harm Exception in response to this comment. The Preventing Harm Exception (§ 171.201) is intended to apply to practices an actor reasonably believes will substantially reduce a risk of harm to one or more particular person(s), and in many circumstances (§ 171.201(d)(3) or (4)) a risk of harm to the life or physical safety of particular persons, such as: A patient or person in the patient's life; or multiple patients whose EHI was corrupted or mismatched due to a technical failure of an actor's systems. Where a non-emancipated minor, or other patient, is otherwise legally entitled to access or receive their own health information that does not include identified information about another person, the Preventing Harm Exception will apply only to those practices reasonable and necessary to address risk to the life or physical safety of another person consistent with § 171.201(d)(3) and its specific cross-reference to § 164.524(a)(3)(i). The Privacy Exception (§ 171.202) is intended to recognize reasonable and necessary practices to protect patients' privacy. We also note that we have clarified in this final rule that although practices that purport to educate patients about the privacy and security practices of applications and parties with which a patient chooses to share their EHI would always be subject to review by OIG if there were a claim of information blocking, such practices likely would not be considered to interfere with the access, exchange, and use of EHI if they meet certain criteria (see section VIII.C.6, above).
                    </P>
                    <HD SOURCE="HD3">Risk of Corrupt or Inaccurate Data Being Recorded or Incorporated in a Patient's Electronic Health Record</HD>
                    <P>We proposed (84 FR 7524) that the Preventing Harm Exception could apply to practices that address risks of harm arising from corrupted or inaccurate EHI being recorded or incorporated in a patient's electronic health record. We further proposed that recognized risks from incorrect or inaccurate information would be limited to those arising from known or reasonably suspected corruption and inaccuracies caused by performance and technical issues affecting health IT. We clarified that the Preventing Harm Exception would not extend to purported accuracy issues arising from the incompleteness of a patient's electronic health record generally. We acknowledged that Federal and State laws may require an actor to obtain an individual's written consent before sharing specific health information, such as information subject to 42 CFR part 2. However, we expressly noted in the Proposed Rule that this exception would not apply to an actor's conduct in refusing to provide access, exchange, or use of the remainder of the patient's record on the basis that the information withheld per patient's non-consent would render the remainder of the patient's record incomplete and thus inaccurate. We also noted that known inaccuracies in some data within a record may not be sufficient justification to withhold the entire record so long as the remainder of the patient's EHI could be effectively shared without also presenting the known incorrect or corrupted information as if it were trustworthy.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were supportive of the Preventing Harm Exception applying to appropriate practices to address corrupt or incorrect data in EHI and the risks that would otherwise arise from propagation of corrupt or otherwise incorrect EHI within a patient's record.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate all of the feedback received, including but not limited to confirmation that responding stakeholders are supportive of this exception applying to practices an actor reasonably believes will substantially reduce a risk of harm otherwise arising from access, exchange, or use of corrupt or inaccurate data within a patient's record.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter, acknowledging that patients' wishes that specific information not be shared should be honored, advocated expanding this exception to cover physicians' declining to disclose any EHI to other physicians where withholding of some information at the patient's request would, in the disclosing physician's view, render the patient's record so distorted as to be misleading.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As we explained in the Proposed Rule, we would not recognize incompleteness of the EHI that an actor can disclose as a source of a risk of harm cognizable under this exception. For instance, patients may make requests that specific information not be accessed, exchanged, or used beyond a specific clinician-patient (or other relevant) relationship because the information is associated with a stigmatized condition, or for personal reasons (such as the patient's subjective perception the information may be embarrassing or otherwise detrimental to them). In the Proposed Rule, we provided an illustrative example of a patient declining consent to share 42 CFR part 2 substance abuse treatment information, and stated we would not consider the remainder of the patient's record inaccurate based on its incompleteness (84 FR 7524). Health care providers receiving any patient's records of prior care presumably have an awareness of the potential that some information may be omitted from the information they receive for a wide variety of reasons that include, but that are not limited to, patients' intentional choices to withhold some information. Therefore, we do not believe it would be appropriate to consider EHI to be corrupt, inaccurate, or otherwise erroneous where it is simply a subset of everything an actor knows about the patient.
                    </P>
                    <P>
                        We are not persuaded that a patient's withholding consent to share specific 
                        <PRTPAGE P="25830"/>
                        portions of their overall EHI, regardless of the patient's rationale for withholding consent, would render the data set their physician (or other health care provider) could share more dangerous to the patient than sharing none of the patient's EHI with another of the patient's providers. Instead, we remind health care providers that nothing in part 171 overrides Federal, State, or tribal law protections of patients' privacy preferences. Likewise, nothing in part 171 reduces variation in what and how much information patients remember, or are willing, to disclose to their health care providers. Patients remain free to withhold various information from their health care providers, including but not limited to what other providers they may have seen in the past.
                    </P>
                    <P>Before enactment of the Cures Act, health care providers could not safely assume every patient record they received from any source necessarily included all the information that could or should be known by that source that would be relevant to the patient's health or care by that provider, even where the source can permissibly share everything they do know. Thus, we reiterate that we do not believe it is reasonable or necessary for purposes of preventing harm that a provider withhold the EHI that they could permissibly share in any particular circumstance simply because they happen to have more EHI than they can permissibly share.</P>
                    <P>
                        However, we also highlight that for purposes of this exception a data export or access mechanism appropriately showing that some data may be unavailable or omitted from the export or presentation is materially different from a data export or presentation that misrepresents the patient's EHI. For example, exports or presentations omitting all medication data and correctly stating “medication data not available,” 
                        <SU>153</SU>
                        <FTREF/>
                         we would not consider corrupt, inaccurate, or otherwise erroneous. By contrast, however, an export or presentation stating “no current medications,” or stating “none” or “none known” in the medication section, when in fact the system producing the export or representation does include current known medications for the patient, represents a type of risk recognized under § 171.201(c)(2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>153</SU>
                             Or otherwise indicating, in a manner appropriate to the circumstances, that absence of information in the extract or representation should not be understood as a statement that there is no such data in the source system.
                        </P>
                    </FTNT>
                    <P>Under § 171.201(d)(4), as finalized, a practice that is likely to, or that in fact does, interfere with otherwise permissible access, exchange, or use of a patient's EHI by their health care providers must be one the actor implementing the practice reasonably believes will substantially reduce a risk of harm of a type that could serve as grounds for denial of the individual's right of access to their EHI under the 45 CFR 164.524(a)(3)(i). Therefore, in order for a practice likely to interfere with the access, exchange, or use of EHI by one of the patient's health care providers to satisfy the conditions of the Preventing Harm Exception, the actor must hold a reasonable belief that the practice will substantially reduce a risk to the patient's, or another natural person's, life or physical safety that would otherwise arise from the access, exchange, or use of the EHI with which the practice interferes. Erroneous misrepresentations that a patient is not known to be taking any medications, when in fact they are known to be taking one or more medications, is typically a system problem and one that can give rise to risk to the physical safety, or even the life, of any or all patients whose EHI may be affected by the problem.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One comment submission highlighted a tension between the data-provision preferences of health care providers requesting data and other actors (such as other providers and their health IT developers) from whom data is requested. This commenter indicated providers requesting data, such as long-term/post-acute providers caring for patients after a hospital stay, may currently have to wait days to receive any of the patient's clinical data from the hospital stay because the hospital or its health IT developer refuses to generate and send the C-CDA document until every last data element is finalized. The commenter suggested we clarify whether § 171.201 would apply to such circumstances.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         An actor's practice of delaying fulfillment of an otherwise feasible and legally permissible request for exchange, access, or use of EHI that is finalized and available to the actor merely because the actor knows more EHI for that patient will become available at some later date would not satisfy the conditions of § 171.201. As we stated in the Proposed Rule, we do not view mere 
                        <E T="03">incompleteness</E>
                         of a patient record as rendering the remainder of the patient's record inaccurate (84 FR 7524). We recognize that specific data points may not be appropriate to disclose or exchange until they are finalized. Such data points would include, but are not necessarily limited to: Laboratory results pending confirmation or otherwise not yet considered by the hospital reliable for purposes of clinical decision making; or notes that the clinician has begun to draft but cannot finalize until they receive (confirmed) laboratory or pathology results or other information needed to complete their decision making. We hope it is, and will be increasingly, rare that an actor cannot effectively sequester non-finalized EHI from finalized EHI. However, we cannot rule out the possibility that some actors may face that problem at some point. If an actor cannot effectively sequester non-finalized EHI from a particular access, exchange, or use where inclusion of non-finalized EHI would not be appropriate, the actor should refer to the new Content and Manner Exception (finalized in § 171.301) or the Infeasibility Exception finalized in § 171.204.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters expressed concerns that many actors' health IT systems currently lack the capability to segment data by class and element that would be needed to withhold only those classes or elements that were corrupted or erroneous as described in the Proposed Rule. Commenters requested clarification on whether the § 171.201 Preventing Harm Exception would in these cases apply to the entirety of the patient's EHI, how it would apply, or if another exception would also be needed.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the circumstances these comments described, the Preventing Harm Exception will apply only to the EHI known or reasonably suspected to be corrupt or erroneous. If an actor lacks the data segmentation capabilities that would be needed to sequester only that data known or reasonably suspected to be corrupt or erroneous from the requested access, exchange, or use, we would encourage the actor to consider meeting the conditions of another exception with respect to the remaining EHI. For example, the Content and Manner Exception (§ 171.301) may allow for the actor to provide the requestor with the EHI not known or reasonably suspected to be corrupt or erroneous, albeit in a different way than was initially requested. Or, if the actor lacks the technical capability to share the EHI that is not known or reasonably suspected to be corrupt or erroneous consistent with the Content and Manner Exception (§ 171.301), then the actor may wish to meet the Infeasibility Exception (§ 171.204). The applicability of the exceptions will depend on the particularized circumstances, including but not limited to the specific request made. We believe the conditions of these exceptions also offer frameworks within which a responding actor and an 
                        <PRTPAGE P="25831"/>
                        EHI requester may be able to identify a mutually agreeable approach to making trustworthy EHI appropriately available in at least some of the instances where a request cannot be safely fulfilled in exactly the manner of the requester's first preference.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One comment expressed a concern that some health care providers, particularly those already receiving feedback from payers about their data quality, might believe the Preventing Harm Exception would allow them to withhold patients' access to the patients' own EHI to prevent the patients from seeing data quality issues the provider knows or believes are present in that EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         If a provider knows that the data quality issues in their records serve as a source of risk consistent with § 171.201(c)(2), so as to form the basis of a reasonable belief the patient's accessing or using the data would place the patient at risk of harm cognizable under this exception,
                        <SU>154</SU>
                        <FTREF/>
                         the exception would apply if all other conditions of the exception were met. However, known corruption or other errors that would place a patient accessing their EHI at risk of harm cognizable under this exception on the basis of accessing—and presumably making health or care decisions based on—that EHI would also raise a substantial concern regarding the safety of that EHI for use by the provider. Thus, we would expect that whenever a given health care provider believes the EHI within their records is safe enough for their own use in the delivery of patient care, the Preventing Harm Exception would not excuse the provider from honoring their patients' requests to access, exchange, or use that EHI simply because the patients might discover error(s) in that EHI. If, to the actor's knowledge or reasonable belief, only some data classes or elements within a patient's EHI are a source of risk consistent with § 171.201(c)(2), the actor should continue to make the remaining data classes and elements available to the patients and other requestors (as appropriate under applicable law). Where the actor lacks the technical ability to appropriately sequester only the corrupt or erroneous data within the EHI they hold for given patient(s), the actor should reference the Content and Manner Exception finalized in § 171.301 or the Infeasibility Exception finalized in 171.204.
                    </P>
                    <FTNT>
                        <P>
                            <SU>154</SU>
                             Note that where the practice interferes with a patient's access to their own EHI, the applicable harm standard is established in § 171.201(d)(3) and is the same one established at § 164.524(a)(3)(i). Currently, that would be harm to life or physical safety.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested clarification on whether an actor has a responsibility to assess the data in their possession, custody, or control for risk of harm before making it available for access, exchange, or use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The conditions finalized in § 171.201 for practices that interfere with the access, exchange, and use of EHI for purposes of preventing harm to be excepted from the definition of information blocking (§ 171.103) do not require that actors generally evaluate data requested for data quality issues or other sources of risk of harm before fulfilling requests for access, exchange, or use of the EHI. At the same time, actors should be aware that where an actor may have an affirmative duty under otherwise applicable law for the quality or accuracy of data, or for assessing other types of risk of harm that could be implicated by an EHI access, exchange, or use request, nothing in § 171.201 should be construed as lessening or otherwise changing that duty. For example, the Preventing Harm Exception does not lessen or otherwise change an actor's existing obligations to ensure patient EHI is created, recorded, and maintained to standards of accuracy and reliability consistent with laws, regulations, and accreditation requirements applicable to the particular actor in any given circumstance.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed appreciation for the inclusion of this exception so that health care providers will not be forced to share incorrect data. Several of these commenters requested we clarify a provider's responsibility for correcting corrupt or incorrect information once it is discovered.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         For health care providers, existing State and Federal laws and regulations address the responsibility to maintain appropriate records of health care furnished and in support of reimbursement sought from various programs and payers. Health care providers that have obtained voluntary accreditations may have made additional commitments related to record-keeping and data quality in context of obtaining and maintaining those accreditations. These existing responsibilities of health care providers are not lessened or otherwise changed by the Preventing Harm Exception. The exception simply provides for exception from the definition of information blocking at § 171.103 of practices interfering with the access, exchange, or use of mismatched, corrupt due to technical failure, or otherwise erroneous EHI in order to substantially reduce a risk of harm. Presuming its conditions are otherwise met, § 171.201 would apply to a variety of practices appropriate to correct mismatched, corrupt due to technical failure, or otherwise erroneous EHI in a manner consistent with otherwise applicable law, regulations, accreditation standards, and payment program standards.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One comment requested clarity regarding the applicability of this exception to data received from a third party, where the actual accuracy of the data cannot be, or has not been, confirmed by the actor asked to make that data available for access, exchange, or use.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We recognize that in some circumstances the available and feasible mechanisms for EHI access, exchange, or use may not support as much data provenance information as an actor might prefer. In such circumstances, the actor would be free to communicate supplemental information about specific data's provenance to a requestor. However, the conditions of the Preventing Harm Exception would not be met where EHI requested was received from a third party and the actor could not confirm the accuracy of the EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A comment from the perspective of health IT developers and implementers stated that this exception should allow an actor to err on the side of caution as the actor looks to determine the extent of potential distortions in a record before sharing it. A number of commenters described practices used today by HIEs to assess and resolve data quality issues, including but not limited to taking all of the records from a particular source offline while assessing the extent or cause of issues identified in some record(s) from that source.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Preventing Harm Exception is intended to apply to a variety of practices reasonable and necessary to protect patients from risk of harm arising from access, exchange, or use of data that is known or reasonably suspected to be corrupt, inaccurate, mismatched, or misidentified. To be covered by the exception, the practice may interfere with the access, exchange, or use of EHI only to the minimum extent necessary to substantially reduce a risk of harm cognizable under the exception, but the exception does not require that every record affected by the practice have first been confirmed to contain corrupt, mismatched, or otherwise dangerously problematic data. In some circumstances, such as a particular data source experiencing a 
                        <PRTPAGE P="25832"/>
                        known or reasonably suspected system or other technical failure producing widespread corruption, mismatching, or other dangerous errors, the minimum reasonable and necessary precautions may make all records from that source unavailable pending resolution of the technical failure and its risk-producing effects. The actor's knowledge or reasonable suspicion could be appropriately derived in various ways. These ways would include, but are not limited to: Detection of specific data quality issues in a sampling of records from the particular source; or receipt of notice from a source that they had experienced technical issues or failures resulting in corruption, mismatching, or other data quality issues giving rise to risks of harm cognizable under this exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter noted that this exception should be applied rarely, and when applied should not be a mechanism to selectively block information from specific actors. However, several other commenters made observations that, in current practice, EHI coming from sources whose data has a pattern of higher-than-normal error rates may be subjected to more extensive review, and potentially delayed in broader availability, compared with EHI from sources whose data error rate is within a more normal range. Comments describing such current practices recommended that this exception should allow for continued application of additional data quality assurance processing to EHI from sources whose data exhibits a history or pattern of more numerous or more risky data quality issues.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         If an actor were to engage in practices systematically interfering with access, exchange, or use of EHI from a particular source based on considerations extraneous to the prevalence and risk profile of data quality issues in the EHI, such practices would not meet the conditions to be excepted under § 171.201 from the definition of information blocking finalized in § 171.103. Examples of considerations we would consider to be extraneous in this context notably include, but are not limited to, whether the data source was competitor of the actor and whether the actor may harbor personal animus toward the data source. However, this exception would apply to practices not based in whole or any part on considerations extraneous to the prevalence and risk profile of data quality issues in the EHI, provided each such practice meets all conditions in § 171.201 that are applicable to the circumstances in which it is used.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters noted that integration of data from various types of sources is challenging because of differences in the data elements that different types of sources can exchange, and because of technical differences in how similar data elements may be structured, defined, or encoded across different types of sources. Commenters also stated that data from new exchange partners may raise questions about potential accuracy issues in interpreting and integrating different types of data as well as integrating similar data from various types of sources. Commenters recommended that § 171.201 recognize that practices may delay integration and availability of EHI in order to address these issues, and also recommended that a time limit be established for completing evaluations of incoming data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' highlighting that the U.S. health care system as a whole includes opportunities for access, exchange, and use of a wider variety of data classes and elements than are currently addressed by standards and implementation specifications adopted in part 170, and more sources than just those actors currently using certified health IT. We are aware that, in a variety of circumstances, safely and appropriately integrating data from a new source may require time to determine and apply appropriate processing approaches to ensure that data are not corrupted in the process of mapping or converting them to the structures and standards used by the recipient. Our finalized exception will apply to appropriately tailored practices for assessing and mitigating risks otherwise posed by integration of data from new sources, that is not standardized, or that is standardized to non-published, proprietary, or obsolete standards. In cases where the original meaning of EHI received cannot be determined in a manner allowing for conversion to the formats and standards used by the recipient's systems, it may sometimes be necessary to decline to integrate such data in the recipient's production systems. However, we believe it would be premature to establish via this rulemaking specific time limits for assessment and processing of EHI received from new exchange partners, in large part due to the considerable variability in systems and circumstances of the actors involved in such exchange relationships. Should the need arise to assess the reasonableness, necessity, and timeliness of an actor's practices applied to data received from new or various types of sources, we would do so in context of the specific circumstances in which particular practices were applied by particular actor(s).
                    </P>
                    <HD SOURCE="HD3">Finalized Policy for Risks of Harm Arising From Corrupt or Inaccurate Data</HD>
                    <P>We have finalized the type of risk condition with modifications to the proposed regulation text. We have reorganized the regulation text, and in the context of that reorganization rephrased the statement of some conditions. We have also, in § 171.201(c)(2) replaced the word “inaccurate” (used in proposed § 171.201(a)(2)) with “erroneous” to better differentiate between normal shortfalls in the complete accuracy of a record and risk-generating errors in the data. We also combine all data-specific sources of risk of harm in the final § 171.201(c)(2) instead of splitting them across two paragraphs as was the case in § 171.201(a)(1) (“corrupt or inaccurate” in the Proposed Rule) and § 171.201(a)(2) (“misidentified or mismatched” in the Proposed Rule). We made this change because misidentified, mismatched, corrupt, and otherwise erroneous data are all sources of risk arising from issues with the data rather than characteristics unique to a patient or their circumstances. Additional conditions must be met for § 171.201 to apply to practices implemented to substantially reduce a risk of harm arising from data issues (consistent with § 171.201(c)(2)), including § 171.201(a), (b), (d)(3) or (4), and (f)(1) or (2). Whether (d)(3) or (d)(4) applies turns on whether the practice is likely to, or does, interfere with a patient's own or other legally permissible access, exchange, or use of the patient's EHI. Whether (f)(1) or (f)(2) applies turns on whether the actor implements the practice consistent with an organizational policy (f)(1) or based on a determination based on the particularized facts and circumstances known or reasonably believed by the actor at the time the determination was made and while the practice remains in use (f)(2).</P>
                    <P>
                        For purposes of providing additional information and explanation as requested by many commenters, we reiterate that a risk of harm arising from data that is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason (§ 171.201(c)(2) as finalized) will not, consistent with discussion and illustrative examples in the preamble to the Proposed Rule (84 FR 7524), satisfy the conditions of the Preventing Harm 
                        <PRTPAGE P="25833"/>
                        Exception if it turns on mere speculation about, or possibilities of, as-yet-undetected inaccuracies or other imperfections in the EHI. An electronic health record, like the paper chart it replaces, is inevitably less than perfectly complete and precisely accurate across 100 percent of the variables potentially relevant to the individual's health. Because the risk that records in general may be imperfect is a risk that we understand as inherent to (and thus ordinarily addressed in the course of) clinical practice, it will not be recognized as justifying practices that implicate the information blocking definition. Thus, the Preventing Harm Exception finalized in § 171.201 does not extend to purported accuracy issues arising from potential, suspected, or known incompleteness of a patient's electronic health record generally, such as the possibility of a patient choosing, or not remembering, to mention some of the medications they regularly take. Similarly, the possibility that any given patient's EHI could at any time contain sporadic, undetected, inaccurate data points as a result of data entry errors—such as an entered weight of 123 instead of the accurate observation of 132—would not be interpreted as satisfying the condition finalized in § 171.201(c)(2).
                    </P>
                    <P>The Preventing Harm Exception will apply in those instances where specific EHI of one or more patients is affected by a risk consistent with the finalized § 171.201(c)(2). Assuming its other conditions that are applicable to the specific circumstances are met, the Preventing Harm Exception will apply to appropriately tailored practices that affect a particular patient's EHI regardless of the origin or cause of known or reasonably suspected data issues giving rise to risk of harm consistent with § 171.201(c)(2), and to the use of the practices for such time as is reasonable and necessary to amend or correct the patient's EHI. In assessing timeliness and reasonableness of an actor's approach to making such corrections, we would take into consideration the facts and circumstances within which they operate, including but not limited to licensure or certification requirements applicable to the actor's EHI governance. For a health care provider, we anticipate such licensure or certification requirements will typically include clinical records standards set by State licensure laws and additional standards applicable to that provider given their specific circumstances, such as patient records maintenance standards set by issuing bodies of facility/organizational accreditations or professional board certifications the provider may also hold.</P>
                    <P>Where an actor lacks the technical capability to sequester from otherwise legally permissible access, exchange, or use only that subset of EHI the actor knows or reasonably suspects is affected by data issues giving rise to risk of harm consistent with § 171.201(c)(2), the Preventing Harm Exception will not recognize withholding of the remaining EHI. In such circumstances, an actor should refer to the exceptions for Content and Manner (§ 171.301) and Infeasibility (§ 171.204), as may be applicable, in regard to the EHI that they do not know or reasonably suspect to be affected by data issues giving rise to risk of harm consistent with § 171.201(c)(2).</P>
                    <HD SOURCE="HD3">Risk Arising From Misidentifying a Patient or Mismatching Patients' Electronic Health Information</HD>
                    <P>
                        The Preventing Harm Exception is intended to apply to practices that are designed to promote data quality and integrity and to support health IT applications properly identifying and matching patient records or EHI. As discussed in the preamble to the Proposed Rule (84 FR 7524), accurately identifying patients and correctly attributing their EHI to them is a complex task and involves layers of safeguards. The task requires application of appropriate procedures for verifying a patient's identity and properly registering the patient in health IT systems. Safeguards include such usability and implementation decisions such as ensuring the display of a patient's name and date of birth, and perhaps a recent photograph, on every screen from which clinicians and other caregivers access, enter, and/or modify data in the patient's record. When a clinician, other health IT user, or other actor knows or reasonably suspects that specific EHI is not correctly attributed to one or more particular patient(s), it would be reasonable for them to avoid sharing the EHI that could introduce or propagate errors in patient records and thereby pose risks to the patient(s) affected.
                        <SU>155</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>155</SU>
                             Please note that practices designed and implemented to ensure that persons requesting access to their EHI are who they claim to be and give them access to only that EHI that is theirs would not be cognizable under the Preventing Harm Exception; we have established two other exceptions designed to address practices reasonable and necessary to protect the privacy (
                            <E T="03">see</E>
                             § 171.202) and security (
                            <E T="03">see</E>
                             § 171.203) of individuals' EHI.
                        </P>
                    </FTNT>
                    <P>
                        Under the Preventing Harm Exception as proposed, an actor's response to the risk of misidentified patient health information would need to be no broader than necessary to mitigate the risk of harm arising from the potentially misidentified record or misattributed data (84 FR 7524). For example, under the proposed exception, an actor—such as a health IT developer of certified health IT—refusing to provide a batch export on the basis that the exported records 
                        <E T="03">might</E>
                         contain a misidentified record would not find that practice recognized under this exception. Similarly, a health care provider or other actor that identified that a particular piece of information had been misattributed to a patient would not be excused under § 171.201 from exchanging or providing access to all other EHI about the patient that had not been misattributed. The actor knowing or reasonably suspecting some data had been misidentified or misattributed would also be expected to confirm the extent of such errors and to take appropriate steps to correct their own records, consistent with applicable law, regulations, and accreditation standards applicable to the actor, and best practices or other appropriate industry benchmarks for health records and information management.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended we consider that actors bear significant responsibility to preserve and promote data quality and integrity, and that actors generally take risk-averse approaches to preventing and to assessing and resolving errors in identifying EHI and matching patient EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the opportunity to assure all stakeholders that we are aware that the EHI an actor receives from various sources may feature a variety of characteristics that call for varying degrees of pre-processing to achieve a level of matching accuracy considered by the health care provider community to be sufficient for safe use of the data in patient care. In some circumstances, we understand additional or special processing—including but not necessarily limited to human eyes-on analysis to confirm matches—may be needed before records are deemed to have been accurately matched, and that data requiring human processing may be delayed in integration and availability compared with data that can be satisfactorily matched through an actor's automated means. Section 171.201 will apply to such practices provided all of its conditions are met.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended the finalized exception recognize as reasonable and necessary to protect patient safety practices such as sequestering from access and exchange all records from a particular source, or 
                        <PRTPAGE P="25834"/>
                        affected by a particular system or technical process, until the scope and cause of patient matching or attribution issues can be identified and appropriately resolved. Commenters stated such practices are commonly used today by HINs/HIEs, and provided illustrative examples of current practice. Comments described as an example current practice of HIEs not making available any record(s) that their monitoring for technical or other issues identifies as an improperly matched patient record—and any other records that may be affected by a similar technical issue—until the record(s) can be corrected to include only accurately matched data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do understand that a variety of methods and approaches may currently be needed to assess the scope, identify, and appropriately address the cause of patient matching or attribution errors. Section 171.201 will apply to practices otherwise meeting its conditions that affect more patients' records than those specifically confirmed to include mismatched or misattributed EHI. Where its conditions are otherwise met, the exception will apply to use of practices likely to interfere with access, exchange, or use of EHI that the actor knows includes mismatched or misattributed data or reasonably suspects includes such errors. Reasonable suspicion could be formed on various bases, such as objectively observable patterns of association between detected errors and a particular data source, application, system, or process. However, a practice of delaying the availability of records from any particular data source based on factors extraneous to matching processes and accuracy would not be excepted from the definition of information blocking. Examples of extraneous factors include, but are not limited to, whether the data source was competitor of the actor and whether the actor may harbor personal animus toward the data source.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested the Preventing Harm Exception allow for providers to refuse to release pediatric data to direct-to-consumer applications unless the provider was satisfied with the applications' ability to properly segment the data where multiple users' records might be stored in the same instance of the application. Specifically, the comment expressed a concern that if applications are not set up to safely handle multiple patients, data from multiple patients could be mixed together in ways that create a potential for serious harm stemming from how those data might then be used or interpreted.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The potential for EHI to be mismatched (or otherwise mishandled) by an application, whether mobile or otherwise, is neither unique to pediatric patients' EHI nor particular to apps that receive the patient's data from a provider's API. A patient whose provider has not yet implemented a standards-based API could use other means to get their EHI into their chosen direct-to-consumer app. Such means could include accessing view, download, and transmit functionality of the provider's certified health IT via the patient portal and transmitting an extract of their data in C-CDA format to the recipient of the patient's (or their legal representative's) choice. An individual or their representative could also exercise the individual's right of access under the HIPAA Privacy Rule to obtain the individual's EHI that is accessible under this right, in another format in which it is readily producible, and then upload it to an app of their choosing. In general, we do not believe it would be appropriate to extend the Preventing Harm Exception to apply to practices whereby actors would limit otherwise legally permissible access, exchange, or use of patient EHI based on concerns that a requestor will not handle patient matching in a manner acceptable to the actor. Therefore, this exception will not apply to actors' refusal to allow access, exchange, or use of EHI on grounds that the actor may not know, or may not be satisfied with, the matching methods to be used by a recipient of the EHI after the EHI has been securely transferred to the recipient. Provided the practices meet its conditions, the Security Exception (§ 171.203) will apply to a variety of practices directly related and tailored to specific security threats to the actor's systems and EHI within those systems that may be posed by particular connections or interfaces with third-party systems or software. We also note that practices that do not inappropriately discourage patients from accessing, exchanging, or using their EHI as they choose, but that are appropriately designed and implemented to help patients make more informed choices about their EHI and apps can be designed and implemented to avoid meeting the definition of information blocking finalized in § 171.103.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed a concern that this exception could become a pretext for an actor to avoid sharing EHI on basis of the actor not being satisfied with the accuracy achieved by a prospective recipient's patient matching methods. This commenter requested ONC clarify that this exception does not allow for an actor to take a position that it will not share EHI unless the requesting entity demonstrates it will match patients using a method, or to a degree of accuracy, satisfactory to the actor being requested to share the information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not believe it would be appropriate to extend the Preventing Harm Exception to apply to practices whereby actors would limit otherwise legally permissible access, exchange, or use of patient EHI based on concerns that a requestor will not handle patient matching in a manner acceptable to the actor. Various recipients and users of EHI will have different purposes and contexts of data use and thus may appropriately deem differing levels of assurance of match accuracy satisfactory to meet their obligations, for patient safety or otherwise. Therefore, this exception will not apply to actors' refusal to allow access, exchange, or use of EHI on grounds that the actor may not know, or may not be satisfied with, the matching methods to be used by a recipient of the EHI after the EHI has been securely transferred to the recipient.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters specifically discussed concerns about potential misuse of this exception on a claim of patient matching concerns, and that this exception could lessen actors' motivations for improving their patient match capabilities. Some commenters suggested specific additional requirements for applicability of this exception to practices implemented to reduce risks of harm arising from mismatch or misidentification of patient EHI, in order to guard against its misuse or potentially incentivizing stagnation in rates of patient matching capabilities advancement. Additional requirements that commenters suggested were:
                    </P>
                    <P>• That an actor only be able to take advantage of this exception on basis of mismatch if the actor's matching methods met or exceeded a performance threshold;</P>
                    <P>• that the actor proactively communicates to requestors the actor's minimum matching criteria and other aspects of its matching methods; and</P>
                    <P>• a requirement for specific features in the actor's systems, such as returning informative error messages regarding match failures.</P>
                    <P>
                        <E T="03">Response.</E>
                         We are aware there is variation across actors in technical capabilities relevant to patient matching, resources to improve those capabilities, and other operational considerations. We are not aware of clear evidence or broad industry consensus on specific practices or 
                        <PRTPAGE P="25835"/>
                        performance thresholds that should apply to across all EHI use cases and operational contexts. We believe it would be premature to limit the availability of this exception to actors able to implement specific practices or meet particular metrics of patient matching performance specified through this rulemaking. Because this exception is intended to except from the definition of information blocking in § 171.103 practices that are reasonable and necessary to protect patients from risks of cognizable harm attributable to types of risk specifically including risks arising from mismatched EHI, rather than to drive changes in patient matching practices in the industry, such requirements could render this exception unavailable in circumstances where it is intended to apply. Thus, we have determined that it is more appropriate to leave actors engaged in using data the discretion and responsibility for determining what level of certainty in the accuracy of record matching is necessary for their use of the EHI. We appreciate this opportunity to clarify that the Preventing Harm Exception would not excuse actors from making appropriate good faith efforts to match patient records, which we expect will ordinarily include communication and cooperation between data sources and recipients. Moreover, we believe an actor will generally have a natural incentive to communicate proactively, appropriately, and in good faith with those with whom they exchange data, specifically to minimize unnecessary extra processing and follow-up communications on the part of both exchange partners. Therefore, we have not modified the Preventing Harm Exception's conditions in response to these comments.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed a concern that to ensure they do not release information that has potential errors in patient matching or attribution, they will need to invest in improved patient record matching accuracy, which the commenter indicates would for them include new technical solutions compared with their current practice.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         This exception is not intended, and we are not persuaded that as finalized it will function, to impose a new or specific obligation on actors to ensure they do not release information that could contain latent errors. Other commenters did recommend we consider doing so. However, for the reasons stated above in response to those comments, we have not established a pre-requisite that an actor meet a particular threshold of patient-matching performance before this exception will apply to practices otherwise meeting the conditions of § 171.201 applicable in the particular circumstances, including that the actor can demonstrate a reasonable belief the practice(s) will substantially reduce a risk of harm cognizable under § 171.201. We emphasize that we have 
                        <E T="03">not</E>
                         established a pre-requisite for applicability of § 171.201 that would call upon an actor to use particular methods, or satisfy particular threshold performance rates on any specific metric, for patient identification and matching.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested clarification as to whether a patient would be liable for accessing another patient's EHI that had been mismatched or misattributed to the patient accessing the information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         This issue is outside the scope of this rulemaking. Those concerned or curious about it should reference Federal,
                        <SU>156</SU>
                        <FTREF/>
                         State, or tribal law and regulations—or reliable sources of information about Federal,
                        <SU>157</SU>
                        <FTREF/>
                         State, or tribal law and regulations—applicable to any individual's (or entity's) unauthorized access to or use of another's personally identifiable information (PII) in the particular jurisdiction(s) and circumstances of potential concern.
                    </P>
                    <FTNT>
                        <P>
                            <SU>156</SU>
                             Potentially applicable Federal law and regulations are not limited to HIPAA and the HIPAA Privacy Rule, but the HIPAA Privacy Rule may be a useful place for those who share interest in the question raised by these comments to begin obtaining additional information.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>157</SU>
                             Authoritative information about the HIPAA Privacy Rule is available in the health information privacy section of the HHS website, starting at 
                            <E T="03">https://www.hhs.gov/hipaa/index.html.</E>
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested creation of a hold-harmless or “safe harbor” policy protecting data recipients from liability for actions taken in good faith reliance on information received after applying best-practice matching methods.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The suggestion appears to reference a safe harbor from liability for decisions or other actions taken in reliance on the EHI in question. That is outside the scope of this rule. Actors should implement matching methodologies and practices in full awareness that this final rule will not change their responsibility under other applicable law for maintaining appropriately reliable medical or other business records. This final rule also does not alter clinicians' responsibilities for exercising sound professional judgment in making clinical decisions based on EHI available to them in context of what they know or reasonably believe about the EHI's reliability.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested, in context and reference to the Preventing Harm Exception, guidance regarding what an actor is obligated to do if they receive EHI as a result of provider matching failure. One commenter specifically requested guidance on what sort of good faith efforts to direct the EHI to the correct recipient would be expected of an inadvertent recipient of mis-directed EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         A provider or other actor who receives EHI that they have reason to believe may have been directed to them by mistake has no obligation under part 171 to identify the correct recipient or to forward the EHI to the correct recipient. The actor who believes they may have received mis-directed EHI should upon forming such belief follow their established practices for handling of PHI and PII received in known or suspected error. We presume these established practices are consistent with Federal, State, or tribal law applicable to the particular actor in the particular operational circumstances.
                    </P>
                    <HD SOURCE="HD3">Statement of Finalized Policy for Risks Arising From Misidentified or Mismatched EHI</HD>
                    <P>
                        We are finalizing the substance of this part of the exception as proposed, with modifications to how it is expressed in regulation text in comparison with the Proposed Rule. We have reorganized the regulation text in response to comments requesting our regulatory text in general be laid out in a way that is easier to use. For example, we have combined risks arising from misidentified or mismatched EHI with other data-specific sources of risk of harm in the final § 171.201(c)(2), instead of splitting them across two paragraphs as was the case in § 171.201(a)(1) (“corrupt or inaccurate” in the Proposed Rule) and § 171.201(a)(2) (“misidentified or mismatched” in the Proposed Rule). We believe this makes the finalized text of § 171.201 easier to use because misidentified, mismatched, corrupt, and otherwise erroneous data are all sources of risk arising from issues with the data rather than characteristics unique to a patient or their circumstances. As was the case in the Proposed Rule, additional conditions must be met for § 171.201 to apply to practices implemented to substantially reduce a risk of harm arising from data issues (consistent with § 171.201(c)(2)). In the structure of the finalized regulation text, these additional conditions are found in § 171.201(a) and (b), and as applicable in the particular circumstances also in (d)(3) or (4), and (f)(1) or (2). Whether (d)(3) or (d)(4) sets out the harm 
                        <PRTPAGE P="25836"/>
                        standard that applies to a practice an actor believes will substantially reduce a risk of harm consistent with § 171.201(c)(2) turns on whether the practice is likely to, or does, interfere with a patient's own or another other legally permissible access, exchange, or use of the patient's EHI. (We note, however, that the harm required to satisfy this condition is the same under (d)(3) and (d)(4), as both cross-reference § 164.524(a)(3)(i).) Whether (f)(1) or (f)(2) applies to a practice an actor believes will substantially reduce a risk of harm consistent with § 171.201(c)(2) turns on whether the actor implements the practice based on an organizational policy (f)(1) or a determination based on facts and circumstances known or reasonably believed by the actor at the time the determination was made and while the practice remains in use (f)(2).
                    </P>
                    <HD SOURCE="HD3">Determination by a Licensed Health Care Professional That the Disclosure of EHI Is Reasonably Likely To Endanger Life or Physical Safety (§ 171.201(c)(1))</HD>
                    <P>We proposed that this exception would recognize practices interfering with EHI access, exchange, or use in circumstances where a licensed health care professional has determined, in the exercise of professional judgment, that the access, exchange, or use of the EHI is reasonably likely to endanger the life or physical safety of the patient or another person (84 FR 7524 and 7525). As we explained, the clinician may have in certain cases individualized knowledge stemming from the clinician-patient relationship that, given the particular patient and that patient's circumstances, harm could result if certain EHI were shared or transmitted electronically. We proposed that, consistent with the HIPAA Privacy Rule, a decision not to provide access, exchange, or use of EHI on this basis would be subject to any right that an affected individual is afforded under applicable Federal or State laws to have the determination reviewed and potentially reversed.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended that actors, such as HINs/HIEs, implementing practices based on a determination by a health care professional, not be required to take steps to review or assess the reasonableness of the health care professional's judgment or determination that a risk of harm exists or that the harm of which a risk was determined to exist met the standard for recognition under this exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We did not propose to require that other actors would ordinarily need to evaluate whether they agreed with individualized determinations of risk made by a licensed health care professional in order for the actor's application of practices consistent with that determination to be recognized under this exception. The finalized exception also does not generally require that actors relying on an individualized determination made by a licensed health care professional in the exercise of professional judgment take steps to review or confirm the health care professional's judgment.
                        <SU>158</SU>
                        <FTREF/>
                         Actors other than the licensed health care professional who makes the determination—including but not limited to HINs/HIEs or hospitals—could implement practices based on organizational policy (consistent with § 171.201(f)(1) as finalized) to rely on such determinations upon becoming aware of the determination and until such time as they become aware that the determination has been reversed or revised. Such other actors also, either in absence of such policy or in particularized facts or circumstances not fully covered by their existing policy at the time they became aware of a licensed health care professional's individualized determination of risk, could demonstrate for those particularized circumstances the reasonable belief required by § 171.201(a) by referencing the licensed health care professional's determination in making their own determination consistent with § 171.201(f)(2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>158</SU>
                             To the extent any particular actor may have an obligation under other Federal, state, or tribal law or regulations (as may be applicable in any particularized circumstances) to afford a patient a right of review of the determination—or to facilitate the patient's requesting a review of the determination from another actor—the actor's practices would need to be in compliance with such law or regulations in order for this exception to apply to those practices.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter suggested that this exception should recognize determinations of the existence of a risk of harm made by licensed health care professionals without requiring a clinician-patient relationship.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In order for practices implemented to substantially reduce a type of risk consistent with finalized § 171.201(c)(1) to be excepted under § 171.201 from the definition of information blocking finalized in § 171.103, the individualized determination of risk of harm in the exercise of professional judgment must be made by a licensed health care professional who has a current or prior clinician-patient relationship with the patient whose EHI is affected by the determination. In the preamble to the Proposed Rule (84 FR 7524) we explained that the clinician may have individualized knowledge stemming from the clinician-patient relationship that, for a particular patient and for that patient's circumstances, harm could result if certain EHI were shared or transmitted electronically. To ensure that both the requirement for a clinician-patient relationship and its specificity to individualized determinations of risk of harm by licensed health care professionals in the exercise of judgment are immediately clear to all actors, we have stated it in the finalized text of § 171.201(c)(1). We are finalizing this as a requirement because a clinician who has never established a clinician-patient relationship to the particular patient would not be expected to have the same individualized knowledge of the individual patient and that patient's circumstances as one who has such a clinician-patient relationship.
                    </P>
                    <P>In contrast, however, we reiterate that a risk is less individualized when it arises from data issues (consistent with § 171.201(c)(2)) and as a result may be identified by clinicians or by other persons with relevant expertise, including but not limited to biomedical informaticists who are not licensed health care professionals. Nothing in § 171.201 requires the involvement of a licensed health care professional with a clinician-patient relationship to any patient(s) whose data may be affected by the practices in the design of, or decision to implement, practices an actor reasonably believes will substantially reduce a risk arising from data issues consistent with § 171.201(c)(2).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended that, in the context of a clinician-patient relationship, the clinician should have broader latitude to consider specifics of a patient's circumstances in determining the existence of a risk of harm or potential harm.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         It may be helpful to highlight the significant and broad discretion inherent in the policy as we proposed it. An individualized determination made in the exercise of professional judgment by a licensed health care professional allows for that professional to consider a wide array of individual patient characteristics and circumstances and to apply all of the knowledge and skills within the licensed health care professional's scope of practice. The exception's conditions as proposed would provide licensed health care professionals broad discretion in how or why they form a reasonable belief that a cognizable risk of harm is associated with particular access, exchange, or use of their 
                        <PRTPAGE P="25837"/>
                        patient's EHI (including by the patient or their legal representative). We have finalized this aspect of the Preventing Harm Exception as proposed, though we have revised how the conditions, and specific requirements within particular conditions, are organized and phrased in regulation text. Nothing in the finalized § 171.201 would limit the types of information on which the licensed health care professional may rely, or the factors they may consider, in exercising their professional judgment to make individualized determinations of risk of harm consistent with § 171.201(c)(1).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters advocated for clinician discretion to determine whether a disclosure of health information was in the patient's best interest.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe an individual clinician's assessment of the patient's best interest is a less objective standard than one based on the exercise of professional judgment paired with a defined standard of cognizable harm. It would thus render the exception more difficult to administer as well as more susceptible to inappropriate use of the exception. We are finalizing the substance of this condition of the Preventing Harm Exception as proposed: To satisfy the conditions of the Preventing Harm Exception, an individualized determination by a licensed health care professional in the exercise of professional judgment must be that a risk of harm cognizable under this exception is associated with particular access, exchange, or use of the patient's EHI. The harm cognizable under this exception will be one that would be recognized under § 164.524(a)(3)(i) (at this time, danger to the life or physical safety of the patient or another person) where a practice affects a patient's access, exchange, or use of their EHI, per the finalized § 171.201(d)(3). Where § 171.201(d)(1) or § 171.201(d)(2) applies, the harm cognizable under this exception will be one that would be recognized under § 164.524(a)(3)(iii) or § 164.524(a)(3)(ii), respectively. At this time, the harm standard in both § 164.524(a)(3)(iii) and § 164.524(a)(3)(ii) is “substantial harm.” For all legally permissible access, exchange, or use of the patient's EHI to which § 171.201(d)(1) through (3) do not apply, the finalized § 171.201(d)(4) applies, by cross-reference, the same § 164.524(a)(3)(i) harm standard of danger to the life or physical safety of the patient or another person that is applicable to practices interfering with the patient's access to their own EHI (that does not include PII of another).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed a concern that the exception as proposed might not sufficiently recognize the entire array of circumstances where persons should not be granted access, exchange, or use of EHI. For instance, commenters suggested no access, exchange, or use of a patient's EHI should be available to a person suspected to be abusing, or at risk of beginning to abuse, the patient. Commenters also suggested that the exception should recognize that broader restrictions of EHI access than illustrated by examples in the Proposed Rule would in many cases be indicated by available evidence, widely recognized clinical practice guidelines, or State laws applicable to instances of known or suspected child, intimate partner, elder, or other abuse.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         This exception applies to practices the actor reasonably believes will substantially reduce a risk of harm determined on an individualized basis in the exercise of professional judgment by a licensed health care professional with a clinician-patient relationship with the patient whose EHI is affected by the determination (finalized § 171.201(c)(1)). Moreover, and as we noted in the Proposed Rule (84 FR 7524), this exception would apply when an actor implements practices that are likely to interfere with the access, exchange, or use of a patient's EHI pursuant to electing to not treat a person as a personal representative in accordance with 45 CFR 164.502(g)(5). We have finalized the substance of this feature of the exception as proposed, though 45 CFR 164.502(g)(5) is not expressly referenced in the final regulation text.
                    </P>
                    <P>The listed examples described in the Proposed Rule were intended to be illustrative, not exhaustive. There are many other situations where the Preventing Harm Exception will apply to an actor's practices so long as the conditions of the exception are otherwise met. As another illustrative example, if a determination of risk of harm consistent with § 171.201(c)(1) indicates that a broad withholding of the patient's EHI from a known, suspected, or potential abuser is reasonably likely to substantially reduce a risk of harm to the patient or another person, then the exception will apply to those practices so long as its conditions are met in full. Moreover, provided its conditions are met in full, this exception will also apply to practices that may be likely to, or do, interfere with a legal representative's access, exchange, or use of a patient's EHI to a lesser degree than might an election not to recognize the representative as the patient's personal representative in accordance with § 164.502(g)(5)(i). Because the finalized § 171.201(d)(1) applies when a practice is likely to, or does, interfere with a legal representative's access to the patient's EHI, the harm standard required in such a situation is that stated in § 164.524(a)(3)(iii). Currently, that harm standard is “substantial harm.”</P>
                    <P>We also expressly note that, although the “substantial harm” standard applied by § 171.201(d)(1) through cross-reference to § 164.524(a)(3)(iii) is not precisely the same as the requirement in § 164.502(g)(5)(i), we will interpret as sufficient for purposes of § 171.201(c)(1) and (d)(1) a licensed health care professional's election not to treat a person as the patient's legal representative in accordance with § 164.502(g)(5)(i). Moreover, having noted above the broad discretion licensed health care professionals have regarding what information to factor into their individualized determinations consistent with § 171.201(c)(1), we highlight that this broad discretion would allow them to consider any knowledge they might have of another licensed health care professional, or other type of covered entity, having elected in accordance with § 164.502(g)(5)(i) not to treat a person as the patient's representative.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some comments implied concerns about the potential conflict between the documentation requirements of this exception and those required under other applicable law.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Provided its conditions are met, this exception is applicable in circumstances where a licensed health care professional in the exercise of professional judgment has determined that there is a risk of abuse 
                        <E T="03">beginning,</E>
                         as well as circumstances in which prior or ongoing abuse is known or suspected. Actors have significant discretion and flexibility in determining how best to document determinations and the bases for their determinations. Where other law or regulations—Federal, State, or tribal—require a specific form, manner, or content of documentation in circumstances that would serve as basis for individualized determinations consistent with the finalized § 171.201(c)(1), we would consider that documentation relevant to assessing the applicability of this exception to those practices. In order to avoid potentially duplicative or other unnecessary burdens on licensed health care professionals or other actors, we have decided not to establish at this time a specific documentation condition and have decided not to establish other 
                        <PRTPAGE P="25838"/>
                        unique documentation requirements for this exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         In reference to a specific illustrative example in the Proposed Rule, one commenter indicated that withholding or delaying availability of only specific sensitive data elements may not be sufficient in circumstances such as those described in the Proposed Rule example, and that revoking a suspected abuser's proxy access on the whole may be more clinically appropriate in such circumstances (84 FR 7525).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In response to this comment, we first clarify the intent and function of the example provided in the Proposed Rule. In the example, the licensed health care professional in the exercise of professional judgment had determined that only some information within the record would need to be withheld from the patient's partner's proxy access to her EHI (84 FR 7525). Although not specifically stated in the Proposed Rule, the example presumes a mature technical capability to sequester data from specific user(s) on an itemized basis. The example also presumes that the licensed health care professional, in their exercise of professional judgment, had not formed a reasonable belief that ceasing to recognize the patient's partner as her personal representative, and entirely revoking the partner's proxy access to her EHI, would substantially reduce a risk of harm to the patient. We intended that the example illustrate that where the licensed health care professional determined a risk of harm would arise from making a specific piece of information accessible to the patient's proxy, the minimum interference necessary to substantially reduce that risk of harm would be to withhold that specific piece of information from the patient's partner's proxy access to her EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter indicated that if a clinician has a suspicion (confirmed or not) that the patient is suffering intimate partner or elder abuse, it is considered clinically important that notes or other data elements indicating the suspicion not be released to the patient in the company of the suspected abuser. The commenter stated that such disclosure could undermine the clinician's ability to help the patient because the patient would likely be forced to switch clinicians. The comment also indicated there may be a risk that an abuser could harm the patient as a result of the disclosure of the clinician's suspicion.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Because information blocking policy is specific to the access, exchange, and use of EHI, we read the commenter's example as suggesting two considerations specific to access, exchange, and use of EHI. First, we believe the comment indicates we should expressly acknowledge that these types of situations are often legally as well as clinically complex. It is not our intent that our policies unnecessarily add to this complexity. It is also not our intent that our policies undermine the ability of a licensed health care professional, or other actor relying on the professional's determination, to take appropriate steps to reduce abuse risks to which the professional's patients would otherwise be exposed. Nothing in § 171.201, or in the information blocking provisions generally, requires an actor to disclose their awareness or suspicion of abuse to the patient's legal representative in order to satisfy the conditions of the Preventing Harm Exception. Second, our understanding of this comment indicates that in some particular individualized circumstances the licensed health care professional may determine in the exercise of professional judgment that to substantially reduce a risk of harm it may be necessary to withhold some portions of a patient's EHI from the patient's own access through an API or patient portal. We can, for example, envision possible circumstances where a licensed health care professional with a clinician-patient relationship to the patient knows or has reason to believe that a person suspected of abusing a patient routinely “looks over the shoulder” of the patient while they access their EHI, or uses the patient's own credentials to access the patient's EHI. In such circumstances, this exception would apply to practices interfering with the patient's own access to their EHI to the extent the practices are not inconsistent with the HIPAA Privacy Rule or the conditions in § 171.201.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters suggested that the Preventing Harm Exception should recognize more types of abuse, and a broader array of potential types of harm than danger to life or physical safety in the context of interfering with access to a patient's EHI by a legal representative suspected of abusing the patient. One commenter advocated that the Preventing Harm Exception should recognize all types of violence and abuse. The commenter provided citations to professional specialty expert committee opinions in support of their recommendation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As discussed above in reference to comments that recommended aligning this rule's harm standards more closely to the HIPAA Privacy Rule, we have, by cross-reference in § 171.201(d)(1), finalized as the harm standard applicable to practices interfering with a legal representative's access to a patient's EHI the same harm standard that would apply to denying a personal representative's access to an individual's PHI under § 164.524(a)(3)(iii). As § 164.524(a)(3)(iii) stands at the time this rule is finalized, it references “substantial harm.” As discussed above, this exception will also apply to practices likely to interfere with a legal representative's access, exchange, or use that are employed pursuant to an election not to treat that legal representative as a personal representative in accordance with § 164.502(g)(5)(i). For purposes of § 171.201, “substantial harm” is interpreted as it is for purposes of § 164.524(a)(3)(iii). Thus, for purposes of not recognizing a personal representative, or otherwise restricting patient EHI access, exchange, or use by a representative known or suspected to be abusing the patient, we believe the harm standard applicable under this exception to practices affecting a legal representative's access, exchange, or use of the patient's EHI is sufficiently broad. We interpret the discretion afforded to a licensed health care professional in making an individualized determination of risk of harm consistent with the finalized § 171.201(c)(1) (type of risk condition) as allowing them to take into consideration clinical practice guidelines and clinical expert groups' studied opinions relevant to abuse-related risks of substantial harm. Only practices based on the potential for harms that would not be recognized as meeting the “substantial harm” standard, as it is interpreted by the HHS Office for Civil Rights for purposes of § 164.524(a)(3)(iii), would fail to satisfy the type of harm condition finalized in § 171.201(d)(1). We remind actors that any decision not to provide access, exchange, or use of EHI on the basis of determination of risk of harm consistent with the finalized § 171.201(c)(1) and § 171.201(d)(1), (2), (3), or (4) is subject to rights the individual patient whose EHI is affected may be afforded by applicable regulations or law to have the determination reviewed and potentially reversed. (See the “patient right to request review of individualized determination of risk of harm” condition finalized in § 171.201(e), for which we also use “patient review rights condition” as a short form of reference for ease of discussion.) Where § 164.524(a)(3) applies in addition to § 171.201, § 164.524(a)(4) specifically 
                        <PRTPAGE P="25839"/>
                        provides for review of determinations made by licensed health care professionals in the exercise of professional judgment. In circumstances where § 171.201 applies but § 164.524 does not, § 171.201(e) requires that an actor's practices be consistent with any rights of review of individualized determinations of risk of harm that the patient may be afforded under applicable Federal, State, or tribal law or regulations. However, for purposes of § 171.201(c)(1) determinations, the type of harm must be consistent with: The harm standard stated in § 164.524(a)(3)(i) (interpreted as it is for purposes of § 164.524(a)(3)(i)) where § 171.201(d)(3) or (4) apply; the harm standard stated in § 164.524(a)(3)(ii) (interpreted as it is for purposes of § 164.524(a)(3)(ii)) where § 171.201(d)(2) applies; or the harm standard stated in § 164.524(a)(3)(iii) (interpreted as it is for purposes of § 164.524(a)(3)(iii)) where § 171.201(d)(1) applies.
                    </P>
                    <HD SOURCE="HD3">Finalized Policy for an Individualized Determination of Risk of Harm by a Licensed Health Care Professional in the Exercise of Professional Judgment</HD>
                    <P>We are finalizing the substance of this aspect of the exception with modifications to the way it is displayed and phrased in the finalized regulation text in comparison to the Proposed Rule. If its other conditions are also met, the finalized Preventing Harm Exception will apply to a practice an actor reasonably believes will substantially reduce a risk of harm consistent with the sub-paragraph of § 171.201(d), as finalized, that applies to the specific access, exchange, or use, where the risk of harm is determined on an individualized basis in the exercise of professional judgment by a licensed health care professional who has a current or prior clinician-patient relationship with the patient whose EHI is affected by the determination. In comparison to the proposed text of § 171.201 (84 FR 7602), we have reorganized the regulation text in response to comments requesting our regulatory text, in general, be easier to use for purposes such as understanding how the conditions of the exception relate to one another and how they apply to practices used in particular types of circumstances. We have left the potential sources of risk of harm in a single paragraph (finalized § 171.201(c)), but separated them from the reasonable belief condition paragraph (finalized § 171.201(a)). The sources of risk of harm are also, as discussed above, presented in two sub-paragraphs in the finalized text of § 171.201(c) (type of harm) instead of being split across three sub-paragraphs as they were in the Proposed Rule.</P>
                    <P>In subparagraph (a)(3) of the proposed text of § 171.201 (84 FR 7602), we expressed the additional condition that practices based on individualized determinations of risk of harm are subject to any rights of review of the determination that the patient may be afforded under applicable law. This patient review rights condition is finalized in § 171.201(e). As finalized, this condition requires that where a risk of harm is determined on an individualized basis (consistent with § 171.201(c)(1) as finalized), the actor must honor any rights the individual patient whose EHI is affected may have under § 164.524(a)(4) or any Federal, State, or tribal law applicable in the circumstances to have the determination reviewed and potentially reversed. We have stated the condition for providing review rights afforded by law in the separate paragraph (e) of § 171.201 instead of including it within subparagraph (c)(1) because in the context of 171.201 the patient review rights condition functions as a condition on how practices based on such belief are implemented more than as a required characteristic of the § 171.201(c)(1) determination itself.</P>
                    <P>
                        The finalized text of § 171.201(c)(1) also differs from the proposed regulation text specific to individualized determinations of risk in explicitly stating the requirement that the licensed health care professional making the determination must have a current or prior clinician-patient relationship with the patient whose EHI is affected by the determination. For purposes of § 171.201—as we discussed in the Proposed Rule's preamble, and above in this preamble—we believe the broad discretion afforded to licensed health care professionals to make individualized determinations of risks of harm in the exercise of professional judgment is appropriate in the context of the expectation that a licensed health care professional with a clinician-patient relationship to a patient has the opportunity to have knowledge of the patient and their individual circumstances that is not generally available outside the context of a clinician-patient relationship. We believe that explicitly stating in § 171.201(c)(1) the requirement for a clinician-patient relationship accomplishes two purposes: First, it ensures that this is immediately clear on the face of the finalized regulation text that only determinations made by licensed health care professionals who have or have had a clinician-patient relationship with the patient will be considered consistent with § 171.201(c)(1); and, second, it is also clear that the condition for a clinician-patient relationship is specific and limited to determinations of risks of harm on an individualized basis in the exercise of professional judgment by a licensed health care professional (§ 171.201(c)(1) as finalized). Please note that this requirement is specific to the individualized determination of risk of harm, and does not limit application of § 171.201 to practices implemented directly by the licensed health care professional making a determination of risk of harm consistent with § 171.201(c)(1) as finalized. Appropriately tailored practices applied because the actor has a reasonable belief the practice will substantially reduce a risk of harm that was determined on an individualized basis consistent with § 171.201(c)(1) will, if all other applicable conditions of § 171.201 are met, be recognized under this exception whether the practices are undertaken by the licensed health care professional making the determination or by another actor (
                        <E T="03">e.g.,</E>
                         another licensed health care professional, a hospital, or a HIN) having custody or control of the patient's EHI and knowledge of the individualized determination of risk of harm associated with particular access(es), exchange(s), or use(s) of that EHI.
                    </P>
                    <P>
                        As finalized, § 171.201(d) differs from the proposed policy in that it does not uniformly require that the risk determined on an individualized basis be to life or physical safety of the patient or another person in all circumstances. Instead, through specified cross-references to the sub-paragraphs of § 164.524(a)(3), the finalized § 171.201(d) type of harm condition uses the same harm standards for the circumstances where both the Preventing Harm Exception and § 164.524(a)(3) apply. Also through cross-references, the type of harm condition applies the § 164.524(a)(3) harm standards in circumstances similar to those in which § 164.524(a)(3) applies but where only § 171.201 actually applies. The finalized § 171.201(d) does not cross-reference § 164.502(g)(5)(i), but it is constructed so that it does apply to practices interfering with a personal representative or other legal representative's access to a patient's EHI consistent with an actor declining to recognize such a representative on the same bases as a HIPAA covered entity could elect not to recognize a person as an individual's personal representative consistent with § 164.502(g)(5)(i). In order to retain a clear, consistent set of 
                        <PRTPAGE P="25840"/>
                        harm standards throughout the § 171.201 type of harm condition, however, we note that where a HIPAA covered entity elects not to recognize an individual's personal representative consistent with § 164.502(g)(5)(ii), the Preventing Harm Exception would not apply.
                        <SU>159</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>159</SU>
                             Because § 164.502(g)(5)(ii) currently applies a standard not of harm but of determination by the covered entity that recognizing a person as personal representative is not in the best interest of the individual, we have determined it is more appropriate to address these circumstances in context of the exception for practices promoting privacy of EHI, finalized in § 171.202 and discussed in Section VIII.D.1.b of this final rule preamble.
                        </P>
                    </FTNT>
                    <P>Consistent with the HIPAA Privacy Rule, a decision not to provide access, exchange, or use of EHI on the basis finalized in § 171.201(c)(1) is subject to the rights the individual patient whose EHI is affected may be afforded by applicable law to have the determination reviewed and potentially reversed. While any such determination reviews may be pending, application of practices interfering with the patient's access, exchange, or use of their EHI based on an individualized determination by a licensed health care professional (§ 171.201(c)) that are otherwise compliant with the conditions of § 171.201 as a whole will be considered to be covered by the exception.</P>
                    <P>Upon becoming aware of a reversal of the determination on which the actor's required reasonable belief was based, whether as a result of a review requested by the patient or other processes, the actor's continued application of practices based on the original determination would no longer be consistent with the conditions of § 171.201. Likewise, upon becoming aware of a revision of the determination on which the actor's required reasonable belief was originally based, whether the revision resulted from a review requested by the patient or other processes, practices applied to the patient's EHI after the revision is made will need to comply with the conditions of § 171.201 in light of the revised determination in order for the practice to continue to be covered under § 171.201.</P>
                    <P>
                        For the specific purposes of § 171.201, the rights to obtain review or reconsideration of a provider's individualized determination of risk of harm reside with the patient whose EHI is affected. The rights in many cases may be exercised on the patient's behalf by the patient's personal or other legal representative. However, it may not be appropriate, or feasible, for the patient's representative to exercise the patient's review rights in circumstances where the individualized determination of risk of harm is or includes a determination that recognizing that same person as the patient's representative, or providing specific information to that same recognized representative, would pose a risk of cognizable harm. In a circumstance where the actor has a reasonable belief that such disclosure could create or increase a risk of harm to the patient, this exception does not require the candid disclosure to a known, suspected, or potential abuser of the rationale for use of particular practices, or even the precise practices, interfering with that representative's access, exchange, or use of EHI. We would, however, generally expect actors to be as candid with the patient 
                        <E T="03">per se</E>
                         as is clinically appropriate and safely practicable in their individualized circumstances.
                    </P>
                    <P>Where an actor lacks the technical capability to sequester only that EHI the actor reasonably believes poses a risk of cognizable harm from other data for which the actor does not pose such risk of harm, this lack of segmentation capability would not render § 171.201 applicable to practices likely to, or that do, interfere with access, exchange, or use of the other data. Rather, where such lack of segmentation capabilities renders the actor unable to support an otherwise legally permissible access, exchange, or use of EHI, the actor should reference the Content and Manner Exception (§ 171.301) or the Infeasibility Exception (§ 171.204).</P>
                    <P>Licensed health care professionals have discretion to determine how to use their EHRs and/or other records kept in their ordinary course of business to capture and preserve documentation of and relevant to their individualized determinations. Information relevant to determinations would include the facts or circumstances that substantially informed each determination, and any other decision-making information that the professional may otherwise have difficulty recalling or reconstructing if later asked to explain how or why they reached their individualized determination in a particular case.</P>
                    <HD SOURCE="HD3">Practices Implemented Based on an Organizational Policy or on Determination Specific to the Facts and Circumstances</HD>
                    <P>
                        To qualify for the Preventing Harm Exception, we proposed that an actor would be required to have, while engaging in the practice(s) for which application of the exception is claimed, a reasonable belief that the practice(s) will “directly and substantially” 
                        <SU>160</SU>
                        <FTREF/>
                         reduce the likelihood of harm to a patient or another person. As discussed in the Proposed Rule and above, the type of risk and the potential harm must also be cognizable under this exception (84 FR 7525 and 7526).
                    </P>
                    <FTNT>
                        <P>
                            <SU>160</SU>
                             As, and for the reasons, discussed earlier in this section of this preamble, we have removed “directly and” from the belief standard finalized in § 171.201(a).
                        </P>
                    </FTNT>
                    <P>
                        Under § 171.201 as proposed, an actor would be able to demonstrate having satisfied the condition of reasonable belief that a practice will reduce the likelihood of harm (“reasonable belief condition”) through a qualifying organizational policy (proposed § 171.201(b)) and/or a qualifying individualized determination (proposed § 171.201(c)). We discuss below the details of our proposal, respond to comments, and summarize finalized policy specific to each of these approaches to demonstrating the required reasonable belief that a practice will substantially 
                        <SU>161</SU>
                        <FTREF/>
                         reduce a risk of harm cognizable under this exception.
                    </P>
                    <FTNT>
                        <P>
                            <SU>161</SU>
                             As, and for the reasons, discussed earlier in this section of this preamble, the belief standard finalized in § 171.201(a) requires the actor believe the practice will “substantially reduce” a risk of harm to a patient or another natural person that would otherwise arise from the access, exchange, or use of electronic health information affected by the practice.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Practices Implemented Based on an Organizational Policy</HD>
                    <P>
                        In the Proposed Rule (84 FR 7525), we proposed that to qualify for this exception, an actor must have had a reasonable belief that the practice or practices will directly and substantially reduce the likelihood of harm to a patient or another person and that the type of risk must also be cognizable under this exception. We proposed that an actor could meet this condition in two ways: Through a “qualifying organizational policy” (§ 171.201(b) as proposed) or through a “qualifying individualized finding” (§ 171.201(c) as proposed). We stated in the Proposed Rule that we anticipate that in most instances where § 171.201 would apply, the actor would demonstrate that the practices it engaged in were consistent with an organizational policy that was objectively reasonable and no broader than necessary for the type of patient safety risks at issue. We also noted in the Proposed Rule that within any type of actor defined in § 171.102, organizations may vary significantly in structure, size, and resources. Further, even when an organizational policy exists, it may not anticipate all of the potential risks of harm that could arise in real-world clinical or production 
                        <PRTPAGE P="25841"/>
                        environments of health IT. Thus, we proposed in § 171.201(c) (84 FR 7602) that in lieu of demonstrating that a practice conformed to a policy that met the conditions described in proposed § 171.201(b) and the Proposed Rule preamble at 84 FR 7525, the actor could justify the practice(s) directly by making a finding in each case, based on the particularized facts and circumstances.
                    </P>
                    <P>We proposed that where the proposed § 171.201(b) (84 FR 7602) would apply, an actor's policy would need to be:</P>
                    <P>• In writing;</P>
                    <P>• developed with meaningful input from clinical, technical, and other appropriate staff or others who have expertise or insight relevant to the risk of harm that the policy addresses;</P>
                    <P>• implemented in a consistent and non-discriminatory manner; and</P>
                    <P>• no broader than necessary to mitigate the risk of harm.</P>
                    <P>We stated that the proposed condition would not be met if, for example, a hospital imposed top-down information sharing policies or workflows established by the hospital's EHR developer and approved by hospital administrators without meaningful input from the medical staff, IT department, and front-line clinicians who are in the best position to gauge how effective it will be at mitigating patient safety risks.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concern that information blocking policy and its interaction with other applicable laws and regulations, such as the HIPAA Rules, are complex and that there will be costs and other burden associated with understanding how the policies affect an actor's daily operations. Commenters also expressed concern that it would be too burdensome to be required to demonstrate, in any of the ways we proposed, that they have a reasonable belief that practices would reduce a risk of cognizable harm.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We understand that complexity can increase difficulty in understanding and complying with any regulation. We also understand that the interaction between the HIPAA Rules and the information blocking provision is inherently complex. However, without an exception from the information blocking definition for practices appropriately tailored to reduce risks of harm, we believe actors would be subject to the greater burden of needing to craft practices that avoid violating the information blocking provision without also making EHI available for access, exchange, or use in circumstances where that puts patients or other natural persons at risk of harm. This exception's conditions give actors a framework within which they can develop or refine their practices in assurance that practices meeting the conditions in § 171.201 are excepted from the definition of information blocking finalized in § 171.103. At the same time, implementing such an exception without appropriate conditions could have the unintended and undesirable effect of excusing conduct that would more appropriately remain within the definition of information blocking.
                    </P>
                    <P>Therefore, in § 171.201, we have finalized conditions that strike a practical balance between minimizing burdens on actors and ensuring that the interests of patients in the access, exchange, and use of their EHI are adequately protected. These conditions are, in comparison to the Proposed Rule, more granularly and durably aligned with relevant HIPAA right of access provisions (§ 164.526(a)(3)) and this alignment reduces complexity.</P>
                    <P>We have revised the way the regulation text is presented and phrased so that it is easier to understand what is required in order for a practice to be excepted from the definition of information blocking under this exception. Moreover, we have avoided specifying particular or unique forms, methods, or content of documentation for purposes of this exception. We believe the flexibility this offers actors to determine the most efficient approach to documenting their practices and determinations relevant to this exception enables them to achieve and document satisfaction of the exception's condition with the lowest practicable burden.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters noted that there will be burden associated with developing or revising organizational policies and training staff so they can use this exception in compliance with its conditions. Several of these commenters suggested we provide additional guidance and informational resources, in this final rule or otherwise, to help actors develop their policies and staff training. Some commenters advocated that we develop templates or models that actors could use to more efficiently develop policies consistent with the conditions for applicability of this exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback and do recognize that developing or revising internal policies and procedures when compliance requirements change due to changes in law requires some effort. While recognizing the utility of the types of resource materials suggested by commenters, we believe they are best developed and provided outside the rulemaking process. We will continue working to engage with the stakeholder communities to promote understanding and foster compliance with the information blocking provision amongst all actors within the definitions in § 171.102. We also believe that in many cases voluntary groups with relevant expertise, such as professional societies and provider organizations, may be in the best position to develop resources tailored to the particular needs and preferences of specific segments or communities within any given type of actor.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stating that developing new or revised organizational policies and training staff in the policies requires time recommended that we establish a grace period before organizations' policies and actual practices must fully comply with § 171.201 conditions in order to be recognized as reasonable and necessary under § 171.201.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         This concern is not unique to § 171.201. Commenters also raised this concern in the context of information blocking in general. As we stated in section VIII.B.3 of this preamble, we thank commenters for their input. Comments related to the overall timing of information blocking enforcement have been shared with OIG. We emphasize that individuals and entities subject to the information blocking provision must comply with the ONC final rule as of the compliance date of the information blocking section of this final rule (45 CFR part 171). We have finalized a compliance date for 45 CFR part 171 as a whole that is six months after the date this final rule is published in the 
                        <E T="04">Federal Register</E>
                        .
                    </P>
                    <P>OIG and ONC are coordinating timing of the compliance date of the information blocking section of this final rule (45 CFR part 171) and the start of information blocking enforcement. We are providing the following information on timing for actors. Enforcement of information blocking CMPs in section 3022(b)(2)(A) of the PHSA will not begin until established by future notice and comment rulemaking by OIG. As a result, actors would not be subject to penalties until CMP rules are final. At a minimum, the timeframe for enforcement would not begin sooner than the compliance date of the information blocking section of this final rule (45 CFR part 171) and will depend on when the CMP rules are final. Discretion will be exercised such that conduct that occurs before that time will not be subject to information blocking CMP.</P>
                    <P>
                        Specific to § 171.201, as discussed above in response to other comments 
                        <PRTPAGE P="25842"/>
                        received specific to the Preventing Harm Exception, we have applied § 164.524(a)(3) harm standards under § 171.201 to circumstances where both sections of 45 CFR would apply, and to circumstances where only § 171.201 applies but that are similar in significant respects to circumstances where § 164.524(a)(3) applies. In substantial part because of this alignment, we do not believe there is a need to delay the applicability of any of the conditions for a practice to be excepted under § 171.201 from the definition of information blocking in § 171.103.
                    </P>
                    <P>Actors who are also HIPAA covered entities or business associates should already have policies in place consistent with the HIPAA Privacy Rule, including but not limited to § 164.524(a)(3). These actors and their staff members should be well versed in these policies and practices. Where § 164.524(a)(3) would not apply but § 171.201(d)(3) or (4) would apply, we believe using the same, familiar standard for the risk that the actor must believe their practice would reduce as would apply to § 164.524(a)(3)(i) should facilitate efficient updates to organizational policies and streamline any staff training that may be indicated specific to § 171.201. We also note that the finalized Preventing Harm Exception also provides, in § 171.201(f)(2), for coverage of practices implemented in absence of an applicable organizational policy or where existing organizational policy does not address the particular practice in the particularized circumstances. Moreover, although we encourage actors to voluntarily conform their practices to the conditions of an exception suited to the practice and its purpose, an actor's choice to do so simply provides them an enhanced level of assurance that the practices do not meet the definition of information blocking. However, failure to meet an exception does not necessarily mean a practice meets the definition of information blocking. We reiterate, if subject to an investigation by HHS, each practice that implicates the information blocking provision would be analyzed on a case-by-case basis.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters indicated that providers' current organizational policies call for practices that delay the release of laboratory results so that the patient's clinician has an opportunity to review the results before potentially needing to respond to patient questions, or has an opportunity to communicate the results to the patient in a way that builds the clinician-patient relationship. Some commenters indicated their standard practice is to automatically time-delay release of results in general, with an automatic release at the end of a time period determined by the organizational policy in place to ensure that patients can consistently access their information within the timeframe targeted by relevant measures under the CMS Promoting Interoperability Programs. Commenters requested we clarify whether such practices would be recognized under § 171.201 or that we recognize such current organizational policies and practices as excepted from the definition of information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         While we recognize the importance of effective clinician-patient relationships and patient communications, we are not persuaded that routinely time-delaying the availability of broad classes of EHI should be recognized as excepted from the information blocking definition under this exception. Consistent with § 171.201(d)(3) as finalized, the harm of which a practice must reduce a risk must, where the practice interferes with the patient's access to their own EHI, be one that could justify denying the patient's right of access to PHI under § 164.524(a)(3). Currently, § 164.524(a)(3)(i) requires that for a covered entity to deny an individual access to their PHI within the designated record set, the disclosure of that PHI must be reasonably likely to endanger the life or physical safety of the patient or another person.
                        <SU>162</SU>
                        <FTREF/>
                         No commenter cited evidence that routinely delaying EHI availability to patients in the interest of fostering clinician-patient relationships substantially reduces danger to life or physical safety of patients or other persons that would otherwise routinely arise from patients' choosing to access the information as soon as it is finalized.
                    </P>
                    <FTNT>
                        <P>
                            <SU>162</SU>
                             Note that for purposes of § 164.524(a)(3)(i), “individual” is defined in § 160.103, but for purposes of § 171.201 an actor must reasonably believe a practice will substantially reduce a risk of cognizable harm to patient(s) or other natural person(s).
                        </P>
                    </FTNT>
                    <P>Moreover, we are independently aware, and some comment submissions confirmed, that it is not uncommon to automatically release lab and other findings to patients electronically regardless of whether a clinician has seen the information or discussed it with the patient before the patient can choose to access it electronically. We presume these types of automatic releases would not be the case if patients' accessing their information on a timeframe that is more of their own choosing routinely posed a risk to the life or physical safety of these patients or other natural persons. Thus, we believe that where applicable law does not prohibit making particular information available to a patient electronically before it has been conveyed in another way, deference should generally be afforded to patients' right to choose whether to access their data as soon as it is available or wait for the provider to contact them to discuss their results. Only in specific circumstances do we believe delaying patients' access to their health information so that providers retain full control over when and how it is communicated could be both necessary and reasonable for purposes of substantially reducing a risk of harm cognizable under § 171.201(d) (as finalized). Circumstances where § 171.201 would apply to such delay are those where a licensed health care professional has made an individualized determination of risk in the exercise of professional judgment consistent with § 171.201(c)(1), whether the actor implementing the practice is the licensed health care professional acting directly on their own determination or another actor implementing the delay in reliance on that determination. An actor could choose to demonstrate the reasonable belief required by § 171.201(a) through an organizational policy (§ 171.201(f)(1)) with which the practice is consistent, or based on a determination based on facts and circumstances known or reasonably believed by the actor at the time the determination was made and while the practice remains in use (§ 171.201(f)(2)), to rely on a determination consistent with § 171.201(c)(1).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Health care professionals commented that clinical experience indicates a systematic and substantial risk that releasing some patient data through a patient portal or API without first communicating the particular results or diagnosis with the patient in a more interactive venue would pose risks of substantial harm to patients. One example commenters specifically cited was genetic testing results indicating a high risk of developing a neurodegenerative disease for which there is no effective treatment or cure. Commenters recommended that we define this exception to allowing delay of the electronic release of such genetic testing results, as a matter of organizational policy, to ensure patients and their families are not exposed to this information without appropriate counseling and context. One comment indicated that delivery by the clinician of the combined results, counseling, and context is clinically appropriate and consistent with the conclusions of relevant research.
                        <PRTPAGE P="25843"/>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         To satisfy the conditions of § 171.201, and actor would have to demonstrate that they held a reasonable belief that delaying availability of information until the information can be delivered in combination with appropriate counseling and context in an interactive venue will substantially reduce a risk of harm cognizable under this exception. An actor could accomplish such demonstration through showing the practice is consistent with either an organizational policy meeting § 171.201(f)(1) or a determination based on facts and circumstances known or reasonably believed by the actor at the time the determination was made and while the practice remains in use meeting § 171.201(f)(2). However, for a practice likely to, or that does in fact, interfere with the patient's access to their own EHI (§ 171.201(d)(3)), the actor implementing these practices must demonstrate a reasonable belief that the practice will substantially reduce a risk of harm to the life or physical safety of the patient. The clinician who orders testing of the sort referenced in the comment would, we presume, do so in the context of a clinician-patient relationship. In the context of that relationship, a licensed health care professional should be well positioned to make determinations consistent with § 171.201(c)(1) as to specifically when their patients, or other particular natural persons, would face a risk of harm cognizable under § 171.201(d)(3)—or § 171.201(d)(1) or (2) if or as may be applicable—if the access, exchange, or use of a particular testing result or diagnosis were to be released electronically before it could be explained and contextualized by an appropriately skilled professional, such as a clinician or a health educator, in real time.
                    </P>
                    <HD SOURCE="HD3">Summary of Finalized Policy: Practices Implemented Based on an Organizational Policy</HD>
                    <P>We have finalized that to demonstrate the reasonable belief required by § 171.201(a) based on an organizational policy, the policy must:</P>
                    <P>(i) Be in writing;</P>
                    <P>(ii) Be based on relevant clinical, technical, and other appropriate expertise;</P>
                    <P>(iii) Be implemented in a consistent and non-discriminatory manner;</P>
                    <P>(iv) Conform each practice to the conditions in paragraphs (a) and (b) of this section, as well as the conditions of paragraphs (c) through (e) of this section applicable to the practice and its use.</P>
                    <P>We have modified the regulation text finalized in § 171.201(f)(1) consistent with other revisions to § 171.201. We have redesignated this paragraph from (b) to (f)(1), and redesignated its proposed sub-paragraphs from (1) through (4) to (i) through (iv). We have in comparison to the main paragraph language of the proposed § 171.201(b) modified the phrasing of the finalized paragraph (f) so that § 171.201 as finalized is more immediately clear on its face that what is finalized in § 171.201(f) is a condition for practices to meet the exception, and that paragraph (f) can be satisfied by meeting either subparagraph (1) or (2).</P>
                    <P>Practices applied based on an organization policy to rely on individualized determinations of risk of harm consistent with § 171.201(c)(1) would be covered under § 171.201 to the extent they otherwise meets its conditions. Neither an organizational policy (§ 171.201(f)(1)), nor a determination based on facts and circumstances known or reasonably believed by the actor at the time the determination was made and while the practice remains in use ((§ 171.201(f)(2)) would be required to routinely evaluate or otherwise assess the licensed health care professional's exercise of professional judgment in order for practices implemented in reliance on the professional's § 171.201(c)(1) determination to be meet the conditions of § 171.201.</P>
                    <HD SOURCE="HD3">Practices Implemented Based on a Determination Specific to the Facts and Circumstances</HD>
                    <P>As discussed in the Proposed Rule, we recognize that some actors (such as small health care providers and small HINs/HIEs) may not have comprehensive and formal policies governing all aspects of EHI and patient safety. Additionally, even if an organizational policy exists, it may not anticipate all of the potential risks of harm that could arise in real-world clinical or production environments of health IT. In these circumstances, in lieu of demonstrating that a practice conformed to the actor's policies and that the policies met the conditions proposed in § 171.201(b), we proposed that the actor could justify its use of particular practices by making a finding in each case, based on the particularized facts and circumstances, that the practice is necessary and no broader than necessary to mitigate the risk of harm. To do so, we proposed that the actor would need to show that the practices were approved on a case-by-case basis by an individual with direct knowledge of the relevant facts and circumstances and who had relevant clinical, technical, or other appropriate expertise. Such an individual would need to reasonably conclude, based on those particularized facts and circumstances and his/her expertise and best professional judgment, that the practice was necessary, and no broader than necessary, to mitigate the risk of harm to a patient or other persons. We further proposed that a licensed health care professional's independent and individualized judgment about the safety of the actor's patients or other persons would be entitled to substantial deference under this proposed exception. So long as the clinician considered the relevant facts and determined that, under the particular circumstances, the practice was necessary to protect the safety of the clinician's patient or another natural person, we would not second-guess the clinician's professional judgment. To provide further clarity on this point, we provided an illustrative example in the preamble to the proposed rule (see 84 FR 7525).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested that we clarify, provide guidance, or establish specifications for the documentation necessary to substantiate applicability of the Preventing Harm Exception based on qualifying determinations particularized to specific facts and circumstances. Some commenters indicated that such specificity or guidance is needed to avoid imposing on actors such as health care providers and HINs/HIEs excess burden associated with documentation in the absence of such guidance or specification.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these commenters highlighting that the potential for uncertainty or confusion about what is minimally necessary to demonstrate satisfaction of a new policy can often lead to capturing and retaining a wide array of information just in case it may be needed or useful later. We have clarified the way in which all of the conditions in § 171.201 are stated and organized within the section. We also note here that an actor does not need to draft for each determination consistent with § 171.201(f)(2) a comprehensive defense of their findings. We believe the finalized statement of the condition, reinforced by this preamble discussion, provides certainty that we do not intend or expect actors to create new records systems or types, or to create or retain duplicate information or documentation across their current medical and other business records. Ultimately, it is the actor's responsibility to demonstrate they met the conditions of an exception.
                        <PRTPAGE P="25844"/>
                    </P>
                    <HD SOURCE="HD3">Summary of Finalized Policy: Practices Implemented Based on a Determination Specific to the Facts and Circumstances</HD>
                    <P>We have finalized the substance of this condition as proposed, with modifications to the regulation text. We have also reorganized § 171.201 so that it is easier to read and understand. We have redesignated this paragraph from (c) to (f), and broken it into subparagraphs. We have in comparison to the main paragraph language of the proposed § 171.201(c) modified the phrasing of the finalized paragraph (f) so that § 171.201 as finalized is more immediately clear on its face that what is finalized in § 171.201(f)(2) is a means to demonstrate a practice implemented in absence of an applicable, or perhaps any, organizational policy nevertheless meets the conditions to be exempted under § 171.201 from the definition of information blocking in § 171.103.</P>
                    <P>We have separated from both the requirements applicable to individualized determinations of risk (finalized in the type of risk condition in § 171.201(c)(1)) and the requirements applicable to practices implemented based on organizational policy (§ 171.201(f)(1)) or to practices implemented pursuant to a determination based on the facts and circumstances (§ 171.201(f)(2)) the patient review rights condition expressed in subparagraph (a)(3) of the proposed text of § 171.201 (84 FR 7602). We have finalized the patient review rights condition in § 171.201(e) instead of the finalized (f) because it applies equally to practices implemented based on an organizational policy and by practices implemented based on determinations based on facts and circumstances, in parallel to the other conditions for a practice to be excepted under § 171.201 from the definition of information blocking in § 171.103.</P>
                    <P>In the finalized patient review rights condition (§ 171.201(e)), in comparison with proposed § 171.201(a)(3) (84 FR 7602), we have revised the wording in which we state the condition for honoring any rights that applicable law may afford patients to have these individualized determinations reviewed and potentially reversed. The condition finalized in § 171.201(e) is that where the risk of harm is consistent with paragraph (c)(1) of this section, the actor must implement its practices in a manner consistent with any rights the individual patient whose EHI is affected may have under § 164.524(a)(4) of this title, or any Federal, State, or tribal law, to have the determination reviewed and potentially reversed.</P>
                    <P>We also revised in finalized § 171.201(e), in comparison with the proposed § 171.201(a)(3), the wording of the condition finalized in § 171.201(e) in comparison to the wording of this condition as proposed in 171.201(a)(3) for two reasons. First, the wording has been revised to fit its placement within the finalized section. Second, the wording has been revised to more clearly and completely state the sources of the review rights that must be afforded, if applicable. We note that such review rights will be afforded by § 164.524(a)(4) in the circumstances where both § 164.524(a)(3) and § 171.201 apply. However, rights that must be honored to meet the conditions of § 171.201 are not limited to those afforded by § 164.24(a)(4) or to circumstances where § 164.524 applies in addition to § 171.201. Rights of review of an individualized determination of risk of harm (§ 171.201(c)(1)) might also be afforded by Federal, State, or tribal law applicable in the particular circumstances.</P>
                    <P>We do not believe it is necessary to expressly state in the regulation text that we interpret regulations promulgated based on such laws, and that have the force and effect of law on individuals and entities they regulate, to be within the meaning of “law” for purposes of § 171.201(e). However, we expressly state this here in order to provide the type of assurance we believe many commenters were seeking when stating in their comment submissions requests or recommendations for additional guidance in the final rule. In order for the practice(s) to satisfy the condition in § 171.201(e), where otherwise applicable law affords a patient right(s) to request review of individualized determinations of risk of harm associated with the patient's access, exchange, or use of their EHI, the actor's practice(s) be implemented in a manner consistent with those rights—regardless of which specific law(s) afford the rights applicable in the particular circumstances.</P>
                    <HD SOURCE="HD3">b. 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?</HD>
                    <P>We proposed to establish an exception to the information blocking provision for practices that are reasonable and necessary to protect the privacy of an individual's EHI, provided certain conditions are met (84 FR 7526). The exception and corresponding conditions were set forth in the proposed regulation text in § 171.202. We noted that any interference practice that an actor is engaged in to protect the privacy of an individual's EHI must be consistent with applicable laws and regulations related to health information privacy, including the HIPAA Privacy Rule, the HITECH Act, 42 CFR part 2, and State laws. We emphasized that this exception to the information blocking provision does not alter an actor's obligation to comply with applicable laws (84 FR 7526).</P>
                    <P>We noted that this exception is necessary to support basic trust and confidence in health IT infrastructure. Without this exception, there would be a significant risk that actors would share EHI in inappropriate circumstances, such as when an individual has taken affirmative steps to request that the EHI not be shared under certain conditions or when an actor has been unable to verify a requester's identity before sharing EHI.</P>
                    <P>We explained that this proposed exception was structured with discrete “sub-exceptions.” An actor's practice must qualify for a sub-exception to be covered by the exception. We noted that the sub-exceptions were, to a large extent, crafted to closely mirror privacy-protective practices that are recognized under State and Federal privacy laws. In this way, the privacy sub-exceptions to the information blocking provision recognize as reasonable and necessary those practices that are engaged in by actors to be consistent with existing laws, provided that certain conditions are met.</P>
                    <P>We proposed four sub-exceptions that address the following privacy protective practices: (1) Not providing access, exchange, or use of EHI when a State or Federal law requires that a precondition be satisfied before an actor provides access, exchange, or use of EHI, and the precondition is not satisfied (proposed in § 171.202(b)); (2) not providing access, exchange, or use of EHI when the actor is a health IT developer of certified health IT that is not covered by the HIPAA Privacy Rule in respect to a practice (proposed in § 171.202(c)); (3) a covered entity, or a business associate on behalf of a covered entity, denying an individual's request to access to their electronic protected health information (ePHI) in the circumstances provided in 45 CFR 164.524(a)(1)(2) or (3) (proposed in § 171.202(d)); and (4) not providing access, exchange, or use of EHI pursuant to an individual's request, in certain situations (proposed in § 171.202(e)) (84 FR 7526).</P>
                    <P>
                        We proposed that an actor would need to satisfy at least one sub-exception with respect to a purportedly 
                        <PRTPAGE P="25845"/>
                        privacy-protective practice that interferes with access, exchange, or use of EHI to not be subject to the information blocking provision. Each proposed sub-exception has conditions that must be met in order for an actor's practice to qualify for protection under the sub-exception (84 FR 7526).
                    </P>
                    <HD SOURCE="HD3">Modification</HD>
                    <P>We have changed the title of this exception from “Exception—Promoting the privacy of electronic health information” in the Proposed Rule (84 FR 7602) to “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?” Throughout this final rule preamble, we use “Privacy Exception” as a short form of this title, for ease of reference. As stated in Section VIII.D of this final rule preamble, we have changed the titles of all of the exceptions to questions to improve clarity. We have edited the wording of the introductory text in § 171.202 as finalized, in comparison to that proposed (84 FR 7602) so that it is consistent with the finalized title of § 171.202. We believe these conforming changes in wording of the introductory text also improve clarity in this section.</P>
                    <HD SOURCE="HD3">Specific Terminology Used for the Purposes of This Proposed Exception</HD>
                    <P>
                        We noted that the proposed exception used certain terms that are defined by the HIPAA Rules 
                        <SU>163</SU>
                        <FTREF/>
                         but that, for purposes of the exception, may have a broader meaning in the context of the information blocking provision and its implementing regulations as set forth in the Proposed Rule. We explained that, in general, the terms “access,” “exchange,” and “use” have the meaning in proposed § 171.102. However, we noted that in some instances we referred to “use” in the context of a disclosure or use of ePHI under the HIPAA Privacy Rule, in which case we explicitly stated that the term “use” had the meaning defined in 45 CFR 160.103. Similarly, we referred in a few cases to an individual's right of access under 45 CFR 164.524, in which case the term “access” should be understood in that HIPAA Privacy Rule context. We emphasized that, for purposes of section 3022 of the PHSA, however, the term “access” includes, but is broader than, an individual's access to their PHI as provided for by the HIPAA Privacy Rule (84 FR 7526).
                    </P>
                    <FTNT>
                        <P>
                            <SU>163</SU>
                             45 CFR part 160 and subparts A, C, and E of part 164.
                        </P>
                    </FTNT>
                    <P>Finally, we noted that the term “individual” is defined by the HIPAA Rules at 45 CFR 160.103. Separately, under the information blocking enforcement provision, we noted that the term “individual” is used to refer to actors that are health IT developers of certified health IT, HINs, or HIEs (see section 3022(b)(2)(A) of the PHSA). We clarified that for purposes of this exception (and only this exception), we used neither of these definitions. Instead, 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.</P>
                    <P>We clarified that (2) varies from (1) because there could be individuals who could be the subject of EHI that is being accessed, exchanged, or used under (2), but who would not be the subject of PHI under (1). For example, an actor which is not a covered entity or business associate as defined under HIPAA such as a health IT developer of certified health IT may access, exchange or use a patient's electronic health information; however this “health information” would not meet the definition of PHI, but nonetheless, would be subject to this regulation.</P>
                    <P>
                        We also clarified that (3) encompasses a person with 
                        <E T="03">legal</E>
                         authority to act on behalf of the individual, which includes a person who is a personal representative as defined under the HIPAA Privacy Rule. We explained that we included the component of 
                        <E T="03">legal</E>
                         authority to act in (3) because the HIPAA Privacy Rule gives rights to parents or legal guardians in certain circumstances where they are not the “personal representative” for their child(ren). For instance, a non-custodial parent who has requested a minor child's medical records under a court-ordered divorce decree may have legal authority to act on behalf of the child even if he or she is not the child's “personal representative.” Further, we noted that in limited circumstances and if permitted under State law, a family member may have 
                        <E T="03">legal</E>
                         authority to act on behalf of a patient to make health care decisions in emergency situations even if that family member may not be the “legal representative” or “personal representative” of the patient.
                    </P>
                    <P>
                        We noted that we adopted this specialized usage to ensure that the Privacy Exception extends protection to information about, and respects the privacy preferences of, 
                        <E T="03">all</E>
                         individuals, not only those individuals whose EHI is protected as ePHI by HIPAA covered entities and business associates (84 FR 7526 and 7527).
                    </P>
                    <HD SOURCE="HD3">Interaction Between Information Blocking, the Exception for Promoting the Privacy of EHI, and the HIPAA Privacy Rule</HD>
                    <P>We stated in the Proposed Rule that we consulted extensively with the HHS Office for Civil Rights (OCR), which enforces the HIPAA Privacy, Security and Breach Notification Rules, in developing proposals to advance our shared goals of preventing information blocking for nefarious or self-interested purposes while maintaining and upholding existing privacy rights and protections for individuals. We noted that the proposed exception for promoting the privacy of EHI (also referred to as the “privacy exception”) operates in a manner consistent with the framework of the HIPAA Privacy Rule. We explained that we designed the sub-exceptions to ensure that individual privacy rights are not diminished as a consequence of the information blocking provision, and to ensure that the information blocking provision does not require the use or disclosure of EHI in a way that would not be permitted under the HIPAA Privacy Rule. We emphasized that our intent was that the information blocking provision would not conflict with the HIPAA Privacy Rule. We noted that the sub-exception proposed in § 171.202(d) reflects a policy that an actor's denial of access to an individual consistent with the limited conditions for such denials that are described in the HIPAA Privacy Rule at 45 CFR 164.524(a)(1)(2) and (3), is reasonable under the circumstances (84 FR 7527).</P>
                    <P>
                        We also noted that the information blocking provision may operate to require that actors provide access, exchange, or use of EHI in situations that the HIPAA Rules would not require access of similar information. This is because the HIPAA Privacy Rule permits, but does not require, covered entities to disclose ePHI in most circumstances. We explained that the information blocking provision, on the other hand, requires that an actor provide access to, exchange, or use of EHI unless they are prohibited from 
                        <PRTPAGE P="25846"/>
                        doing so under an existing law or are covered by one of the exceptions. As an illustration, we noted that the HIPAA Privacy Rule permits health care providers to exchange ePHI for treatment purposes but does not require them to do so. Under the information blocking provision, unless an exception to information blocking applies, or the interference is required by law, a primary care provider would be required to exchange ePHI with a specialist who requests it to treat an individual who was a common patient of the provider and the specialist, even if the primary care provider offered patient care services in competition with the specialist's practice, or would usually refer its patients to another specialist due to an existing business relationship (84 FR 7527).
                    </P>
                    <HD SOURCE="HD3">Promoting Patient Privacy Rights</HD>
                    <P>We stated that the information blocking provision would not require that actors provide access, exchange, or use of EHI in a manner that is not permitted under the HIPAA Privacy Rule or other laws. As such, the privacy-protective controls existing under the HIPAA Rules would not be weakened by the information blocking provision. Moreover, we described that we structured the Privacy Exception to ensure that actors can engage in reasonable and necessary practices that advance the privacy interests of individuals (84 FR 7527).</P>
                    <P>We explained that unless required by law, actors should not be compelled to share EHI against patients' expectations under applicable law or without adequate safeguards out of a concern that restricting the access, exchange, or use of the EHI would constitute information blocking. We acknowledged that this could seriously undermine patients' trust and confidence in the privacy of their EHI and diminish the willingness of patients, providers, and other entities to provide or maintain health information electronically. In addition, we noted that such outcomes would undermine and not advance the goals of the information blocking provision and be inconsistent with the broader policy goal of the Cures Act to facilitate trusted exchange of EHI. We stated that trusted exchange requires not only that EHI be shared in accordance with applicable law, but also that it be shared in a manner that effectuates individuals' expressed privacy preferences. We noted that an individual's expressed privacy preferences will not be controlling in all cases. An actor will not be able to rely on an individual's expressed privacy preference in circumstances where the access, exchange, or use is required by law (84 FR 7527).</P>
                    <P>For these reasons, we proposed that the sub-exception in § 171.202(e) would generally permit an actor to give effect to individuals' expressed privacy preferences, including their desire not to permit access, exchange, or use of their EHI. At the same time, however, we emphasized that the Privacy Exception must be tailored to ensure that protection of an individual's privacy is not used as a pretext for information blocking. Accordingly, we proposed that this exception would be subject to strict conditions (84 FR 7527).</P>
                    <HD SOURCE="HD3">Privacy Practices Required by Law</HD>
                    <P>
                        We stated in the Proposed Rule that because the information blocking provision excludes from the definition of information blocking practices that are required by law (section 3022(a)(1) of the PHSA), privacy-protective practices that are required by law do not implicate the information blocking provision and do not require coverage from an exception. We noted that practices that are “required by law” can be distinguished from other practices that an actor engages in pursuant to a law, but which are not “required by law.” Such laws are typically framed in a way that permit an access, exchange or use of health information to be made only if specific preconditions are satisfied but do not expressly require that the actor engage in a practice that interferes with access, exchange, or use of EHI. For example, we noted that the HIPAA Privacy Rule provides that a covered entity 
                        <E T="03">may</E>
                         use or disclose PHI in certain circumstances where the individual concerned has authorized the disclosure.
                        <SU>164</SU>
                        <FTREF/>
                         The effect of this condition is that the covered entity should not use or disclose the PHI in the absence of an individual's authorization. However, we noted that because the condition does not prohibit the actor from exchanging the EHI in all circumstances, the actor would be at risk of engaging in a practice that was information blocking unless an exception applied. For this reason, we included a sub-exception, proposed in § 171.202(b), that provided that an actor will not be engaging in information blocking if a State or Federal law imposes a precondition to the provision of access, exchange, or use, and that precondition has not been satisfied (84 FR 7527 and 7528).
                    </P>
                    <FTNT>
                        <P>
                            <SU>164</SU>
                             45 CFR 164.508 (Uses and disclosures for which an authorization is required).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended that we allow for EHI to be withheld if there are contractual privacy restrictions for the actor that may define conditions or limits on what the actor may do because of those contractual restrictions. In addition, some commenters suggested that contractual restrictions should be treated similarly to State and Federal privacy laws under the Privacy Exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Please see section VIII.C.6.a (Prevention, Material Discouragement, and Other Interference) above regarding interference that discusses contracts including business associate agreements where this is discussed in depth.
                    </P>
                    <HD SOURCE="HD3">Definitions in This Exception</HD>
                    <P>As noted above, we stated in the Proposed Rule that we consulted extensively with the HHS Office for Civil Rights (OCR), which enforces the HIPAA Privacy, Security and Breach Notification Rules, in developing proposals to advance our shared goals of preventing information blocking for nefarious or self-interested purposes while maintaining and upholding existing privacy rights and protections for individuals (84 FR 7527).</P>
                    <P>This Privacy Exception operates in a manner consistent with the framework of the HIPAA Rules. We have finalized the sub-exceptions to ensure that individual privacy rights are not diminished as a consequence of the information blocking provision, and to ensure that the information blocking provision does not require the use or disclosure of EHI in a way that would not be permitted under the HIPAA Privacy Rule. We emphasize that our intent is that the information blocking provision would not conflict with the HIPAA Rules. As such, we added in the definitions section of this exception the term “HIPAA Privacy Rule” to mean 45 CFR parts 160 and 164 to improve readability and support the policy goal of alignment with the HIPAA Privacy Rule.</P>
                    <P>
                        With regards to the definition of “individual,” we have finalized this definition as proposed with a minor clarification, and it is not contrary to the HIPAA Rules. We note that the term “individual” is defined by the HIPAA Rules at 45 CFR 160.103. Separately, under the information blocking enforcement provision, we noted that the term “individual” is used to refer to actors that are health IT developers of certified health IT, HINs, or HIEs (see section 3022(b)(2)(A) of the PHSA). We finalized that for purposes of this exception (and only this exception), we used neither of these definitions. Instead, the term “individual” encompassed any or all of the following: (1) An individual defined by 45 CFR 
                        <PRTPAGE P="25847"/>
                        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), in making decisions related to health care, as a personal representative, in accordance with 45 CFR 164.502(g); (4) a person who is a legal representative of and can make health care decisions on behalf of any person described in paragraph (a)(1) or (2); or (5) an executor or administrator or other person having authority to act on behalf of a deceased person described in (1) or (2) or the individual's estate under State or other law.
                    </P>
                    <P>
                        To clarify, we have finalized that § 171.202(a)(2)(iii) encompasses only a person who is a personal representative as defined under the HIPAA Privacy Rule. We distinguish a “personal representative” defined under the HIPAA Privacy Rule from all other natural persons who are 
                        <E T="03">legal</E>
                         representatives and who can make health care decisions on behalf of the individual, and thus those persons are included in § 171.202(a)(2)(iv). We misstated in the Proposed Rule that the HIPAA Privacy Rule gave rights to parents or legal guardians in certain circumstances where they are not the “personal representatives.” We clarify in this final rule that, in limited circumstances and if permitted under State law, a family member may be the 
                        <E T="03">legal</E>
                         representative to act on behalf of a patient to make health care decisions in emergency situations even if that family member may not be the “personal representative” of the patient.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments opposing this condition of the proposed definition of “individual” in the Privacy Exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We finalized and clarified that § 171.202(a)(2)(iii) refers to only persons who meet the definition of a personal representative under 45 CFR 164.502(g), and § 171.202(a)(2)(iv) refers to all other persons who are legal representatives of and can make health care decisions on behalf of any person that was proposed in § 171.202(a)(4).
                    </P>
                    <HD SOURCE="HD3">Sub-Exception 1: “Precondition Not Satisfied”</HD>
                    <P>We stated in the Proposed Rule that State and Federal privacy laws that permit the disclosure of PHI often impose conditions that must be satisfied prior to a disclosure being made. In the final rule we are deleting the word “privacy” when it refers to laws in the regulation text in § 171.202(b) in order to alleviate any ambiguity about what is meant as a “privacy law.”</P>
                    <P>We proposed to establish a sub-exception to the information blocking provision that recognizes that an actor will not be engaging in information blocking if the actor does not provide access, exchange, or use of EHI because a necessary precondition required by law has not been satisfied. We explained that this exception would apply to all instances where an actor's ability to provide access, exchange, or use is “controlled” by a legal obligation required by law that a certain condition (or multiple conditions) must be met before access, exchange, or use of the EHI may be provided. We emphasized that to be covered by this exception, the actor must comply with certain conditions, which are discussed below.</P>
                    <P>We noted that the nature of the preconditions that an actor must satisfy in order to provide access, exchange, or use of EHI will depend on the laws that regulate the actor. For example, an actor that is regulated by a restrictive State law may need to satisfy more conditions than an actor regulated by a less restrictive State law before providing access, exchange, or use of EHI (84 FR 7527 and 7528).</P>
                    <P>We requested comments generally on this proposed sub-exception. More specifically, we sought comment on how this proposed sub-exception would be exercised by actors in the context of State laws. We noted our awareness that actors that operate across State lines or in multiple jurisdictions sometimes adopt organization-wide privacy practices that conform with the most restrictive laws regulating their business. We stated that we were considering the inclusion of an accommodation in this sub-exception that would recognize an actor's observance of a legal precondition that the actor is required by law to satisfy in at least one State in which it operates. We noted that, in the event that we did adopt such an accommodation, we would also need to carefully consider how to ensure that before the use of the most stringent restriction is applied in all jurisdictions, the actor has provided all privacy protections afforded by that law across its entire business. This type of approach would ensure that an actor cannot take advantage of a more-restrictive law for the benefit of this exception while not also fulfilling the privacy-protective obligations of the law being relied on. We requested comment on whether there is a need for ONC to adopt such an accommodation for actors operating in multiple states and encouraged commenters to identify any additional conditions that should attach to the provision of such an accommodation. We also requested comment on our proposed approach to addressing variation in State laws throughout this proposed sub-exception (84 FR 7528).</P>
                    <P>
                        We also recognized that some states have enacted laws that more comprehensively identify the circumstance in which an individual or actor can and cannot provide access, exchange, or use of EHI. We stated that we were considering to what extent health care providers that are not regulated by the HIPAA Privacy Rule, and would rely instead on State laws for this sub-exception, would be able to benefit from this sub-exception when engaging in practices that interfere with access, exchange, or use of EHI for the purpose of promoting patient privacy. We sought comment on any challenges that may be encountered by health care providers that are not regulated as covered entities under the HIPAA Privacy Rule when seeking to take advantage of this proposed sub-exception. We also sought comment on whether there exists a class of health care provider that is not regulated by 
                        <E T="03">any</E>
                         Federal or State law that prescribes preconditions that must be satisfied in connection with the disclosure of EHI, and whether any such class of health care provider would benefit from a sub-exception similar to that proposed in § 171.202(c) for health IT developers of certified health IT (84 FR 7529).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended that actors who operate across multiple states with different preconditions for disclosure under local laws should be able to adopt uniform requirements across their organizations that satisfy the most stringent preconditions of those local laws for purposes of this sub-exception. They stated that this is appropriate because it is often difficult for organizations operating across State lines to develop different workflows for each State. However, other commenters requested that actors should be permitted to select which portions of a State law should be included in procedures implemented across all states rather than being required to provide all privacy protections afforded by that law across its entire business. Other commenters believed that it should be left to the actor's discretion to determine whether it is better to have a uniform approach across all the jurisdictions it operates in or whether a State-by-State approach is more appropriate. They mentioned that such flexibility also would align with the Department's overall goal of reducing administrative burden particularly on providers while ensuring a high degree of privacy protection for patients.
                        <PRTPAGE P="25848"/>
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the various comments and recognize that it is difficult for organizations operating across State lines to have different workflows for each State while assuring privacy, particularly the individual's right under the HIPAA Rules to obtain their PHI. Additionally, it is important that any uniform policies and procedures must in fact be implemented across an actor's entire organization and not be applied selectively in ways which might be contrary to the information blocking provision.
                    </P>
                    <P>
                        Balancing these goals, this final rule provides that, except for an individual's access to their EHI as discussed below, actors may meet this sub-exception if they operate across multiple states and elect to adopt and implement uniform policies and procedures required by one State that are more restrictive (
                        <E T="03">i.e.,</E>
                         provide greater privacy protections) than would otherwise be required by another specific State or Federal law. To be considered more restrictive in this context, a law might require more or different preconditions to the access, exchange, or use of EHI than Federal law or the law of another State in which the actor operates. Alternatively, an actor could comply with the preconditions of each State in which it operates on a State-by-State basis with respect to the EHI requested. These alternatives provide multi-state actors with significant flexibility without adversely impacting an individual's right to obtain EHI as described below.
                    </P>
                    <P>An actor that operates in multiple states could either comply with the laws of each State in which it operates or comply with the most restrictive State laws in which it operates and where applicable, comply with Federal law requirements. The actor will need to document either approach in its policies and procedures in which the actor has adopted and implemented in order to meet the conditions of § 171.202(b)(1)(i) because the uniform approach will not be available to actors that operate on a case by case basis without policies and procedures as contemplated by subsection § 171.202(b)(1)(ii). Those actors without uniform policies and procedures will need to comply with each of the applicable State and Federal laws.</P>
                    <P>As noted above, the uniform policy and procedure approach to individual access requests for EHI must assure alignment with the HIPAA Privacy Rule and individual access implementation specifications to help assure that the broader policy goals for individual access to EHI are met. Specifically, when an actor receives a request by or on behalf of an individual under 45 CFR 164.524 for the individual's EHI, the actor must not impose preconditions in its policies and procedures which would affect the individual's right to access under the HIPAA Rules even when it is operating in multiple states.</P>
                    <P>We note that an actor may not inappropriately seek to use State or Federal laws as a shield against disclosing EHI. For example, we would expect that actors implement State-mandated preconditions consistently and in a non-discriminatory manner when fulfilling requests to access, exchange, or use EHI. Additionally, we caution actors who repeatedly change their privacy policies depending on the EHI requestor or the request that such actions may be considered intended to materially interfere with, prevent, or discourage the access, exchange, or use of EHI.</P>
                    <P>We note that we have modified the introductory text in § 171.202(b) for clarity and precision. The final introductory text reads as follows: “To qualify for the exception on the basis that one or more Federal or State preconditions for providing access, exchange, or use of electronic health information have not been satisfied, the following requirements must be met . . .” The changes to the final introductory text from the proposed introductory text (see 84 FR 7602) are not substantive and do not change the meaning of the introductory text.</P>
                    <P>
                        We also note that we have added “and actions” in § 171.202(b)(3)—“For purposes of determining whether the actor's privacy policies and procedures 
                        <E T="03">and actions</E>
                         satisfy the requirements of subsections (b)(1)(i) and (b)(2) above when the actor's operations are subject to multiple laws which have inconsistent preconditions, they shall be deemed to satisfy the requirements of the subsections if the actor has adopted uniform privacy policies and procedures to address the more restrictive preconditions.” We added this language for accuracy and clarity.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested that we provide clarification on all the Federal and State privacy laws considered when developing the “applicable State and Federal privacy laws” threshold condition of this sub-exception. They requested that the final rule make clear that those State privacy laws that are more restrictive than Federal privacy laws (
                        <E T="03">e.g.,</E>
                         42 CFR part 2 and HIPAA) take precedence over the less stringent Federal privacy laws.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As mentioned above, for clarity purposes, we have not included the word “privacy” in the final regulation text in § 171.202(b) in order to alleviate any ambiguity regarding what is meant as a “privacy law.” The HIPAA Privacy Rule provides a Federal floor of privacy protections for an individual's individually identifiable health information where that information is held by a covered entity or by a business associate of the covered entity. This sub-exception does not alter an actor's ability to comply with applicable Federal or State laws.
                    </P>
                    <P>To illustrate this sub-exception, we provided the following examples. We note that this list of examples is not exhaustive and that preconditions required by law that control access, exchange, or use of EHI that are not listed below would still qualify under this proposed sub-exception so long as all conditions are met.</P>
                    <P>• Although the HIPAA Privacy Rule does not have individual “consent” requirements for uses and disclosures of PHI for purposes such as treatment, payment, and health care operations, certain Federal and State laws do require that a person provide consent before their EHI can be accessed, exchanged, or used for specific purposes. For example, some State laws require an individual's consent for uses and disclosures of EHI regarding some sensitive health conditions such as HIV/AIDS, mental health, or genetic testing. Additionally, actors that are under “Part 2 programs,” which means federally assisted programs (“federally assisted” as defined in 42 CFR 2.12(b) and “program” as defined in 42 CFR 2.11), generally are required to obtain an individual's consent to disclose or re-disclose patient-identifying information related to the individual's substance use disorder, such as treatment for addiction. The sub-exception would operate to clarify an actor's compliance obligations in these situations. In such scenarios, it would not be considered information blocking to refuse to provide access, exchange, or use of EHI if the actor has not received the individual's consent, subject to requirements discussed herein.</P>
                    <P>• If an actor is required by law to obtain an individual's HIPAA authorization before providing access, exchange, or use of the individual's EHI, then the individual's refusal to provide an authorization would justify the actor's refusal to provide access, exchange, or use of EHI. The actor's refusal would, subject to conditions discussed herein, be protected under this sub-exception.</P>
                    <P>
                        • The HIPAA Privacy Rule, and many State laws, permit the disclosure of PHI in certain circumstances only once the identity and authority of the person requesting the information has been verified. We acknowledge that it is 
                        <PRTPAGE P="25849"/>
                        reasonable and necessary that actors take appropriate steps, consistent with Federal and State laws, to ensure that EHI is not disclosed to the wrong person or to a person who is not authorized to receive it. Where an actor cannot verify the identity or authority of a person requesting access to EHI, and such verification is required by law before the actor can provide access, exchange, or use of the EHI, the actor's refusal to provide access, exchange, or use of the EHI will, subject to the conditions discussed herein, will not be information blocking.
                    </P>
                    <P>• Under the HIPAA Privacy Rule, a health care provider may share information with another health care provider for a quality improvement project if it has verified that the requesting entity has a relationship with the person whose information is being requested. Where the actor could not establish if the relationship existed, it would not be information blocking for the actor to refuse to provide access, exchange, or use, subject to the conditions discussed herein.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments on the Privacy Exception expressing concern about whether a business associate (as defined under the HIPAA Privacy Rule) would be liable for information blocking practices for not providing access, exchange, or use of EHI because doing so would violate its business associate agreement.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Please see section VIII.C.6.a. (Prevention, Material Discouragement and Other Interference) above regarding interference that discusses contracts including business associate agreements where this is discussed in depth.
                    </P>
                    <HD SOURCE="HD3">Sub-Exception 1: “Precondition Not Satisfied”: Conditions To Be Met To Qualify for This Sub-Exception</HD>
                    <P>We noted that in most circumstances, an actor would be in a position to influence whether a precondition is satisfied. For example, an actor could deprive a person of the opportunity to take some step that is a prerequisite for the exchange of their EHI, could assume the existence of a fact prejudicial to the granting of access without seeking to discover the actual facts, or could make a determination that a precondition was not satisfied without properly considering or seeking all relevant information. As such, we proposed that this exception would be subject to conditions that ensure that the protection of an individual's privacy is not used as a pretext for information blocking (84 FR 7529).</P>
                    <P>We proposed that an actor can qualify, in part, for this sub-exception by implementing and conforming to organizational policies and procedures that identify the criteria to be used by the actor and, as applicable, the steps that the actor will take, in order to satisfy the precondition.</P>
                    <P>We noted that most actors are covered entities or business associates for the purposes of the HIPAA Privacy Rule, and are already required to have policies, procedures, and training programs in place that address how ePHI (as defined in 45 CFR 160.103) is used and disclosed. As such, we expected that the overwhelming majority of actors will already be in a position to meet this condition or would be able to meet this condition with modest additional effort. However, we acknowledged that some actors may not, for whatever reason, have privacy policies and practices in place, or may have implemented privacy policies and practices that do not sufficiently address the criteria to be used, and steps to be taken, to satisfy a precondition relied on by the actor. As such, we proposed to provide an alternative basis on which to qualify, in part, for this sub-exception. We proposed to permit actors to instead document, on a case-by-case basis, the criteria used by the actor to determine when the precondition will be satisfied, any criteria that were not met, and the reason why the criteria were not met (84 FR 7529).</P>
                    <P>Separately, we proposed that if the precondition that an actor purportedly needs to satisfy relies on the provision of a consent or authorization from an individual, it is a requirement for the condition(s) of this sub-exception that the actor (i) did all things reasonably necessary within its control to provide the individual with a meaningful opportunity to provide the consent or authorization and (ii) did not improperly encourage or induce the individual to not provide the consent or authorization (84 FR 7529).</P>
                    <HD SOURCE="HD3">Sub-Exception 1: “Precondition Not Satisfied”: Practice Must Be Implemented in a Consistent and Non-Discriminatory Manner</HD>
                    <P>We proposed that in order for a practice to qualify for this sub-exception, the practice must be implemented in a consistent and non-discriminatory manner (proposed § 171.202(b)(3)(ii)). This condition would provide basic assurance that the purported privacy practice is directly related to a specific privacy risk and is not being used to interfere with access, exchange, or use of EHI for other purposes to which this exception does not apply.</P>
                    <P>We proposed that this condition requires that the actor's privacy-protective practices must be based on objective criteria that apply uniformly for all substantially similar privacy risks. We explained that an actor could not, for example, implement an organizational privacy policy that imposed unreasonably onerous requirements on a certain class of individuals or entities without a legitimate justification for doing so. We explained that this condition provides basic assurance that the purported privacy-protective practice is not being used to interfere with access, exchange, or use of EHI for other purposes to which this proposed exception does not apply (84 FR 7532).</P>
                    <P>We requested comment on this proposed condition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters agreed that having an organizational policy which outlines patient preference categories and restrictions should be created and utilized in a consistent and non-discriminatory manner for all patient requests.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenters, and for clarity, we moved this proposed section to finalize in § 171.202(b)(1), in order to address when an actor has conformed to its organizational policies and procedures and when an actor documents on a case-by-case basis when a precondition has been satisfied. In both cases, the actor's practice must be implemented in a consistent and non-discriminatory manner. We provide the following example to illustrate the requirement that a practice must be implemented in a consistent and non-discriminatory manner.
                    </P>
                    <P>For example, we noted an actor that offered a patient-facing software application (app) would not be able to benefit from this exception if it refused to exchange EHI with a competitor app because the individual failed to meet onerous authorization requirements that applied only to the exchange of EHI with the competitor app and did not apply to others that presented no greater privacy or security risk.</P>
                    <P>
                        In context of this condition of the Privacy Exception, and consistent with its interpretation for information blocking exceptions defined in part 171 subpart B in general, “consistent and non-discriminatory” should be understood to mean that similarly situated actors whose interactions pose the same level of privacy risk should be treated consistently with one another under the actor's privacy practices. Inconsistent treatment across similarly situated actors whose interactions pose the same level of privacy risk based on 
                        <PRTPAGE P="25850"/>
                        extraneous factors, such as whether they are a competitor of the actor implementing the privacy practices, would not be considered appropriate.
                    </P>
                    <HD SOURCE="HD3">Sub-Exception 1: “Precondition Not Satisfied”: Practice Must Be Tailored to the Applicable Precondition</HD>
                    <P>We proposed that for actors who seek to qualify for this sub-exception, an actor's privacy-protective practice (proposed (§ 171.202(b)(3)(i)) must be tailored to the specific privacy risks that the practice actually addresses. This condition necessarily presupposes that an actor has carefully evaluated the privacy requirements imposed on the actor, the privacy interests to be managed by the actor, and has developed a considered response that is tailored to protecting and promoting the privacy of EHI. For example, we noted that the HIPAA Privacy Rule at 45 CFR 164.514(h) requires that, in certain circumstances, the disclosure of PHI is only authorized once the identity and authority of the person requesting the information has been verified. The privacy issue to be addressed in this instance is the risk that PHI will be disclosed to the wrong individual or an unauthorized person. We proposed that if an actor chooses not to provide access, exchange, or use of EHI on the basis that the actor's identity verification requirements have not been satisfied, the actor's practice must be tailored to the specific privacy risks at issue. We noted that this would require that the actor ensure that it does not impose identity verification requirements that are unreasonably onerous under the circumstances (84 FR 7531).</P>
                    <P>For the purposes of this sub-exception, we proposed that engaging in an interference on the basis that a precondition has not been satisfied would be a practice that addresses a privacy risk or interest, and so tailoring that interference to satisfy a precondition could satisfy this requirement if all of the elements are met.</P>
                    <P>We requested comment on this proposed condition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed a belief that a requirement that a “practice must be tailored to the specific privacy risk or interest being addressed” could lead to unnecessary complexity, and that such a policy could be overly prescriptive. In addition, commenters expressed that we should provide more use cases to help providers and others better understand how this element of the sub-exception could be met.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree. We believe that a precondition should be tailored to the applicable legal requirement and not be tied only to a privacy risk or interest. To require that an actor's practice be tailored to the specific privacy risk or interest without a legally imposed requirement could lead to overly strict as well as an ambiguous requirement. As such, we believe that it is an important policy interest that an actor carefully evaluate the State or Federal law requirements imposed upon an actor, and that the actor develop a response that is tailored to the legal precondition which protect and promote the privacy of EHI. We provide the following use case to provide a greater understanding of how this element of the sub-exception can be met.
                    </P>
                    <P>• To meet a legal precondition whereby an actor must identify a patient before accessing, exchanging or using EHI, an actor's policy that a driver's license was the only accepted government-issued form of identification (as opposed to other types of legally acceptable forms of identification such as a valid passport) would not be a practice that is tailored to the applicable precondition legal requirement because the provider's preference for one form of government-issued identification over another does not meaningfully address this legal precondition.</P>
                    <P>We have finalized that to qualify for this sub-exception on the basis that State or Federal law requires one or more preconditions to be met before providing access, exchange, or use of EHI the precondition should be based upon the applicable legal requirements.</P>
                    <HD SOURCE="HD3">Sub-Exception 1: “Precondition Not Satisfied”: Organizational Policies and Procedures or Case-by-Case Basis</HD>
                    <P>We proposed that if an actor seeks to qualify for this sub-exception, in part, by implementing and conforming to organizational policies and procedures, such policies and procedures must be in writing, and specify the criteria to be used by the actor, and, if applicable, the steps that the actor will take, in order to satisfy the precondition relied on by the actor not to provide access, exchange, or use of EHI. We emphasized that it would not be sufficient for an actor to simply identify the existence of the precondition in their organizational policies and procedures.</P>
                    <P>We proposed that an actor would only be eligible to benefit from this sub-exception if it has implemented and followed its processes and policies. This would include taking reasonable steps to ensure that its workforce members and agents understand and consistently apply the policies and procedures (84 FR 7529 and 7530).</P>
                    <P>We requested comment on the proposed condition generally, and specifically, on whether an actor's organizational policies and procedures provide a sufficiently robust and reliable basis for evaluating the bona fides, reasonableness, and necessity of practices engaged in to satisfy preconditions required by State or Federal privacy laws (84 FR 7529 and 7530).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters recommended that actors should be able to have written organization-specific policies that may be more restrictive than State or Federal law and that health information networks and exchanges should be given an exemption based on their existing written governance policies. Other commenters recommended adding language indicating that organizational policies must comply with Federal, State, and local laws or that the final rule should specify that organizations should implement policies which conform to the specific State laws in which the information originates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted above, this final rule includes a limited exception that permits an actor that operates in more than one State to adopt uniform policies and procedures based on more restrictive provisions of State and Federal law, subject to certain conditions. ONC reiterates that an actor's organizational policies and procedures should not be used as a pretext for information blocking. For example, information blocking may exist if an actor's policies and procedures impose onerous additional privacy requirements for access, exchange or use of EHI beyond what is required by law, or where an actor repeatedly changes its privacy policies and procedures to circumvent this exception. Further, the actor's policies and procedures must be tailored and must be implemented in a consistent and non-discriminatory manner.
                    </P>
                    <P>
                        We do not agree that health information exchanges or networks should be given a blanket exemption based on their existing written governance policies because that could lead to a situation involving information blocking if those policies imposed conditions that conflict with the information blocking provision. Secondly, we expect that an actor's organizational policies will conform with applicable laws, including the information blocking provision, so it is not necessary to further require actors to implement policies which conform to the specific laws, including the law of 
                        <PRTPAGE P="25851"/>
                        the State in which the information originated.
                    </P>
                    <HD SOURCE="HD3">Documenting Criteria and Rationale</HD>
                    <P>If an actor's practice does not conform to an actor's organizational policies and procedures as required by § 171.202(b)(1)(i), we proposed that an actor can seek to qualify for this sub-exception, in part, by documenting how it reached its decision that it would not provide access, use, or exchange of EHI on the basis that a precondition had not been satisfied. We proposed that such documentation must be created on a case-by-case basis proposed in § 171.202(b)(1)(ii). We noted that an actor will not satisfy this condition if, for instance, it sought to document a general practice that it had applied to all instances where the precondition had not been satisfied. Rather, we stated that the record created by the actor must address the specific circumstances of the specific practice (or interference) at issue.</P>
                    <P>We proposed that the record created by the actor must identify the objective criteria used by the actor to determine when the precondition is satisfied. Consistent with the condition to this sub-exception that the practice must be tailored to the privacy interest at issue, those criteria would need to be directly relevant to satisfying the requirement. For example, we explained that if the requirement at issue was the provision of a valid HIPAA authorization, the actor's documented record should reflect, at minimum, that the authorization would need to meet each of the requirements specified for a valid authorization at 45 CFR 164.508(c). The record would then need to document the criteria that had not been met, and the reason why it was not met. We noted that the actor could record that the authorization did not contain the name or other specific identification of the person making the request because the authorization only disclosed the person's first initial rather than a first name, and the actor had records about multiple people with that same initial and last name.</P>
                    <P>We noted that this condition would provide the transparency necessary to demonstrate whether the actor has satisfied the conditions applicable to this exception. Moreover, we noted that it will help ensure that a decision to not provide access, exchange, or use of EHI is considered and deliberate, and therefore reasonable and necessary (84 FR 7530).</P>
                    <P>We requested comment on this proposed condition.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested that we should provide specificity on what type of documentation would suffice to demonstrate that an actor met this sub-exception. Commenters were concerned that these were stringent documentation requirements and that provider practices may inadvertently trigger a violation of information blocking. Other commenters suggested that we should remove or consider reducing onerous requirements for documentation for qualifying for the privacy sub-exceptions, and other commenters requested specification on what form the documentation must be and to specify whether existing documentation required by the HIPAA Rules (
                        <E T="03">e.g.,</E>
                         patient informed consent and authorization forms, Notice of Privacy Practices, Security Risk Analysis, etc.) would satisfy the documentation requirements under this Privacy Exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The documentation requirements are for the actor to comply with applicable State and Federal laws and to assure that after the fact rationalizations are not used to justify practices that have already occurred, consistent with the policy objectives of the information blocking provision.
                    </P>
                    <P>To finalize the documentation requirements we looked to OIG, which has authority under section 3022(b) of the PHSA to investigate any claim that an actor engaged in information blocking. OIG regulations in other contexts include a writing requirement. For example, OIG has promulgated the “safe harbors” provisions at 42 CFR 1001.952, specifying various payment and business practices that would not be subject to sanctions under the Anti-Kickback Statute. Several of these safe harbors include a writing requirement to document in writing an agreement, lease, or other transaction. These documentation requirements do not often get into specific terms or requirements, but rather tend to be more general in nature. However, the documentation requirements do provide indicia of evidence that an entity has met the requirements of the safe harbor provisions.</P>
                    <P>In addition, we considered the documentation requirements in the HIPAA Rules. The HIPAA Privacy Rule at 45 C.F.R 164.530 (j) requires a covered entity to maintain its policies and procedures in written or electronic form for six years from the date of its creation or the date when it last was in effect, whichever is later. In our review of the OIG and HIPAA regulations, we believe that the documentation requirement for this sub-exception is consistent with the safe harbor and HIPAA Privacy Rule documentation requirements. Further, we do not believe this documentation requirement would be onerous.</P>
                    <P>Therefore, we have finalized the following requirements for this sub-exception. An actor must document its organizational policies and procedures and specify the criteria used by the actor and as applicable, the steps that the actor will take to satisfy the precondition. Such steps may include providing the actor's workforce members with training on those policies and procedures. Alternatively, we have finalized a requirement an actor must document on a case-by-case basis how it reached its decision that it would not provide access, use, or exchange of EHI on the basis that a precondition had not been satisfied, including the criteria it used to determine when the precondition is satisfied. That is, an actor can provide documentation that identifies the objective criteria that the actor applied in order to determine whether the precondition had been satisfied. Additionally, the actor must provide documentation that the practice is tailored to those criteria that are directly relevant to satisfying the precondition.</P>
                    <HD SOURCE="HD3">Sub-Exception 1: “Precondition Not Satisfied”: Precondition Relies on a Consent or Authorization</HD>
                    <P>We proposed that if the precondition that an actor purports to rely upon requires the provision of a consent or authorization from an individual, it is a condition of this sub-exception that the actor must have done all things reasonably necessary within its control to provide the individual with a meaningful opportunity to provide that consent or authorization. We noted that this requirement will be relevant when, for example, a State privacy law or the HIPAA Privacy Rule requires an individual to provide consent and/or a HIPAA authorization before identifiable information can be accessed, exchanged, or used for specific purposes.</P>
                    <P>
                        We stated that we were considering addressing this condition in further detail, whether by way of additional guidance or in regulation text. To this end, we requested comments regarding what actions an actor should take, within the actor's control, to provide an individual with a meaningful opportunity to provide a required consent or HIPAA authorization, and whether different expectations should arise in the context of a consent versus a HIPAA authorization. Separately, we proposed that to qualify for this sub-exception, to the extent that the precondition at issue was the provision of a consent or HIPAA authorization by an individual, the actor must not have 
                        <PRTPAGE P="25852"/>
                        improperly encouraged or induced the individual to not provide the consent or HIPAA authorization. We clarified that this does not mean that the actor cannot inform an individual about the advantages and disadvantages of exchanging EHI and any associated risks, so long as the information communicated is accurate and legitimate. However, we noted that an actor would not meet this condition in the event that it misled an individual about the nature of the consent to be provided, dissuaded individuals from providing consent in respect of disclosures to the actor's competitors, or imposed onerous requirements to effectuate consent that were unnecessary and not required by law.
                    </P>
                    <P>We requested comment on whether the proposed condition requiring the provision of a meaningful opportunity and prohibiting improper encouragement or inducement should apply to preconditions beyond the precondition that an individual provide consent or authorization. We requested comment on whether the conditions specified for this sub-exception, when taken in total, are sufficiently particularized and sufficiently strict to ensure that actors that are in a position to influence whether a precondition is satisfied will not be able to take advantage of this sub-exception and seek protection for practices that do not promote the privacy of EHI. We also requested comment on whether we should adopt a more tailored approach to conditioning the availability of this exception. For example, we noted that we were considering whether different conditions should apply depending on: (i) The nature of the EHI at issue; (ii) the circumstances in which the EHI is being access, exchanged, or used; (iii) the interest being protected by the precondition; or (iv) the nature of the precondition to be satisfied. We encouraged commenters to identify scenarios in which the application of the conditions applicable to this sub-exception, as proposed, give rise to unnecessary burden, or would require activities that do not advance the dual policy interests of preventing information blocking and promoting privacy and security (84 FR 7530 and 7531).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters noted that the entire condition was too vague and generally inconsistent with current standard industry relationships and practices. Several commenters suggested that the burden to obtain the consent should be on the organization requesting the data rather than on the organization that holds the data. However, commenters who suggested this often acknowledged that modifying our proposal to fit their suggestion would require an actor to receive assurances that consents are legitimate and in their possession before sharing any data. These commenters often noted that it was not clear how recipients of health care data subject to authorizations and consent would be expected to provide individuals with a meaningful opportunity to consent if they do not have an existing relationship with that individual or means to contact that individual. A few commenters recommended modifying this condition so that an actor that does not have a direct relationship with patients is not required to obtain patient consent or authorization.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenters and have attempted to address concerns about vagueness and consistency with industry practices and relationships. This finalized sub-exception requires the actor to have used reasonable efforts within its control if the actor has already received a form of required consent or authorization that does not meet all applicable requirements. Specifically, the actor must have used reasonable efforts within its control to provide the individual with a consent or authorization form that satisfies all applicable requirements or have provided other reasonable assistance with respect to the deficiencies. In effect, this places more of an obligation on the party requesting the EHI and the individual to attempt to satisfy the precondition by providing a consent or authorization. This final rule does not require the actor that receives the request to obtain a patient's consent or authorization to do all things reasonably necessary within its control to provide the individual with a meaningful opportunity to provide the consent or authorization. Rather, the final rule requires that the actor is obligated to take reasonable steps to provide a sufficient consent or authorization form or other reasonable assistance.
                    </P>
                    <P>Providing other reasonable assistance does not mean that the actor needs to “chase” the individual to obtain a sufficient consent or authorization. Such other reasonable assistance might include notifying the individual of elements that are missing in the consent or authorization initially provided, such as a witness or an expiration date if legally required.</P>
                    <P>We believe that setting the standard for an actor's actions with respect to an insufficient consent or authorization at reasonable efforts is an appropriate standard to use because it aligns with the case-by-case approach that is captured in the information blocking provision that is the subject of this final rule.</P>
                    <P>We recognize that actors must accommodate variations in laws across the states in which they operate. As discussed above, this final rule provides flexibility to multi-state providers with respect to how they may structure uniform policies and procedures regarding consents and authorizations provided that they do in fact apply them. We also recognize that some types of actors will not have the necessary legal rights or the technical access to detailed patient information to determine if a consent or authorization is required as a precondition.</P>
                    <P>We intend that each actor must do what is reasonable and what is within its control. This applies to actors who are providers that have a direct patient relationship and to actors that are supporting a health care provider with respect to an insufficient consent or authorization that must also use reasonable efforts to avoid possible information blocking.</P>
                    <P>A health information network that receives an insufficient consent or authorization might find that this sub-exception helpful if it does not have lawful access to the individual's information to determine what consent might be required under State or Federal confidentiality laws that apply to information about mental health, substance abuse, HIV status or other highly confidential diseases or conditions. We also note that if a network is not able to review such information under applicable law, providing a corrected consent would not be within its control.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters were concerned that our definition of “meaningful opportunity” was too broad. These few commenters suggested that, as proposed, our definition of “meaningful opportunity” could place a significant burden on providers. Specifically, these commenters suggested that adding a “meaningful” opportunity to consent to the patient, with its requisite new forms and procedures, would add new burdens on actors without appearing to solve any existing problems.
                    </P>
                    <P>One commenter recommended that we modify this requirement to include a reasonable opportunity for the provider to obtain the individual's consent the next time the patient visits the office if the patient is not present in the office to provide consent.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments that we have received on the meaningful opportunity provision. After considering the comments, we 
                        <PRTPAGE P="25853"/>
                        eliminated the “meaningful opportunity” provision in this final rule. However, this sub-exception still requires the actor to use reasonable efforts within its control and to provide reasonable assistance, which might include explaining the required elements of a consent or authorization, or providing a witness if required by law and requested by the patient at an office visit with the actor.
                    </P>
                    <P>However, the requirement of reasonable efforts is based on an assumption that actors may not use the protection of an individual's privacy as pretext for information blocking. If a requestor provides or obtains some form of patient documented consent or authorization that requires the actor's assistance to satisfy elements that are not required by law and the actor does not provide such assistance, the actor may be engaged in information blocking.</P>
                    <P>We recognize that meeting certain preconditions may be outside the direct control of the provider. For example, the actor may have a pre-existing consent form from the individual that needs to be modified due to a change in applicable law. The actor may have a very difficult time tracking down a former patient to provide the updated consent form. In most cases, it would be reasonable to mail or email the updated form to the patient's last address on the actor's records or present it to the patient at visit scheduled in the near future. If the patient cancels the visit, it may be reasonable for the actor to wait to obtain the consent until the next time the patient visits the physical location of the actor's office, so long as the actor explains the insufficiency and provides a sufficient consent form at the next visit.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters have mentioned that a health information network (HIN) does not have operational control over or visibility into the detailed decision-making of an individual's consent or authorization of its participants, and they argue that an actor such as a HIN should not be obligated to review or confirm the individuals' consent or authorization, and that such confirmation is a requirement of the health care provider because health care provider has a direct relationship with the patient.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We believe that actors such as a HIN do have the obligation to comply with the conditions of this sub-exception. We have taken the approach that each actor must use its “reasonable efforts” and focus on what reasonable steps they can take to provide their reasonable efforts. We do not, however, believe that actors who have a direct patient relationship would have a higher standard of reasonable efforts than those actors such as HINs which do not have a direct relationship with a patient and are acting on behalf of a health care provider. However, even actors that do not have a direct relationship with an individual, should use their reasonable efforts for the activities under their control as it relates to supporting the providing or obtaining of a consent or authorization.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concerns that actors would be required to create new policies beyond HIPAA aimed at offering patients a “meaningful” opportunity to consent, and as a result, more challenges than solutions would result from this policy. Commenters noted unnecessary administrative burdens, confusion with HIPAA requirements, and complexity for actors as some of the possible challenges.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted above, the “meaningful opportunity” requirement was not included in this final rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters expressed the opinion that actors meeting certain preconditions may be outside the direct control of the actor and recommended that examples should be provided about what actions are sufficient to meet the “reasonably necessary” standard. Another commenter argued that the reasonably necessary standard for the meaningful opportunity requirement only stands to further aggravate the burdensome nature of more stringent privacy laws. Other commenters were concerned that the requirement that the actor “did all things reasonably necessary within its control to provide the individual with a meaningful opportunity to provide the consent or authorization” was too rigid a requirement and that even if one possible action was not done, the exception would not apply. Other commenters argued that this standard was an extremely onerous requirement and contradicts the stated intent of reducing the overall administrative burden on health care practices.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted above, the standard is now based on reasonable efforts within the actor's control, and it applies only after the actor receives a consent or authorization form that does not satisfy all applicable conditions. We believe that this change addresses the comments noted above. We note that we have slightly modified the terminology used in § 171.202(b)(2)(i). We proposed “a form of consent or authorization” (84 FR 7602) and have change that language in the final rule to “a consent or authorization form” for clarity. This modification does not change the meaning of § 171.202(b)(2)(i).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter expressed concern to modify this exception to make it clear that a hospital or health system may claim the exception when an entity requesting patient data does not communicate that it has obtained consent.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted above, this condition of the sub-exception applies only after an insufficient consent or authorization is received. This condition of the sub-exception in the final rule does not apply when the actor has not received anything regarding the individual's consent or authorization. In such cases, the actor would not be required to communicate to the entity requesting the EHI that the actor has not obtained the individual's consent or authorization in order to meet this sub-exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter argued that actors should provide the individual with a “reasonably convenient opportunity” to provide the consent or authorization, rather than requiring “all things reasonably necessary within its control” to provide consent or authorization. The commenter noted that where entities make the request on behalf of the individual, the actor making the request should facilitate the gathering of the consent or authorization.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         As noted above, both the “reasonable opportunity” and the “all things reasonably necessary” language are not included in this final rule, but the actor must satisfy the reasonable efforts standard when an insufficient consent or authorization has been received. This might include providing a correct form or reasonable assistance to the individual to solve any consent or authorization documentation problems necessary to address the insufficiency.
                    </P>
                    <HD SOURCE="HD3">Sub-Exception 1: Precondition Not Satisfied: Did Not Improperly Encourage or Induce the Individual To Withhold the Consent or Authorization</HD>
                    <P>
                        We proposed that to qualify for this sub-exception, to the extent that the precondition at issue was the provision of a consent or authorization by an individual, the actor must not have improperly encouraged or induced the individual to not provide the consent or authorization. As proposed, an actor would not meet this condition in the event that it misled an individual about the nature of the consent to be provided, dissuaded individuals from providing consent in respect of disclosures to the actor's competitors, or imposed onerous requirements to effectuate consent that 
                        <PRTPAGE P="25854"/>
                        were unnecessary and not required by law.
                    </P>
                    <P>We sought comment on whether the proposed condition requiring the provision of prohibiting improper encouragement or inducement should apply to preconditions beyond the precondition that an individual provide consent or authorization. We sought comment on whether the conditions specified for this sub-exception, when taken in total, are sufficiently particularized and sufficiently strict to ensure that actors that are in a position to influence whether a precondition is satisfied will not be able to take advantage of this sub-exception and seek protection for practices that do not promote the privacy of EHI. We also sought comment on whether we should adopt a more tailored approach to conditioning the availability of this sub-exception (84 FR 7531).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments opposing this condition applicable to practices that implement the provision of a consent or authorization from an individual to an actor.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Within the sub-exception (§ 171.202(b)) applicable to practices that implement a consent or authorization, we are finalizing in § 171.202(b)(2)(ii) as proposed.
                    </P>
                    <HD SOURCE="HD3">Sub-Exception 2: Sub-Exception: Health IT Developer of Certified Health IT Not Covered by HIPAA</HD>
                    <P>The sub-exception we proposed in § 171.202(b) recognized as reasonable and necessary the activities engaged in by actors consistent with the controls placed on access, exchange, or use of EHI by Federal and State laws. We noted that the sub-exception was limited to actors that are subject to those Federal and State laws; an actor that is not regulated by HIPAA cannot benefit from the exception proposed in § 171.202(b).</P>
                    <P>
                        We proposed to establish a sub-exception to the information blocking provision that would apply to actors that are health IT developers of certified health IT but not regulated by the HIPAA Privacy Rule in respect to the operation of the actor's health IT product or service (referred to as “non-covered actors” for this sub-exception). We noted that we expect that the class of actors to which this proposed sub-exception applies will be very small. We explained that the vast majority of health IT developers of certified health IT operate as business associates to covered entities under HIPAA. As business associates, they are regulated by the HIPAA Privacy Rule, and may be able to benefit from the exception proposed in § 171.202(b) to the extent that the HIPAA Privacy Rule (or applicable State law) imposes preconditions to the provision of access, exchange, or use of EHI. However, we recognized that direct-to-consumer health IT products and services are a growing sector of the health IT market. The privacy practices of consumer-facing health IT products and services are typically regulated by the Federal Trade Commission Act (FTC Act). However, while the FTC Act prohibits unfair or deceptive acts or practices in or affecting commerce (15 U.S.C. 45(a)(1)), it does not prescribe specific privacy requirements.
                        <SU>165</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>165</SU>
                             
                            <E T="03">See</E>
                             HHS, 
                            <E T="03">Examining Oversight of the Privacy &amp; Security of Health Data Collected by Entities Not Regulated by HIPAA, https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>We proposed that where a health IT developer of certified health IT offers a health IT product or service not regulated by the HIPAA Privacy Rule, such product or service is still subject to the information blocking provision. We wanted to ensure that such non-covered actors under the information blocking provisions are able to avail themselves of the Privacy Exception. As such, we proposed that an entity that is not covered by HIPAA will not engage in information blocking if the actor declines to provide access, exchange, or use of EHI where the practice implements a process that is described in the actor's organizational privacy policy and has been disclosed to any individual or entity that uses the actor's health IT. We proposed this sub-exception in § 171.202(c) which sets forth additional detail (84 FR 7532).</P>
                    <P>In the final rule, we have finalized that when engaging in a practice that promotes the privacy interests of an individual, the non-covered actor must implement the practice according to a process described in the organizational privacy policies, disclosed those organizational privacy policies to the individuals and entities that use the actor's product or service before they agreed to use them, and the non-covered actor's organizational privacy policies must: (1) Comply with applicable State or Federal laws; (2) be tailored to the specific privacy risk or interest being addressed; and (3) be implemented in a consistent and non-discriminatory manner. Public comments on specific conditions are summarized below, in context of each condition proposed. We believe our responses to these comments furnish the clarity non-covered actors need to understand the conditions of the sub-exception finalized in § 171.202(c).</P>
                    <HD SOURCE="HD3">Practice Must Implement Privacy Policy</HD>
                    <P>We proposed that in order to qualify for this sub-exception, the practice engaged in by the non-covered actor—the interference with access, exchange, or use of EHI—must also implement a process described in the actor's organizational privacy policy. This requires that a non-covered actor must have documented in detail in its organizational privacy policy the processes and procedures that the actor will use to determine when the actor will not provide access, exchange, or use of EHI. For example, we explained that a non-covered actor that proposed to require the provision of written consent for the use or disclosure of EHI would need to describe in its organizational privacy policy the processes and procedures to be utilized by the actor to implement that privacy-protective practice so that the practice be considered reasonable and necessary and qualify for this sub-exception. We noted that compliance with this condition ensures that the sub-exception recognizes only legitimate practices that have been tailored to the privacy needs of the individuals that use the non-covered actor's health IT, and does not recognize practices that are a pretext or after-the-fact rationalization for actions that interfere with access, exchange, or use of EHI.</P>
                    <P>We also proposed that the non-covered actor's practice must implement its documented organizational privacy policy. We noted that practices that diverge from an actor's documented policies, or which are not addressed in an actor's organizational privacy policy, would not qualify for this proposed sub-exception (84 FR 7532).</P>
                    <HD SOURCE="HD3">Policies Must Have Been Disclosed to Users</HD>
                    <P>
                        We proposed that a non-covered actor that seeks to benefit from the sub-exception must also ensure that it has previously disclosed the privacy-protective practice to the individuals and entities that use, or will use, the health IT. These users are affected by the practices engaged in by a non-covered actor but may otherwise have no visibility of the non-covered actor's approach to protecting the privacy of EHI. We noted that we expect that non-covered actors will seek to satisfy this condition by using a privacy notice.
                        <FTREF/>
                        <SU>166</SU>
                          
                        <PRTPAGE P="25855"/>
                        We emphasized that the disclosure must be meaningful. In assessing whether a non-covered actor's disclosure was meaningful, we explained that regard will be paid to whether the disclosure was in plain language and conspicuous, including whether the disclosure was located in a place, and presented in a manner, that is accessible and obvious to the individuals and entities that use, or will use, the health IT.
                    </P>
                    <FTNT>
                        <P>
                            <SU>166</SU>
                             ONC has provided a Model Privacy Notice (MPN) that is a voluntary, openly available resource designed to help developers clearly convey information about their privacy and security policies to their users. The MPN provides a snapshot of a company's existing privacy practices encouraging transparency and helping consumers make informed choices when selecting products. 
                            <PRTPAGE/>
                            The MPN does not mandate specific policies or substitute for more comprehensive or detailed privacy policies. See 
                            <E T="03">https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn</E>
                            .
                        </P>
                    </FTNT>
                    <P>We proposed that to qualify for this sub-exception, a non-covered actor would not be required to disclose its organizational privacy policy to its customers or to the public generally. Rather, the non-covered actor need only describe, with sufficient detail and precision to be readily understood by users of the non-covered actor's health IT, the privacy-protective practices that the non-covered actor has adopted and will observe. We explained that this is necessary because a non-covered actor that is not subject to prescribed privacy standards in connection with the provision of health IT will have significant flexibility in the privacy-protective practices that it adopts. If a non-covered actor is not required to inform the individuals and entities that use, or will use, the health IT, about the privacy-protective practices that it will implement in its product, or when providing its service, we noted that there is a risk that the sub-exception will give deference to policies and processes that are post hoc rationalizations used to justify improper practices. We stated that this condition also serves as a check on the nature of the interferences that a non-covered actor writes into its organizational privacy policies; transparency will help to ensure that a non-covered actor takes a balanced approach to protecting privacy interests on one hand, and pursuing business interests that might be inconsistent with the information blocking provision, on the other hand (84 FR 7533).</P>
                    <P>We proposed that it will be a matter for non-covered actors to determine the most appropriate way to communicate its privacy practices to users. We noted that it would be reasonable that non-covered actors would, at a minimum, post their privacy notices, or otherwise describe their privacy-protective practices, on their websites (84 FR 7533).</P>
                    <HD SOURCE="HD3">Practice Must Be Tailored to Privacy Risk and Implemented in a Non-Discriminatory Manner</HD>
                    <P>Finally, we proposed that in order for a practice to qualify for this sub-exception, an actor's practice must be tailored to the specific privacy risks that the practice actually addresses and must be implemented in a consistent and non-discriminatory manner.</P>
                    <P>We requested comment on this proposed sub-exception generally. Specifically, we requested comment on whether HIEs or HINs would benefit from a similar sub-exception. We also requested comment on whether the conditions applicable to this sub-exception are sufficient to ensure that non-covered actors cannot take advantage of the exception by engaging in practices that are inconsistent with the promotion of individual privacy. We also requested comment on the level of detail that non-covered actors should be required to use when describing their privacy practices and processes to user of health IT (84 FR 7533).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters believed that this sub-exception could be helpful for those developing their own health IT tools, which are outside of the electronic health record.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree that this sub-exception would be helpful for those developing their own health IT tools. The sub-exception address those certified Health IT products not covered by HIPAA and would have in place an organizational privacy policy which is tailored to a specific privacy risk or interest.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters noted that regarding the sub-exception proposed for “non-covered actors” that develop patient-facing health IT, they urged the need to balance the conditions of this sub-exception with the requirements placed on actors who institute organizational privacy policies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comment. In order to meet this sub-exception, the organizational privacy policies of a non-covered actor would need to comply with other applicable State and Federal laws. Further, we have finalized that non-covered actors that seek to benefit from this sub-exception must also ensure that their organizational privacy policies are disclosed to the individuals and entities that use their product or service before the individuals and entities agree to use them. The organizational privacy policies are important for transparency for users of the certified technologies and to demonstrate compliance with applicable State and Federal laws. Non-covered actors have the discretion to determine the most appropriate way to communicate their privacy policies to individuals and users. As stated above and in the Proposed Rule (84 FR 7533), it would be reasonable for non-covered actors to, at a minimum, post their privacy notices, or otherwise describe their privacy-protective practices, on their websites.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters stated that it is unclear whether application developers are subject to HIPAA if they are not business associates or covered entities.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. Where application developers are not defined as a covered entity or business associate as defined under 45 CFR 160.103, then the application developer is not covered under the HIPAA Privacy Rule or HIPAA Security Rule.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern that data will be made available to third-party application suppliers, commercial analytics companies, and/or entities that are not governed by HIPAA and that such availability of data would not serve patients' best interests and could result in potential misuse of patient data.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback and agree that an actor who is a health IT developer of certified health IT that is not required to comply with the HIPAA Privacy Rule must comply with all applicable State and Federal laws, including the FTC Act. Further, such actors must have an organizational privacy policy that is tailored to the privacy risk or interest being addressed in order to meet this sub-exception. We emphasize that where a health IT developer of certified health IT offers a health IT product or service not regulated by the HIPAA Privacy Rule, such product or service is subject to the information blocking provision. Our goal is to ensure that non-covered actors that engage in reasonable and necessary privacy-protective practices that interfere with the access, exchange, or use of EHI could seek coverage under the sub-exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters stated that actors that are not covered by HIPAA should make their privacy policies publicly available. Other commenters did not believe that the Proposed Rule fully addressed patient and consumer privacy protections.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the comments. We believe that it is important that users know what to expect when electing to use a non-covered actor's product or service.
                        <PRTPAGE P="25856"/>
                    </P>
                    <HD SOURCE="HD3">Sub-Exception 3: Denial of an Individual's Request for Their Electronic Protected Health Information in the Circumstances Provided in 45 CFR 164.524(a)(1) and (2)</HD>
                    <P>
                        We proposed a limited sub-exception to the information blocking provision that would permit a covered entity or business associate to deny an individual's request for access to their PHI in the circumstances provided under 45 CFR 164.524(a)(1) (2) and (3). We noted that this exception would avoid a potential conflict between the HIPAA Privacy Rule and the information blocking provision. Specifically, the HIPAA Privacy Rule contemplates circumstances under which covered entities, and in some instances business associates, may deny an individual access to PHI and distinguishes those grounds for denial which are reviewable from those which are not. We proposed that this exception applies to both the “unreviewable grounds” and “reviewable grounds” of access. We noted that the “unreviewable grounds” for denial for individuals include situations involving: (1) Certain requests that are made by inmates of correctional institutions; (2) information created or obtained during research that includes treatment, if certain conditions are met; (3) denials permitted by the Privacy Act; and (4) information obtained from non-health care providers pursuant to promises of confidentiality. In addition, we noted that two categories of information are expressly excluded from the HIPAA Privacy Rule individual right of access: (1) Psychotherapy notes, which are the notes recorded by a health care provider who is a mental health professional documenting or analyzing the contents of a conversation during a private counseling session and that are maintained separate from the rest of the patient's medical record; and (2) information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding.
                        <SU>167</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>167</SU>
                             See 45 CFR 164.501; 45 CFR 164.524 (a)(1)(i) and (ii).
                        </P>
                    </FTNT>
                    <P>We noted the “reviewable grounds” of access as described in § 164.524(a)(3), which provides that a covered entity may deny access provided that the individual is given a right to have such denials reviewed under certain circumstances. We explained that one such circumstance is when a licensed health care professional, in the exercise of professional judgment, determines that the access requested is reasonably likely to endanger the life or physical safety of the individual or another person. In addition, we noted that if access is denied, then the individual has the right to have the denial reviewed by a licensed health professional who is to act as a reviewing official and did not participate in the original decision to deny access (see generally 45 CFR 164.524(a)(3)) (84 FR 7533 and 7534).</P>
                    <P>As mentioned above with regards to the harm exception (§ 171.201) our purpose is to avoid unnecessary complexity. By including the “reviewable grounds” of 45 CFR 164.524(a)(3) in the harm exception at § 171.201, we align these regulations in a way that streamlines compliance for actors subject to the HIPAA Privacy Rule and this regulation. We removed the 45 CFR 164.524(a)(3) reference in the privacy sub-exception in § 171.202(d) and moved it to the harm exception in § 171.201 in order to promote clarity and alignment with the inter-relationship between this final rule and the HIPAA Privacy Rule.</P>
                    <P>In restricting this privacy sub-exception to only “unreviewable grounds” in 45 CFR 164.524(a)(1) and (2), we clarify the regulation text so that it is immediately clear that actors who are covered entities, and in some instances business associates, may deny an individual access to EHI of the individual and such denials would not provide an opportunity for review of the denial under certain circumstances. We clarify in the final rule that if an individual requests EHI under the right of access provision under 45 CFR 164.524(a)(1) from an actor that must comply with 45 CFR 164.524(a)(1), the actor's practice must be consistent with 45 CFR 164.524(a)(2). 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.</P>
                    <P>Unlike the “unreviewable grounds,” the “reviewable grounds” that are finalized § 171.201 are directly related to the likelihood of harm to a patient or another person and requires that actors seeking to avail themselves of this exception must have a reasonable belief that the practice will substantially reduce a risk of harm that would otherwise arise from the specific access, use, or exchange of EHI affected by the practice, and the harm must be one that would be cognizable under 45 CFR 164.524(a)(3) as a basis for denying an individual's right of access to their PHI in analogous circumstances. In other words, the “reviewable grounds” of access as described in 45 CFR 164.524(a)(3), provides that a covered entity may deny access provided that the individual is given a right to have such denials reviewed when a licensed health care professional, in the exercise of professional judgment, determines that the access requested is reasonably likely to endanger the life or physical safety of the individual or another person. In addition, we noted that if access is denied, then the individual has the right to have the denial reviewed by a licensed health professional who is to act as a reviewing official and did not participate in the original decision to deny access and the risk to be reduced must be one that would otherwise arise from the specific access, use, or exchange of EHI affected by the practice.</P>
                    <P>We proposed that if an actor who is a covered entity or its business associate denies an individual's request for access to their PHI on the basis of these unreviewable grounds, and provided that the denial of access complies with the requirements of the HIPAA Privacy Rule in each case, then the actor would qualify for this exception and these practices would not constitute information blocking (84 FR 7534).</P>
                    <P>We requested comment on this proposed sub-exception.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters were concerned that HINs that are business associates may not be authorized to provide individual access on the behalf of covered entity. Further, commenters sought clarification that this sub-exception would also apply in circumstances where as a business associate, the HIN would deny the individual's request for access because of its obligations as a business associate.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We share this concern. To meet this privacy sub-exception, if an individual requests their ePHI under 45 CFR 164.524(a)(1), the actor may deny the request in the circumstances provided in 45 CFR 164.524(a)(1) or (2). That is, an actor that is a covered entity may deny an individual's request for access to all or a portion of the PHI and must meet its requirements under the HIPAA Privacy Rule. As we discussed earlier, an individual's right under the HIPAA Privacy Rule to access PHI about themselves includes PHI in a designated record set maintained by a business associate on behalf of a covered entity. However, if the same PHI that is the subject of an access request is maintained in both the designated record set of the covered entity and the designated record set of the business associate, the PHI need only be 
                        <PRTPAGE P="25857"/>
                        produced once in response to the request for access.
                        <SU>168</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>168</SU>
                             45 CFR 164.524(c)(1).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested clarification that covered entities and business associates could meet this sub-exception when conducting clinical research with a blinded or masked designed. The EHI is typically `tagged' as part of a blinded or masked research during a research study.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         To meet this privacy sub-exception, if an individual requests their ePHI under 45 CFR 164.524(a)(1), the actor may deny the request in the circumstances provided in 45 CFR 164.524(a)(1) or (2). Under certain limited circumstances under the Privacy Rule, a covered entity may deny an individual's request for access to all or a portion of the PHI requested. In some of these circumstances, an individual does not a right to have the denial reviewed by a licensed health care professional. It is known as “unreviewable grounds” for denial.
                        <SU>169</SU>
                        <FTREF/>
                         One of the “unreviewable grounds” involves individual access to ePHI in a research study. An actor may deny access to an individual provided that the requested PHI is in a designated record set that is part of a research study that includes treatment (
                        <E T="03">e.g.,</E>
                         clinical trial) and is still in progress, provided the individual agreed to the temporary suspension of access when consenting to participate in the research. The individual's right of access can be reinstated upon completion of the research study.
                    </P>
                    <FTNT>
                        <P>
                            <SU>169</SU>
                             45 CFR 164.524(a)(2).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Sub-Exception 4: Sub-Exception: Respecting an Individual's Request Not To Share Information</HD>
                    <P>We proposed to establish an exception to the information blocking provision that would, in certain circumstances, permit an actor not to provide access, exchange, or use of EHI if an individual has specifically requested that the actor not do so. This sub-exception was proposed in § 171.202(e). We noted that this sub-exception is necessary to ensure that actors are confident that they can respect individuals' privacy choices without engaging in information blocking, and to promote public confidence in the health IT infrastructure by effectuating patients' preference about how and under what circumstances their EHI will be accessed, exchanged, and used. We recognized in the Proposed Rule that individuals may have concerns about permitting their EHI to be accessed, exchanged, or used electronically under certain circumstances. As a matter of public policy, we explained that these privacy concerns, if expressed by an individual and agreed to by an actor, would be reasonable and necessary, and an actor's conduct in abiding by its agreement would, if all conditions are met, be an exception to the information blocking provision (84 FR 7534).</P>
                    <P>We proposed that this proposed sub-exception would not apply under circumstances where an actor interferes with a use or disclosure of EHI that is required by law, including when EHI is required by the Secretary to enforce HIPAA under 45 CFR 164.502(a)(2)(ii) and 45 CFR 164.502(a)(4)(i). Stated differently, this sub-exception would not operate to permit an actor to refuse to provide access, exchange, or use of EHI when that access, exchange, or use is required by law. We noted that this sub-exception recognizes and supports the public policy objective of the HIPAA Privacy Rule, which identifies uses and disclosures of EHI for which the public interest in the disclosure of the individual's information outweighs the individual's interests in controlling the information.</P>
                    <P>We proposed that this sub-exception would permit an actor not to share EHI if the following conditions are met: (1) The individual made the request to the actor not to have their EHI accessed, exchanged, or used; (2) the individual's request was initiated by the individual without any improper encouragement or inducement by the actor; and (3) the actor or its agent documents the request within a reasonable time period.</P>
                    <P>We described that to qualify for this sub-exception, the request that the individual's EHI not be accessed, exchanged, or used must come from the individual. Moreover, the individual must have made the request independently and without any improper encouragement or inducement by the actor.</P>
                    <P>We proposed that if an individual submits a request to an actor not to disclose her EHI, and the actor agrees with and documents the request, the request would be valid for purposes of this sub-exception unless and until it is subsequently revoked by the individual. We proposed that once the individual makes the request, she should not, subject to the requirements of applicable Federal or State laws and regulations, have to continually reiterate her privacy preferences, such as having to re-submit a request every year. Likewise, we proposed that once the actor has documented an individual's request, the actor should not have to repeatedly reconfirm and re-document the request. We requested comment, however, regarding whether this approach is too permissive and could result in unintended consequences. We also sought comment on this proposed sub-exception generally, including on effective ways for an individual to revoke their privacy request for purposes of this sub-exception.</P>
                    <P>We also proposed that in order for a practice to qualify for this sub-exception, an actor's practice must be implemented in a consistent and non-discriminatory manner. This condition would provide basic assurance that the purported privacy practice is directly related to the risk of disclosing EHI contrary to the wishes of an individual, and is not being used to interfere with access, exchange, or use of EHI for other purposes to which this exception does not apply. We noted that this condition requires that the actor's privacy-protective practice must be based on objective criteria that apply uniformly for all substantially similar privacy risks (84 FR 7534 and 7535).</P>
                    <P>We noted that under the HIPAA Privacy Rule, individuals have the right to request restrictions on how a covered entity will use (as that term is defined in 45 CFR 160.103) and disclose PHI about them for treatment, payment, and health care operations pursuant to 45 CFR 164.522(a)(1). Under 45 CFR 164.522(a), a covered entity is not required to agree to an individual's request for a restriction (other than in the case of a disclosure to a health plan under 45 CFR 164.522(a)(1)(vi)), but is bound by any restrictions to which it agrees (84 FR 7534).</P>
                    <P>We proposed that if an individual submitted a request to an actor not to disclose her EHI, and the actor agreed with and documents the request, the request would be valid for the purposes of this sub-exception unless and until it was subsequently revoked by the individual. We believed that this approach would minimize compliance burdens for actors while also respecting individuals' requests. We sought comment on this proposed sub-exception generally, including on effective ways for individuals to revoke their privacy request for purposes of this sub-exception (84 FR 7534). In the final rule, we align with the HIPAA Privacy Rule, specifically, 45 CFR 164.522(a)(2) which includes specific requirements with respect to the termination of an individual's restriction. Similar to the HIPAA Privacy Rule, we include § 171.202(e)(4) to address situations where the individual terminates its individual's restriction.</P>
                    <P>
                        An actor may terminate a restriction with the individual's written or oral agreement. If the individual's agreement 
                        <PRTPAGE P="25858"/>
                        is obtained orally, the actor must document that agreement. A note in the certified EHR or similar notation is sufficient documentation. If the individual agrees to terminate the restriction, the actor may use and disclose EHI as otherwise permitted under this final rule. An actor may only access, exchange or use EHI after it informs the individual of the termination. The restriction continues to apply to EHI accessed, exchanged or used prior to informing the individual of the termination. That is, any EHI that had been collected before the termination may not be accessed, exchanged or used in a way that is inconsistent with the restriction, but any information that is collected after informing the individual of the termination of the restriction may be used or disclosed as otherwise permitted under the final rule. In § 171.201(e)(4), we clarify that an actor must document a restriction to which it has agreed. We do not require a specific form of documentation; a note in the certified EHR or similar notation is sufficient.
                    </P>
                    <P>A restriction is only binding on the actor that agreed to the restriction. We encourage actors to inform others of the existence of a restriction when it is appropriate to do so. If a restriction does not permit an actor to disclose EHI to a particular person, the actor must carefully consider whether disclosing the existence of the restriction to that person would also violate the restriction.</P>
                    <P>We clarified that for the purposes of this proposed sub-exception, the actor may give effect to an individual's request not to have an actor disclose EHI even if State or Federal laws would allow the actor not to follow the individual's request. We explained that this is consistent with our position that, absent improper encouragement or inducement, and subject to appropriate conditions, it should not be considered information blocking to give effect to patients' individual preferences about how their EHI will be shared or how their EHI will not be shared.</P>
                    <P>We requested comments on this sub-exception generally. Specifically, we sought comment on what would be considered a reasonable time frame for documentation. In addition, we also sought comment on how this sub-exception would affect public health disclosures and health care research, if an actor did not share a patient's EHI due to a privacy preference, including any effects on preventing or controlling diseases, injury, or disability, and the reporting of disease, injury, and vital events such as births or deaths, and the conduct of public health surveillance and health care research (84 FR 7534 and 7535).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended that we provide guidance regarding what could be considered a “reasonable time period” under § 171.202(e)(3) and to provide clarity to health information professionals that will be tasked with documenting the individual's privacy preferences in accordance with this regulation.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In order to align with HIPAA, we looked to the HIPAA Privacy Rule at 45 CFR 164.522 for guidance on this issue. The HIPAA Privacy Rule requires a covered entity to document a restriction of PHI, but gives covered entities the discretion to determine the exact timing of the documentation. The documentation requirement is consistent with the HIPAA Privacy Rule, which is already being observed by covered entities and business associates.
                    </P>
                    <P>
                        Under the HIPAA Privacy Rule, a covered entity may voluntarily choose, but is not required, to obtain the individual's consent for it to use and disclose information about him or her for treatment, payment, and health care operations.
                        <SU>170</SU>
                        <FTREF/>
                         A “consent” document is not a valid permission to use or disclose PHI for a purpose that requires an “authorization” under the HIPAA Privacy Rule (see 45 CFR 164.508), or where other requirements or conditions exist under the HIPAA Privacy Rule for the use or disclosure of PHI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>170</SU>
                             
                            <E T="03">See</E>
                             45 CFR 164.506(b).
                        </P>
                    </FTNT>
                    <P>Similarly, we believe that actors should be given the discretion to document an individual's request and such documentation should be within a reasonable period of time after making such a request. Although we do not require the request form to be dated at the time it is signed, we would recommend that it be dated so that actors and others can document that the request was obtained prior to an actor's agreement for the restriction of the individual's access, exchange or use of EHI. What would be deemed as an unreasonable period of time would be the unreasonable delay in performance and in documentation by the actor as well as whether there were any objective manifestations of expectation expressed between the individual and the actor.</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter recommended that a reasonable time frame should balance and not burden an individual or organization such as reviewing preferences with the individual each year and that the risk/benefit profile in the fast-changing health-IT market may well have changed and that the individual has a right to have those changes disclosed to make an informed decision. Another commenter expressed a belief that not asking the individual to reconfirm their preference is too permissive.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree that once the individual makes the request to an actor, she should not, subject to the requirements of applicable Federal or State laws and regulations, have to continually reiterate her privacy preferences, such as having to re-submit a request every year. Likewise, we finalized that once the actor has documented an individual's request within a reasonable period of time, then the actor is not required to repeatedly reconfirm and re-document the request.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter recommended that the request needs to be in writing, and suggested that we provide guidance regarding how the individual's request could be documented. Another commenter requested that we develop a template consent form whereby patients could indicate if they would like to have their health information disclosed to third parties and to ensure that the content of this form would be absent of any “improper encouragement or inducement” and that we should work in consultation with OCR to develop the recommended language for a model consent form.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree that an individual's request and an individual's request for revocation should be in writing assuming such a request is not required or prohibited by law. Alternatively, an actor could document a conversation with an individual. Such documentation could be documented in a certified EHR in some manner, and if the individual was provided a specific request form, the form could be included in a certified EHR. We believe that an individual should have sufficient opportunity to consider whether to provide a request and that an actor should minimize the possibility of coercion or undue influence and refrain from any improper encouragement or inducement. Any form provided by the actor should have information provided in plain language that is understandable to the individual.
                    </P>
                    <P>
                        For example, we noted that it would be improper to discourage individuals from sharing information with unaffiliated providers on the basis of generalized or speculative risks of unauthorized disclosure. On the other hand, we noted that if the actor was aware of a specific privacy or security risk, it would be proper to inform individuals of that risk. Likewise, an 
                        <PRTPAGE P="25859"/>
                        actor would be permitted to provide an individual with general information about her privacy rights and options, including for example, the option to not provide consent, provided the information is presented accurately, does not omit important information, and is not presented in a way that is likely to improperly influence the individual's decision about how to exercise their rights.
                    </P>
                    <P>It is important to note that the sub-exception conditions in the regulation are not intended to preempt any applicable Federal, State, or local laws that may require additional information to be disclosed for an agreement to be legally effective. We will continue to work in consultation with OCR to develop resources as necessary to support actors' compliance with the conditions of this Privacy Exception.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters requested greater clarity on how this regulation would affect public health disclosures and health care research, if an actor did not share a patient's EHI due to a privacy preference, including any effects on preventing or controlling diseases, injury, or disability, and the reporting of disease, injury, and vital events such as births or deaths, and the conduct of public health surveillance and health care research.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         With regard to public health disclosures, to the extent that such disclosures are required by law, the actor would not be in a position to grant the patient's request for restriction. With regard to EHI used for research, the unavailability of the individual's information resulting from a restriction would be consistent with the patient's right to withhold authorization for research uses and disclosures. However, an Institutional Review Board may approve a consent procedure that alters some or all of the elements of informed consent, or waive the requirement to obtain informed consent under HHS regulations at 45 CFR 46.116(c), and to the extent that the researcher has obtained a waiver of informed consent, research could be compromised by the unavailability of certain EHI. One possible way to resolve this issue would be the establishment of a field that actors covered could check in a certified EHR that would indicate that restrictions have been applied to the individual's EHI (without providing detail of the nature of such restriction). In this case, actors could exclude the individual's EHI from research.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter suggested that EHI should be accessed, exchanged or used despite a patient's privacy agreement with an actor in emergency treatment situations particularly when an individual is unavailable to provide a revocation. The commenter was concerned that if the EHI was not disclosed to health care provider in an emergency, the individual could be subject to imminent harm or death.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         In the Proposed Rule (proposed § 171.202(e)), we did not provide how an individual could revoke her privacy agreement with the actor. In response, we included in the final rule in § 171.202(e)(4) to specifically address the termination of an individual's request. In order to address these specific circumstances and align with the HIPAA Privacy Rule, we agree that an individual's restriction may need to be compromised in emergency treatment situations, and we have finalized that an actor may terminate an individual's request for a restriction to not provide access, exchange or use of EHI under limited circumstances.
                    </P>
                    <P>c. Security Exception—When will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to protect the security of electronic health information not be considered information blocking?</P>
                    <P>We proposed in the Proposed Rule (84 FR 7535 through 7538) to establish an exception to the information blocking provision that would permit actors to engage in practices that are reasonable and necessary to promote the security of EHI, subject to certain conditions. We explained that, without this exception, actors may be reluctant to implement security measures or engage in other activities that are reasonable and necessary for safeguarding the confidentiality, integrity, and availability of EHI. This could undermine the ultimate goals of the information blocking provision by discouraging best practice security protocols and diminishing the reliability of the health IT ecosystem.</P>
                    <P>We noted (84 FR 7535) that robust security protections are critical to promoting patients' and other stakeholders' trust and confidence that EHI will be collected, used, and shared in a manner that protects individuals' privacy and complies with applicable legal requirements. We also noted that public confidence in the security of their EHI has been challenged by the growing incidence of cyber-attacks in the health care sector. More than ever, we explained, health care providers, health IT developers, HIEs and HINs must be vigilant to mitigate security risks and implement appropriate safeguards to secure the EHI they collect, maintain, access, use, and exchange.</P>
                    <P>
                        We emphasized (84 FR 7535) that, while the importance of security practices cannot be overstated, the proposed exception would not apply to 
                        <E T="03">all</E>
                         practices that purport to secure EHI. Rather, we stated that the exception would only be available when the actor's security-based practice satisfies the conditions applicable to this exception.
                        <SU>171</SU>
                        <FTREF/>
                         We noted that it would not be appropriate to prescribe a “maximum” level of security or to dictate a one-size-fits-all approach for all actors as that may not be appropriate in all circumstances and may not accommodate new threats, countermeasures, and best practices in a rapidly changing security landscape. We further noted that we did not intend for the proposed exception to dictate a specific security approach. Moreover, we emphasized that effective security best practices focus on the mitigation and remediation of risks to a reasonable and acceptable level.
                    </P>
                    <FTNT>
                        <P>
                            <SU>171</SU>
                             In the Proposed Rule (84 FR 7535), we used the phrase “conditions applicable to this exception” to mean the conditions (inclusive of requirements within specific conditions) of the exception applicable to a particular practice in a particular circumstance. Where we are not summarizing what we stated in the proposed rule, in this preamble we have generally used plainer-language phrasings, such as “the conditions of the exception that are applicable to a practice [in the particular circumstances].”
                        </P>
                    </FTNT>
                    <P>With consideration of the above (84 FR 7535), we proposed that actors would be able to satisfy the exception through practices that implement either security policies and practices developed by the actor, or case-by-case determinations made by the actor. We proposed that whether a security-motivated practice meets this exception would be determined on a case-by-case basis using a fact-based analysis of the conditions set forth in the Proposed Rule.</P>
                    <P>
                        We emphasized (84 FR 7535) that the practices implemented by a single physician office with limited technology resources, for example, will be different to those implemented by a large health system, and that this difference does not affect an actor's ability to qualify for this exception. The fact-based approach that we proposed would allow each actor to implement policies, procedures, and technologies that are appropriate for its particular size, organizational structure, and risks to individuals' EHI. We noted that a fact-based analysis also aligns with the HIPAA Security Rule 
                        <SU>172</SU>
                        <FTREF/>
                         concerning the security of ePHI. The HIPAA Security Rule requires HIPAA covered entities or business associates to develop security practices and implement administrative, physical, and 
                        <PRTPAGE P="25860"/>
                        technical safeguards that take into account: The entity's size, complexity, and capabilities; technical, hardware, and software infrastructure; the costs of security measures; and the likelihood and possible impact of potential risks to ePHI.
                        <SU>173</SU>
                        <FTREF/>
                         We noted (84 FR 7535 and 7536), however, that while our proposed approach would be consistent with the regulation of security practices under the HIPAA Security Rule, the fact that a practice complies with the HIPAA Security Rule would not establish that it meets the conditions of the exception to the information blocking provision. We emphasized (84 FR 7536) that the HIPAA Security Rule and the proposed exception have different foci. The HIPAA Security Rule establishes a baseline by requiring certain entities to ensure the confidentiality, integrity, and availability of ePHI by implementing security measures, among other safeguards, that the entities determine are sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. In contrast, we explained that the purpose of the exception to the information blocking provision is to provide flexibility for reasonable and necessary security practices without excepting from the definition of information blocking in § 171.103 practices that purport to promote the security of EHI but that are unreasonably broad and onerous on those seeking access to EHI, not applied consistently across or within an organization, or otherwise may unreasonably interfere with access, exchange, or use of EHI.
                    </P>
                    <FTNT>
                        <P>
                            <SU>172</SU>
                             45 CFR 164.306, 308, 310, and 312.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>173</SU>
                             45 CFR 164.306(b)
                        </P>
                    </FTNT>
                    <P>To qualify for this exception, we proposed that an actor's conduct must satisfy threshold conditions. As discussed in detail in the Proposed Rule (84 FR 7535 through 7538), the particular security-related practice must be directly related to safeguarding the confidentiality, integrity, and availability of EHI, implemented consistently and in a non-discriminatory manner, and tailored to identified security risks (84 FR 7535). We also proposed (84 FR 7537) that where an actor has documented security policies that align with applicable consensus-based standards, and where the policies are implemented in a consistent and non-discriminatory manner, a practice's conformity with such policies would provide a degree of assurance that the practice was reasonable and necessary to address specific security risks and thus should not constitute information blocking. We also stated in the Proposed Rule (84 FR 7537) that we recognize that EHI security may present novel and unexpected threats that even a best-practice risk assessment and security policy cannot anticipate. We stated that if a practice that does not implement an organizational security policy is to qualify for this exception; however, it must meet certain conditions. The public comments received, our responses to these comments, and the conditions as finalized in § 171.203 are discussed below in this section of this final rule preamble.</P>
                    <P>We encouraged comment on these conditions (84 FR 7538), and our overall approach to the proposed exception, including whether our proposal provided adequate flexibility for actors to implement measures that are commensurate to the threats they face, the technology infrastructure they possess, and their overall security profiles and, equally important, whether this exception adequately mitigates the risk that actors will adopt security policies that are unnecessarily restrictive or engage in practices that unreasonably interfere with access, exchange, or use of EHI. Commenters were encouraged to propose additional conditions that may be necessary to ensure that the exception is tailored and does not extend protection to practices that are not reasonable and necessary to promote the security of EHI and that could present information blocking concerns. We also requested comment on whether the use of consensus-based standards and guidance provides an appropriate reference point for the development of security policies.</P>
                    <P>Finally, we asked commenters to offer an alternative basis for identifying practices that do not offer a security benefit (compared with available alternatives) but that cause an information blocking harm by interfering with access, exchange, or use of EHI (84 FR 7538).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments supporting, and did not receive any comments opposed to, the establishment of the Security Exception. We also received no comments offering an alternative basis for identifying practices that do not offer a security benefit (compared with other available alternatives) but that cause an information blocking harm by interfering with access, exchange, or use of EHI to a greater degree than necessary. We received a number of comments requesting additional guidance about how the exception's conditions can be met in practice. Commenters asked questions about, or recommended that we furnish additional guidance on how an actor might determine which a security practices meet the conditions in § 171.203 to qualify for the exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' feedback. We have finalized the exception in § 171.203, with some modification to the regulation text. We have changed the title of the exception from “Exception—Promoting the security of electronic health information” in the Proposed Rule (84 FR 7603) to “Security Exception—When will a practice likely to interfere with access, exchange, or use of electronic health information in order to protect the security of electronic health information not be considered information blocking?” Throughout this final rule preamble, we use “Security Exception” as a short form of this title, for ease of reference. As stated in Section VIII.D of this final rule preamble, we have changed the titles of all of the exceptions to questions to improve clarity. We have edited the wording of the introductory text of § 171.203 as finalized, in comparison to that proposed (84 FR 7603) so that it is consistent with the finalized title of § 171.203. We believe these conforming changes in wording of the introductory text also improve clarity of expression in this section.
                    </P>
                    <P>Comments on specific conditions are summarized below, in context of each condition proposed. We believe our responses to these comments furnish the clarity actors need to understand the conditions and of the exception finalized in § 171.203 for practices likely to interfere with access, exchange, or use of EHI in order to protect the security of EHI to be considered excepted from the definition of information blocking in § 171.103.</P>
                    <HD SOURCE="HD3">Condition: The Practice Must Be Directly Related to Safeguarding the Confidentiality, Integrity, and Availability of Electronic Health Information</HD>
                    <P>We proposed that, as a threshold condition, the exception would not apply to practices that are not directly related (84 FR 7536) to safeguarding the security of EHI. We explained that, in assessing the practice, we would consider whether and to what extent the practice directly addressed specific security risks or concerns. We noted that we would also consider whether the practice served any other purposes and, if so, whether those purposes were merely incidental to the overriding security purpose or provided an objectively distinct, non-security-related rationale for engaging in the practice.</P>
                    <P>
                        We noted (84 FR 7536) that it should not be particularly difficult or onerous for an actor to demonstrate that its 
                        <PRTPAGE P="25861"/>
                        practice was directly related to a specific security risk or concern. For example, we explained that the actor may show that the practice was a direct response to a known security incident or threat; or that the practice directly related to the need to verify a person's identity before granting access to EHI; or that the practice was directly related to ensuring the integrity of EHI.
                    </P>
                    <P>We emphasized (84 FR 7536) that the salient issue under this condition, therefore, would be whether the security practice was actually necessary and directly related to the specific security risk being addressed. To that end, we noted that we would consider the actor's purported basis for adopting the particular security practice, which could be evidenced by the actor's organizational security policy, risk assessments, and other relevant documentation, which most actors are already required to develop pursuant to requirements under the HIPAA Rules. However, we proposed that the documentation of an actor's decision making would not necessarily be dispositive. For example, we noted that if the practice had the practical effect of disadvantaging competitors or steering referrals, this could be evidence that the practice was not directly related and tailored to the specific security risk. We proposed that such an inference would also not be warranted where the actor has not met the other conditions of this exception, as where the actor's policies were not developed or implemented in a reasonable manner; its security policies or practices were not tailored to specific risks; or it applied its security policies or practices in an inconsistent or discriminatory manner.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a number of comments supporting the applicability of this exception to practices directly related to safeguarding the confidentiality, integrity, and availability of EHI and that are consistent with the HIPAA Security Rule. We received no comments recommending that this exception not be applicable to such practices.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized this condition as proposed. In order to meet this specific condition (finalized in § 171.203(a)), a practice must be directly related to safeguarding the confidentiality, integrity, and availability of EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concerns with what commenters described as the complexity of fact-based analysis and use of terms such as “directly related.” Commenters stated that analyzing their policies and practices against such standards could be burdensome, especially in the context of the requirement to meet all conditions at all relevant times.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         While fact-based analysis may not be as simple as determining if a particular security practice does or does not conform to a pre-specified approach, we believe that it is the most practical approach given the inherent complexity of the regulatory and threat landscapes relevant to an actor's cybersecurity practices. This landscape complexity contributes substantially to our belief that a one-size-fits-all detailed definition or test for security measures or methods to be deemed “directly related” to safeguarding the confidentiality, integrity, and availability of EHI would not be the optimal approach at this time. We have not established a specific, regulatory definition for “directly related” as we are using both “directly” and “related” in their ordinary meanings.
                        <SU>174</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>174</SU>
                             Ordinary meanings of the adverb “directly” and the adjective “related” in American usage can be found in widely published dictionaries, such as 
                            <E T="03">The American Heritage Dictionary of the English Language, Dictionary.com,</E>
                             or 
                            <E T="03">Merriam-Webster.com.</E>
                        </P>
                    </FTNT>
                    <P>With respect to the condition that a practice meet all conditions in § 171.203 at all relevant times in order to satisfy the exception, we do not believe it would be particularly difficult, in context of a fact-specific analysis, for an actor to demonstrate that its practice was directly related to a specific security risk or concern. For example, the actor may show that the practice was a direct response to a known security incident or threat, or that the practice was directly related to the need to verify a person's identity before granting access to EHI. We also note that, although we encourage actors to voluntarily conform their practices to the conditions of an exception suited to the practice and its purpose, an actor's choice to do so simply provides it an enhanced level of assurance that the practices do not meet the definition of information blocking. Failure to meet an exception does not necessarily mean a practice meets the definition of information blocking. If subject to an investigation by HHS, each practice that implicates the information blocking provision and that does not meet any exception would be analyzed on a case-by-case basis.</P>
                    <P>
                        The overarching purpose of the Security Exception is to provide flexibility for reasonable and necessary security practices while screening out practices that purport to promote the security of EHI but that otherwise unreasonably and/or unnecessarily interfere with access, exchange, and use of EHI. Confidentiality, integrity and availability, also known as the CIA triad, is a model designed to guide policies for information security practices within an organization. The elements of the triad are considered the three most crucial components of information security practices.
                        <SU>175</SU>
                        <FTREF/>
                         In assessing whether a practice meets the condition finalized in § 171.203(a), the information that we would expect to consider includes, but is not necessarily limited to, the actor's purported basis for adopting the particular security practice, which could be evidenced by the actor's organizational security policy, risks assessments the actor had performed that informed the actor's security-based practice(s), and other relevant documentation that an actor maintains. We also reiterate our observation that many actors are also HIPAA covered entities or business associates. For that reason, many actors are likely to have, pursuant to their meeting the requirements of the HIPAA Security Rule, documentation relevant to showing their security-based practice(s) satisfy the Security Exception condition that is finalized in § 171.203(a).
                        <SU>176</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>175</SU>
                             
                            <E T="03">See</E>
                             NIST Special Publication 800-12, revision 1, An Introduction to Information Security.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>176</SU>
                             45 CFR 164.316
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Condition: The Practice Must Be Tailored to the Specific Security Risk Being Addressed</HD>
                    <P>To meet the exception, we proposed (84 FR 7536) that an actor's security-related practice must be tailored to specific security risks that the practice actually addressed. We explained that this condition necessarily presupposes that an actor has carefully evaluated the risk posed by the security threat and developed a considered response that is tailored to mitigating the vulnerabilities of the actor's health IT or other related systems.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed concerns with what commenters described as the complexity of fact-based analysis and use of terms such as “tailored.” Commenters stated that analyzing their policies and practices against such standards could be burdensome, especially in context of the requirement to meet all conditions at all relevant times.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         While fact-specific analysis may not be as simple as determining if a particular security practice does or does not conform to a pre-specified approach, we believe that it is the most practical approach given the inherent complexity of the regulatory and threat landscapes relevant to an actor's cybersecurity practices. This landscape 
                        <PRTPAGE P="25862"/>
                        complexity contributes substantially to our belief that a one-size-fits-all definition or test for security measures or methods to be deemed conformant with the condition finalized in § 171.203(b) would not be the optimal approach at this time. Instead, we have finalized the condition proposed in § 171.201(b) as proposed. We believe requiring that the actor's policies and practices be tailored to the risk being addressed is currently the most appropriate and practical approach. We intend for this exception to be applicable to a wide array of practices that are reasonable and necessary to protect the security of EHI in various actors' specific operational contexts. In assessing whether a practice meets the condition finalized in § 171.203(b), we would consider whether and to what extent the practice directly addresses specific security risks or concerns and whether it was tailored to those risks. We would also consider whether the practice served any other purposes and if so, whether those purposes were merely incidental to an overriding security purpose or provided an objectively distinct, non-security related rationale for engaging in the practice. We also believe the ordinary meaning of “tailored” 
                        <SU>177</SU>
                        <FTREF/>
                         provides sufficient clarity that we expect the practices to be made or adapted to serve the particular purpose or need for which they are deployed. With respect to the requirement that a practice meet all conditions in § 171.203 at all relevant times in order to satisfy the exception, we do not believe it would be particularly difficult, in context of a fact-specific analysis, for an actor to demonstrate that each practice was made or adapted to serve the particular purpose or need for which is was deployed. For example, where a practice meets the condition finalized in § 171.203(a) by being a direct response to a known security incident or threat, it logically follows that the practice should also be made or adapted to the purpose of responding to such incident or threat. In which case, the practice's inherent characteristics would support the actor's ability to show that it meets the condition finalized in § 171.203(b). Similarly, where an identity-proofing practice satisfies the condition finalized in § 171.203(b) by being directly related to the need to verify a person's identity before granting access to EHI, it would be logical to expect the practice would also be tailored to address that need.
                    </P>
                    <FTNT>
                        <P>
                            <SU>177</SU>
                             
                            <E T="03">See, e.g.,</E>
                             sense 1.b. of the entry for the verb “tailor” in the Merriam-Webster dictionary: “to make or adapt to suit a special need or purpose” (
                            <E T="03">https://merriam-webster.com/dictionary/tailor</E>
                            , last accessed Feb. 6, 2020). 
                            <E T="03">See also, e.g.,</E>
                             sense 3 of the entry for the verb “tailor” in The American Heritage Dictionary of the English Language: “to make, alter, or adapt for a particular end or purpose” (
                            <E T="03">https://ahdictionary.com</E>
                            , last accessed Feb 6, 2020).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters recommended that actors should be permitted to develop and implement security policies that exceed the minimum requirements of HIPAA with the intent to promote data security or to comply with State law or policies.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         If its conditions are otherwise met, this exception would apply to security-based practices that exceed the minimum conditions of the HIPAA Security Rule. As would be the case with a practice implemented to comply with the HIPAA Security Rule requirements, the fact that a practice was implemented to meet another applicable legal mandate would be considered in assessing whether a practice meets this exception. However, a practice that is consistent with a law or regulation setting a minimum requirement for protecting confidentiality, integrity, and availability of EHI might not meet this exception. For example, a practice that is consistent with a minimum legal condition related to the security of EHI might not meet this exception if it is not also tailored to avoid interfering with the access, exchange, or use of EHI to a greater extent than reasonable and necessary to appropriately mitigate the risk it addresses.
                    </P>
                    <P>We have finalized this condition in § 171.203(b) without modification to the text of this condition as proposed (84 FR 7603).</P>
                    <HD SOURCE="HD3">Condition: The Practice Must Be Implemented in a Consistent and Non-Discriminatory Manner</HD>
                    <P>We proposed (84 FR 7536 and 7537) that in order for a practice to qualify for this exception, the actor's practice must have been implemented in a consistent and non-discriminatory manner. We explained that this condition would provide basic assurance that the purported security practice is directly related to a specific security risk and is not being used to interfere with access, exchange, or use of EHI for other purposes to which this exception does not apply.</P>
                    <P>
                        As an illustration solely of the non-discriminatory manner condition (84 FR 7536 and 7537), we discussed a hypothetical example of a health IT developer of certified health IT that offers apps to its customers via an app marketplace. We stated that if the developer requires that third-party apps sold (or made available) via the developer's app marketplace meet certain security requirements, those security requirements must be imposed in a non-discriminatory manner. We noted that this would mean, for example, that if a developer imposed a requirement that third-party apps include two-factor authentication for patient access, the developer would need to ensure that the same requirement was imposed on, and met by, all other apps, including any apps made available by the developer itself. We also noted that such a developer requirement must also meet the other conditions of the exception (
                        <E T="03">e.g.,</E>
                         the condition that the practice be tailored to the specific security risk being addressed).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments opposed to the condition that practices must be implemented in a consistent and non-discriminatory manner. We did receive one comment recommending that we recognize under this exception risk-based cybersecurity practices that may result in applying different security requirements to different exchange partners based on risk posed.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We intend this exception, including but not limited to this specific condition, to allow for recognition of risk-based security practices. Assessment of whether practices satisfy the conditions of this exception will be fact-based. We also recognize that objectively reasonable practices applied on the basis of the cybersecurity risks posed by particular system connections or data exchanges may result in practices that are tailored to this risk and thus not necessarily identical across all connections, interchanges, and therefore all individuals or entities with whom an actor engages. In context of this condition of the Security Exception, “consistent and non-discriminatory” should be understood to mean that similarly situated actors whose interactions pose the same level of security risk should be treated consistently with one another under the actor's security practices. Inconsistent treatment across similarly situated actors whose interactions pose the same level of security risk based on extraneous factors, such as whether they are a competitor of the actor implementing the security practices, would not be considered appropriate.
                    </P>
                    <P>We have finalized this condition as proposed. It is codified in § 171.203(c).</P>
                    <HD SOURCE="HD3">Condition Applicable to Practices That Implement an Organizational Security Policy</HD>
                    <P>
                        We discussed in the Proposed Rule (84 FR 7537) that an actor's approach to information security management would reflect the actor's particular size, organizational structure, and risk 
                        <PRTPAGE P="25863"/>
                        posture. Because of this, we emphasized that actors should develop and implement organizational policies that secure EHI. We proposed that, where an actor has documented security policies that align with applicable consensus-based standards, and where the policies are implemented in a consistent and non-discriminatory manner, a practice's conformity with such policies would provide a degree of assurance that the practice was reasonable and necessary to address specific security risks and thus should not constitute information blocking.
                    </P>
                    <P>
                        We stated (84 FR 7537) that a practice that went beyond an actor's established policies or procedures by imposing security controls that were not documented would not qualify for this exception 
                        <E T="03">under this condition</E>
                         (although the actor may be able to qualify under the alternative basis for practices that do not implement a security policy). We further stated that such practices would be suspect under the information blocking provision 
                        <E T="03">if</E>
                         there were indications that the actor's security-related justification was a pretext or after-the-fact rationalization for its conduct or was otherwise unreasonable under the circumstances.
                    </P>
                    <P>We reiterated (84 FR 7537) that, to the extent that an actor seeks to justify a practice on the basis of its organizational security policies, such policies must be in writing and implemented in a consistent and non-discriminatory manner. We emphasized that what a policy requires will depend on the facts and circumstances. However, we proposed that to support a presumption that a practice conducted pursuant to the actor's security policy was reasonable, the policy would have to meet conditions stated and discussed in Section VIII.D.3 of the Proposed Rule (84 FR 7537). The details within paragraph (d) of § 171.203 were proposed in regulation text (84 FR 7603). The detailed requirements of the condition as proposed in § 171.203(d) were: If the practice implements an organizational security policy the policy must—</P>
                    <P>• Be in writing;</P>
                    <P>• Have been prepared on the basis of, and directly respond to, security risks identified and assessed by or on behalf of the actor;</P>
                    <P>• Align with one or more applicable consensus-based standards or best practice guidance; and</P>
                    <P>• Provide objective timeframes and other parameters for identifying, responding to, and addressing security incidents.</P>
                    <P>We discuss each of these requirements (subparagraphs) within the condition applicable to practices that implement an organizational security policy (§ 171.203(d)) in more detail below.</P>
                    <HD SOURCE="HD3">Paragraph (d)(1): Security Policy in Writing</HD>
                    <P>
                        We proposed that the actor's security policy must be in writing (84 FR 7537). This requirement is applicable to practices that implement an organizational security policy and is consistent with the HIPAA Security Rule.
                        <SU>178</SU>
                        <FTREF/>
                         The importance of written security policies is also consistent with consensus-based standard and best practice guidance.
                        <SU>179</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>178</SU>
                             45 CFR 164.316
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>179</SU>
                             
                            <E T="03">See</E>
                             SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments opposed to this condition proposed in § 171.203(d).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Within the condition (§ 171.203(d)) applicable to practices that implement an organizational security policy, we have finalized in § 171.203(d)(1) the requirement that the policy must be in writing. We have finalized this condition as proposed.
                    </P>
                    <HD SOURCE="HD3">Paragraph (d)(2): Security Risks Identified and Assessed</HD>
                    <P>
                        We proposed (84 FR 7537) that the actor's security policy must be informed by an assessment of the security risks facing the actor. While we did not propose any requirements as to a risk assessment, we noted that a good risk assessment would use an approach consistent with industry standards,
                        <SU>180</SU>
                        <FTREF/>
                         and would incorporate elements such as threat and vulnerability analysis, data collection, assessment of current security measures, likelihood of occurrence, impact, level of risk, and final reporting.
                        <SU>181</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>180</SU>
                             See OCR, Guidance on Risk Analysis, 
                            <E T="03">https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html?language=es</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>181</SU>
                             ONC and OCR have jointly launched the HHS HIPAA Security Risk Assessment (SRA) Tool, 
                            <E T="03">https://www.healthit.gov/providers-professionals/security-risk-assessment-tool</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments opposed to requiring a linkage between an organization's security policy and a risk assessment. We did receive a couple of comments expressing a concern that not all actors may yet be proficient in identifying and assessing the risks associated with specific health IT functionalities, such as standards-based APIs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Within the condition (§ 171.203(d)) applicable to practices that implement an organizational security policy, we have finalized § 171.203(d)(2) with a revision to the wording of the regulation text in comparison with that proposed (84 FR 7603). Specifically, we have replaced “and respond directly to” that appeared in the regulation text with “and be directly responsive to” in the text finalized in § 171.203(d)(2). Thus, the finalized text in § 171.203(d)(2) reads: “have been prepared on the basis of, and be directly responsive to, security risks identified and assessed by or on behalf of the actor.”
                    </P>
                    <P>We made this editorial revision because we believe it makes the resulting regulation text easier to read. Although actors may have obligations under other existing law or regulations, such as the HIPAA Security Rule, to conduct security risk assessments, this condition, which is applicable to security-based practices that implement an organizational security policy, does not establish a set threshold for an actor's proficiency in identifying, assessing, and responding to security risks. If any actor believes it may lack the technical or other expertise necessary to conduct a risk assessment appropriate to its operations and the EHI for which it is responsible, we would encourage that actor to seek additional information, training, or support from an individual or entity with the required expertise. As finalized in § 171.203(d)(2), the requirement that risks have been identified and assessed expressly provides for this to have been done either by the actor or on the actor's behalf. We are sensitive to the possibility that some actors, including but not limited to small clinician practices, may not be in a position to meet the condition finalized in paragraph (d) of § 171.203 immediately or for all of their security-based practices, and we therefore reiterate that we have finalized in § 171.203(e) an alternative condition that an actor may choose to meet in circumstances where it may not be practical for them to meet the condition finalized in § 171.203(d).</P>
                    <P>
                        We also reiterate that, while we do encourage actors to voluntarily conform their practices to the conditions of an exception suited to the practice and its purpose, an actor's choice to do so simply provides them an enhanced level of assurance that the practices do not meet the definition of information blocking. Failure to meet an exception does not necessarily mean a practice meets the definition of information blocking. If subject to an investigation by HHS, each practice that implicates the information blocking provision and that does not meet any exception would be analyzed on a case-by-case basis.
                        <PRTPAGE P="25864"/>
                    </P>
                    <HD SOURCE="HD3">Paragraph (d)(3): Consensus-Based Standards or Best Practice Guidance</HD>
                    <P>We proposed (84 FR 7537) that the actor's policy must align with one or more applicable consensus-based standards or best practice guidance. We noted that at present, examples of relevant best practices for development of security policies include, but are not limited to: NIST-800-53 Rev. 5; the NIST Cybersecurity Framework; and NIST SP 800-100, SP 800-37 Rev. 2, SP 800-39, as updated and as interpreted through formal guidance. We noted that best practice guidance on security policies is also developed by consensus standards bodies such as ISO, IETF, or IEC. We stated that HIPAA covered entities and business associates may be able to leverage their HIPAA Security Rule compliance activities and can, if they choose, align their security policy with those parts of the NIST Cybersecurity Framework that are referenced in the HIPAA Security Rule Crosswalk to NIST Cybersecurity Framework to satisfy this condition. We noted that relevant consensus-based standards and frameworks provide actors of varying sizes and resources with the flexibility needed to apply the right security controls to the right information systems at the right time to adequately address risk.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed a concern that a small independent clinician practice that conducts a risk analysis consistent with its obligation under the HIPAA Security Rule may lack the technical expertise or other organizational capabilities needed to develop a customized security policy that appropriately applies consensus-based standards to each risk identified. This commenter recommended that we incorporate in § 171.203(d) regulation text a statement that these conditions apply “subject to the actor's sophistication and technical capabilities.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the point highlighted by the commenter that, even within a given type of actor, specific individuals or organizations may have different operational contexts that include variations in their technical capabilities, expertise, and other resources. We do not, however, believe it is necessary to revise the regulation text as recommended in order to allow for assessment of whether the actor's practices, such as its organizational security policy, were objectively reasonable in the circumstances in which they were implemented.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A number of commenters requested that this exception allow providers to be proactive when promoting the security of EHI rather than taking a reactive stance. Commenters contended that for novel threats, consensus-based standards and best practice guidance may not exist, making it impossible for an actor to meet the condition that the organizational security policy align with such standards.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         With cybersecurity risk continuously evolving and the large number of threat sources active in the modern cybersecurity landscape, we recognize that actors must continuously monitor, assess, and respond to security risks that can themselves represent an impediment to EHI access, exchange, and use. Thus, this exception allows actors flexibility in selecting and tailoring their practices to mitigate specific security risks, provided each such practice otherwise meets the conditions of this exception, notably including that it be directly related and tailored to the specific security risk being addressed and be implemented in a consistent and non-discriminatory manner. We also note that best security practices in security mitigation can take a proactive as well as a reactive approach. A documented policy that provides explicit references to consensus-based standards and best practice guidance (such as the NIST Cybersecurity Framework) offers an objective and robust means by which we can evaluate the reasonableness of a particular security control for the purpose of the exception. We also recognize that, as a practical matter, some actors (such as small health care providers or those with limited resources) may have organizational security policies that are less robust or that otherwise fall short of the minimum conditions proposed. In such circumstances an actor can still benefit from this exception by demonstrating that the practice met the conditions of this exception for circumstances where no formal (organizational) security policy was implemented (see our discussion under “
                        <E T="03">conditions applicable to practices that do not implement an organizational security policy”</E>
                         header, below within this section of this final rule preamble).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter noted that it could be a difficult for an actor to meet the standard to that the actor's organizational policy on security must align with one or more consensus-based standards or best practice guidance because there are many emerging security threats that occur that are new and unexpected.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not believe that it would be difficult for an actor's organizational policy on security to align with one or more consensus-based standards or best practice guidance documents. An actor's written security policies should be based on consensus-based standards or best practice guidance documents which specifically address security risks and threats. A security policy should be clearly written and observed and refers to clear, comprehensive, and well-defined plans, rules, and practices that regulate access to an actor's information systems and the EHI included in it. We believe a good policy serves as a prominent statement to the outside world about the actor's commitment to security, and that such a policy should be based on objective consensus-based standards and should not be ad hoc or arbitrary.
                    </P>
                    <P>We do agree that there are emerging and novel security threats that occur, and in those situations which are not specifically addressed by an actor's security policies, we included in the exception as proposed an alternative condition (proposed in § 171.203(e)) to address those situations in which those security risks can be addressed based on particularized facts and circumstances.</P>
                    <P>Within the condition (§ 171.203(d)) applicable to practices that implement an organizational security policy, the actor's policy must align with one or more applicable consensus-based standards or best practice guidance. The finalized condition is codified in § 171.203(d)(3).</P>
                    <HD SOURCE="HD3">Paragraph (d)(4): Objective Timeframes and Other Parameters</HD>
                    <P>
                        We proposed that the actor's security policy must provide objective timeframes and common terminology used for identifying, responding to, and addressing security incidents. We noted examples of acceptable sources for development of a security response plan include: NIST Incident Response Procedure (
                        <E T="03">https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final</E>
                        ), US-CERT for interactions with government systems (
                        <E T="03">https://www.us-cert.gov/government-users/reporting-requirements</E>
                        ), and ISC-CERT for critical infrastructure (
                        <E T="03">https://ics-cert.us-cert.gov/</E>
                        ) (84 FR 7537).
                    </P>
                    <P>
                        As a point of clarification, we noted that an actor's compliance with the HIPAA Security Rule (if applicable to the actor) would be relevant to, but not dispositive of, whether the actor's policies and procedures were objectively reasonable for the purpose of the exception. We explained that an actor's documentation of its security policies and procedures for compliance with the HIPAA Security Rule may not offer a sufficient basis to evaluate whether the actor's security practices 
                        <PRTPAGE P="25865"/>
                        unnecessarily interfere with access, exchange, or use of EHI. We further noted that a documented policy that provides explicit references to consensus-based standards and best practice guidance (such as the NIST Cybersecurity Framework) would offer an objective and robust means by which to evaluate the reasonableness of a particular security control for the purpose of the exception (84 FR 7537).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received no comments opposing this requirement of the condition applicable to practices that implement an organizational security policy.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Within the condition (§ 171.203(d)) applicable to practices that implement an organizational security policy, we have finalized in § 171.203(d)(4) the condition that the actor's organizational security policy “provide objective timeframes and other parameters for identifying, responding to, and addressing security incidents.” We have finalized this condition as proposed.
                    </P>
                    <HD SOURCE="HD3">Condition Applicable to Practices That Do Not Implement an Organizational Security Policy</HD>
                    <P>In the Proposed Rule (84 FR 7537), we recognized that, as a practical matter, some actors (such as small health care providers or those with limited resources) may have organizational security policies that are less robust or that otherwise fall short of the minimum conditions proposed. We proposed that in these circumstances an actor could still benefit from the exception by demonstrating that the practice at issue was objectively reasonable under the circumstances, without regard to a formal policy. While we noted in the Proposed Rule (84 FR 7537) that we expect that most security practices engaged in by an actor will implement an organizational policy, we recognized that EHI security may present novel and unexpected threats that even a best-practice risk assessment and security policy cannot anticipate. We noted that if a practice that does not implement an organizational policy is to qualify for this exception, however, it must meet certain conditions. We stated that the actor's practice must, based on the particularized facts and circumstances, be necessary to mitigate the security risk. Importantly, we proposed that the actor would have to demonstrate that it considered reasonable and appropriate alternatives that could have reduced the likelihood of interference with access, exchange, or use of EHI and that there were no reasonable and appropriate alternatives that were less likely to interfere with access, exchange or use of EHI.</P>
                    <P>We noted (84 FR 7538) that an actor's consideration of reasonable and appropriate alternatives will depend on the urgency and nature of the security threat in question. We further noted that we anticipate that an actor's qualification for the exception would accommodate exigent circumstances. For example, we stated that we would not expect an actor to delay the implementation of a security practice in response to an emergency on the basis that it has not yet been able to initiate a fully realized risk assessment process. However, we also stated that we would expect that in these exigent circumstances, where the actor has implemented a security practice without first considering whether there were reasonable and appropriate alternatives that were less likely to interfere with access, exchange or use of EHI, the actor would expeditiously make any necessary changes to the practice based on the actor's re-consideration of reasonable and appropriate alternatives that are less likely to interfere with access, exchange or use of EHI. We proposed that the exception would apply in these instances so long as an actor takes these steps and complies with all other applicable conditions.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters stated that the absence of a policy means that one is dealing with an unexpected and evolving situation as best one can (
                        <E T="03">e.g.,</E>
                         a sustained and sophisticated attack). Commenters suggested we create a further “safety valve” for short-lived actions that are taken in good faith while a situation is being evaluated and understood and that we should recognize the valid need to allow for due diligence as distinct from simply delaying access and such due diligence should not need the Security Exception to avoid implicating or being judged as engaged in information blocking. Commenters stated this is a core need for small medical practices with limited resources.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We anticipate that the exception's conditions as proposed and finalized would accommodate exigent circumstances. For example, we would not expect an actor to delay the implementation of a security measure in response to an emergency such as a cyberattack simply because it has not yet been able to implement a fully realized risk assessment process. We believe the exception as posed does provide a “safety valve” for situations where an actor in direct response to exigent circumstances may have implemented in good faith a security practice without first considering whether there were reasonable and appropriate alternatives that were less likely to interfere with access, exchange, or use of EHI, but where the initial-response practice may be in place for only a short while. Presumably, such initial-response practices are in place for only a short time precisely because, upon more fully identifying and assessing current risks in context or as follow-up to the exigent circumstances, the actor will have concluded it carried a greater than necessary burden—including the burden of interference with access, exchange or use of EHI—and consequently modified or replaced its initial-response practice with a less onerous alternative that was reasonable and appropriately tailored to the specific risk addressed.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter agreed that this exception allows for an actor to maintain flexibility in its approach to address security incidents or threats.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree that this exception provides an actor the flexibility to address security incidents or threats based on particularized facts and circumstances which are necessary to mitigate the security risk to EHI, provided that there are no reasonable and appropriate alternatives to the practice that address the security risk that are less likely to interfere with, prevent, or materially discourage access, exchange or use of EHI.
                    </P>
                    <P>We have finalized as proposed, in § 171.203(e), the requirements applicable to practices that meet the threshold conditions established in §§ 171.203(a), (b) and (c) and that do not implement an organizational security policy.</P>
                    <P>d. 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?</P>
                    <P>
                        We proposed in the Proposed Rule in § 171.205 (84 FR 7542 and 7603) to establish an exception to the information blocking provision that would permit an actor to decline to provide access, exchange, or use of EHI in a manner that is infeasible, provided certain conditions are met. We proposed that in certain circumstances legitimate practical challenges beyond an actor's control may limit its ability to comply with requests for access, exchange, or use of EHI. In some cases, the actor may not have—and may be unable to obtain—the requisite technological capabilities, legal rights, financial resources, or other means necessary to provide a particular form of access, exchange, or use. In other cases, the actor may be able to comply with the 
                        <PRTPAGE P="25866"/>
                        request, but only by incurring costs or other burdens that are clearly unreasonable under the circumstances (84 FR 7542).
                    </P>
                    <P>We proposed that the exception would permit an actor to decline a request in certain narrowly-defined circumstances when doing so would be infeasible (or impossible) and when the actor otherwise did all that it reasonably could do under the circumstances to facilitate alternative means of accessing, exchanging, and using the EHI. We proposed a structured, fact-based approach for determining whether a request was “infeasible” within the meaning of the exception. We noted that this approach would be limited to a consideration of factors specifically delineated in the exception and that the infeasibility inquiry would focus on the immediate and direct financial and operational challenges of facilitating access, exchange, and use, as distinguished from more remote, indirect, or speculative types of injuries (84 FR 7542).</P>
                    <P>We encouraged comment on these and other aspects of this proposal (84 FR 7542).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments in general support of the proposed exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of our proposal. We note that we have changed the title of this exception from “Exception—Responding to requests that are infeasible” (84 FR 7603) to “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?” Throughout this final rule preamble, we use “Infeasibility Exception” as a short form of this title, for ease of reference. As stated in Section VIII.D of this final rule preamble, we have changed the titles of all of the exceptions to questions to improve clarity. We have also edited the wording of the introductory text in § 171.204 as finalized, in comparison to that proposed (84 FR 7603 and 7604), so that it is consistent with the finalized title of § 171.204. We believe these conforming changes in wording of the introductory text also improve clarity in this section.
                    </P>
                    <HD SOURCE="HD3">i. Infeasibility of the Request</HD>
                    <P>To qualify for the exception, we proposed that compliance with the request for access, exchange, or use of EHI must be infeasible. We proposed a two-step test that an actor would need to meet in order to demonstrate that a request was infeasible. Under the first step of the infeasibility test, we proposed that the actor would need to show that complying with the particular request in the manner requested would impose a substantial burden on the actor. Second, we proposed that the actor must also demonstrate that requiring it to comply with the request—and thus to assume the substantial burden demonstrated under the first part of the test—would have been plainly unreasonable under the circumstances (84 FR 7542 and 7543). We proposed that whether it would have been plainly unreasonable for the actor to assume the burden of providing access, exchange, or use will be highly dependent on the particular facts and circumstances. We proposed to rely primarily on the following key factors enumerated in proposed § 171.205(a)(1):</P>
                    <P>• The type of EHI and the purposes for which it may be needed;</P>
                    <P>• The cost to the actor of complying with the request in the manner requested;</P>
                    <P>• The financial, technical, and other resources available to the actor;</P>
                    <P>• Whether the actor provides comparable access, exchange, or use to itself or to its customers, suppliers, partners, and other persons with whom it has a business relationship;</P>
                    <P>• Whether the actor owns or has control over a predominant technology, platform, health information exchange, or health information network through which EHI is accessed or exchanged;</P>
                    <P>• Whether the actor maintains ePHI on behalf of a covered entity, as defined in 45 CFR 160.103, or maintains EHI on behalf of the requestor or another person whose access, exchange, or use of EHI will be enabled or facilitated by the actor's compliance with the request;</P>
                    <P>• Whether the requestor and other relevant persons can reasonably access, exchange, or use the information from other sources or through other means; and</P>
                    <P>• The additional cost and burden to the requestor and other relevant persons of relying on alternative means of access, exchange, or use (84 FR 7543).</P>
                    <P>We acknowledged in the Proposed Rule that there may be situations when complying with a request for access, exchange, or use of EHI would be considered infeasible because an actor is unable to provide such access, exchange, or use due to unforeseeable or unavoidable circumstances that are outside the actor's control. As examples, we stated that an actor could seek coverage under this exception if it is unable to provide access, exchange, or use of EHI due to a natural disaster (such as a hurricane, tornado or earthquake) or war. We emphasized that, consistent with the requirements for demonstrating that practices meet all the conditions of a proposed exception, the actor would need to produce evidence and ultimately prove that complying with the request for access, exchange, or use of EHI in the manner requested would have imposed a clearly unreasonable burden on the actor under the circumstances (84 FR 7543 and 7544).</P>
                    <P>We stated that certain circumstances would not constitute a burden to the actor for purposes of this exception and would not be considered in determining whether complying with a request would have been infeasible. We proposed that it would not be considered a burden if providing the requested access, exchange, or use of EHI in the manner requested would have (1) facilitated competition with the actor; or (2) prevented the actor from charging a fee (84 FR 7544).</P>
                    <P>We requested comment on the proposed approach for determining whether a request is “infeasible” within the meaning of the exception. We encouraged comment on, among other issues, whether the factors we specifically delineated properly focus the infeasibility inquiry; whether our approach to weighing these factors is appropriate; and whether there are additional burdens, distinct from the immediate and direct financial and operational challenges, that are similarly concrete and should be considered under the fact-based rubric of the exception (84 FR 7544).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments in support of our proposed approach for determining whether a request was “infeasible.” We also received several comments that expressed various concerns and suggestions for improvement regarding our proposals. Several commenters expressed concern that the language in the proposed exception, particularly regarding the “infeasibility” of a request, was too vague or ambiguous and that the inclusion of undefined terms could create uncertainty for actors regarding whether they meet the conditions under the exception. Commenters noted that such uncertainty could dissuade actors from taking advantage of the exception. Commenters requested additional examples and guidance to clarify the conditions under the exception.
                    </P>
                    <P>
                        A few commenters questioned whether it would be considered information blocking if they could not segment EHI to respond to a request for a patient's EHI (
                        <E T="03">e.g.,</E>
                         when patient consent to share EHI subject to 42 CFR part 2 or a State privacy law has not been provided). These commenters 
                        <PRTPAGE P="25867"/>
                        expressed concern about the ability of their technology to segment a patient's EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of our proposed approach for determining whether a request is “infeasible,” as well as the constructive feedback. We agree with commenters that each exception should clearly explain the conduct that would and would not be covered by each exception. We also reiterate that failure to meet the exception does not mean that an actor's practice related to infeasible requests necessarily meets the information blocking definition. However, as we noted in the Proposed Rule, the broad definition of information blocking in the Cures Act means that any practice that is likely to interfere with the access, exchange, or use of EHI implicates the information blocking provision. As a result, practices that do not meet the exception will have to be assessed on a case-by-case basis to determine, for example, the actor's intent and whether the practice rises to the level of an interference.
                    </P>
                    <P>
                        We have restructured this exception to provide further clarity. Toward that end, we have eliminated the proposed two-step test that an actor would need to meet in order to demonstrate that a request is infeasible (84 FR 7542 and 7543). Instead, we have finalized a revised framework for this exception that provides two new conditions that must be met in order for an actor to be covered by the exception and a revised condition that provides an exception for those actors unable to meet the new Content and Manner Exception. When the practice by an actor meets 
                        <E T="03">one</E>
                         of the conditions in § 171.204(a) and the actor meets the requirements for responding to requests in § 171.204(b) (which are discussed in more detail below), the actor is not required to fulfill a request for access, exchange, or use of EHI due to the infeasibility of the request.
                    </P>
                    <P>The first new condition is that the actor cannot fulfill the request for access, exchange, or use of EHI due to events beyond the actor's control, namely a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority (§ 171.204(a)(1)). This is consistent with our statements in the Proposed Rule describing events that an actor could seek coverage for under this exception if it is was unable to provide access, exchange, or use of EHI due to events beyond its control (84 FR 7543). This new condition makes clear that such events are all that are necessary to meet this exception and no consideration of factors must be demonstrated and proven.</P>
                    <P>
                        The second new condition is that the actor is not required to fulfill a request for access, exchange, or use of EHI if the actor cannot unambiguously segment the requested EHI from other EHI: (1) Because of a patient's preference or because the EHI cannot be made available by law; or (2) because the EHI is withheld in accordance with the Harm Exception in § 171.201 (§ 171.204(a)(2)). For instance, an actor will be covered under this condition if the actor could not fulfill a request to access, exchange, or use EHI because the requested EHI could not be unambiguously segmented from patient records created by federally assisted programs (
                        <E T="03">i.e.,</E>
                         Part 2 Programs) for the treatment of substance use disorder (and covered by 42 CFR part 2) or from records that the patient has expressed a preference not to disclose.
                    </P>
                    <P>The revised condition in § 171.204(a)(3)(i) specifically aligns with our proposal (84 FR 7543) in that an actor would not be required to fulfill a request for access, exchange, or use of EHI if the actor demonstrates, through contemporaneous written record or other documentation, its consideration of the following factors in a consistent and non-discriminatory manner, prior to responding to the request pursuant to paragraph (b) of this section, that led to its determination that complying with the request would be infeasible under the circumstances:</P>
                    <P>• The type of EHI and the purposes for which it may be needed;</P>
                    <P>• The cost to the actor of complying with the request in the manner requested;</P>
                    <P>• The financial and technical resources available to the actor;</P>
                    <P>• Whether the actor's practice is non-discriminatory and the actor provides the same access, exchange, or use of EHI to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship;</P>
                    <P>• Whether the actor owns or has control over a predominant technology, platform, health information exchange, or health information network through which electronic health information is accessed or exchanged; and</P>
                    <P>• Why the actor was unable to provide access, exchange, or use of EHI consistent with the Content and Manner Exception in § 171.301.</P>
                    <P>We note that the above provisions align with our proposal in the Proposed Rule that the actor must provide the requestor with a detailed written explanation of the reasons why the actor cannot accommodate the request (84 FR 7544). The difference in the final language is that we have not specified the level of detail required in the written record or other documentation, and have clarified that such a written record or other documentation must be contemporaneous so that an actor cannot use a post hoc rationalization for claiming the request was infeasible under circumstances that were not considered at the time the request was received.</P>
                    <P>
                        We proposed in the Proposed Rule (84 FR 7544) and have finalized in this final rule in § 171.204(a)(3)(ii) the following factors that may 
                        <E T="03">not</E>
                         be considered in the determination: (1) Whether the manner requested would have facilitated competition with the actor; and (2) whether the manner requested prevented the actor from charging a fee or resulted in a reduced fee. We note that we have clarified in the final rule that charging “a” fee includes a reduced fee as well. Our rationale for carving out these considerations is that the purpose of the Infeasibility Exception is to provide coverage to actors who face 
                        <E T="03">legitimate practical challenges beyond their control</E>
                         that limit their ability to comply with requests to access, exchange, or use EHI. We do not believe that whether the manner requested would have facilitated competition with the actor or prevented the actor from charging a fee or resulted in a reduced fee qualify as the type of legitimate practical challenges beyond the actor's control that should be covered by the exception. Regarding the consideration of fees, the actor is able to charge fees for costs reasonably incurred, with a reasonable profit margin, for accessing, exchanging, or using EHI under the Fees Exception in § 171.302.
                    </P>
                    <P>We have finalized in § 171.204(a)(3)(i)(F) the criterion that considers an actor's ability to provide access, exchange, and use of EHI consistent with the Content and Manner Exception in § 171.301 in order to assure alignment of this exception with the Content and Manner Exception. We further discuss the Content and Manner Exception in section VIII.D.2.a of this final rule.</P>
                    <P>
                        We did not finalize three factors that were proposed in the context of the infeasibility analysis: (1) Whether the actor maintains electronic protected health information on behalf of a covered entity, as defined in 45 CFR 160.103, or maintains electronic health information on behalf of the requestor or another person whose access, exchange, or use of electronic health information will be enabled or facilitated by the 
                        <PRTPAGE P="25868"/>
                        actor's compliance with the request; (2) whether the requestor and other relevant persons can reasonably access, exchange, or use the electronic health information from other sources or through other means; and (3) the additional cost and burden to the requestor and other relevant persons of relying on alternative means of access, exchange, or use (see the proposed factors at 84 FR 7543). We removed the first factor because it was confusing and was not a strong indicator of whether a request was infeasible. We removed the second and third factors because we proposed them with the intention that they would be indicators of whether the relative burden on the requestor was greater than that on the actor. However, we have shifted away from this relative burden analysis in the final rule. To illustrate, consideration does not have to be given as to whether other means are available for access, exchange, or use of EHI or the cost to the requestor for that alternative means because of the new Content and Manner Exception (§ 171.301) and its relationship to this exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter recommended that claims of infeasibility based on the classification of EHI as proprietary and claims of infeasibility rooted in discriminatory practices should not be included in the exception, as they do not support ONC's policy goals of promoting competition and innovation in health IT and ultimately disadvantage customers and patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenter that claiming the 
                        <E T="03">EHI</E>
                         itself as proprietary is not a justification for claiming this exception. As discussed in more detail in the Fees Exception, we emphasize that almost all of the patient EHI found in the U.S. health care system has been generated and paid for with either public dollars through Federal programs, including Medicare and Medicaid, or directly subsidized through the tax preferences for employer-based insurance.
                    </P>
                    <P>
                        We explained in the Proposed Rule how use of IP rights for interoperability elements can serve to interfere with access, exchange, and use of EHI. We also explained in the Proposed Rule that the mere fact that EHI is stored in a proprietary format or has been combined with confidential or proprietary information does 
                        <E T="03">not</E>
                         alter the actor's obligations under the information blocking provision to facilitate access, exchange, and use of the EHI in response to a request (84 FR 7517). We emphasize that actors who control proprietary interoperability elements and demand royalties or license terms from competitors or other persons who are technologically dependent on the use of those interoperability elements would also be subject to the information blocking provision, unless they meet all conditions of the Licensing Exception (§ 171.303).
                    </P>
                    <P>We note, however, that actors may seek coverage under the Infeasibility Exception (§ 171.204) or Content and Manner Exception (§ 171.301) for certain issues related to IP. For instance, an actor may claim to be unable to fulfill a request to access, exchange, or use EHI because the actor is not the owner of the IP rights and lacks requisite authority to provide the requested access, exchange, or use of EHI. In such a situation, the actor could claim that the request is infeasible under the circumstances (see § 171.204(a)(3)). Under § 171.204(a)(3)(i)(E), one factor that can be considered when determining whether a practice is infeasible under the circumstances is whether the actor owns or has control over a predominant technology, platform, HIE, or HIN through which EHI is accessed or exchanged. The actor could also seek coverage under the Content and Manner Exception. Under § 171.301(b)(2), an actor may provide the EHI requested in an alternative manner if responding to the request in the manner requested would require the actor to license IP. As we have explained throughout this final rule, each information blocking case, and whether the actor's practice would meet all conditions of an exception, will depend on its own unique facts and circumstances. We refer readers to the detailed discussions regarding the Content and Manner Exception (VIII.D.2.a) and Licensing Exception (VIII.D.2.c) in this preamble.</P>
                    <P>
                        We also agree with the commenter that infeasibility rooted in discriminatory practices should not be a justification for claiming this exception. It was never our intention to allow such conduct to be covered by this exception. In response to this comment, we have clarified the factor in § 171.204(a)(3)(i)(D) to explicitly state that one consideration for determining whether a request is infeasible under the circumstances is whether 
                        <E T="03">the actor's practice is non-discriminatory</E>
                         and the actor provides the same access, exchange, or use to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters expressed concern that this exception does not fully consider potential conflicts between valid contracts, such as business associate agreements (BAAs), and subsequent requests for access, exchange, and use of EHI that are inconsistent with those contracts. Commenters urged ONC to specify whether an actor can refuse a request to access, exchange, or use EHI as being infeasible due to such contractual restrictions and obligations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. We reiterate, as we explained in the Proposed Rule, that one means by which actors restrict access, exchange, or use of EHI is through formal restrictions, such as contract or license terms, EHI sharing policies, organizational policies or procedures, or other instruments or documents that set forth requirements related to EHI or health IT (84 FR 7518). We emphasize that such restrictions are one of the forms of information blocking the Cures Act and our final rule seek to address. We refer readers to the discussion of “Practices that May Implicate the Information Blocking Provision” in section VIII.C.6 of this final rule for a more detailed discussion of when contracts and agreements will be considered an “interference” with access, exchange, or use of EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters encouraged ONC to add a provision to the exception that would enable entities who have joined Trusted Exchange Framework and Common Agreement (TEFCA) to claim the Infeasibility Exception if a requestor or third party refused to join the TEFCA and instead demanded a one-off interface.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments, but have decided not to adopt this suggested addition at this time. The TEFCA is still new, the Common Agreement is not yet finalized, and it would be premature to establish special treatment for entities that join the TEFCA. We may reconsider this suggestion at a later date. We note that this does not necessarily mean that actors in these situations will not be covered by the exception, as they could still show that a request for a one-off interface is infeasible under the circumstances (see § 171.204(a)(3)). However, not joining TEFCA is not de facto proof of infeasibility. We note that in addition to seeking coverage for infeasibility under the circumstances, the actor could also seek coverage from: (1) The Content and Manner Exception if the actor could not fulfill request to access, exchange, or use EHI in the manner requested (via a one-off interface), but could fulfill the request through an acceptable alternative manner (see § 171.301(b)); or (2) the Fees Exception or Licensing Exception if the actor chooses to provide the one-off interface as requested, but charges 
                        <PRTPAGE P="25869"/>
                        fees/royalties related to developing or licensing the one-off interface, which could include fees or royalties that result in a reasonable profit margin (see § 171.302 and 303).
                    </P>
                    <HD SOURCE="HD3">ii. Responding to Requests—Timely and Written Responses</HD>
                    <P>We proposed, in addition to demonstrating that a particular request was infeasible, that an actor would have to show that it satisfied additional conditions. Specifically, we proposed that to qualify for the exception, the actor must have timely responded to all requests relating to access, exchange, and use of EHI. Further, we proposed that for any request that the actor claims was infeasible, the actor must have provided the requestor with a detailed written explanation of the reasons why the actor could not accommodate the request. We proposed that the actor's failure to meet any of these conditions would disqualify the actor from the exception and could also be evidence that the actor knew that it was engaging in practices that contravened the information blocking provision (84 FR 7544).</P>
                    <P>We proposed that the duty to timely respond and provide reasonable cooperation would necessarily be assessed from the standpoint of what is objectively reasonable for an individual or entity in the actor's position. We emphasized that we will look at the specific facts and circumstances of each case to determine whether the practice is objectively reasonable (84 FR 7544).</P>
                    <P>We encouraged comment on these conditions and related considerations. Specifically, we requested comment regarding potential obstacles to satisfying these conditions and improvements we could make to the proposed process (84 FR 7544).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Many commenters, primarily provider organizations, expressed concern that the proposed response requirements could create burden on providers, hospitals, and clinical data registries. Commenters explained that each time a requester makes a request that an actor deems infeasible, the actor would be required to timely respond and provide a detailed written explanation of its reasons for denial. A commenter also recommended that, in the event a request is infeasible and a written explanation is necessary, that such explanation need not contain detailed technical information.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and have revised the response condition in this exception to address commenters' concerns and establish a set timeframe for responding to requests (§ 171.204(b)). We removed the use of the term “timely” and restructured the provision to more clearly explain ONC's expectations for responding to requests. Under the response condition, if an actor does not fulfill a request for access, exchange, or use of EHI for any of the reasons in § 171.204(a), the actor must, within ten business days of receipt of the request, provide to the requestor in writing the reason why meeting the request was infeasible. Our decision to finalize a 10-business day response timeframe was informed by our knowledge of the industry, stakeholder commenters, and a desire to create consistent timeframes across exceptions, such as alignment with the 10-business day response timeframe in the Licensing Exception (see § 171.303(a)(1)).
                    </P>
                    <P>In instances when an actor is unable to respond within 10 business days, the actor may be unable to avail themselves of the requirements of the exception. As part of an information blocking investigation, ONC and OIG may consider documentation or other writings maintained by the actor around the time of the request that provide evidence of the actor's intent. Additional documentation would not permit the actor to avail themselves of this exception, but ONC or OIG could examine the actor's intent using this documentation when assessing the information blocking claim.</P>
                    <P>We have decided not to specify the level of detail or specific type of information (such as technical information) that must be contained in a written response. We believe it would be imprudent to create such boundaries for the written response given that the facts and circumstances will vary significantly from case to case. Instead, the finalized provision allows actors to determine what content is necessary to include in the written response in order to explain the reason the request is infeasible. We note that we have revised the requirement for the written response from the Proposed Rule. In the Proposed Rule an actor was required to provide a “detailed written explanation of the reasons why the actor cannot accommodate the request” (84 FR 7544) whereas we have finalized the requirement that the actor must provide “in writing the reason(s) why the request is infeasible” (§ 171.204(b)). We believe this revised requirement will alleviate burden on actors by providing them discretion to decide the appropriate level of detail to include in their written responses. It also places a greater emphasis on establishing that the request was infeasible to meet.</P>
                    <HD SOURCE="HD3">Reasonable Alternative</HD>
                    <P>We proposed that, if the actor could not meet the request for EHI, the actor must work with the requesting party in a timely manner to identify and provide a reasonable alternative means of accessing, exchanging, or using the EHI, as applicable (84 FR 7544).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters, primarily provider organizations, were supportive of the proposed requirement to provide a reasonable alternative. We also received a range of comments related to improving ONC's proposals regarding the provision of a reasonable alternative, including comments requesting more examples and guidance as to what would be considered a “reasonable alternative.” Another commenter requested that ONC provide greater deference to the actor to determine the appropriate format/functionality for sharing the requested EHI when a comparable functionality, distinct from the format/functionality requested, is made available and enables access, exchange, or use of EHI on equivalent terms. One commenter requested ONC place guardrails around requests for information sharing, such that if an actor is able to share data in an industry-accepted format, the requesting organization cannot make an information blocking claim if that format does not meet their preferred, specific data transmission standard.
                    </P>
                    <P>
                        A few commenters requested that ONC remove the requirement that an actor both “identify” and “provide” a reasonable alternative means of accessing EHI, and instead require only that an actor “identify” a reasonable alternative. One commenter requested that ONC clarify that the proposed requirement to identify a reasonable alternative means of accessing, exchanging, or using EHI is only necessary where any such alternative exists. The commenter noted that there could be instances in which no reasonable alternative exists, and the request is in effect impossible to comply with. One commenter requested that ONC clarify that, regarding the provision of a reasonable alternative, an actor must only work with the requestor in a timely manner to identify and provide a reasonable alternative means of accessing, exchanging, or using the EHI as applicable. One commenter expressed concern that this exception could be used to send patients to other sources to get their health information because that approach would be less burdensome than providing the information to the patient directly. The commenter recommended that ONC 
                        <PRTPAGE P="25870"/>
                        preclude the use of this exception for patient access requests.
                    </P>
                    <P>Some provider, hospital, and clinical data registry commenters expressed concern regarding the potential burden on the actor related to identifying and providing a reasonable alternative means of accessing, exchanging or using the EHI. Other commenters, primarily health IT developers, expressed concern regarding the potential impact and burden on health IT developers, HINs, and HIEs of complying with a request to access, exchange, or use EHI, especially when the request requires custom development. Commenters explained that if a system, even a large system, were required to comply with many custom forms of integration, collectively they would cause a significant burden to both business and budget. Some commenters also noted that the proposed exception seems imbalanced, favoring the requester of the EHI over the actor providing the EHI.</P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the support for our proposal, as well as the array of constructive comments. We first note that, in many instances, the exceptions, including the finalized third condition of this exception (§ 171.204(a)(3)), favor the request for EHI because the overall information blocking paradigm is to eliminate interference with access, exchange, and use of EHI. We have removed the “reasonable alternative” requirement from this exception and instead have finalized the new Content and Manner Exception in § 171.301 that establishes the content (
                        <E T="03">i.e.,</E>
                         the EHI) required in the response and the manner in which the actor may respond to the request for access, exchange, or use of EHI. This new exception improves on the “reasonable alternative” requirement in the Proposed Rule by clarifying actors' obligations for providing access, exchange, or use of EHI in all situations and creating actionable technical procedures.
                    </P>
                    <P>We believe the Content and Manner Exception in § 171.301 is responsive to the above comments, will reduce burden on actors, and is principled and tailored in a manner that will promote basic fairness and encourage parties to work cooperatively to implement efficient solutions to interoperability challenges. We refer readers to the Content and Manner Exception and the discussion of such exception in this preamble in sections VIII.C and VIII.D.2.a. With regard to the comment suggesting that no reasonable alternative may exist, we believe that the new exception will address this concern. However, if the actor still could not meet the new exception, the actor could avail itself of the third condition in this exception and demonstrate that the request was infeasible under the circumstances.</P>
                    <HD SOURCE="HD3">e. Health IT Performance Exception—When will an actor's practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of electronic health information not be considered information blocking?</HD>
                    <P>We proposed to establish an exception to the information blocking provision for certain practices that are reasonable and necessary to maintain and improve the overall performance of health IT, provided certain conditions are met (84 FR 7550). We stated in the Proposed Rule that this exception would apply to the unavailability of health IT occasioned by both planned and unplanned maintenance and improvement. We noted that planned maintenance or improvements are often carried out at regular intervals and address routine repairs, updates, or new releases while unplanned maintenance or improvements typically respond to urgent or time-sensitive issues. We proposed to codify the exception's regulation text in § 171.207 (84 FR 7605).</P>
                    <P>To ensure that the actor's practice of making health IT, and in turn EHI, unavailable for the purpose of carrying out maintenance or improvements is reasonable and necessary, we proposed conditions that would need to be satisfied at all relevant times a practice to be recognized as excepted from the definition of information blocking under this proposed exception.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received numerous comments supporting the establishment of this exception. We did not receive comments opposing the establishment of this exception. Many of the comments received requested clarification or recommended revisions to specific points within the proposed exception. The comments requesting clarification or making recommendations are summarized below.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. We have established the proposed exception with modifications from the regulation text proposed in the Proposed Rule. We have retitled the exception from “Exception—Maintaining and improving health IT performance” (proposed § 171.207, at 84 FR 7605) to “Health IT Performance Exception—When will a practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of electronic health information not be considered information blocking?” (§ 171.205 as finalized). For ease of reference and discussion, we use “Health IT Performance Exception” as a short title for the finalized exception throughout this preamble. Unless we are directly quoting the Proposed Rule or accurate re-statement of Proposed Rule content requires otherwise, we use “Health IT Performance Exception” in this section of this preamble when discussing this exception as proposed as well as the finalized exception. As stated in section VIII.D of this preamble (under the heading “modifications”), we changed the titles of all of the information blocking exceptions to questions for additional clarity. We revised the wording of the finalized § 171.205 introductory text in comparison with that proposed in § 171.207 so that it is consistent with the finalized title of the exception (and § 171.205). Consistent with the restructuring of part 171 that is also described in section VIII.D of this preamble (under the heading “modifications”), this exception has been redesignated from § 171.207 in the Proposed Rule (84 FR 7605) to § 171.205 as finalized. Commenters' requests for clarification and suggested revisions on specific points are discussed below. Other revisions we have made to the regulation text finalized in § 171.205 in comparison to that proposed in § 171.207 are also discussed below.
                    </P>
                    <HD SOURCE="HD3">Unavailability of Health IT Must Be for No Longer Than Necessary To Achieve the Maintenance or Improvements for Which the Health IT Was Made Unavailable</HD>
                    <P>We proposed that any unavailability of health IT must be for a period of time no longer than necessary to achieve the maintenance or improvement purpose for which the health IT is made unavailable or its performance degraded (84 FR 7550 and 7551). We provided as an illustrative example that a health IT developer of certified health IT that has the right under its contract with a large health system to take its system offline for four hours each month to conduct routine maintenance would not qualify for this exception if an information blocking claim was made about a period of unavailability during which no maintenance was performed.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments from a variety of stakeholders on the proposed requirement that any unavailability of health IT would need to be for a period of time no longer than necessary to achieve the maintenance or improvements for which the health IT was made unavailable. Some commenters agreed that temporary unavailability of health IT “for a period 
                        <PRTPAGE P="25871"/>
                        of time no longer than necessary” created an appropriate standard for both planned and unplanned downtimes. Other commenters indicated they did not support this standard, stating concerns that the requirement that the health IT be made unavailable “for a period of time no longer than necessary” would be too difficult to assess without more specific criteria such as defined time periods. Some commenters suggested we modify our language to allow for greater flexibility in maintenance downtime situations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized within the condition for maintenance and improvements to health IT in § 171.205(a)(1) the requirement proposed in § 171.201(a)(1), with modifications to the regulation text that are described below (immediately preceding the preamble discussion of the next subparagraph of § 171.205(a)). When an actor choosing to conform its practice to the health IT performance exception implements a practice that makes health IT under that actor's control temporarily unavailable, or temporarily degrades the performance of health IT, in order to perform maintenance or improvements to the health IT, the actor's practice must be (§ 171.205(a)(1)) implemented for a period of time no longer than necessary to complete the maintenance or improvements for which the health IT was made unavailable or the health IT's performance degraded. We believe that establishing specific timeframes applicable to various maintenance and improvement purposes would be impractical at this time due to the wide variety of system architectures and operational contexts in which health IT to which part 171 is applicable is currently, or may in the future be, deployed. We have finalized the “no longer than necessary” requirement of this condition, which we believe provides substantial flexibility to consider the particular circumstances of each case, and a variety of factors including but not limited to the service level agreements in place for the specific health IT at issue, the type of maintenance or improvements, the technical resources available to the actor, or best practices or other industry benchmarks relevant to the particular maintenance or improvements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Noting our use of the phrase “as soon as possible” in the Proposed Rule's preamble discussion of this condition (84 FR 7551), specifically in an example where an actor takes health IT offline in response to a software failure, some commenters requested we clarify how we interpret that phrase. A commenter described practices such as procedures that phased restoration of full functionality across a complex system, to manage system loads or confirm the original failure is fully resolved, and asked if we would interpret this exception's proposed conditions as excluding such procedures. Some comments from members of the developer community suggested that we modify our proposed language from “for a period of time no longer than necessary” to “a reasonable period of time.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The “no longer than necessary” standard provides actors substantial flexibility to address the particular circumstances of each case, allowing for consideration of a variety of factors including but not limited to the service level agreements in place for the specific health IT at issue, the type of maintenance or improvements, the technical resources available to the actor, or best practices or other industry benchmarks relevant to the particular maintenance or improvements. In response to comments requesting we clarify how we interpret “as soon as possible” and how it would apply to specific types of practices, we first ask readers to note that in this final rule preamble for the Health IT Performance Exception we use the phrase “as soon as possible” 
                        <E T="03">only</E>
                         in summarizing and responding to these comments. We see how this phrase could be read as implying that we might uniformly expect restarts in a shorter time or more abrupt manner than might be consistent with best practices for ensuring the affected component(s) or production environment are restored to stable, reliable operating status. We do not, however, interpret the finalized condition as uniformly mandating immediate full restarts of any or every system. In determining whether an actor's practice made health IT under its control unavailable, or degraded the health IT's performance, for longer than was necessary in the particular circumstances, we would consider a variety of factors such as (but not limited to) the service level agreements in place for the specific health IT at issue, the type of maintenance or improvements, the technical resources available to the actor, or best practices or other industry benchmarks relevant to the particular maintenance or improvements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters recommended that this exception apply to downtime necessary for testing whether a maintenance or improvement activity, such as deploying a new or updated application into a particular production environment for the first time, will operate in that environment as it is intended to operate or without adversely affecting other functions of the system.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We interpret “minimum time necessary” to complete a maintenance or improvement purpose, objective, or activity to include reasonable and necessary practices, such as confirmatory testing and phased restart protocols, to ensure that a newly deployed or newly updated application functions in a particular production environment as it is intended to perform and does not adversely affect system stability or the performance of critical functions or components of that system. In determining whether an actor's practice affected health IT's availability or performance for longer than was necessary in the particular circumstances, we reiterate that we would consider a variety of factors such as (but not limited to) the service level agreements in place for the specific health IT at issue, the type of maintenance or improvements, the technical resources available to the actor, or best practices or other industry benchmarks relevant to the particular maintenance or improvements.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters recommended that we recognize there may be circumstances where an instance of downtime may exceed service level agreements but still be no longer than necessary to address the issue. These commenters suggested such violations of service level agreements and other provisions of contracts between the parties should remain to be resolved through contractual mechanisms and not automatically considered information blocking on basis of exceeding the terms of the agreements. One commenter suggested actors who make their health IT temporarily unavailable under this exception be held to industry standards for necessary timeframes to complete any maintenance or improvements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         For purposes of determining whether a period of health IT unavailability or performance degradation is (or was) no longer than necessary to accomplish its purpose, we note that service level agreements and industry practices would be relevant information to be considered but not necessarily dispositive. For example, a period of health IT unavailability or performance degradation could be within the parameters of applicable service level agreements but still be longer than necessary to accomplish the maintenance or improvement purpose for the health IT was made unavailable or its performance degraded. For a contrasting example, a period of health IT unavailability or performance 
                        <PRTPAGE P="25872"/>
                        degradation could be outside the parameters of applicable service level agreements—a contractual matter for the parties to resolve through other appropriate channels—without being “longer than necessary” in the totality of applicable circumstances and, therefore, without necessarily constituting information blocking as defined in § 171.103.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested we clarify whether this exception would apply to practices that degrade some aspects of a health IT system's performance, without making it entirely unavailable, for purposes of conducting maintenance and improvement of the health IT system or some of its components.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the feedback. We agree that there may be circumstances where the minimum disruption of an overall health IT system's availability needed to accomplish particular maintenance or improvement purposes may be less than total. We do not intend that this exception would apply only to complete unavailability of health IT. We intend the exception to apply to reasonable and necessary practices that disrupt EHI access, exchange, or use not only for the shortest time but also to the least extent practicable to accomplish their specific maintenance or improvement purposes under the particular circumstances. Accordingly, we have modified the language of § 171.205(a)(1) as finalized to expressly include temporary performance degradation as well as temporary unavailability of health IT affected by maintenance and improvement practices.
                    </P>
                    <HD SOURCE="HD3">Discussion of Finalized Text of § 171.205(a)(1)</HD>
                    <P>The regulation text finalized in § 171.205(a)(1) has been modified in comparison to the regulation text proposed in § 171.207(a)(1) in several ways. The finalized regulation text expressly includes “or the health IT's performance degraded,” for the reasons stated in response to comments (above). In the text of this provision, finalized at § 171.205(a)(1), we have also replaced the verb “to achieve” with the verb “to complete.” Reflecting on the comments received, we have reviewed the dictionary definition of “achieve” and now believe that our use of “achieve” in the regulation text proposed in in § 171.207(a)(1) may have contributed to commenters' concerns about whether we would interpret time for confirmatory testing of system performance or phased restart protocols as falling within the “minimum time necessary” for any particular maintenance or upgrade.</P>
                    <P>
                        We believe “complete” less ambiguously expresses our intent that this requirement of this condition encompasses the minimum time necessary, in the totality of the particular circumstances, to fully complete the maintenance or improvement activity, including any confirmatory testing or other protocols necessary to ensure an orderly and reliable restoration of normal operating status. We have also revised the wording of § 171.205(a) as finalized so that it is consistent with the title and introductory text of § 171.205 as finalized.
                        <SU>182</SU>
                        <FTREF/>
                         We made modifications to the titles and introductory text of all of the finalized exceptions for reasons described in section VIII.D of this preamble (under the heading “modifications”). As finalized, § 171.205(a)(1) requires, in order to meet the condition in § 171.205(a), that when an actor implements a practice that makes health IT under that actor's control temporarily unavailable, or temporarily degrades the performance of health IT, in order to perform maintenance or improvements to the health IT, the actor's practice must be implemented for a period of time no longer than necessary to complete the maintenance or improvements for which the health IT was made unavailable or the health IT's performance degraded.
                    </P>
                    <FTNT>
                        <P>
                            <SU>182</SU>
                             As noted above in this section of this preamble, titles of all the finalized exceptions have been revised to be more clear and easy to understand.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Unavailability of Health IT for Maintenance or Improvements Must Be Implemented in a Consistent and Non-Discriminatory Manner</HD>
                    <P>We proposed (in proposed § 171.207(a)(2)) that any unavailability of health IT occasioned by the conduct of maintenance or improvements must be implemented in a consistent and non-discriminatory manner (84 FR 7551). We explained that this condition provides a basic assurance that when health IT is made unavailable for the purpose of performing maintenance or improvements the unavailability is not abused by the actor that controls the health IT. However, we indicated that this condition would not require that actors conduct all planned maintenance or improvements simultaneously, or require that every health IT contract provide the same promises in regard to planned maintenance or improvements. We further noted that a recipient of health IT could agree to a longer window for unavailability in exchange for a reduced fee for system maintenance, which would not contravene this condition of this exception.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed support for requiring practices be implemented in a non-discriminatory manner to meet the conditions of the Health IT Performance Exception. One commenter supported the requirement but stated that they believed practices applied selectively against an actor or third-party application inappropriately accessing interoperability resources should be exempt from this condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate the opportunity to clarify two points. First, we want to reiterate that there is an important distinction between conduct of individuals or entities (or the behavior of applications) that poses a security risk and conduct or behavior that may merely adversely affect performance of a health IT system or its core functions. If an actor or an application is making or attempting unauthorized access to systems or to EHI, the actor with control of the system subject to that security risk should take prompt action to address that risk. As stated in the finalized § 171.205(d), the Health IT Performance Exception expressly does 
                        <E T="03">not</E>
                         apply to security-related practices. If the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a security risk to electronic health information, the actor does not need to satisfy the conditions of § 171.205, but must comply with all applicable conditions of § 171.203 at all relevant times if they wish to seek the added assurance of conforming their practices to an exception to the information blocking provision. Second, we recognize there are circumstances where an application's behavior does not pose a security risk but does adversely impact the performance of a health IT system's overall or core functions performance. We decline to modify § 171.205(a)(2) in the manner the commenter recommended in order to address adverse impacts on health IT performance. Instead, in response to this and other comments, we have finalized in § 171.205(b) an alternative condition that expressly provides for the finalized Health IT Performance Exception to apply to practices implemented to mitigate a third-party application's negative impact on an actor's health IT's performance.
                        <PRTPAGE P="25873"/>
                    </P>
                    <HD SOURCE="HD3">Unavailability of Health IT for Maintenance or Improvements Must Be Agreed</HD>
                    <P>In order to benefit from this exception, we proposed that the unavailability of health IT due to maintenance or improvements initiated by a health IT developer of certified health IT, HIE, or HIN, must be agreed to by the individual or entity to whom the health IT is supplied (84 FR 7551). We noted that the availability of health IT is typically addressed in a written contract or other written agreements, that puts the recipient of the health IT on notice about the level of EHI and health IT unavailability that can be expected for users of the health IT. By such agreements, the recipient of the health IT willfully agrees to that level of planned and unplanned unavailability (typically referred to in health IT contracts as “downtime”). We proposed that in circumstances where health IT needs to be taken offline for maintenance or improvements on an urgent basis and in a way that is not expressly permitted under a health IT contract an actor could satisfy the proposed condition so long as the maintenance or improvements are agreed to by the recipient of the health IT. We proposed that this could be achieved by way of an oral agreement such as reached between the parties by telephone, but we noted that because an actor must demonstrate that it satisfies the conditions of this exception, it would be best practice for an actor to ensure the agreement was in writing or, at minimum, contemporaneously documented.</P>
                    <P>
                        We proposed that this condition would 
                        <E T="03">only</E>
                         apply when the unavailability of health IT is caused by a health IT developer of certified health IT, HIE, or HIN because it is the supplier of the health IT and thus controls if and when health IT is intentionally taken offline for maintenance or improvements. We proposed that this condition would not apply when health IT is made unavailable for maintenance or improvements at the initiative of a recipient (or customer) of health IT, noting that when it is a customer of health IT who initiates unavailability, the unavailability would not need to be the subject of an agreement with the supplier of that health IT, nor anyone else, in order for the customer of health IT to benefit from this exception.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters from the provider community recommended advance notice of downtime. Several commenters from the provider community suggested that planned downtimes should be documented, scheduled, and executed within a predefined window of time. One commenter recommended that actors create a public website that displays planned and unplanned system downtime and allow other actors to subscribe to notifications of these downtimes. One commenter suggested we explicitly prohibit an entity from regularly scheduling extensive time periods where query and response services are unavailable. Another commenter suggested we make allowances within the conditions of this exception for an actor who may fall slightly out of compliance with terms agreed to regarding downtime in a service level agreement if the impact is 
                        <E T="03">de minimis</E>
                         and the actor was acting in good faith. One commenter contended that the information blocking provisions should not regulate the level of service provided by health IT developers to their customers. We also received several comments from members of the HIE and HIN community that recommended against any requirement to include specific details such as dates and times for maintenance because such a requirement could result in HIEs and HINs having to undertake the process of amending thousands of legal agreements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We do not believe it is necessary to dictate the availability or health IT or other contractually defined details of the business relationship between parties for the purposes of this exception. Parties to a health IT contract can determine and communicate their respective service level needs and capabilities or commitments in legally enforceable contracts. Contractual provisions can establish specific details of service levels, planned downtime, unplanned downtime, and communications regarding planned and unplanned downtime, that are practical and appropriate to the context of a particular contract. In the event parties do not honor such contract provisions, remedies are available to the parties outside and independent of part 171. We also agree with commenters' observations that any specific requirements, such as those recommended by some other commenters, could require amending contracts in ways that could create significant burden and costs for actors. Thus, we did not modify this exception in response to commenters' recommendations that we require service level or other contractual agreements between parties conform to specific prescribed timeframes, scheduling (including specifically or query and response services), notice, and scope of planned downtimes expectations in order for maintenance and improvement health IT downtimes to meet the information blocking exception for maintenance and improvement. Similarly, we have not modified the exception in response to recommendations from some commenters that we require display of planned and unplanned downtime on publicly available websites. We are not persuaded such measures would generally render benefits commensurate with the time and effort that would be needed for actors to implement and maintain them.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Two commenters disagreed with our proposed requirement that temporary unavailability initiated by a health IT developer of certified health IT, HIE, or HIN must be agreed to by the individual or entity to whom the health IT developer of certified health IT, HIE, or HIN supplied the health IT. Both commenters recommended removing the “agreed upon with user” provision we proposed and recommended that ONC eliminate the requirement for prior agreement of planned downtime in order to meet the conditions of this exception. These commenters suggested that we instead allow for unilateral notice to organizations at least 10 days prior to scheduled maintenance.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We continue to believe that unplanned downtime must be done with the agreement of the individual or entity to which the health IT is supplied. This condition protects health care providers and other uses or health IT under the specific circumstance of health IT being made temporarily unavailable due to unplanned maintenance or improvements. It also reduces the potential for downtime purportedly for purposes of health IT maintenance or improvement to be a pretext for information blocking and thus makes it less likely that this exception will be abused. However, the conditions of this exception finalized in § 171.205 can be met by unplanned downtime in the absence of contemporaneous agreement so long as it is consistent with an existing service level agreement. We also note that specific agreement by all users to temporary unavailability is not required in all instances of unplanned downtime not already covered by an existing service level or other contractual agreement, such as downtime resulting from events beyond the actor's control that prevent it from meeting the requirement, and practices that are consistent with the conditions of the Preventing Harm Exception (§ 171.201), 
                        <PRTPAGE P="25874"/>
                        Security Exception (§ 171.203), or Infeasibility Exception (§ 171.204).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters from the developer community expressed appreciation for the opportunity to comment on throttling, arguing that it is a reasonable approach to maintain access to functionality. Many of these commenters stated that, when applied with the agreement of health IT users, strategies such as throttling or metering certain health IT functions should not be considered information blocking. One commenter suggested that throttling should not be considered information blocking if the health IT developer or health care provider is forced to throttle access so as not to negatively impact hospital operations. The commenter recommended that when requests for EHI from third-party applications created an unreasonable and significant burden on health IT and the installed infrastructure, the two contracting parties could mutually agree that the third-party application was poorly designed and could be throttled or even denied access. Another commenter suggested that the practice of throttling should only occur if that portion of the health IT affected by an application is impacting highly critical functions such as inpatient or emergency department care delivery and documentation. The commenter stated that it was important to distinguish between the practice of throttling generally and the practice of throttling as a response to impact on critical functions because the practice of throttling generally could be applied too broadly.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate commenters' input. We recognize that in some circumstances it may be appropriate for actors to take action (
                        <E T="03">e.g.,</E>
                         deny access, throttle, or meter) to limit the negative impact on the performance of health IT that may result from the technical design, features, or behavior of a third-party application. This would include, but not be limited to, third-party applications that a patient might choose to use to access their EHI. The regulation text finalized in § 171.205 has been expanded, in comparison to the text proposed in § 171.207 (84 FR 7605), to include paragraph (b), which we have titled “assured level of performance.” As finalized, § 171.205(b) establishes a condition expressly applicable to actions taken against a third-party application that is negatively impacting the health IT's performance. The specific requirements for action against a third-party application to meet the condition finalized in § 171.205(b) and thus be excepted from the definition of information blocking parallel the requirements finalized in § 171.205(a), the condition applicable to practices that make health IT temporarily unavailable, or its performance degraded, for purposes of maintenance and improvement.
                    </P>
                    <P>
                        To meet the Health IT Performance Exception under the assured level of performance condition, an action against a third-party application (§ 171.205(b)) must be: (1) For a period of time no longer than necessary to resolve any negative impacts; (2) implemented in a consistent and non-discriminatory manner; and (3) consistent with existing service level agreements, where applicable. For example, if the service level agreement stated how and to what extent negative impacts should be addressed (
                        <E T="03">e.g.,</E>
                         over-capacity), then it is expected that such provisions of an existing service level agreement would be followed unless they violated one of the other requirements of the (§ 171.205(b)) assured level of performance condition (
                        <E T="03">e.g.,</E>
                         resulted in discriminatory application or lasted longer than necessary to resolve the negative impacts). We believe this approach will help to address situations where actions such as throttling become necessary to protect the overall performance of health IT.
                    </P>
                    <HD SOURCE="HD3">Interaction With the Preventing Harm and Security Exceptions</HD>
                    <P>We proposed that when health IT is made unavailable for maintenance or improvements aimed at preventing harm to a patient or other person, or securing EHI, an actor must comply with the conditions specified in the proposed Harm Exception or proposed Security Exception, respectively, in order for these particular practices to be excepted from the definition of information blocking in § 171.103.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a few comments that expressed concern that our maintenance exception, as proposed, did not address unplanned downtime without notice in the instance of a potential threat to security of EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Unplanned downtime or other practices reasonable and necessary in response to exigent threats to EHI security should be implemented consistent with the conditions for the Security Exception as finalized in § 171.203. We expressly stated in the proposed regulation text at § 171.207(c), and have finalized in § 171.205(d), that if the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a security risk to EHI, the actor does not need to satisfy the conditions of the Health IT Performance Exception, but must comply with all conditions of § 171.203 at all relevant times for such practices to be excepted from the definition of information blocking in § 171.103. We believe this paragraph of the finalized Health IT Maintenance Exception's regulation text (finalized in § 171.205(d)) provides ample clarity that this exception is not intended to apply to unplanned downtime implemented specifically in response to emergent security threats. We have finalized this approach to the relationship between the Health IT Performance Exception and Security Exception as proposed, because we continue to believe it ensures that the Health IT Performance Exception cannot be used to avoid compliance with conditions applicable under the Security Exception when the practice leading to unplanned downtime is implemented specifically in response to a risk to security of EHI.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments from stakeholders in the developer community that it would be impossible for certified health IT developers, HIEs, or HINs to meet the conditions of this exception as proposed in the event of downtime as a result of something like a natural disaster because those parties would be unable to secure agreement from entities and individuals prior to uncontrollable downtime.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Infeasibility Exception finalized in § 171.204 has been revised, in comparison to the proposed regulation text in the Proposed Rule, to expressly address uncontrollable events. In cases of natural or human-made disaster, public health emergency, public safety, incident war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority, an actor can avail itself of the Infeasibility Exception. We determined these situations should be addressed in the Infeasibility Exception rather than the Health IT Performance Exception in part because the breadth of circumstances where access, exchange, or use of EHI may be interfered with due to these uncontrollable events is more consistent with the intent and function of the Infeasibility Exception. Thus, we have not modified the Health IT Maintenance Exception (§ 171.205) to address uncontrollable events of the type expressly addressed by the finalized Infeasibility Exception (§ 171.204).
                    </P>
                    <P>
                        We have finalized the substance of the relationship between the Health IT Maintenance Exception and the Preventing Harm and Security Exceptions as proposed. We have also 
                        <PRTPAGE P="25875"/>
                        finalized as proposed the provisions of the Health IT Maintenance Exception specific to 
                        <E T="03">“practices that prevent harm”</E>
                         and 
                        <E T="03">”security-related practices,”</E>
                         but have redesignated them within the structure of the Health IT Maintenance Exception as finalized in § 171.205 in comparison to the structure proposed at § 171.207 (84 FR 7605). Specifically, the 
                        <E T="03">“practices that prevent harm”</E>
                         provision is finalized in paragraph (c) of the finalized Health IT Maintenance Exception in § 171.205 instead of paragraph (b) as was the case in the Proposed Rule (84 FR 7605). Likewise, the 
                        <E T="03">“security-related practices”</E>
                         provision is finalized in paragraph (d) of the finalized Health IT Maintenance Exception in § 171.205 instead of paragraph (c) as was the case in the Proposed Rule (84 FR 7605). Both of these provisions were moved down to accommodate the addition of the 
                        <E T="03">“assured level of performance”</E>
                         condition as paragraph (b) of § 171.205 as finalized.
                    </P>
                    <P>
                        The paragraph of the Health IT Maintenance Exception finalized in § 171.205(c), specific to 
                        <E T="03">“practices that prevent harm,”</E>
                         continues to provide that if the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a risk of harm to a patient or another person, the actor does not need to satisfy the requirements of this section, but must comply with all conditions of § 171.201 at all relevant times to qualify for an exception. Likewise, the paragraph of the Health IT Maintenance Exception finalized in § 171.205(d), specific to 
                        <E T="03">“security-related practices,”</E>
                         continues to provide that if the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a security risk to electronic health information, the actor does not need to satisfy the requirements of this section, but must comply with all conditions of § 171.203 at all relevant times to qualify for an exception.
                    </P>
                    <HD SOURCE="HD3">Request for Comment</HD>
                    <P>We requested comments on the exception in general, and on whether the proposed conditions would impose appropriate limitations on actor-initiated health IT maintenance or improvement activities that lead to temporary unavailability of EHI.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments generally opposed to the establishment of this exception. One commenter recommended that if a patient is affected by a practice that could be recognized under this exception, such as unavailability of health IT for an app registration, the patient should be provided an opportunity to access the EHI through another means, such as the patient portal.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         The Health IT Performance Exception is applicable to a variety of specific practices making health IT unavailable. It does not recognize only downtime or performance degradation of an actor's entire health IT system. An actor who takes down one means of EHI access to conduct health IT maintenance or improvement could provide alternative access to EHI, in circumstances where this may be practical, and remain in compliance with the requirements for their practices to be excepted under § 171.205 from the definition of information blocking in § 171.103. However, we stress that an actor conducting maintenance or improvement of health IT in the actor's control is not 
                        <E T="03">required</E>
                         to provide an alternative electronic health information access mechanism during the downtime in order for the Health IT Performance Exception to apply to the actor's maintenance or improvement practices. We are aware that actors' operational contexts and existing health IT capabilities vary substantially throughout the health IT ecosystem. In a variety of circumstances where downtime or performance degradation may be reasonable and necessary to maintain or improve health IT performance, an actor may not have the capability needed to meet a requirement that EHI must always be immediately available in response to every patient request. For example, in some circumstances it may be impossible to achieve a particular maintenance or improvement purpose within a specific system without temporarily rendering all EHI in the system unavailable to all functions, services, and other components of the system (such as APIs and portals) through which EHI is ordinarily accessed, exchanged, or used.
                    </P>
                    <P>2. Exceptions that involve procedures for fulfilling requests to access, exchange, or use EHI</P>
                    <HD SOURCE="HD3">a. Content and Manner Exception—When will an actor's practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use electronic health information not be considered information blocking?</HD>
                    <P>In this final rule, we have established a new exception in § 171.301 (referred to as the Content and Manner Exception) under section 3022(a)(3) of the PHSA as a means to identify reasonable and necessary activities that do not constitute information blocking. Although we did not propose this exception in the Proposed Rule, it is related to our proposals and requests for comment in the Proposed Rule regarding the proposed EHI definition (84 FR 7513) and the proposed requirement to identify and provide a reasonable alternative means for accessing, exchanging, or using EHI as part of the proposed Infeasibility Exception (84 FR 7544). We discuss below the connection between these proposals and requests for comment in the Proposed Rule and the conditions in the Content and Manner Exception.</P>
                    <P>We note that a failure to meet the Content and Manner Exception does not mean that an actor's practice meets the information blocking definition. However, as we noted in the Proposed Rule, the broad definition of information blocking in the Cures Act means that any practice that is likely to interfere with the access, exchange, or use of EHI implicates the information blocking provision (see 84 FR 7515). As a result, practices that do not meet the Content and Manner Exception will have to be assessed on a case-by-case basis to determine, for example, the actor's intent and whether the practice rises to the level of an interference. We discuss the comments received regarding the proposals related to the EHI definition (84 FR 7513) and the requirement to identify and provide a reasonable alternative means for accessing, exchanging, or using EHI under the Infeasibility Exception (84 FR 7544) below.</P>
                    <P>
                        <E T="03">Comments.</E>
                         As discussed in more detail section VIII.C.3, we received many comments expressing concerns regarding the breadth of the proposed EHI definition and requesting flexibility in the implementation of the information blocking provision. Many commenters stated that it would be difficult for actors to provide the full scope of EHI as it was proposed to be defined, particularly as soon as the final rule was published. Some commenters opined that we were trying to do too much too fast. Commenters requested that we provide flexibility for actors to adjust to the scope of the EHI definition, as well as the exceptions. Commenters asserted that such an approach would permit them to adapt their processes, technologies, and systems to enable the access, exchange, and use of EHI as required by the Cures Act and this final rule. Some commenters suggested that EHI under the information blocking provision should be limited to ePHI as defined in 45 CFR 160.103, while others requested that ONC consider constraining the EHI covered by the information blocking provision to only the data included in the USCDI.
                        <PRTPAGE P="25876"/>
                    </P>
                    <P>
                        We also received a range of comments requesting clarification and concerning improvements to our proposal in the Infeasibility Exception that, for any request that the actor claims is infeasible, the actor must work with the requesting party in a timely manner to identify and provide a 
                        <E T="03">reasonable alternative means</E>
                         of accessing, exchanging, or using the EHI, as applicable (proposed in § 171.205(d), 84 FR 7604). Commenters, primarily provider organizations, were supportive of the proposed condition. Some commenters requested clarification and additional examples about what manner of response would constitute a “reasonable alternative” and when it would be acceptable to enable requestors to access, exchange, or use EHI in an alternative manner. One commenter requested that ONC place guardrails around requests for information sharing, such that if an actor is able to share data in an industry-accepted format, the requesting organization cannot make an information blocking claim if that format does not meet the organization's preferred, specific data transmission standard. One commenter requested that ONC clarify that the proposed requirement to identify a reasonable alternative means of accessing, exchanging, or using EHI is only necessary where any such alternative exists. The commenter noted that there could be instances in which no reasonable alternative exists, and the request is in effect impossible to comply with.
                    </P>
                    <P>A few commenters requested that ONC remove the requirement that an actor both “identify” and “provide” a reasonable alternative means of accessing EHI, and instead require only that an actor “identify” a reasonable alternative. One commenter expressed concern that this exception could be used to send patients to other sources to get their health information because that approach would be less burdensome than providing the information to the patient in the manner requested. The commenter recommended that ONC preclude the use of this exception for patient access requests.</P>
                    <P>Some provider, hospital, and clinical data registry commenters expressed concern regarding the potential burden on the actor related to identifying and providing a reasonable alternative means of accessing, exchanging or using the EHI. Other commenters, primarily health IT developers, expressed concern regarding the potential impact and burden on health IT developers, HINs, and HIEs of complying with a request to access, exchange, or use EHI, especially when the request requires custom development. Some commenters also noted that the proposed exception seems imbalanced, favoring the requester of the EHI over the actor providing the EHI.</P>
                    <P>
                        <E T="03">Response.</E>
                         The Content and Manner Exception in § 171.301 addresses the two groups of comments noted above: (1) Comments expressing concerns regarding the breadth of the proposed EHI definition (proposed in § 171.102, 84 FR 7601) and requesting flexibility in the implementation of the information blocking provision; and (2) comments requesting clarification concerning and improvement to our proposal in the Infeasibility Exception regarding the provision of a reasonable alternative (proposed in § 171.205(d), 84 FR 7604). In response to these comments, we have removed the reasonable alternative provision from the Infeasibility Exception and we have finalized the Content and Manner Exception in § 171.301 which describes the content (
                        <E T="03">i.e.,</E>
                         the EHI) required to be provided in an actor's response to a request to access, exchange, or use EHI and the manner in which an actor must fulfill the request in order to satisfy the exception. We believe this new exception will address the broad range of comments we received about the content of an actor's response to and manner for fulfilling a request to access, exchange, or use EHI, and will provide the clarity and transparency sought by commenters. We also believe, as discussed in more detail below, that this new exception provides market participants the ability to reach and maintain market negotiated terms for the access, exchange, and use of EHI.
                    </P>
                    <HD SOURCE="HD3">Content</HD>
                    <P>The first condition of this exception (“content condition”) in § 171.301(a) establishes the content an actor must provide in response to a request to access, exchange, or use EHI in order to meet this exception. As discussed in section VIII.C.3 of this preamble, we have focused the scope of the EHI definition in this final rule to ePHI as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501, with limited exception. We also address commenter concerns regarding the scope of the EHI definition and the pace at which we are implementing the information blocking provision through the Content and Manner Exception. Specifically, section 171.301(a)(1) states that for up to May 2, 2022, an actor must respond to a request to access, exchange, or use EHI with, at a minimum, the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) standard adopted in § 170.213. Section 171.301(a)(2) states that on and after May 2, 2022, an actor must respond to a request to access, exchange, or use EHI with EHI as defined in § 171.102.</P>
                    <P>We explained in section VIII.C of this final rule that we have finalized a new paragraph in the information blocking definition in § 171.103 that aligns with the content condition described above. That new paragraph, which is finalized in § 171.103(b), states that, until May 2, 2022, EHI for purposes of part 171 is limited to the EHI identified by the data elements represented in the USCDI standard adopted in § 170.213. We have included a detailed discussion in section VIII.C of our rationale for including the content condition in the Content and Manner Exception and for including paragraph (b) in § 171.103. That discussion includes an explanation of how those provisions address the commenters' concerns detailed above. We refer readers to the discussion in section VIII.C.</P>
                    <HD SOURCE="HD3">Manner</HD>
                    <P>
                        The second condition of this exception (“manner condition”) in § 171.301(b) establishes the manner in which an actor must fulfill a request to access, exchange, or use EHI in order to meet this exception. This condition is similar to our proposal in the Infeasibility Exception in the Proposed Rule that, for any request the actor claims is infeasible, the actor must have worked with the requesting party in a timely manner to identify and provide a 
                        <E T="03">reasonable alternative</E>
                         means of accessing, exchanging, or using the EHI, as applicable (see proposed § 171.205(d), 84 FR 7604). We explained in the Proposed Rule that this proposed condition would minimize the risk that the Infeasibility Exception could protect improper refusals to enable access, exchange or use of EHI, including discriminatory blanket refusals as well as other practices, such as improper delays for access or exchange that would present information blocking concerns (84 FR 7544).
                    </P>
                    <P>
                        After review of comments, further consideration of proposed conditions, and taking into account the revised structure of the exceptions, we determined that the concept of providing a “reasonable alternative” fits better in the Content and Manner Exception than in the Infeasibility Exception. As such, we removed the “reasonable alternative” requirement from the Infeasibility Exception and incorporated the general concept into 
                        <PRTPAGE P="25877"/>
                        the Content and Manner Exception. We believe this approach improves on the “reasonable alternative” requirement in the Proposed Rule by clarifying actors' obligations for providing access, exchange, or use of EHI in all situations; creating actionable technical procedures; and aligning the requirement for providing an alternative with the Fees and Licensing Exceptions.
                    </P>
                    <P>Under § 171.301(b)(1), an actor must fulfill a request described in the content condition (paragraph (a) of the exception) in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request (§ 171.301(b)(1)(i)). If an actor fulfills a request described in the content condition in any manner requested: (1) Any fees charged by the actor in relation to its response are not required to satisfy the Fees Exception in § 171.302; and (2) any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the Licensing Exception in § 171.303 (§ 171.301(b)(1)(ii)).</P>
                    <P>
                        Section 171.301(b)(2) provides requirements for fulfilling a request to access, exchange, or use EHI in an alternative manner than the manner requested. If an actor does not fulfill a request described in the content condition of this exception in any manner requested because it is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request, the actor must fulfill the request in an alternative manner in order to satisfy the exception. Section 171.301(b)(2)(i) states that the actor must fulfill the request without unnecessary delay in the following order of priority, starting with the first paragraph and only proceeding to the next consecutive paragraph if the actor is technically unable to fulfill the request in the manner identified in a paragraph. That order of priority is as follows: (1) Using technology certified to standard(s) adopted in part 170 that is specified by the requestor (§ 171.301(b)(2)(i)(A)); (2) using content and transport standards specified by the requestor and published by the Federal Government or a standards developing organization accredited by the American National Standards Institute (ANSI) 
                        <SU>183</SU>
                        <FTREF/>
                         (§ 171.301(b)(2)(i)(B)); and (3) using an alternative machine-readable format, including the means to interpret the EHI, agreed upon with the requestor (§ 171.301(b)(2)(i)(C)). Section 171.301(b)(2)(ii) requires that any fees charged by the actor in relation to fulfilling the request must satisfy the Fees Exception in § 171.302. Similarly, § 171.301(b)(2)(iii) requires that any license of interoperability elements granted by the actor in relation to fulfilling the request is required to satisfy the Licensing Exception in § 171.303.
                    </P>
                    <FTNT>
                        <P>
                            <SU>183</SU>
                             
                            <E T="03">See</E>
                              
                            <E T="03">https://www.ansi.org/</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We chose this approach because we believe actors should, first and foremost, attempt to fulfill requests to access, exchange, or use EHI in the manner requested. This principle is central to our information blocking policies (
                        <E T="03">e.g.,</E>
                         it was part of the proposed Infeasibility Exception) and will help ensure that EHI is made available where and when it is needed. Our approach acknowledges, however, that there may be instances when an actor should not be required to respond in the manner requested.
                    </P>
                    <P>
                        First, if an actor is 
                        <E T="03">technically unable</E>
                         to fulfill a request to access, exchange, or use EHI in the manner requested, the actor is allowed to fulfill the request in an alternative manner (§ 171.301(b)(1)(i)). We emphasize that we use “technically unable” in this context to mean that actors 
                        <E T="03">cannot</E>
                         fulfill a request to access, exchange, or use EHI due to technical limitation. For example, if an individual requested their EHI via an API and the actor could not fulfill the request via the API, but the individual then requested the EHI be provided via email and the actor was technically able to do so, we expect that the actor would fulfill the request in that “manner requested.” This standard sets a very high bar, and would not be met if the actor is technically able to fulfill the request, but chooses not to fulfill the request in the manner requested due to cost, burden, or similar justifications. If, for instance, under the alternative manner, fulfilling the request would prove costly for the actor, the actor would be able to charge a fee that results in a reasonable profit margin under the Fees Exception in § 171.302 or license any requisite interoperability elements and make reasonable royalties under the Licensing Exception in § 171.303. If the burden on the actor for fulfilling the request is so significant that the actor chooses not to fulfill the request at all, the actor could seek coverage under the Infeasibility Exception in § 171.204. We believe this framework for utilizing this exception, which works in harmony with the Infeasibility Exception (§ 171.204), Fees Exception (§ 171.302), and Licensing Exception (§ 171.303), is principled and tailored in a manner that will promote basic fairness and encourage parties to work cooperatively to implement efficient solutions to interoperability challenges.
                    </P>
                    <P>
                        Second, we establish that an actor is not required to fulfill a request to access, exchange, or use EHI in the manner requested if the actor cannot reach agreeable terms with the requestor to fulfill the request (§ 171.301(b)(1)(i)). We also establish that if an actor fulfills a request to access, exchange, or use EHI in 
                        <E T="03">any manner requested,</E>
                         the fees or licenses associated with fulfilling such requests will 
                        <E T="03">not</E>
                         be limited by the conditions in the Fees Exception or Licensing Exception. These provisions will allow actors to first attempt to negotiate agreements in any manner requested with whatever terms the actor chooses and at the “market” rate—which supports innovation and competition. We then allow flexibility for actors to still satisfy the exception by fulfilling the request in an alternative manner if the actor cannot reach agreeable terms with the requestor to fulfill the request. For instance, under the exception, actors who cannot reach agreeable terms with the requestor to fulfill the request are 
                        <E T="03">not</E>
                         required to license their IP to proprietary technology in order to satisfy the exception.
                    </P>
                    <P>
                        In contrast, § 171.301(b)(2)(ii) and (iii) require that any fees charged or licenses granted by the actor in relation to fulfilling a request to access, exchange, or use EHI in an 
                        <E T="03">alternative</E>
                         manner 
                        <E T="03">must</E>
                         satisfy the Fees Exception in § 171.302 and the Licensing Exception in § 171.303. We recognize that it is possible that responding in an alternative manner may require licensing of interoperability elements. However, we do not believe that, in most cases, licensing certified technology (§ 171.301(b)(2)(i)(A)) or standards-based technology (§ 171.301(b)(2)(i)(B)) would involve the type of licensing of proprietary interoperability elements that concerned the majority of commenters because the standards in § 171.301(b)(2)(i)(a) and (B) are “open” standards. Therefore, it is our understanding that a health IT developer of certified health IT would not normally be required to license its IP in order to meet the requirements for fulfilling a request to access, exchange, or use EHI in those alternative manners. On the other hand, the technology/software that the developer uses to fulfill a request in any manner requested 
                        <E T="03">could</E>
                         constitute the developer's IP, depending on the request. We emphasize that this exception does 
                        <E T="03">not</E>
                         require developers to open-source their technology/software.
                    </P>
                    <P>
                        For instance, if a health IT developer of certified health IT enables access to 
                        <PRTPAGE P="25878"/>
                        EHI using HL7 (which is an ANSI-accredited standards developing organization) FHIR Release 2 (R2) Standard, that means the developer will provide EHI in the format specified in FHIR R2. In this example, the actual software code that is used by the developer to convert the EHI from the developer's proprietary format to FHIR R2 is the developer's IP and is not required to be provided to the requestor. We also note that our experience and knowledge of the health IT landscape indicate that the market is increasingly moving toward open standards, and we believe this movement will further decrease the need to license IP in the future. We believe this framework and approach are supportive of innovation and address commenter concerns regarding their ability to protect their IP.
                    </P>
                    <P>
                        We included in § 171.301(b)(2)(i) that an actor must fulfill the request 
                        <E T="03">without unnecessary delay</E>
                         in order to make clear that actors seeking coverage under this exception by responding in an alternative manner will be held to same unnecessary delay or “timeliness” considerations as all actors are in determining whether there is an interference under the information blocking provision. The fact that an actor responds in an alternative manner does 
                        <E T="03">not</E>
                         entitle that actor to any additional time to respond to a request to access, exchange, or use of EHI that the actor would not be afforded if responding in any manner requested. As such, any unnecessary delays related to responding in an alternative manner could disqualify an actor from meeting the alternative manner condition in the same way that an unnecessary delay in responding to a request to access, exchange, or use EHI in any manner requested could constitute an interference. We refer readers to the discussion of “Limiting or Restricting the Interoperability of Health IT” in section VIII.C.6.c.ii.
                    </P>
                    <P>Under § 171.301(b)(2)(i)(A), if an actor does not fulfill a request described in the content condition of this exception in any manner requested because it is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request, the actor must fulfill the request in an alternative manner. Specifically, the actor must attempt to fulfill the request using technology certified to standards adopted in part 170 specified by the requestor. This manner of response is given precedence because it advances a certified, standards-based approach that supports the Promoting Interoperability Programs (previously Medicare and Medicaid EHR Incentive Programs) administered by the Centers for Medicare &amp; Medicaid Services (CMS), other Federal and State programs that use certified health IT, and other Federal Departments (Department of Defense and Veterans Affairs). In addition, the certification criteria under the ONC Health IT Certification Program (the Program) include robust oversight, including technical and interoperability requirements, ONC-Authorized Certification Body (ONC-ACB) in-the-field surveillance expectations, and cost transparency and other disclosure requirements. To illustrate how this would work, if the requestor only requests the EHI using the C-CDA 2.1 content standard, then the actor would not have to also use the Direct transport standard to provide the EHI. However, if the requestor requests the EHI through the use of both standards, then the actor would be expected to respond in such a manner if the actor has certified health IT that supports both standards.</P>
                    <P>If the actor is technically unable to respond using technology certified to standards adopted in part 170 specified by the requestor, then the actor may respond using content and transport standards specified by the requestor and published by the Federal Government or a standards developing organization accredited by the ANSI (§ 171.301(b)(2)(i)(B)). We chose to specify that standards published by a standards developing organization accredited by ANSI would qualify for this manner of response because ANSI oversees the development of voluntary consensus standards in the United States and it accredits standards that are developed by representatives of other standards organizations. ANSI accreditation signifies that the procedures used by standards developing organizations meet the institute's requirements for openness, balance, consensus, and due process. Voluntary consensus standards developed by an ANSI-accredited standards developing organization carry a high degree of acceptance both in United States and internationally. ANSI has broad membership across government agencies, industry, academia, and international bodies and is the official United States representative to the International Organization of Standards (ISO). This manner of response also advances interoperability through standards-based exchange, even if the standard is not certified under the Program.</P>
                    <P>
                        As noted above, the “manner” of response specific in § 171.301(b)(2)(i)(B) includes two distinct components: (1) Content standard; and (2) transport standard. The content standard deals with whether the information is in an appropriate format and is universally understood. This standard includes the structure (
                        <E T="03">i.e.,</E>
                         syntax) and terminology (
                        <E T="03">i.e.,</E>
                         semantics) of the EHI. Examples of content standards include: US Fast Healthcare Interoperability Resources (FHIR) Core IG; Consolidated Clinical Document Architecture (C-CDA 2.1); HL7 V2.5.1; HL7 v2.7 (which is a standard that is not part of certification from an ANSI-accredited standards developing organization); and Argonaut Data Query Implementation Guide. The transport standard is the method to connect two or more parties without a focus on the data that is transported from one party to another. Put another way, the transport standard is the method by which information moves from one point to another. Examples of transport standards include: 
                        <E T="03">Direct Project Standard,</E>
                         ONC Applicability Statement for Secure Health Transport, Version 1.0 (incorporated by reference in § 170.299) (§ 170.202(a)); and Simple Object Access Protocol (SOAP) based exchange specifications such as “Nationwide Health Information Network Messaging Platform Specification.” 
                        <SU>184</SU>
                        <FTREF/>
                         Under the manner condition, an actor could proceed to the next consecutive “manner” under § 171.301(b)(2)(i) if the actor was technically unable to respond with 
                        <E T="03">either</E>
                         the content standard or the transport standard requested.
                    </P>
                    <FTNT>
                        <P>
                            <SU>184</SU>
                             
                            <E T="03">See</E>
                             ONC, Connecting Health and Care for the Nation, A Shared Nationwide Interoperability Roadmap, FINAL Version 1.0, 
                            <E T="03">https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf</E>
                            ; ONC, 2015 Interoperability Standards Advisory, 
                            <E T="03">https://www.healthit.gov/isa/sites/default/files/2015interoperabilitystandardsadvisory01232015final_for_public_comment.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        Last, if an actor is technically unable to fulfill a request for access, exchange, or use of EHI using a content and transport standard specified by the requestor and published by the Federal Government or a standards developing organization accredited by ANSI, 
                        <E T="03">only then</E>
                         can the actor respond using an alternative machine-readable format, including the means to interpret the EHI, agreed to by the actor and requestor (§ 171.301(b)(2)(i)(C)). This option to respond using an agreed upon alternative machine-readable format is a flexible option for actors who cannot meet the “manner” requirements in § 171.301(b)(2)(i)(A) and (B), but still want to be responsive to the requestor and seek coverage under this exception. Examples of alternative machine readable formats include CSV, public domain standards, public advisory 
                        <PRTPAGE P="25879"/>
                        standards, and other community efforts used to represent the data.
                    </P>
                    <P>We emphasize two key components of § 171.301(b)(2)(i)(C). First, the alternative machine-readable format must include the means to interpret the EHI. The goal with this requirement is to ensure that, if an actor fulfills a request for access, exchange, or use of EHI using an alternative machine-readable format, the EHI provided through that format will be usable by the requestor. As an example, the format used for the EHI Export functionality (§ 170.315(b)(10)) discussed earlier in this final rule could be used to fulfill such a request. Second, the alternative machine-readable format must be agreed upon with the requestor. This condition ensures that, even if the actor is technically unable to meet the requirements in § 171.301(b)(2)(i)(A) and (B), the actor is still providing the requestor the opportunity to access, exchange, or use the EHI in a manner that is amenable to the requestor.</P>
                    <HD SOURCE="HD3">b. Fees Exception—When will an actor's practice of charging fees for accessing, exchanging, or using electronic health information not be considered information blocking?</HD>
                    <P>
                        We proposed in the Proposed Rule to establish an exception at § 171.204 (84 FR 7589) to the information blocking provision that would permit the recovery of certain costs reasonably incurred for the access, exchange, or use of EHI. We interpreted the definition of information blocking to include 
                        <E T="03">any</E>
                         fee that is likely to interfere with the access, exchange, or use of EHI. We noted that this interpretation may be broader than necessary to address genuine information blocking concerns and could have unintended consequences on innovation and competition. Specifically, unless we establish an exception, actors may be unable to recover costs that they reasonably incur to develop technologies and provide services that enhance interoperability. This could undermine the ultimate goals of the information blocking provision by diminishing incentives to invest in, develop, and disseminate interoperable technologies and services that enable more robust access, exchange, and use of EHI. Therefore, we proposed to establish an exception that would permit the recovery of certain costs that we believe are unlikely to present information blocking concerns and would generally promote innovation, competition, and consumer welfare, provided certain conditions are met. We emphasized that actors can make a reasonable profit under this exception, provided that all applicable conditions are met (84 FR 7538 through 7541).
                    </P>
                    <P>
                        We proposed that the exception would be subject to strict conditions to prevent its potential abuse. Specifically, we explained our concern that a broad or insufficiently tailored exception for the recovery of costs could protect rent-seeking, opportunistic fees, and exclusionary practices that interfere with the access, exchange, and use of EHI. We explained that these practices fall within the definition of information blocking and reflect some of the most serious concerns that motivated its enactment (see 84 FR 7538 and section VIII.B of this preamble). For example, in the Information Blocking Congressional Report,
                        <SU>185</SU>
                        <FTREF/>
                         we cited evidence of wide variation in fees charged for health IT products and services. While we cautioned that the issue of fees is nuanced, and that variations in fees could be attributable in part to different technology architectures, service models, capabilities, service levels, and other factors, we concluded that these factors alone could not adequately explain all of the variation in prices that we had observed. Based on these and other indications, we concluded that some actors were engaging in opportunistic pricing practices or, in some cases, charging prices designed to deter connectivity or exchange with competing technologies or services. In the time since we published the Information Blocking Congressional Report, these practices have persisted and, in certain respects, become more pronounced. In a national survey of HIE executives published in 2017, 47 percent of respondents reported that EHR developers “often/routinely” charge high fees for exchange that are unrelated to cost, and another 40 percent reported that they “sometimes” do.
                        <SU>186</SU>
                        <FTREF/>
                         Meanwhile, we have continued to receive credible evidence of rent-seeking and other opportunistic behaviors, such as fees for data export and data portability that are not plausibly related to any time, materials, or other costs that a developer would reasonably incur to provide these services. And, while some practices described in the Information Blocking Congressional Report have become less prevalent (such as the charging of per-transaction fees), other practices have emerged that are equally concerning (84 FR 7538).
                    </P>
                    <FTNT>
                        <P>
                            <SU>185</SU>
                             ONC, Information Blocking Congressional Report (April 2015), 
                            <E T="03">https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>186</SU>
                             Julia Adler-Milstein and Eric Pfeifer, 
                            <E T="03">Information Blocking: Is It Occurring And What Policy Strategies Can Address It?,</E>
                             95 Milbank Quarterly 117, 124-25 (Mar. 2017), 
                            <E T="03">available at http://onlinelibrary.wiley.com/doi/10.1111/1468-0009.12247/full</E>
                            .
                        </P>
                    </FTNT>
                    <P>As just one illustration, some EHR developers have begun conditioning access or use of customer EHI on revenue-sharing or royalty agreements that bear no plausible relation to the costs incurred by the EHR developer to grant access to the EHI. We have also heard of discriminatory pricing policies that have the obvious purpose and effect of excluding competitors from the use of interoperability elements. Many of the industry stakeholders who shared their perspectives with us in listening sessions prior to the Proposed Rule, including several health IT developers of certified health IT, condemned these practices and urged us to swiftly address them (84 FR 7538).</P>
                    <P>In light of these concerns, we proposed that this exception would apply only to the recovery of certain costs and only when the actor's methods for recovering such costs comply with certain conditions at all relevant times. In general, these conditions would require that the costs the actor recovered were reasonably incurred, did not reflect costs that are speculative or subjective, were appropriately allocated, and based on objective and verifiable criteria. Further, the exception would not apply to certain fees, such as those based on the profit or revenue associated with the use of EHI (either being earned by the actor, or that could be realized by another individual or entity) that exceed the actor's reasonable costs for providing access, exchange, or use of the EHI (84 FR 7539 through 7541).</P>
                    <P>Finally, the exception would provide additional conditions applicable to fees charged in connection with: (1) The certified APIs described in § 170.404 (84 FR 7594); and (2) the EHI export criterion proposed in § 170.315(b)(10) (84 FR 7590) to support single patient EHI export and to support the export of all EHI when a health care provider chooses to migrate information to another health IT system. We emphasized that access to EHI that is provisioned by supplying some form of physical media, such as paper copies (where the EHI is printed out), or where EHI is copied onto a CD or flash-drive, would not be a practice that implicated the information blocking provision provided that the fee(s) charged for that access complied with the HIPAA Privacy Rule (45 CFR 164.524(c)(4)) (84 FR 7539).</P>
                    <HD SOURCE="HD3">Clarification</HD>
                    <P>
                        We clarify that the Fees Exception we have finalized in this rule in no way supports or encourages the 
                        <E T="03">sale of EHI.</E>
                          
                        <PRTPAGE P="25880"/>
                        We emphasize that this exception permits the recovery of certain costs reasonably incurred for the 
                        <E T="03">access, exchange, or use</E>
                         of EHI. We note that many individuals and entities who are considered “actors” under the information blocking provision are also subject to the HIPAA Privacy Rule and therefore prohibited from selling PHI unless certain conditions are met, and in particular, receiving remuneration for a disclosure of PHI in accordance with 45 CFR 164.502(a)(5)(ii). This exception to the information blocking definition in no way affects existing HIPAA Privacy Rule compliance responsibilities of entities subject to the HIPAA Rules.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments in general support of the proposed exception. Commenters appreciated ONC's goal of addressing rent-seeking, opportunistic fees, and exclusionary practices that interfere with the access, exchange, and use of EHI. Some commenters suggested that ONC should take additional steps and measures to ensure that the requirements under this exception are clear. A couple of commenters recommended that fees and costs of information exchange should be made publicly available. Another commenter suggested that ONC develop a process for actors to routinely report their use of this exception, including specific timeframes for actors to submit information to ONC and for ONC to determine whether the exception can be applied under specific circumstances.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of and feedback on this exception. We appreciate the suggestions for improved transparency under this exception. We believe actors should have discretion to decide if they would like to enhance transparency by making fees and costs of information exchange publicly available. We believe that choosing not to disclose fees, on its own, would not likely implicate the information blocking provision. Further, while we wholeheartedly support the goal of enhanced transparency and commend commenters' desire to enhance transparency in the final rule, we believe their suggestions could create additional burden for actors and such burden could outweigh the benefits of the measures they suggest. We will continue to consider steps to further promote transparency regarding our information blocking policies in future rulemakings.
                    </P>
                    <P>We appreciate the comment that we should develop a process for letting actors know whether this exception could be applied under certain circumstances. We may consider developing materials in the future regarding the application of the exceptions should the need arise. However, we believe the final rule clearly describes the conditions actors must meet in order to be covered by each exception, and informational materials are not necessary at this time.</P>
                    <HD SOURCE="HD3">Requirement That Costs Be Reasonably Incurred</HD>
                    <P>In the Proposed Rule, we stated that, regardless of the type of cost at issue, a basic condition of the proposed exception was that any costs the actor seeks to recover must have been reasonably incurred to provide the relevant interoperability elements for the access, exchange, or use of EHI. Whether a cost was reasonably incurred will ultimately depend on the particular facts and circumstances. We requested comment on considerations that may be relevant to assessing the reasonableness of costs incurred for purposes of this exception (84 FR 7539).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested additional clarity in the final rule regarding various terms and concepts in the proposed exception. Commenters noted that many terms and concepts regarding the reasonableness of fees, and which fees would or would not be considered “reasonably incurred” under the exception, were ambiguous and overly broad. Some commenters were concerned that such ambiguity and vagueness could undercut ONC's overall intent to prevent rent-seeking and opportunistic fees and could create a loophole that would enable actors to use the exception to continue to charge unreasonably high fees. Some commenters requested additional examples of “costs reasonably incurred” under the exception. One commenter asked that ONC outline different cost categories (such as development costs, deployment costs, usage costs) and indicate which of those costs would or would not fall under the exception. A couple of commenters requested that ONC explicitly state that fees the actor pays to a developer for “Release of Information” (ROI) services and technology would be considered “costs reasonably incurred.”
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. Actors may choose to satisfy the conditions of this exception to be certain that the fees they charge for the access, exchange, or use of EHI do not implicate the information blocking provision. We reiterate that failure to meet the exception does not mean that an actor's practice related to charging fees meets the information blocking definition. However, as we explained in the Proposed Rule, we interpret the broad definition of information blocking in section 3022(a) of the PHSA to encompass 
                        <E T="03">any</E>
                         fee that is likely to interfere with the access, exchange, or use of EHI (84 FR 7521). Fees that do not meet this exception may implicate the information blocking provision and will have to be assessed on a case-by-case basis to determine, for example, the actor's intent and whether the practice rises to the level of an interference. Consistent with the conditions of this exception, an actor seeking the significant protection afforded by this exception will have to assess the fees they charge in light of the costs incurred.
                    </P>
                    <P>
                        We emphasize that our intention with this exception is not to set any particular fees related to products or services for accessing, exchanging, or using EHI, but rather to allow the market to define the appropriate price for such products or services so long as certain methods are followed and certain criteria are met. We believe this approach is appropriate for this exception in light of the considerable diversity in the types of costs actors might incur and the range of factors that could bear on the reasonableness of those costs. For example, the costs of developing software may vary with the purposes it is intended to serve, the settings in which it will be deployed, the types and scope of capabilities included, and the extent to which these development efforts build on existing development efforts and know-how. Additionally, the costs of providing services, including the implementation of technology in production environments, may vary based on the technology design or architecture, individual customer needs, local implementation conditions, and other factors. An analysis of the approach for recovering costs will also account for different distribution and service models under which the costs are calculated. For these reasons, we have decided not to specify cost categories, such as development costs, deployment costs, usage costs, or ROI services and technology costs. However, we note that if an actor meets all necessary conditions of the finalized exception, the actor 
                        <E T="03">could</E>
                         recover such categories of cost under the exception.
                    </P>
                    <P>
                        We have taken a few distinct steps to clarify this exception and address the overall concern from commenters regarding the clarity of this exception. First, we have restructured the exception for clarity. We have changed the title of the exception from “Exception—Recovering costs reasonably incurred” to “When will an actor's practice of charging fees for 
                        <PRTPAGE P="25881"/>
                        accessing, exchanging, or using electronic health information not be considered information blocking?” Throughout this final rule preamble, we use “Fees Exception” as a short form of this title, for ease of reference. As stated in Section VIII.D of this final rule preamble, we have changed the titles of all of the exceptions to questions to improve clarity. We have also edited the wording of the introductory text in § 171.302, in comparison to that proposed (84 FR 7603), so that it is consistent with the finalized title in § 171.302. We believe these conforming changes in wording of the introductory text also improve clarity in this section.
                    </P>
                    <P>We have also divided the exception into three conditions in § 171.302—(a) Basis for fees condition; (b) Excluded fees condition; and (c) Compliance with the Conditions of Certification condition. We explain upfront in the introductory sentence of the exception that, pursuant to these conditions, an actor may charge fees, including fees that result in a reasonable profit margin, for the access, exchange, or use of EHI without implicating the information blocking provision. We believe this framework provides actors with a clear roadmap for voluntarily satisfying the conditions of the exception. We discuss the substantive changes we have made to these provisions in the discussion of each condition later in this section of the preamble.</P>
                    <P>We also note that we have further clarified the fees allowed under this exception by focusing the scope of the EHI definition (discussed in section VIII.C.3 of this preamble) and adding paragraph (b) to the information blocking definition in § 171.103 (discussed in section VIII.C of this preamble). By changing the definition of EHI to electronic protected health information (ePHI) as defined in 45 CFR 160.103 included in a designated record set as defined in 45 CFR 164.501, we have focused the scope of information covered by the information blocking provision. In addition, under the finalized information blocking definition, for up to 18 months after the six-month delayed compliance date of the information blocking section of this final rule (part 171) (a total of 24 months after the publication date of this final rule), EHI for purposes of the information blocking definition is limited to the EHI identified by the data elements represented in the USCDI standard adopted in § 170.213 (see (§ 171.103(b)).</P>
                    <HD SOURCE="HD3">Basis for Fees Condition</HD>
                    <P>To qualify for this exception, we proposed that the method by which the actor seeks to recover its costs must meet certain conditions. We proposed that this would require that the actor base its recovery of costs on objective and verifiable criteria that are uniformly applied for all substantially similar or similarly situated classes of persons and requests. We proposed that any differences in prices or price terms would have to be based on actual differences in the costs that the actor incurred or other reasonable and non-discriminatory criteria. We further proposed to require that the method by which the actor recovers its costs must be reasonably related to the actor's costs of providing the type of access, exchange, or use to, or at the request of, the person or entity to whom the fee is charged (84 FR 7539).</P>
                    <P>We also proposed that the costs must be reasonably allocated among all customers to whom the technology or service is supplied, or for whom the technology is supported. A reasonable allocation of costs would require that the actor allocate its costs in accordance with criteria that are reasonable and between only those customers that either cause the costs to be incurred or benefit from the associated supply or support of the technology (84 FR 7539).</P>
                    <P>We proposed that the exception would not apply if the method by which the actor recovers its costs is based, in any part, on whether the requestor or other person is a competitor, potential competitor, or will be using the EHI in a way that facilitates competition with the actor. The use of such criteria would be suspect because it suggests the fee the actor is charging is not based on its reasonable costs to provide the services and may have the purpose or effect of excluding or creating impediments for competitors, business rivals, or other persons engaged in developing or enabling the use of interoperable technologies and services (84 FR 7539).</P>
                    <P>
                        Last, we stated that the method by which the actor recovers its costs must not be based on the sales, profit, revenue, or other value that the requestor or other persons derive or may derive from the access to, exchange of, or use of EHI, including the secondary use of such information, that 
                        <E T="03">exceeds</E>
                         the actor's reasonable costs for the access, exchange, or use of EHI (84 FR 7539).
                    </P>
                    <P>We requested comment on the proposed conditions and other issues we should consider in assessing whether the methodology by which an actor distributes costs and charges fees should be considered reasonable and necessary for purposes of the exception. In particular, we noted that we were considering whether to introduce specific factors and methods for assessing when profit will be reasonable. We requested comment on whether the pro-competitive or efficiency-adding aspect of an actor's approach to providing access, exchange, or use of EHI should be taken into account when assessing the reasonableness of profits. We asked commenters to consider whether there are specific use cases for which actors' profits should be limited or prohibited for purposes of meeting the exception (84 FR 7539).</P>
                    <P>We also asked commenters to consider alternate approaches to the exception that would also achieve the goal of allowing actors to recover certain types of costs that would promote innovation, competition and consumer welfare and that are unlikely to present information blocking concerns. In assessing other potential approaches to this exception, we encouraged commenters to contemplate such considerations as enforceability, potential burden on the parties, and overall effectiveness in meeting the above stated goals (84 FR 7539).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments regarding our proposed approach for cost recovery and profits. Some commenters supported our proposed approach. A couple of commenters recommended that we prohibit all profits under the exception to ensure that actors cannot continue rent-seeking and exclusionary pricing practices. Several commenters requested clarification regarding the profits that would be allowed under the exception and expressed concern that the regulation text does not clearly state that profits are allowed under the exception. Several other commenters, primarily health IT developers, disagreed with the proposed cost recovery approach and limits on profits, expressing concern that ONC's proposals will serve as a barrier to innovation, competition, and interoperability. Some commenters stated that ONC's proposals regarding fees and profits go beyond the congressional intent in the Cures Act and questioned whether ONC has regulatory authority to regulate costs and profits.
                    </P>
                    <P>
                        We received some comments that recommended we take a different approach for assessing whether an actor's costs recovered are reasonable. Commenters recommended using an approach that distinguishes, as appropriate, between: (1) Pure cost or expense recovery, with no provision for margin or profit; (2) “cost-based pricing” or “cost plus accounting,” where margin or profit is allowed; and (3) “market-based pricing,” where there 
                        <PRTPAGE P="25882"/>
                        are no restrictions on pricing. A couple of commenters recommended that where a cost-based pricing mechanism is required, the method for assessing the cost basis should be reasonably associated with the complexity or cost of providing the capabilities. Such methods could include reasonable heuristics, estimates, or other commonly used methods.
                    </P>
                    <P>Commenters recommended that we distinguish “basic access” (with no profits or limited profits) from “value-added” access, exchange, or use (which would allow for increased profits). A couple of commenters recommended that allowed fees for “basic access” be on a pure direct cost recovery basis only. Those commenters recommended that the cost to develop and/or map to standards should not be part of the cost basis for fees for “basic access;” rather any such costs should be a part of the fees for the health IT. The commenters recommended that when the outputs of value-added services are incorporated into, or from, an essential part of the legal medical record, or are routinely used for decision making, they constitute part of the set to which basic access is required. The commenters also recommended that we distinguish between intellectual property (IP) rights that are essential to access EHI and IP rights that allow for value-added services.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of our proposals and for the thoughtful comments on this aspect of the exception. We appreciate that commenters were concerned both about the elimination of rent-seeking, opportunistic fees, and exclusionary pricing practices that interfere with the access, exchange, and use of EHI as well as the importance of finalizing policies that support and promote innovation. We have finalized the proposed approach for determining whether the basis for fees charged is acceptable under this exception, with some clarifications and updates detailed below.
                    </P>
                    <P>
                        As we discussed in the Proposed Rule, we believe our approach will provide actors that seek to meet this exception certainty that charging fees to recover certain costs reasonably incurred for the access, exchange, or use of EHI will not implicate the information blocking provision, provided the actor's practice meets the conditions of the exception. We reiterate that an actor who seeks to comply with the conditions of this exception will 
                        <E T="03">not</E>
                         be prevented from making a reasonable profit in connection with the access, exchange, or use of EHI, provided that all applicable conditions are met. We emphasize that our intention with this exception is not to set any particular costs that would be considered “reasonably incurred,” but rather to allow the market to define the appropriate price so long as certain methods are followed and certain criteria are met as established by the conditions. To be responsive to comments, we have added text in the introductory sentence of this exception that clarifies that fees that result in a reasonable profit margin will be covered by this exception so long as they are in compliance with the conditions in the exception (§ 171.302).
                    </P>
                    <P>We also appreciate the comments that encouraged us to prohibit all profits under this exception. We considered this approach, but believe that actors should be able to make a reasonable profit margin, subject to the conditions in this exception. The allowance of a reasonable profit margin is necessary to incentivize innovation and allow innovators to earn returns on the investments they have made to develop, maintain, and update innovations that ultimately improve health care delivery and benefit patients. We believe the finalized approach strikes the appropriate balance of addressing the rent-seeking and exclusionary pricing practices noted by the commenters while enabling and supporting innovation. However, to be responsive to these comments related to limiting profits, we added a provision in § 171.302(a)(1)(iv) that the fees an actor charges must be based on costs not otherwise recovered for the same instance of service to a provider and third party. The intent of this provision is that the exception will not apply to practices where an actor charges twice for the same exact service. For example, the exception likely would not apply where an actor charges a hospital for providing a third party that the hospital contracts with access to certain EHI, and then charges that same third party an additional fee for access to the same EHI. This condition creates a necessary guardrail to address potential misuse of this exception that could result in a windfall for certain actors who charge fees for the same services multiple times.</P>
                    <P>We have also modified other aspects of this final rule that address commenter concerns regarding this exception. First, as discussed previously in this section and in more detail in section VIII.C.3 of this preamble, we have focused the scope of the EHI definition. This change addresses commenters' concerns regarding potential ambiguity regarding the types of information for which profits could be realized. Actors seeking certainty about their practices related to charging fees only need to comply with this exception if their practices interfere with the access, exchange, and use of EHI. We emphasize that we are not limiting the fees and/or profits related to the access, exchange, or use of information outside the scope of EHI. We refer readers to section VIII.C.3 of this preamble for a detailed discussion of focused scope of the EHI definition.</P>
                    <P>Second, under the finalized information blocking definition, for up to 18 months after the six-month delayed compliance date of the information blocking section of this final rule (part 171) (a total of 24 months after the publication date of this final rule), EHI for purposes of part 171 is limited to the EHI identified by the data elements represented in the USCDI standard adopted in § 170.213 (see (§ 171.103(b)). The fees an actor charges during that time will only be limited pursuant to the conditions in this exception for that subset of EHI.</P>
                    <P>
                        We note that we revised § 171.302(a)(1)(i) for clarity by limiting the requirement to “objective and verifiable criteria that are uniformly applied for all 
                        <E T="03">similarly situated</E>
                         classes of persons and requests” instead of “objective and verifiable criteria that are uniformly applied for all 
                        <E T="03">substantially similar or similarly situated</E>
                         classes of persons and requests.” We believe the final standard achieves the same goal as the proposed standard and provides a clearer condition for the regulated community to follow. We updated § 171.302(a)(2)(ii) by removing the illustrative language regarding the “secondary use of such information” and by removing the proposed language about exceeding the actor's reasonable costs for providing access, exchange, or use of EHI (see 84 FR 7539). The provision finalized in § 171.302(a)(1)(ii)—that an actor's fees must be reasonably related to the actor's costs of providing the type of access, exchange, or use of EHI to, or at the request of, the person or entity to whom the fee is charged—achieves the same purpose of limiting fees to those necessary to recover the costs reasonably incurred.
                    </P>
                    <P>
                        We removed the “secondary use” language because it seemed superfluous to include in the regulation text; however, we emphasize that we maintain that the fees an actor charges must 
                        <E T="03">not</E>
                         be based on the sales, profit, revenue or other value that the requestor or other persons derive or may derive from the subsequent use of EHI. Our policy on this point has not changed from the Proposed Rule. Practices that use this method to recover costs will not 
                        <PRTPAGE P="25883"/>
                        benefit from this exception and may implicate the information blocking provision. Last, we note that we have added “or entities” to follow “person” to align with the language in § 171.302(a)(1)(ii).
                    </P>
                    <P>We note, with regard to the “basis for fees” and “excluded fees” conditions (§ 171.302(a) and (b), respectively), that each provision under these conditions was proposed in the Proposed Rule with the exception of two new provisions: (1) The fees an actor charges must be based on costs not otherwise recovered for the same instance of service to a provider and third party (§ 171.302(a)(1)(iv)); and (2) the fees an actor charges must not be based on any costs that led to the creation of IP, if the actor charged a royalty for that IP pursuant to § 171.303 and that royalty included the development costs for the creation of the intellectual property (§ 171.302(a)(2)(vi)). We discuss each of these additions in the discussion below. Regarding the conditions that were included in the proposed exception, we note that some of the conditions were in different subsections of the proposed exception and/or have been updated for clarity and consistency with other sections of this final rule. We describe all the substantive changes to these provisions in this preamble, but refer readers to the proposed exception to review the full scope of structural changes and clarifications we have made (see 84 FR 7603).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received some comments regarding the scaling of fees and the proposed condition that the method by which the actor recovers its costs must be reasonably allocated among all customers to whom the technology or service is supplied or for whom the technology is supported. Some commenters stated that the notion that costs can be evenly divided among clients is flawed. Commenters requested that ONC allow a fee scale as opposed to a blanket fee structure. Commenters noted that a sliding scale structure would ensure that smaller entities would not be limited by a restrictive pricing application that threatens their operating costs, which may exist on a slim margin. A couple of commenters requested that ONC recognize that for many organizations, especially non-profits, it is common and appropriate for fees to scale with the size of a member/participant organization.
                    </P>
                    <P>Several HIEs and HINs expressed concern that the proposed condition regarding the reasonable allocation of costs could have the unintended effect of prohibiting the fee structure of many public HIEs/HINs. Commenters noted that many HIEs/HINs choose to charge fees to only a subset of their participants. However, as proposed, the condition that costs be reasonably allocated among all customers could undercut this ability. Commenters emphasized that the ability to offer free services to smaller providers, particularly as HIEs/HINs work to engage providers across the care continuum, is an important flexibility for such organizations. Commenters requested that HIE/HIN membership/participation costs and subscription fees not be considered restricted fees under the information blocking provision.</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these thoughtful comments. We maintain that the condition regarding reasonable allocation of costs in § 171.302(a)(iii) is necessary to ensure that actors do not allocate fees in an arbitrary or anti-competitive manner. The final condition requires that an actor allocate its costs in accordance with criteria that are reasonable and between only those customers that either cause the costs to be incurred or benefit from the associated supply or support of the technology. We have finalized this condition with a modification discussed below.
                    </P>
                    <P>
                        We agree with commenters that there may be situations when it would be reasonable for an actor to allocate costs differently for different classes of customers. In response to these comments, we have revised the condition in § 171.302(a)(1)(iii) so that the fees an actor charges must be reasonably allocated among all 
                        <E T="03">similarly situated</E>
                         customers to whom the technology or service is supplied, or for whom the technology is supported. This addition addresses commenters' concerns by providing actors with the discretion to allocate costs differently for different classes of customers, while ensuring that any differences in cost allocation are based on actual differences in the class of customer. For instance, under this provision, fees must be reasonably allocated among all similarly situated large hospital systems (above a certain established size threshold) to whom a technology or service is supplied, or for whom the technology is supported. However, the allocation of fees for the same technology or service could be quite different for a small, non-profit, rural health clinic.
                    </P>
                    <P>We also note that we have replaced “customers” with “persons or entities” in § 171.302(a)(1)(iii) in order to align the language with § 171.302(a)(1)(i) and (ii). We believe aligning the provisions within § 171.302(a) will strengthen the exception and provide actor's with clarity regarding what is necessary to meet the exception.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments, primarily from providers and provider organizations, regarding the potential financial burden the proposed exception will place on actors. Commenters recommended that ONC carefully consider the downstream financial impact of new requirements, especially that providers, including providers without certified health IT and who do not participate in CMS programs, will bear the brunt of the financial burden of these policies. More specifically, commenters expressed concern regarding potential recordkeeping and administrative burden caused by this exception. Commenters explained that actors may need to retain extensive records to document all of the costs that the actor incurred so that it can prove that its fees only constitute those costs plus a reasonable profit. Further, commenters stated that the administrative burden required to assess and monitor this exception would be significant and not sustainable. Commenters explained that cost accounting is challenging for even very large and well-resourced organizations and there is concern that the exception will result in unintended negative consequences for many actors.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. We reiterate that actors may choose to satisfy the conditions of this exception to be certain that the fees they charge for the access, exchange, or use of EHI do not implicate the information blocking provision. We also reiterate that failure to meet the exception does not mean that an actor's practice related to charging fees meets the information blocking definition. However, as we explained in the Proposed Rule, we interpret the broad definition of information blocking in section 3022(a) of the PHSA to encompass 
                        <E T="03">any</E>
                         fee that is likely to interfere with the access, exchange, or use of EHI (84 FR 7521). Fees that do not meet this exception may implicate the information blocking provision and will have to be assessed on a case-by-case basis to determine, for example, the actor's intent and whether the practice rises to the level of an interference. This exception, as well as the other finalized exceptions, strike a balance by identifying, as the Cures Act requires, activities that interfere with access, exchange, or use of EHI but which are reasonable and necessary.
                    </P>
                    <P>
                        We believe the overwhelming benefits of the information blocking provision and the exceptions to the information blocking definition—which enable patients to access, exchange, and use their EHI where and when it is 
                        <PRTPAGE P="25884"/>
                        needed—far outweigh the potential burden on actors. We believe the revisions we have made to this exception, the addition of paragraph (b) in the information blocking definition (see § 171.103(b)) and the discussion in section VIII.C of this preamble), the addition of the Content and Manner Exception, as well as the revisions we have made to the other exceptions and relevant terms will have the overall effect of reducing burden on actors. The fact the information blocking section of this rule (part 171) has a 6-month delayed compliance date from the publication date of this final rule will also relieve the burden on actors and give them time to prepare for administrative changes.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments about the interplay and potential overlap between the proposed Fees Exception and Licensing Exception. Some commenters suggested that we combine the two exceptions for clarity. Some commenters requested clarification as to whether an actor may charge both a fee to recover reasonable costs associated with EHI services and a reasonable royalty for licensing interoperability elements. One commenter expressed concern that the overlap between the two exceptions creates the potential for actors to recover the same costs twice. The commenter explained that licensing of IP is intended to recoup the costs of development of that IP, so where the IP is an interoperability element, the costs reasonably incurred for its development should be incorporated into the royalty rate. The commenter recommended that we should be clearer that, in these circumstances, only a single recovery is permitted.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the thoughtful feedback and agree that the distinction between the Fees Exception and the Licensing Exception (§ 171.303) must be clear. We emphasize that both exceptions deal with the fees actors may charge regarding the access, exchange, or use of EHI and under both exceptions actors use interoperability elements (as defined in § 171.102) to facilitate the access, exchange, or use of EHI. The exception for recovering costs reasonably incurred enables actors to recover their costs to develop technologies and provide services that enhance interoperability. On the other hand, the exception for licensing interoperability elements specifically addresses circumstances when it is necessary for an actor to 
                        <E T="03">license</E>
                         interoperability elements in order fulfill a request to access exchange, or use EHI. The Licensing Exception deals with the requisite licensing conditions. We believe there should be a distinction made between these two exceptions, and have therefore decided not to combine the two exceptions.
                    </P>
                    <P>
                        We agree with the commenter that actors should 
                        <E T="03">not</E>
                         be able to recover the same costs twice and have added a provision in § 171.302(a)(2)(vi) that the fees an actor charges must not be based on any costs that led to the creation of IP, if the actor charged a royalty for that IP pursuant to § 171.303 and that royalty included the development costs for the creation of the intellectual property.
                    </P>
                    <HD SOURCE="HD3">Excluded Fees Condition</HD>
                    <P>We proposed that certain costs should be explicitly excluded from the exception regardless of the method for recovering the costs (84 FR 7540).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments regarding the overall proposed approach of excluding certain costs from this exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the structure of this exception to exclude certain fees with the changes described in the discussions above and below. We note that we have substituted the “or” that preceded the final excluded fee in the proposed exception (see 84 FR 7603) with an “and” in the final exception. This is not a substantive change, as our intent has always been that the exception does not apply to 
                        <E T="03">each</E>
                         of “excluded fees.” This revision clarifies that point.
                    </P>
                    <HD SOURCE="HD3">Costs Due to Non-Standard Design or Implementation Choices</HD>
                    <P>We proposed that this exception would not permit the recovery of any cost that the actor incurred due to the health IT being designed or implemented in non-standard ways that unnecessarily increase the complexity, difficulty or burden of accessing, exchanging, or using EHI. To the extent that such costs can be reasonably avoided, we stated that we believe that actors should internalize the costs of such behaviors, which do not benefit consumers, and which create unnecessary impediments to access, exchange, and use of EHI. We requested comments on the proposed exclusion of these types of costs from the exception (84 FR 7540).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received several comments regarding the proposed exclusion of costs due to non-standard design or implementation choices from this exception. A couple of commenters expressed support for the proposal. A couple of other commenters disagreed with the proposal and recommended that actors should be able to recover all reasonable implementation costs independent of design decisions. One commenter requested additional clarity about what “non-standard” means. A couple of commenters noted that requestors may prefer information in a non-standard manner to meet their business purposes, due to their own constraints, or for other reasons.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support of this proposal, as well as the constructive feedback. We emphasize that the problematic nature of non-standard implementation choices was identified by Congress in the Cures Act. Section 3022(a)(2)(B) of the PHSA states that information blocking may include implementing health IT in non-standard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using EHI. Due to Congress's clear objective to restrict these practices, along with our continued concern that these practices will lead to unnecessary complexity and burden related to the access, exchange, or use of EHI, we have finalized the proposed provision regarding non-standard design and implementation choices. We have updated § 171.302(a)(2)(iii) to address comments indicating that requestors may prefer information in a non-standard manner to meet their business purposes, due to their own constraints, or for other reasons. We agree with commenters that in those situations—when the requestor requests access, exchange or use of EHI in the non-standard way—the exception should allow the actor to charge fees for the reasonable costs associated with the requested non-standard design or implementation. We emphasize, however, and make clear in § 171.302(a)(2)(iii), that such fees related to non-standard design or implementation are 
                        <E T="03">only</E>
                         covered by the exception when the requestor agreed to the fee associated with the non-standard design or implementation to access, exchange, or use EHI. We note that this provision was proposed as an “excluded cost” but has been finalized within the “Basis for fees condition” for clarity and to align with the revised structure of this exception.
                    </P>
                    <P>
                        We also note that the new Content and Manner Exception in § 171.301 further addresses commenter concerns because it provides actors with clear procedures regarding the manner in which they may provide access, exchange, or use of EHI if they are technically unable to respond in the manner requested or the manner requested requires the actor to license intellectual property and the actor cannot reach agreeable terms with the requestor (discussed in section VIII.D.2.a of this preamble). If an actor 
                        <PRTPAGE P="25885"/>
                        meets that exception, its practice would not implicate the information blocking provision. For instance, if a requestor requested that the actor provide EHI in a non-standard manner, but the actor is technically unable to provide the EHI in the manner requested, the actor's response to the request would not implicate the information blocking provision if it provides the EHI via an alternative manner in accordance with § 171.301(b). The actor could also potentially seek coverage under the Infeasibility Exception if the request is infeasible and the actor meets all the conditions in § 171.204.
                    </P>
                    <P>Regarding the comment concerning additional clarity about what “non-standard” means, we explained and provided examples in the Proposed Rule of practices related to implementing health IT in non-standard ways that substantially increase the complexity or burden of accessing, exchanging, or using EHI, and therefore implicate the information blocking provision (84 FR 7521). In addition, the Cures Act specifically describes information blocking practices to include implementing health IT in nonstandard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using electronic health information (see section 3022(a)(2)(B) of the PHSA). Therefore, the Proposed Rule discussion regarding non-standard ways of implementing health IT also applies for purposes of the Fees Exception. As explained in the Proposed Rule, non-standard implementation of health IT may arise where an actor chooses not to adopt, or to materially deviates from, relevant standards, implementation specifications, and certification criteria adopted by the Secretary under section 3004 of the PHSA (84 FR 7521). Even where no federally adopted or identified standard exists, if a particular implementation approach has been broadly adopted in a relevant industry segment, deviations from that approach will be suspect unless strictly necessary to achieve substantial efficiencies. For further discussion regarding our rationale for this provision, as well as specific, non-exhaustive examples of conduct that would be likely to interfere with the access, exchange, or use of EHI, we refer readers to the Proposed Rule (84 FR 7521).</P>
                    <HD SOURCE="HD3">Subjective or Speculative Costs</HD>
                    <P>
                        We proposed to limit this exception to the recovery of costs that an actor 
                        <E T="03">actually</E>
                         incurred to provide the relevant interoperability element or group of elements (which may comprise either products or services). We proposed that the exception would not permit the recovery of certain types of costs that are subjective or speculative. We noted two important examples of this limitation. First, we proposed that an actor would not be permitted to recover any costs associated with intangible assets (including depreciation or loss of value), other than the actual development or acquisition costs of such assets. For example, an actor could not charge a customer a fee based on the purported “cost” of allowing the customer to use the actor's patented technology, computer software, databases, trade secrets, copyrighted works, and the like. We noted that the customer's use of the asset could be considered a “cost” in the sense that, were it not for the information blocking provision, the actor could charge a royalty or other fee for the use of its intangible assets. For this reason we proposed to permit an actor to license most interoperability elements on reasonable and non-discriminatory terms, subject to certain conditions. For purposes of this more general exception, however, we explained that it would be inappropriate to permit an actor to charge a fee based on these considerations, which are inherently subjective and could invite the kinds of rent-seeking and opportunistic pricing practices that fall squarely within the definition of information blocking. We proposed that an actor's practices could qualify for both this exception (Fees Exception) and the Licensing Exception (finalized in § 171.303). In that case, the actor could recover costs under both exceptions (84 FR 7540).
                    </P>
                    <P>Second we stated the exception would not apply to “opportunity costs,” such as the revenues that an actor could have earned had it not provided the interoperability elements. We clarified that the exclusion of opportunity costs would not preclude an actor from recovering its reasonable forward-looking cost of capital (84 FR 7540).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on our proposals regarding subjective or speculative costs.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized this provision as proposed with some modifications for clarity. We have modified the provision regarding intangible assets in § 171.301(a)(2)(iv) by removing the parenthetical that noted that such costs include the depreciation or loss of value. The parenthetical was illustrative and was not necessary in the regulation text, as it is just one of the many types of intangible assets on which a fee must not be based. We have also modified the provision regarding opportunity costs in § 171.301(a)(2)(v) by clarifying that the specific opportunity costs on which a fee must 
                        <E T="03">not</E>
                         be based are those 
                        <E T="03">unrelated</E>
                         to the access, exchange, or use of EHI instead of the proposed qualifying language of “except for the reasonable forward-looking cost of capital” (see 84 FR 7603). We believe this finalized language is clearer than the proposed language. In addition, it is more precise than the proposed language because it creates a connection to the information blocking definition. We note that we proposed these provisions as “excluded costs” (see 84 FR 7603) but have finalized them within the “Basis for fees condition” for clarity.
                    </P>
                    <HD SOURCE="HD3">Fee Prohibited by 45 CFR 164.524(c)(4)</HD>
                    <P>
                        We also proposed that the exception would not apply to fees prohibited by 45 CFR 164.524(c)(4). We noted in the Proposed Rule that the HIPAA Privacy Rule permits a covered entity to impose a reasonable, cost-based fee if the individual requests a copy of the PHI (or agrees to receive a summary or explanation of the information). The fee may include only the cost of: (1) Labor for copying the PHI requested by the individual, whether in paper or electronic form; (2) supplies for creating the paper copy or electronic media (
                        <E T="03">e.g.,</E>
                         CD or USB drive) if the individual requests that the electronic copy be provided on portable media; (3) postage, when the individual requests that the copy, or the summary or explanation, be mailed; and (4) preparation of an explanation or summary of the PHI, if agreed to by the individual (45 CFR 164.524(c)(4)). The fee may not include costs associated with verification; documentation; searching for and retrieving the PHI; maintaining systems; recouping capital for data access, storage, or infrastructure; or other costs not listed above even if such costs are authorized by State law (84 FR 7540).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a couple of comments regarding copying fees allowed under the HIPAA Privacy Rule. One commenter stated that reasonable, cost-based fees for certain costs, consistent with the HIPAA Privacy Rule individual access provisions, should not be allowed under the exception. One commenter requested that ONC harmonize the exception with the HIPAA Privacy Rule provisions that govern the charging of fees for electronic copies of medical records.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. We have decided to finalize the provision as proposed, which harmonizes this part of the exception (§ 171.302) with those provisions of the HIPAA Privacy Rule. The exception does not apply to fees prohibited by 45 CFR 164.524(c)(4). Consistent with the 
                        <PRTPAGE P="25886"/>
                        HIPAA Privacy Rule's individual access fee implementation specification, an actor can charge a reasonable, cost-based fee related to certain costs (described above) if a patient requests a copy of her records.
                    </P>
                    <HD SOURCE="HD3">Individual Electronic Access</HD>
                    <P>
                        We proposed that the exception would not apply if the actor charged a fee based in any part on the electronic access by an individual or their personal representative, agent, or designee to the individual's EHI. We stated that such fees are distinguished from the cost-based fees that a covered entity is permitted to charge individuals for the provision of copies of ePHI under the HIPAA Privacy Rule access provisions (45 CFR 164.524(c)(4)), and similar allowable costs under State privacy laws, which would 
                        <E T="03">not</E>
                         be excluded from the costs recoverable under the exception. We clarified that access to EHI that is provisioned by supplying some form of physical media, such as paper copies (where the EHI is printed out), or where EHI is copied onto a CD or flash-drive, would not be a practice that implicated the information blocking provision provided that the fee(s) charged for that access complied with the HIPAA Privacy Rule access provisions (45 CFR 164.524(c)(4)) (84 FR 7540).
                    </P>
                    <P>We stated that a fee based on electronic access by an individual or their personal representative, agent, or designee to the individual's EHI, in contrast, would arise if an actor sought to impose on individuals, or their personal representatives, agents, or designees, a fee that operated as a toll to electronically access, exchange, or use EHI. For example, a health care provider that charges individuals a fee in order for the individuals to receive access to their EHI via the health care provider's patient portal or another internet-based method, would not be able to benefit from this exception. Similarly, where an individual authorizes (approves) a consumer-facing app to receive EHI on the individual's behalf, the exception would not apply to practices where an actor charges the app or its developer a fee to access or use APIs that enable an individual's access to the individual's EHI. We explained that this would be true whether the actor is a supplier of the API technology or an individual or entity that has deployed the API technology, such as a health care provider (84 FR 7540).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Commenters expressed overwhelming support for our proposal regarding individual electronic access. Commenters from across stakeholder groups emphasized that patients have a fundamental right to access their data and should be able to access, exchange, and use their EHI at no charge. Commenters emphasized that the EHI belongs to the patient, and neither health care providers, EHR developers, nor payers should profit from the sale of EHI, as that will only serve to limit data transfer, increase health care costs, and adversely affect patient care.
                    </P>
                    <P>
                        Commenters strongly supported our proposal (within the API Condition of Certification) that API fees should not be a barrier in allowing patient access to their EHI (see proposed § 170.404 and 84 FR 7487 through 7491). They stressed that neither individuals nor app developers (
                        <E T="03">i.e.,</E>
                         API Users) should be charged a fee for API uses that are associated with the access, exchange, and use of EHI by patients or their applications, technologies, or services. Several commenters supported our efforts to bolster patient access, noting that the capacity to offer a patient access to EHI, through an API, without cost, is well-supported in the Proposed Rule. One commenter requested that we differentiate between an individual electronically accessing EHI and third parties, at the direction of the individual, electronically accessing EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for the support and have finalized this provision as proposed with a slight modification to the text in § 171.302(b)(2) and clarification of the meaning of electronic access, which we have codified in § 171.302(d). We have reordered the language for clarity and, in order to clarify the terms “agent” and “designee,” we have replaced them with “another person or entity designated by the individual.” These other individuals or entities (
                        <E T="03">e.g.,</E>
                         a third-party app) receive access to EHI at the direction of the individual and individuals control whether the third-party receives access to the individual's EHI. This modification is merely a clarification of our proposal and is not a substantive change as we clearly stated in the Proposed Rule that, as summarized above, this exception would not apply to practices where an actor charges the 
                        <E T="03">app or its developer</E>
                         a fee to access or use APIs that enable access to the individual's EHI. Fees can be a method of interfering with the access, exchange, and use of EHI, as we have emphasized in the Proposed Rule and this final rule. When it comes to an individual's electronic access to their EHI, we believe that any fee, whether direct or indirectly passed on through a fee charged to a third-party app that the individual has chosen to facilitate access to their EHI, could interfere with an individual's access and use of their EHI. ONC's implementation of the Cures Act is predicated on an understanding that access to EHI should not be treated as a commodity that should be traded or sold. ONC takes this approach because we view patients as having an overwhelming interest in EHI about themselves, and because we understand that the true value of EHI can only be realized if it is available where and when it is needed, including providing electronic access to patients. Patients have already effectively paid for their health information, either directly or through their employers, health plans, and other entities that negotiate and purchase health care items and services on their behalf. We have codified this provision in § 170.302(b)(2) to not permit “[a] fee based in any part on the electronic access of an individual's EHI by the individual, their personal representative, or another person or entity designated by the individual.”
                    </P>
                    <P>
                        For purposes of the Fees Exception, we define electronic access to mean an internet-based method that makes EHI available at the time the EHI is requested and where no manual effort is required to fulfill the request (§ 171.302(d)). We discussed the meaning of “electronic access” in the Proposed Rule (see 45 FR 7540). We have defined “electronic access” in § 171.302(d) in this final rule consistent with the Proposed Rule, including distinguishing it from the methods and efforts we cited in the Proposed Rule that we did not consider electronic access and for which a fee could be charged (see 45 FR 7540). We have chosen “internet-based method” in lieu of the proposed “web-based delivery” because it more technically aligns with the concept we were attempting to convey in the Proposed Rule. Such methods would be, as described in part in the Proposed Rule, access via an API, patient portal, or other internet-based means. To note, the 2015 Edition “view, download, and transmit to 3rd party” certification criterion uses this same concept of “internet-based” to convey that “patients (and their authorized representatives) must be able to use 
                        <E T="03">internet-based technology</E>
                         to view, download, and transmit. . . .” In terms of fulfilling a request without manual effort, we clarify that it entails the completion of the process where there is 
                        <E T="03">no</E>
                         manual effort involved to meet the request at the time of the request. To illustrate the inverse, we recognize that there are times that manual effort may be involved in collating or assembling EHI from various systems in response to a request. In such instances, this provision (§ 170.302(b)(2)) would not 
                        <PRTPAGE P="25887"/>
                        apply to the costs of those efforts because the efforts would not fall under the definition of “electronic access.”
                    </P>
                    <P>
                        We reaffirm that this exception would not apply to an actor that charges individuals a fee in order for the individuals to receive access to their EHI using an internet-based delivery method, including where an individual uses consumer-directed technology (
                        <E T="03">e.g.,</E>
                         patient-chosen apps, personal health apps, standalone/untethered personal health records (PHR), email) to request and/or receive their EHI. This includes sharing it with an entity designated by the individual (
                        <E T="03">e.g.,</E>
                         allowing individuals to donate/share EHI with a biomedical research program of the individual's choice). Practices that involve an actor charging an individual (or the individual's personal representative or another person or entity designated by the individual) a fee to access, exchange, or use their EHI would be inherently suspect and would be extremely likely to implicate the information blocking provision. We emphasize that practices that do not meet this condition, or any other conditions in the Fees Exception, would be subject to case-by-case review (unless another exception applies). We further refer readers to our discussion of “interfere with” or “interference,” including examples of practices that would likely interfere with access, exchange, and use of EHI (section VIII.C.6).
                    </P>
                    <HD SOURCE="HD3">Export and Portability of EHI Maintained in EHR Systems</HD>
                    <P>We explained in the Proposed Rule that the definition of information blocking specifically mentions transitions between health IT systems and the export of complete information sets as protected forms of access, exchange, and use (see section 3022(a)(2)(C)(i) of the PHSA). We noted that in our experience, health care providers frequently encounter rent-seeking and opportunistic pricing practices in these and other contexts in which they are attempting to export EHI from their systems for use in connection with other technologies or services that compete with or could reduce the revenue opportunities associated with an EHR developer's own suite of products and services. We explained that most EHI is currently maintained in EHRs and other source systems that use proprietary data models or formats; this puts EHR developers in a unique position to block the export and portability of EHI for use in competing systems or applications, or to charge rents for access to the basic technical information needed to facilitate the conversion or migration of data for these purposes. We emphasized that our concerns are compounded by the fact that EHR developers rarely disclose in advance the fees they will charge for data export and data portability services (see 80 FR 62719; 80 FR 16880 and 81).</P>
                    <P>
                        For these reasons, we proposed that fees charged for the export, conversion, or migration of data from an EHR technology would not qualify for this exception unless they also meet two additional conditions. First, we proposed that health IT developers of certified health IT would, for purposes of the exception, be precluded from charging a fee to perform an export of EHI via the capability of health IT certified to the proposed 2015 Edition “EHI export” certification criterion for the purposes of supporting single patient EHI export upon a valid request from that patient or a user on the patient's behalf, or supporting the export of all EHI when health care provider chooses to transition or migrate information to another health IT system. We stated that, as part of the “Assurances” Condition of Certification, health IT developers that produce and electronically manage EHI would need to be certified to the criterion and provide the functionality to its customers. We stated that fees or limitations associated with the 
                        <E T="03">use</E>
                         of the “EHI export” certification criterion (as distinguished from deployment or other costs reasonably incurred by the developer) would not receive protection under the exception and may be suspect under the information blocking provision (84 FR 7541).
                    </P>
                    <P>We clarified that the condition would not preclude a developer from charging a fee to deploy the “EHI export” certification criterion in a health care provider's production environment, or to provide additional services in connection with this capability other than those reasonably necessary to enable its intended use. For example, we explained that this condition would not preclude a developer from charging a fee to perform an export of EHI via the capability of health IT certified to the proposed § 170.315(b)(10) for a third-party analytics company. We noted in the Proposed Rule that, because the certification criterion provides only a baseline capability for exporting data, we anticipated that health IT developers of certified health IT will need to provide other data portability services to facilitate the smooth transition of health care providers between different health IT systems. We proposed that such fees may qualify for protection under the exception, but only if they meet the other conditions described above and in proposed § 171.205(a).</P>
                    <P>Second, we proposed that the exception would not apply to a fee to export or convert data from an EHR technology unless such fee was agreed to in writing at the time the technology was acquired, meaning when the EHR developer and the customer entered into a contract or license agreement for the EHR technology (84 FR 7541).</P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter requested clarification regarding the proposal to exclude from the exception costs related to fees to export or convert data from an EHR technology, unless such fee was agreed to in writing at the time the technology was acquired. The commenter asked that ONC clarify if this provision is applicable to export or the conversion of EHI from certified health IT or if it is applicable to any export or conversion of EHI from any health IT. The commenter also requested that ONC clarify if this provision is prospective in nature, meaning it would only apply to agreements entered into after the effective date of a final rule. The commenter recommended that ONC change the focus of this proposal so that it only requires that the parties agree in writing that fees of a particular nature may be charged for the export of EHI.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment. In response to the comment, we clarify that this exclusion from the exception is not limited to the export of EHI from certified health IT. Instead, this provision applies to the export or conversion of any EHI from an actor's technology(ies). As we discuss elsewhere in this Final Rule, we interpret the information blocking provision broadly such that practices of a health IT developer of certified health IT that do not pertain specifically to certified health IT may implicate the information blocking provision. Consistent with this interpretation of the information blocking provision, the exception will not protect practices where an actor charges fees to export or convert data from any EHR technology, unless such fee was agreed to in writing at the time technology was acquired. Further, we clarify that if a fee to export or convert data is not subject to this exclusion in § 171.302(b)(4) because it was agreed to in writing, it still must meet the other applicable conditions in § 171.302 to be covered by the Fees Exception.
                    </P>
                    <P>
                        Without this exclusion, actors may seek to take advantage of the exception and enable rent-seeking or opportunistic pricing practices. Thus, we have decided not to limit the condition so that it only requires that the parties 
                        <PRTPAGE P="25888"/>
                        agree in writing that fees of a particular nature may be charged for the export of EHI as suggested by the commenter. Only requiring the parties to agree to the fee in writing (without applying the other conditions in this exception), may allow an actor to charge an unreasonable fee or engage in a practice that is likely to interfere with the access, exchange, or use of EHI. While a party may agree to pay a fee under specific circumstances, that agreement does not change the fact that the fee must be reasonably related to the actor's costs or may otherwise interfere with the access, exchange, or use of EHI.
                    </P>
                    <P>We have finalized these provisions as proposed with a slight modification. We changed the condition from “A fee to export or convert data from an EHR technology, unless such fee was agreed to in writing at the time the technology was acquired” (see 84 FR 7603) to “A fee to export or convert data from an EHR technology that was not agreed to in writing at the time the technology was acquired” (§ 171.302(b)(4)). We made this change for clarity based on the change we made to the introductory language in the exception, that a practice will not be considered information blocking when the practice meets the conditions in paragraph (a), does not include any of the excluded fees in paragraph (b), and, as applicable, meets the condition in paragraph (c). This modification does not change the substance of this condition in any way.</P>
                    <HD SOURCE="HD3">Compliance With the Conditions of Certification</HD>
                    <P>We stated in the Proposed Rule that health IT developers of certified health IT subject to the API Condition of Certification may not charge certain types of fees and are subject to more specific cost accountability provisions than apply generally under this proposed exception. We noted that the failure of developers to comply with these additional requirements would impose impediments to consumer and other stakeholder access to EHI without special effort and would be suspect under the information blocking provision. We proposed, therefore, that a health IT developer of certified health IT subject to the API Condition of Certification must comply with all requirements of that condition for all practices and at all relevant times in order to qualify for the exception (84 FR 7541).</P>
                    <P>We also stated that a health care provider that acts as an API Data Provider should be subject to the same constraints. We noted that the API Condition of Certification prohibits a health IT developer from charging a usage fee to patient-oriented apps. We noted that information blocking concerns would arise if a provider were to charge such a fee, notwithstanding the fact that the provider is not subject to the certification requirements. For this reason, we proposed that, if the actor is an API Data Provider, the actor would only be permitted to charge the same fees that an API Technology Supplier would be permitted to charge to recover costs consistent with the permitted fees specified in the Condition of Certification (84 FR 7541).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments on these proposals.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the first provision detailed above as proposed with a slight modification for clarity. The final provision in § 171.302(c) states: Notwithstanding any other provision of this exception, if the actor is a health IT developer subject to the Conditions of Certification in § 170.402(a)(4), § 170.404, 
                        <E T="03">or both</E>
                         of this subchapter, the actor must comply with all requirements of such conditions for all practices and at all relevant times. We added “or both” into the final language because a health IT developer could be subject to both § 170.402(a)(4) and § 170.404 and in such instances would be covered by this provision.
                    </P>
                    <P>We have removed the second provision detailed above regarding a health care provider that acts as an API Data Provider (see the Proposed Rule at 84 FR 7603) for clarity, as not all of the permitted fees specified in the API Condition of Certification (§ 170.404) are applicable for API Data Providers.</P>
                    <HD SOURCE="HD3">Application of the Exception to Individual Practices</HD>
                    <P>
                        We stated in the Proposed Rule that the conditions of this exception, including those governing the methodology and criteria by which an actor calculates and distributes its costs, must be satisfied for 
                        <E T="03">each and every</E>
                         fee that an actor charges to a customer, requestor, or other person for accessing, exchanging, or using EHI. All applicable conditions of the exception must be met at all relevant times for each practice (84 FR 7541).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on this proposed policy.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized this policy as proposed.
                    </P>
                    <HD SOURCE="HD3">c. Licensing Exception—When will an actor's practice to license interoperability elements in order for electronic health information to be accessed, exchanged, or used not be considered information blocking?</HD>
                    <P>We proposed in the Proposed Rule in § 171.206 to establish an exception to the information blocking provision that would permit actors to license interoperability elements on reasonable and non-discriminatory (RAND) terms, provided that certain conditions are met. We proposed that the information blocking provision would be implicated if an actor were to refuse to license or allow the disclosure of interoperability elements to persons who require those elements to develop and provide interoperable technologies or services—including those that might complement or compete with the actor's own technology or services (84 FR 7544). Moreover, we proposed that the information blocking provision would be implicated if the actor licensed such interoperability elements subject to terms or conditions that have the purpose or effect of excluding or discouraging competitors, rivals, or other persons from engaging in these pro-competitive and interoperability-enhancing activities. Thus, we proposed the Licensing Exception would apply in both vertical and horizontal relationships and provided an example emphasizing that point in the Proposed Rule (see 84 FR 7544).</P>
                    <P>
                        We noted in the Proposed Rule that some licensees do not require interoperability elements to develop products or services that can be interoperable with the actor's health IT. We explained that there may be firms that simply want to license the actor's technology for use in developing their own interoperability elements. Their interest would be for access to the technology itself—
                        <E T="03">not</E>
                         for the use of the technology to interoperate with either the actor or its customers to enable the access, exchange, or use of EHI. We emphasized that in such cases, the actor's licensing of its intellectual property (IP) in such a context would 
                        <E T="03">not</E>
                         implicate the information blocking provision (in other words, would not be in scope for information blocking). For a non-exhaustive list of examples of situations that 
                        <E T="03">would</E>
                         implicate the information blocking provision, see the Proposed Rule (84 FR 7544-45).
                    </P>
                    <P>
                        In our experience, contractual and IP rights are frequently used to extract unreasonable rents for access to EHI or to prevent competition from developers of interoperable technologies and services. These practices frustrate access, exchange, and use of EHI and stifle competition and innovation in the health IT sector. As a case in point, we noted in the Proposed Rule that even following the enactment of the Cures Act, some health IT developers had been selectively prohibiting—whether expressly or through commercially unreasonable terms—the disclosure or 
                        <PRTPAGE P="25889"/>
                        use of technical interoperability information required for third-party applications to access, exchange, and use EHI maintained in EHR systems. We noted that such practices limit health care providers' use of the EHI maintained on their behalf to the particular capabilities and use cases that their EHR developer happens to support. More than this, by limiting the ability of providers to choose what applications and technologies they can use with their EHR systems, we indicated that these practices close off the market to innovative applications and services that providers and other stakeholders need to deliver greater value and choice to health care purchasers and consumers (84 FR 7545).
                    </P>
                    <P>Despite these serious concerns, we recognized in the Proposed Rule that the definition of information blocking may be broader than necessary and could have unintended consequences. We proposed that it is generally appropriate for actors to license their IP on RAND terms that do not interfere with access, exchange, or use of EHI provided certain conditions were met. We explained that these practices would further the goals of the information blocking provision by allowing actors to protect the value of their innovations and earn returns on the investments made to develop, maintain, and update those innovations. We explained that this would protect future incentives to invest in, develop, and disseminate interoperable technologies and services. Conversely, we explained that if actors cannot (or believe they cannot) protect and commercialize their innovations, they may not engage in these productive activities that improve access, exchange, and use of EHI (84 FR 7545).</P>
                    <P>We proposed that the exception would be subject to strict conditions to ensure, among other things, that actors license interoperability elements on RAND terms and that actors do not impose collateral terms or engage in other practices that would impede the use of the interoperability elements or otherwise undermine the intent of the exception (84 FR 7545). We acknowledged that preventing IP holders from extracting rents for access to EHI may differ from standard IP policy. We proposed that absent specific circumstances, IP holders are generally free to negotiate with prospective licensees to determine the royalty to practice their IP, and this negotiated royalty frequently reflects the value the licensee would obtain from exercising those rights. However, in the context of EHI, we proposed that a limitation on rents is essential due to the likelihood that rents will frustrate access, exchange, and use of EHI, particularly because of the power dynamics that exist in the health IT market (84 FR 7545).</P>
                    <P>We also emphasized that actors are not required to seek the protection under this (or any other) exception. We explained that if an actor does not want to license a particular technology in accordance with the exception, it may choose to comply with the information blocking provision in another way, such as by developing and providing alternative means of accessing, exchanging, and using EHI that are similarly efficient and efficacious (84 FR 7545).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments in support of this proposed exception. One commenter highlighted the significance of the exception, noting that data is often locked in proprietary software systems, at times preventing providers from being able to connect and exchange information. Some commenters requested additional examples and that ONC issue guidance to assist actors in understanding how they can determine whether a request to license is valid, when this exception would apply, and what steps actors would be required to take to attain coverage under the exception. A couple of commenters suggested that there should be a distinction between requests to license interoperability elements to facilitate a patient's treatment or individual access versus requests that are simply for the requestor's own business purposes, such as commercializing a competing product. A couple of commenters requested additional provisions in the final rule to improve transparency regarding licensing of interoperability elements. Commenters recommended that ONC require regulated actors who engage in RAND licensing of interoperability elements to publish either standard licensing rate offers or actual licenses.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their support for this exception as well as the constructive feedback. We may consider developing materials in the future regarding the application of the exceptions should the need arise. However, we believe the final rule clearly describes the conditions actors must meet in order to be covered by each exception, and informational materials are not necessary at this time.
                    </P>
                    <P>
                        We appreciate the comments that recommended that there should be a distinction between requests for licensing of interoperability elements to facilitate a patient's treatment or individual access versus requests that are simply for the requestor's own business purposes. We emphasize that we made such a distinction in the Proposed Rule and we reiterate that distinction here in the final rule. In order for an actor to consider licensing its interoperability elements under this exception, the requestor would need to have a claim to the underlying, existing EHI for which the interoperability element would be necessary for access, exchange, or use (see the Privacy Exception discussion in VIII.D.1.b). An actor will not implicate the information blocking provision and does not need to seek coverage under this exception in circumstances where the entity requesting to license or use the interoperability element is not seeking to use the interoperability element to interoperate with either the actor or the actor's customers in order for EHI to be accessed, exchanged, or used. For instance, an actor would not need to consider licensing its interoperability elements in accordance with this exception to a firm that requested a license solely for that firm's use in developing its own technologies or business when 
                        <E T="03">no</E>
                         EHI is sought to be accessed, exchanged, or used. In other words, if there is no nexus between a requestor's need to license an interoperability element and existing EHI on one or more patients, an actor does 
                        <E T="03">not</E>
                         need to consider licensing the interoperability element requested in accordance with this exception. For example, if a developer of certified health IT included proprietary APIs in its product to support referral management, it would 
                        <E T="03">not</E>
                         need to license the interoperability element(s) associated with those referral management APIs simply because a requestor “knocked on the actor's door” and asked for a license with no EHI involved. The license request from a requestor 
                        <E T="03">must always be based on a need</E>
                         to access, exchange, or use EHI at the time the request is made—
                        <E T="03">not</E>
                         on the requestor's prospective intent to access, exchange, or use EHI at some point in the future.
                    </P>
                    <P>
                        We appreciate the recommendation that ONC should require regulated actors who license interoperability elements to publish either standard licensing rate offers or actual licenses. However, we have decided not to finalize such a requirement because we believe actors should have discretion to decide whether to publish their licensing rates and/or licenses. We believe this exception will still effectively regulate the licensing of interoperability elements even if it does not require the publication of such rates and licenses. Nonetheless, we commend 
                        <PRTPAGE P="25890"/>
                        commenters' desire to enhance transparency in the final rule and will continue to consider steps to further promote transparency regarding our information blocking policies in future rulemakings.
                    </P>
                    <P>We note that we have changed the title of this exception from “Exception—Licensing of interoperability elements on reasonable and non-discriminatory terms” to “When will an actor's practice to license interoperability elements in order for electronic health information to be accessed, exchanged, or used not be considered information blocking?” Throughout this final rule preamble, we use “Licensing Exception” as a short form of this title, for ease of reference. As stated in Section VIII.D of this final rule preamble, we have changed the titles of all of the exceptions to questions to improve clarity. We have also edited the wording of the introductory text in § 171.303, in comparison to that proposed (84 FR 7602), so that it is consistent with the finalized title in § 171.303. We believe these conforming changes in wording of the introductory text also improve clarity in this section.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments requesting greater clarity and precision regarding key terms within the proposed exception in order to clarify the scope and application of the exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments and agree with commenters that it is essential that our final policies are clear, administrable, and actionable. Accordingly, we have made several updates to this exception as well as to terms and concepts that apply broadly throughout the information blocking section. Notably, we have: (1) Revised the definition of interoperability element (see section VIII.C.3.b); (2) clarified the process and timeframe for negotiating a license (see the discussion later in this section of the preamble); (3) removed the “RAND” framework, which commenters noted was confusing (see the discussion later in this section of the preamble); and (4) clarified the relationship between this exception and the Fees Exception (see § 171.302 and the discussion later in this section of the preamble).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A few commenters requested clarification regarding whether the information blocking provision, and particularly this exception, applies to all licensing agreements already in effect; only licensing agreements that were entered into following the effective date of the Cures Act; or only those licensing agreements entered into after the effective date of ONC's final rule. Commenters recommended that licensing agreements that were entered into prior to the effective date of the final rule should be considered valid and effective. Commenters also recommended that all negotiations and licensing agreements entered into after the effective date of ONC's final rule should comply with the requirements of the final rule. Commenters requested that if ONC plans to enforce provisions of the final rule retroactively, ONC should allow actors to review and renegotiate licensing agreements for compliance with the terms at the request of the licensee.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these comments. We emphasize that actors are expected to be in full compliance with the information blocking provision when this rule becomes effective. We note that the information blocking section of this final rule (part 171) will not become effective until 6 months after the publication date of the final rule. We believe this delayed compliance date will provide actors with adequate time to assess their existing licensing contracts or agreements and make appropriate changes and amendments to comply with this final rule.
                    </P>
                    <P>OIG and ONC are coordinating timing of the compliance date of the information blocking section of this final rule (45 CFR part 171) and the start of information blocking enforcement. We are providing the following information on timing for actors. Enforcement of information blocking CMPs in section 3022(b)(2)(A) of the PHSA will not begin until established by future notice and comment rulemaking by OIG. As a result, actors would not be subject to penalties until CMP rules are final. At a minimum, the timeframe for enforcement would not begin sooner than the compliance date of this final rule and will depend on when the CMP rules are final. Discretion will be exercised such that conduct that occurs before that time will not be subject to information blocking CMPs.</P>
                    <P>We are aware that some actors may currently have in place licensing agreements that contravene the information blocking provision and do not meet the requisite conditions for this exception. We expect actors in these situations to take immediate steps to come into compliance with the information blocking provision by amending their contracts or agreements to eliminate or void any clauses that contravene the information blocking provision. We emphasize that an existing license is no excuse or justification for information blocking. One of the ways we have heard that actors interfere with the access, exchange, and use of EHI is through formal restrictions, such as discriminatory licensing agreements, and this final rule, as well as this exception, seek to address those very circumstances and situations.</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter expressed concern about this exception on privacy and security grounds. The commenter noted that a proliferation of EHI to a multitude of entities who have not and cannot be vetted is likely to increase the risks to the privacy and security of such data and create secondary and tertiary markets for such data without clear regulation and oversight.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment and understand that the secondary use of data creates privacy and security challenges in the health care industry and beyond. We refer readers to section VIII.C.6 of this preamble for a detailed discussion of how we are addressing this issue in this rule.
                    </P>
                    <HD SOURCE="HD3">i. Responding to Requests</HD>
                    <P>We proposed that, upon receiving a request to license or use interoperability elements, an actor would be required to respond to the requestor within 10 business days from receipt of the request. We noted that the request could be made to “license” or “use” the interoperability elements because a requestor may not always know that “license” is the legal mechanism for “use” when making the request (84 FR 7546).</P>
                    <P>
                        In order to meet this condition, we proposed that the actor would be required to respond to the requestor within 10 business days from the receipt of the request by: (1) Negotiating with the requestor in a RAND fashion to identify the interoperability elements that are needed; and (2) offering an appropriate license with RAND terms, consistent with its other obligations under the exception. We emphasized that, in order to qualify for the proposed exception, the actor would only be required to 
                        <E T="03">negotiate</E>
                         with the requestor in a RAND fashion and to 
                        <E T="03">offer</E>
                         a license with RAND terms. We proposed that the actor would not be required to 
                        <E T="03">grant</E>
                         a license in all instances. We did not propose a set timeframe for when the negotiations must be resolved (84 FR 7546).
                    </P>
                    <P>
                        We requested comment on whether 10 business days is an appropriate amount of time for the actor to respond to the requestor. We noted that we considered proposing response timeframes ranging from 5 business days to 15 business days. We also considered proposing two separate timeframes for: (1) Negotiating 
                        <PRTPAGE P="25891"/>
                        with the requestor; and (2) offering the license. We stated that if commenters prefer a different response timeframe or approach than proposed, we requested that commenters explain their rationale with as much detail as possible. In addition, we requested comment on whether we should create set limits for: (1) The amount of time the requestor has to accept the actor's initial offer or make a counteroffer; (2) if the requestor makes a counteroffer, the amount of time the actor has to accept the requestor's counteroffer or make its own counteroffer; and (3) an allowable number of counteroffers in negotiations (84 FR 7546).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments regarding the proposed framework and timeframe for responding to requests to license or use interoperability elements. Some commenters were supportive of our proposal and stated that 10 business days is an appropriate amount of time for the actor to respond to the requestor. Other commenters disagreed with the proposed timeframe, explaining that 10 business days is insufficient time to begin a license negotiation. Commenters suggested various alternate timeframes ranging from 20 to 90 business days. One commenter requested that ONC consider differentiating the timeline expected for making an offer predicated on an interoperability element being available as an existing capability, as opposed to an interoperability element requiring new formal licensure or requiring one off “custom” or “spec” development. Another commenter recommended that the process be divided into a series of steps with a requirement that a request for information be acknowledged and negotiations begin within 10 business days and completed within 20 business days. One commenter recommended that the 10-day timeframe be for beginning negotiations with the intent to furnish a quotation for a license. Some commenters stated that timeframes should not be set, as the license negotiation process is highly variable based on the specific requestor and circumstances. One commenter expressed concern that the proposed exception would increase the administrative burden on covered entities, particularly regarding the response timeframe and the actor's inability to review and/or vet the appropriateness of a request before responding.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these thoughtful comments. To be responsive to comments, we have updated the response and license negotiation framework and timeframe. The finalized provision in § 171.303(a) states that, upon receiving a request to license an interoperability element for the access, exchange, or use of EHI, the actor must: (1) Begin license negotiations with the requestor within 10 business days from receipt of the request (§ 171.303(a)(1)); and (2) negotiate a license with the requestor, subject to the licensing conditions in paragraph (b) of the exception, within 30 business days from receipt of the request (§ 171.303(a)(2)). We note that the expectation in (2) above is that the actor will negotiate with the requestor in good faith. If it is determined that the negotiation is not in good faith, the actor would not qualify for this exception. These provisions create a clear and administrable timeline for actors to follow that is informed by stakeholder comments and will reduce potential burden on actors. Further, it provides actors with appropriate flexibility for negotiating a good faith license, taking into consideration the potential complexity and variability associated with negotiations for licensing interoperability elements.
                    </P>
                    <P>In instances when an actor is unable to negotiate a good faith license subject to the requirements in § 171.303(a)(2), the actor may not meet the conditions of this exception. As part of an information blocking investigation, ONC and OIG may consider documentation or other writings maintained by the actor around the time of the request that indicate why the actor was unable to meet the conditions. This would not permit the actor to be covered by this exception, but discretion in determining whether to enforce the information blocking provision may be exercised.</P>
                    <P>
                        We note that we have revised paragraph § 171.303(a) by changing “a request to license 
                        <E T="03">or use”</E>
                         to “a request to license” for clarity. We emphasize, however, that this change does not alter the meaning or application of the provision. We reiterate, as we proposed, that the request could be made to “license” or “use” the interoperability elements because a requestor may not always know that “license” is the legal mechanism for “use” when making the request (see 84 FR 7546). We believe it is unnecessary to include “or use” in the regulation text because actors should know that a request to “use” would be synonymous with a request to “license” and would thus be covered by this exception. Further, the inclusion of “or use” could be confusing since “use” is a defined term in the context of “access, exchange, or use” of EHI, but would carry different meaning in the context of “using” an interoperability element, as opposed to “using” EHI.
                    </P>
                    <HD SOURCE="HD3">ii. Licensing Conditions</HD>
                    <P>We proposed to require, as a condition of this exception, that any terms upon which an actor licenses interoperability elements must be reasonable and non-discriminatory (RAND). We recognized in the Proposed Rule that strong legal protections for IP rights can promote competition and innovation. Nevertheless, IP rights can also be abused in ways that undermine these goals. We explained that we believe this potential for abuse is heightened when the IP rights pertain to functional aspects of technology that are essential to enabling interoperability. We emphasized that to the extent that the interoperability elements are essential to enable the efficient access, exchange, or use of EHI by particular persons or for particular purposes, any practice by the actor that could impede the use of the interoperability elements for that purpose—or that could unnecessarily increase the cost or other burden of using the elements for that purpose—would give rise to an obvious risk of interference with access, exchange, or use of EHI under the information blocking provision (84 FR 7546).</P>
                    <P>We explained that our goal was to balance the need for IP protections with the need to ensure that this proposed exception does not permit actors to abuse their IP or other proprietary rights in inappropriate ways that would block the development, adoption, or use of interoperable technologies and services. The abuse of IP rights in such ways is incompatible with the information blocking provision, which protects the investments that taxpayers and the health care industry have made to adopt technologies that will enable the efficient sharing of EHI to benefit consumers and the health care system. We emphasized that while actors are entitled to protect and exercise their IP rights, to benefit from the exception to the information blocking provision they must do so on terms that do not undermine these efforts and prevent the appropriate flow of EHI. We proposed that these requirements would apply to both price terms (such as royalties and license fees) and other terms, such as conditions or limitations on access to interoperability elements or the purposes for which they can be used (see 84 FR 7546).</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several health IT developers strongly disagreed with the framework and conditions of this exception. These commenters stated that compulsory licensing of health IT on RAND terms is inconsistent with the usual use of RAND with regards to 
                        <PRTPAGE P="25892"/>
                        standards development. The commenters opined that the proposed exception is a significant overstep that exceeds Congressional intent in the Cures Act and would have a detrimental effect on innovation in the industry. Commenters stated that IP rights would not be adequately protected under the exception, as the exception would allow unprecedented access to IP, and requested that ONC better protect IP rights in the final rule. One commenter recommended that ONC make clear that there are other ways for actors to be in compliance with the information blocking provision besides licensing interoperability elements to all.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these comments. Responsive to these comments, we have removed all references to “RAND.” However, we have finalized the majority of the substantive conditions for the licensing of interoperability elements under this exception (§ 171.303(b)) as proposed (
                        <E T="03">i.e.,</E>
                         the sections on scope of rights, reasonable royalty, non-discriminatory terms, collateral terms, and non-disclosure agreement), with slight modifications discussed below.
                    </P>
                    <P>
                        In response to comments regarding compulsory licensing, we emphasize that we do not view this exception as constituting compulsory licensing. Each exception is voluntary and actors may choose whether or not they want to seek coverage under an exception. The exceptions operate to the benefit of actors and are intended to provide actors with certainty that certain practices that would normally constitute information blocking will not be considered information blocking, provided the actor's practice meets the conditions of the exception. The fact that a practice to license interoperability elements does not meet the conditions of an exception does 
                        <E T="03">not</E>
                         mean that the practice would necessarily constitute information blocking. As a result, practices that do not meet the exception will have to be reviewed on a case-by-case basis in order to assess the specific facts and circumstances and to determine, for example, the actor's intent and whether the practice rises to the level of an interference.
                    </P>
                    <P>In addition, under the Content and Manner Exception (§ 171.301), we establish that an actor is not required to respond to a request to access, exchange, or use EHI in the manner requested if the actor would be required to license IP and cannot reach agreeable terms for the license with the requestor (§ 171.301(b)(1)(ii)). This provision allows actors who do not want to license their IP to respond in an alternative manner that does not require the licensing of proprietary IP. Further, if the actor chooses to respond in the manner requested, and such manner requires the licensing of an interoperability element(s), the actor could license the interoperability elements(s) with whatever terms the actor chooses, so long as the actor is able to reach agreeable terms with the requestor. We refer readers to the discussion in the Content and Manner Exception in VIII.D.2.a, which highlights how the Content and Manner Exception supports an actor's ability to protect their IP.</P>
                    <P>
                        We understand and appreciate that health IT developers and other entities have invested significant resources to innovate and our policies aim to support these innovations and advancements regarding the access, exchange, and use of EHI. We stress that this exception was drafted with innovation in mind and operates to benefit health IT developers and other actors by allowing them to obtain remuneration for their IP. The Cures Act did 
                        <E T="03">not</E>
                         create a specific carve out to the information blocking provision for IP rights, but did provide HHS with the authority to establish reasonable and necessary exceptions that do not constitute information blocking. We interpret the definition of information blocking in the Cures Act (section 3022(a) of the PHSA) to encompass 
                        <E T="03">any</E>
                         fee that materially discourages or otherwise inhibits the access, exchange, or use of EHI, so long as the actor has the requisite intent in the statute. Thus, without clarifying this exception, an actor could implicate the information blocking provision whenever it charged any royalty to license its interoperability elements. We believe this broad interpretation of the information blocking provision would have a detrimental effect of innovation, competition, and consumer welfare. As such, we established this exception to provide assurances to actors that licensing of interoperability elements for access, exchange, or use will not be considered information blocking, 
                        <E T="03">so long as</E>
                         the actor's practice meets all conditions in the exception. We reiterate that the actor would also need to have the requisite intent, as set forth in the statute. We emphasize that actors are able to make reasonable profits from the licensing of interoperability elements, so long as such profits comply with the “reasonable royalty” provision in this exception in § 171.303(b)(2). We also note that the non-disclosure agreement provision in § 171.303(b)(5) establishes additional IP protections.
                    </P>
                    <P>
                        We emphasize that, in the context of information blocking, control of interoperability elements is often a proxy for control of access, exchange and use of EHI. For example, where EHI is stored in a proprietary format, the EHI cannot be accessed or used if information about the proprietary format does not accompany the EHI. Similarly, when EHI is stored electronically, a technological solution must exist to make the EHI available for use by others. We clarify that health IT developers are 
                        <E T="03">not</E>
                         required to license 
                        <E T="03">all</E>
                         of their IP. As discussed earlier in this section, an actor would not need to seek coverage under this exception if the actor's practice is not likely to interfere with the access, exchange, or use of 
                        <E T="03">actual EHI.</E>
                         Thus, an essential element of the information blocking provision is that there is actual EHI at stake. Further, as discussed above, there would also need to be a nexus between a requestor's need to license an interoperability element and the existing EHI. If there is not such a nexus, the actor would 
                        <E T="03">not</E>
                         need to seek coverage under this exception (see the Privacy Exception discussion in VIII.D.1.b).
                    </P>
                    <P>
                        We clarify that, if an actor licenses an interoperability element to one requestor, the actor must license that same interoperability element to future similarly situated requestors with the same terms. Once an actor has granted a license for a particular interoperability element, an actor 
                        <E T="03">cannot</E>
                         choose to license an interoperability element to one requestor and then refuse or use different terms to license the same interoperability element to a second similarly situated requestor, even if the actor offers to provide the EHI via an alternative manner in accordance with the Content and Manner Exception in § 171.301. In other words, an actor cannot pick and choose who can license a given interoperability element or who gets favorable license terms based on the actor's relationship with the requestor.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A couple of commenters noted that there is a wide-spectrum of perspectives among stakeholders of common license agreement terms such as limitations on liability and indemnification, which may make reasonableness and non-discriminatory aspects challenging to interpret.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate these concerns and understand that there is the potential for significant variability in the terms included in license agreements, particularly for licensing interoperability elements. We believe the conditions adopted in this final exception are clear, equitable, and implementable. We emphasize that each information blocking case will turn on its own unique facts and circumstances. 
                        <PRTPAGE P="25893"/>
                        This fact-based approach is appropriate for this exception particularly due to the potential variability in interoperability elements and licensing terms noted by the commenters.
                    </P>
                    <HD SOURCE="HD3">Scope of Rights</HD>
                    <P>To qualify for the proposed exception, we proposed that the actor must license the requested interoperability elements with all rights necessary to access and use the interoperability elements for the following purposes, as applicable:</P>
                    <P>• All rights necessary to access and use the interoperability elements for the purpose of developing products or services that are interoperable with the actor's health IT or with health IT under the actor's control and/or any third party who currently uses the actor's interoperability elements to interoperate with the actor's health IT or health IT under the actor's control. These rights would include the right to incorporate and use the interoperability elements in the licensee's own technology to the extent necessary to accomplish this purpose.</P>
                    <P>• All rights necessary to market, offer, and distribute the interoperable products and services described above to potential customers and users, including the right to copy or disclose the interoperability elements as necessary to accomplish this purpose.</P>
                    <P>• All rights necessary to enable the use of the interoperable products or services in production environments, including using the interoperability elements to access and enable the exchange and use of EHI (84 FR 7546 and 7547).</P>
                    <P>We requested comment on whether these rights are sufficiently inclusive to support licensees in developing interoperable technologies, bringing them to market, and deploying them for use in production environments. We also requested comment on the breadth of these required rights and if they should be subject to any limitations that would not interfere with the uses we have described above (84 FR 7547).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a couple of comments regarding the scope of rights under this exception. One commenter recommended that ONC specify that actors can require that licensees of the proprietary IP embodied in an interoperability element use that IP only for the licensed purpose, or ONC should allow actors to decline to license that IP at all. One commenter suggested that we broaden the scope of rights regarding the development of products or services that are interoperable so that interoperability does not need to be tied to the actor's health IT, health IT under the actor's control, or any third party who currently uses the actor's interoperability elements to interoperate with the actor's health IT or health IT under the actor's control.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these thoughtful comments. We have streamlined the “scope of rights” section of this exception for clarity and to align with the overarching goal throughout the information blocking section of enabling the access, exchange, and use of EHI. The finalized “scope of rights” section in § 171.303(c)(1) states that the license must provide all rights necessary to: (1) Enable the access, exchange, or use of EHI; and (2) achieve the intended access, exchange, or use of EHI via the interoperability element(s). These rights replaced the rights we proposed in the “scope of rights” section (see proposed § 171.206(b)(1)(i)-(iii) and 84 FR 7546 and 7547) because they more clearly and succinctly explain the scope of rights we were trying to convey in the Proposed Rule. The proposed scope of rights included examples that are not necessary in the regulatory text.
                    </P>
                    <P>
                        Regarding the comment that we should specify that actors can require that licensees of the proprietary IP embodied in an interoperability element use that IP only for the licensed purpose, or ONC should allow actors to decline to license that IP at all, we clarify that actors may require that licensees of the proprietary IP embodied in an interoperability element only use that IP for the licensed purpose, so long as such limits are in compliance with all the conditions in § 171.303, including the scope of rights provisions in § 171.303(c)(1). For instance, an actor could place a limitation in the license that the license only covers a one-time use of the interoperability element for accessing and exchanging certain EHI. In this scenario, this limitation 
                        <E T="03">could</E>
                         be allowed under the exception if: (1) Despite the limitation, the licensee's request for access, exchange, or use of EHI is met; and (2) the limitation complies with the conditions in § 171.303. Similarly, if an app developer requests to license a health IT developer's interoperability element in order to enable the exchange of EHI by integrating the app developer's CDS software into Provider A's EHR, the health IT developer could scope the rights in the license to restrict the app developer from using the license to complete the same integration for Provider B, so long as the license complies with the conditions in § 171.303. We also emphasize that under the Content and Manner Exception (§ 171.301), actors are decline to license their proprietary IP so long as they are able to respond to the request to access, exchange, or use EHI through an alternative manner specified in § 171.301(b)(2)(ii)(A)-(C).
                    </P>
                    <P>
                        We have decided not to broaden the scope of rights regarding the development of products or services that are interoperable as suggested by the commenter because we believe this provision, as proposed, is appropriately tailored to addresses information blocking and 
                        <E T="03">should</E>
                         be focused on health IT under the actor's control or any third party who currently uses the actor's interoperability elements to interoperate with health IT under the actor's control.
                    </P>
                    <HD SOURCE="HD3">Reasonable Royalty</HD>
                    <P>
                        As a condition of this exception, we proposed that if an actor charges a royalty for the use of interoperability elements, the royalty base and rate must be reasonable. Importantly, we proposed that the reasonableness of any royalties would be assessed solely on the basis of the independent value of the actor's technology to the licensee's product, 
                        <E T="03">not</E>
                         on any strategic value stemming from the actor's control over essential means of accessing, exchanging, or using EHI (84 FR 7547).
                    </P>
                    <P>In evaluating the actor's assertions and evidence that the royalty was reasonable, we proposed that ONC may consider the following factors:</P>
                    <P>• The royalties received by the actor for the licensing of the proprietary elements in other circumstances comparable to RAND-licensing circumstances.</P>
                    <P>• The rates paid by the licensee for the use of other comparable proprietary elements.</P>
                    <P>• The nature and scope of the license.</P>
                    <P>• The effect of the proprietary elements in promoting sales of other products of the licensee and the licensor, taking into account only the contribution of the elements themselves and not of the enhanced interoperability that they enable.</P>
                    <P>• The utility and advantages of the actor's interoperability element over the existing technology, if any, that had been used to achieve a similar level of access, exchange, or use of EHI.</P>
                    <P>• The contribution of the elements to the technical capabilities of the licensee's products, taking into account only the value of the elements themselves and not the enhanced interoperability that they enable.</P>
                    <P>
                        • The portion of the profit or of the selling price that may be customary in the particular business or in comparable businesses to allow for the use of the proprietary elements or analogous 
                        <PRTPAGE P="25894"/>
                        elements that are also covered by RAND commitments.
                    </P>
                    <P>• The portion of the realizable profit that should be credited to the proprietary elements as distinguished from non-proprietary elements, the manufacturing process, business risks, significant features or improvements added by the licensee, or the strategic value resulting from the network effects, switching costs, or other effects of the adoption of the actor's technology.</P>
                    <P>• The opinion testimony of qualified experts.</P>
                    <P>• The amount that a licensor and a licensee would have agreed upon (at the time the licensee began using the elements) if both were considering the RAND obligation under the exception and its purposes, and had been reasonably and voluntarily trying to reach an agreement (84 FR 7547).</P>
                    <P>
                        We noted that these factors mirror those used by courts that have examined the reasonableness of royalties charged pursuant to a commitment to a standards developing organization to license standard-essential technologies on RAND terms (
                        <E T="03">see Microsoft Corp.</E>
                         v. 
                        <E T="03">Motorola, Inc.;</E>
                         
                        <SU>187</SU>
                        <FTREF/>
                         In re 
                        <E T="03">Innovatio IP Ventures, LLC Patent Litig.;</E>
                         
                        <SU>188</SU>
                        <FTREF/>
                         and 
                        <E T="03">Realtek Semiconductor Corp.</E>
                         v. 
                        <E T="03">LSI Corp.</E>
                         
                        <SU>189</SU>
                        <FTREF/>
                         ). We noted, however, that we adapted the factors to the information blocking context (84 FR 7547).
                    </P>
                    <FTNT>
                        <P>
                            <SU>187</SU>
                             Case No. 10-cv-1823 JLR, 2013 WL 2111217 (W.D.Wash. Apr. 25, 2013).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>188</SU>
                             MDL 2303, 2013 WL 5593609 (N.D.Ill. Oct. 3, 2013).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>189</SU>
                             Case No. 5:12-cv-03451-RMW, 2014 WL 46997 (N.D.Cal. Jan. 6, 2014).
                        </P>
                    </FTNT>
                    <P>We proposed that the RAND inquiry should focus on whether the royalty demanded by the actor represents the independent value of the actor's proprietary technology. We proposed that if the actor has licensed the interoperability element through a standards developing organization in accordance with such organization's policies regarding the licensing of standards-essential technologies on RAND terms, the actor may charge a royalty that is consistent with such policies. We proposed that we would ask whether the actor is charging a royalty that is not based on the value of its technology (embodied in the interoperability elements) but rather includes the strategic value stemming from the adoption of that technology by customers or users. We proposed that we would consider the technical contribution of the actor's interoperability elements to the licensee's products—such as any proprietary capabilities or features that the licensee uses in its product—but would screen out any functional aspects of the actor's technology that are used only to establish interoperability and enable EHI to be accessed, exchanged, and used. Additionally, we proposed that to address the potential risk of royalty stacking, we would need to consider the aggregate royalties that would apply if owners of other essential interoperability elements made royalty demands of the implementer. Specifically, we proposed that, to qualify for the exception, the actor must grant licenses on terms that are objectively commercially reasonable taking into account the overall licensing situation, including the cost to the licensee of obtaining other interoperability elements that are important for the viability of the products for which it is seeking to license interoperability elements from the actor (84 FR 7547 and 7548).</P>
                    <P>We clarified that this condition would not preclude an actor from licensing its interoperability elements pursuant to an existing RAND commitment to a standards developing organization. We also noted that, in addition to complying with the requirements described above, to meet this proposed condition, any royalties charged must meet the condition, proposed separately below, that any license terms be non-discriminatory (84 FR 7548).</P>
                    <P>We requested comment on these aspects of the proposed exception. We encouraged commenters to consider, in particular, whether the factors and approach we described will be administrable and appropriately balance the unreasonable blocking by actors of the use of essential interoperability elements with the need to provide adequate assurance to investors and innovators that they will be able to earn a reasonable return on their investments in interoperable technologies. Further, we noted that if our proposed approach did not adequately balance these concerns or would not achieve our stated policy goals, we asked that commenters suggest revisions or alternative approaches. We asked that such comments be as detailed as possible and provide rigorous economic justifications for any suggested revisions or alternative approaches (84 FR 7548).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received many comments regarding reasonable royalties and the ability of actors to make a profit. Some commenters supported the proposed framework. A couple of commenters recommended that we not allow 
                        <E T="03">any</E>
                         royalty for licensing interoperability elements. One of those commenters suggested we require “RAND-Zero” licensing, by which the copyright holder may still impose non-discriminatory licensing terms on the licensee but may not charge a royalty. The commenter also expressed concern that the overlap between this exception and the exception for recovering costs reasonably incurred creates the potential for actors to earn a double recovery. The commenter explained that licensing of IP is intended to recoup the costs of development of that IP, so where the IP is an interoperability element, the costs reasonably incurred for its development should be incorporated into the royalty rate. The commenter recommended that we be clearer that in these circumstances, only a single recovery is permitted. Provider and registry organizations were concerned that the ability to charge reasonable royalties to license interoperability elements may present an opening for health IT developers to charge unreasonably high fees for exchanging information with provider groups and registries. As such, the commenters recommended that ONC require actors to disclose the methodology behind their fees.
                    </P>
                    <P>Alternatively, other commenters, consisting primarily of health IT developers, expressed concern that the proposals regarding reasonable royalties were too restrictive. Commenters were concerned that the exception, as proposed, would have a detrimental effect on innovation in the industry as it provides disincentives for established companies to develop new, forward-leaning solutions. A few commenters recommended that the value of the actor's technology must be constructed on a “fair market” basis. Commenters stated that ONC should not set or determine the reasonableness of royalties. However, if ONC decided to set or define the reasonableness of royalties, the primary factor for such a determination should be the willingness of licensees to agree to a given royalty rate. A couple of commenters requested clarification regarding ONC's approach for calculating reasonable royalties and ONC's basis for determining whether a royalty is “reasonable.”</P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these thoughtful comments. First, we note, as discussed previously in this section, we have removed all references to “RAND.” However, we have finalized this reasonable royalty provision (§ 171.303(c)(2)) as proposed, with a slight modification for consistency and the addition of a paragraph in § 171.303(c)(2)(iv). The slight modification was made to § 171.303(c)(2)(iii), in which we deleted “on reasonable and non-discriminatory terms” in order to align with the overall approach of removing “RAND” 
                        <PRTPAGE P="25895"/>
                        throughout the exception. In response to comment, we added a paragraph in § 171.303(c)(2)(iv) to address the potential for double recovery in this exception and the Fees Exception (§ 171.302). The new paragraph states that an actor may 
                        <E T="03">not</E>
                         charge a royalty for IP if the actor recovered any development costs pursuant to § 171.302 that led to the creation of the IP.
                    </P>
                    <P>In response to the commenters who expressed concern that our approach for allowing reasonable royalties is too restrictive and could slow innovation, we emphasize that our regulatory approach to implementing the information blocking provision of the Cures Act is informed by years of research and stakeholder engagement indicating that information blocking undermines public and private sector investments in the nation's health IT infrastructure and frustrates efforts to use modern technologies to improve health care quality and efficiency, accelerate research and innovation, and provide greater value and choice to health care consumers. In our experience, contractual and IP rights are frequently used to extract rents for access to EHI or to prevent competition from health IT developers of interoperable technologies and services. These practices frustrate access, exchange, and use of EHI and stifle competition and innovation in the health IT sector.</P>
                    <P>We believe the general claim that the limits on licensing royalties within this exception would inhibit innovation misstates the experiences many stakeholders face today. Our experience in the health IT industry has highlighted that innovation has struggled under current market practices, in which there is no limit on fees and royalties for access and use of interoperability elements. In fact, the ability of large entities with significant market power to prevent access and use of essential interoperability elements has prevented and continues to prevent large amounts of potential investment in innovative solutions for the United States health care market. We also refer readers to the Content and Manner Exception (§ 171.301), where we further address commenter concerns regarding protections for their proprietary IP.</P>
                    <P>
                        We also appreciate the comments that suggested we not allow 
                        <E T="03">any</E>
                         royalty for licensing interoperability elements because allowing a royalty could create an opening for actors to continue to charge unreasonably high fees for the exchange of EHI. We have decided to allow reasonable royalties that must meet certain requirements (see § 171.303(b)(2)) because the allowance of such royalties will promote competition, consumer welfare, and investment in innovation. The conditions we have finalized in § 171.303(b)(2) are specifically tailored to address the type of abuse about which commenters expressed concern. Under the finalized reasonable royalty provision, it would generally be appropriate for actors to license their IP on terms that are non-discriminatory and do not interfere with the access, exchange, or use of EHI so long as the actor meets all of the conditions in § 171.303. We emphasize that actors are able to make reasonable profits from the licensing of interoperability elements, so long as such profits comply with § 171.303(b)(2). These licensing practices will further the goals of the information blocking provision by allowing actors to protect the value of their innovations and earn returns on the investments they have made to develop, maintain, and update those innovations. This approach will also protect future incentives to invest in, develop, and disseminate interoperable technologies and services that could improve the lives and safety of patients nationwide.
                    </P>
                    <P>We acknowledge that limiting the royalties IP holders can charge for access, exchange, or use of EHI departs from IP policy. Absent specific circumstances, IP holders are generally free to negotiate with prospective licensees to determine the royalty to practice their IP, and this negotiated royalty frequently reflects the value the licensee would obtain from exercising those rights. However, in the context of EHI, a limitation on royalties is essential due to the likelihood that unreasonable royalties would frustrate access, exchange, and use of the EHI, particularly because of the imbalanced power dynamics that currently exist in the health IT market.</P>
                    <P>
                        In response to commenters who requested clarification regarding ONC's approach for calculating reasonable royalties, we emphasize that each case of potential information blocking, as well as the “reasonableness” of a royalty, will hinge on the specific facts and circumstances of the case. We explained in the Proposed Rule that the actor would need to show that the royalty base was reasonable and that the royalty was within a reasonable range for the interoperability elements at issue. Importantly, we explained that the reasonableness of any royalties would be assessed solely on the basis of the independent value of the actor's technology to the licensee's product, 
                        <E T="03">not</E>
                         on any strategic value stemming from the actor's control over essential means of accessing, exchanging, or using EHI (84 FR 7547 and 7548). For additional clarification regarding the specific factors to be considered in evaluating an actor's assertion and evidence that a royalty was reasonable, we refer reader to the discussion above and the discussion in the Proposed Rule regarding reasonable royalties (see 84 FR 7547 and 7548).
                    </P>
                    <HD SOURCE="HD3">Non-Discriminatory Terms</HD>
                    <P>We proposed that for the exception to apply, the terms on which an actor licenses and otherwise provides interoperability elements must be non-discriminatory. We explained that this condition would apply to both price and non-price terms, and thus would apply to the royalty terms discussed immediately above as well as other types of terms that may be included in licensing agreements or other agreements related to the provision or use of interoperability elements (84 FR 7548).</P>
                    <P>We proposed that to comply with this condition, the terms on which the actor licensed the interoperability elements must be based on criteria that the actor applied uniformly for all substantially similar or similarly situated classes of persons and requests. In order to be considered non-discriminatory, such criteria would have to be objective and verifiable, not based on the actor's subjective judgment or discretion. We emphasized that this proposal does not mean that the actor must apply the same terms for all persons or classes of persons requesting a license. However, any differences in terms would have to be based on actual differences in the costs that the actor incurred or other reasonable and non-discriminatory criteria. Moreover, we proposed that any criteria upon which an actor varies its terms or conditions would have to be both competitively neutral—meaning that the criteria are not based in any part on whether the requestor or other person is a competitor, potential competitor, or will be using EHI obtained via the interoperability elements in a way that facilitates competition with the actor—and neutral as to the revenue or other value that the requestor may derive from access, exchange, or use of the EHI obtained via the interoperability elements, including any secondary use of such EHI (84 FR 7548). For a detailed example regarding this proposed condition, see the Proposed Rule (84 FR 7548).</P>
                    <P>
                        We noted that the foregoing conditions were not intended to limit an actor's flexibility to set different terms based on legitimate differences in the 
                        <PRTPAGE P="25896"/>
                        costs to different classes of persons or in response to different classes of requests, so long as any such classification was in fact based on neutral criteria (in the sense described above) that are objectively verifiable and were applied in a consistent manner for persons and/or requests within each class. For instance, the proposed condition would not preclude an actor from pursuing strategic partnerships, joint ventures, co-marketing agreements, cross-licensing agreements, and other similar types of commercial arrangements under which it provides more favorable terms than for other persons with whom it has a more arms-length relationship. We explained that in these instances, the actor should have no difficulty identifying substantial and verifiable efficiencies that demonstrate that any variations in its terms and conditions were based on objective and neutral criteria (84 FR 7548).
                    </P>
                    <P>We proposed that a health IT developer of certified health IT who is an “API Technology Supplier” under the Condition of Certification proposed in § 170.404 would not be permitted to offer different terms in connection with the APIs required by that Condition of Certification. We proposed that API Technology Suppliers are required to make these APIs available on terms that are no less favorable than provided to their own customers, suppliers, partners, and other persons with whom they have a business relationship (84 FR 7548 and 7549).</P>
                    <P>We requested comments on the foregoing conditions (84 FR 7549).</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter disagreed with the proposal that the terms must not be based in any part on revenue or other value the requestor may derive from access, exchange, or use of EHI obtained via the interoperability elements, including the secondary use of such EHI. The commenter stated that such information should be considered.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank the commenter for this feedback, but have decided to finalize this provision as proposed, with slight modification. We continue to believe that license terms for licensing interoperability elements required for the access, exchange, or use of EHI should not be based in any part of the revenue or other value the requestor may derive from access, exchange, or use of EHI obtained via the interoperability elements, including the subsequent use of such EHI. The allowance of such terms could enable the type of opportunistic pricing and anti-competitive behavior that this exception seeks to address. We note that we have removed the proposed example about “secondary use” from the regulation text because such an example is not necessary in the regulation text (see 84 FR 7604). We emphasize, however, that we continue to maintain that the terms must 
                        <E T="03">not</E>
                         be based on revenue or other value derived from the subsequent use of EHI. Our policy on this point has not changed from the Proposed Rule. The terms and conditions 
                        <E T="03">could</E>
                         vary based on neutral, objectively verifiable, and uniformly applied criteria. These might include, for example, significantly greater resources consumed by certain types of apps, such as those that export large volumes of data on a continuous basis, or the heightened risks associated with apps designed to “write” data to the EHR database or to run natively within the EHR's user interface.
                    </P>
                    <P>
                        We emphasize that health IT developers that license interoperability elements in order for EHI to be accessed, exchanged, or used could 
                        <E T="03">not</E>
                         vary the license terms and conditions based on subjective criteria, such as whether it thinks an app will be “popular” or is a “good fit” for its ecosystem. Nor could developers offer different terms or conditions on the basis of objective criteria that are not competitively neutral, such as whether an app “connects to” other technologies or services, provides capabilities that the EHR developer plans to incorporate in a future release of its technology, or enables an efficient means for customers to export data for use in other databases or technologies that compete directly with the EHR developer. Similarly, the EHR developer could not set different terms or conditions based on how much revenue or other value the app might generate from the information it collects through the APIs, such as by introducing a revenue-sharing requirement for apps that use data for secondary purposes that are very lucrative and for which the EHR developer would like a “piece of the pie.” Such practices would disqualify the actor from this exception and would implicate the information blocking provision.
                    </P>
                    <P>We note that we made a slight modification to § 171.303(c)(3)(i) in that we removed “substantially similar.” We believe “similarly situated,” without “substantially similar” is clearer, maintains the intended effect, and is consistent with language used in other exceptions.</P>
                    <HD SOURCE="HD3">Collateral Terms</HD>
                    <P>
                        We proposed five additional conditions that would reinforce the requirements of the proposed exception. We explained that these additional conditions would provide bright-line prohibitions for certain types of collateral terms or agreements that we believe are inherently likely to interfere with access, exchange, or use of EHI. We proposed that any attempt to 
                        <E T="03">require</E>
                         a licensee or its agents or contractors to do or agree to do any of the following would disqualify the actor from the exception and would be suspect under the information blocking provision (84 FR 7549).
                    </P>
                    <P>First, we proposed that the actor must not require the licensee or its agents or contractors to not compete with the actor in any product, service, or market, including markets for goods and services, technologies, and research and development. We explained that we are aware that such agreements have been used to either directly exclude suppliers of interoperable technologies and services from the market or to create exclusivity that reduces the range of technologies and options available to health care providers and other health IT customers and users (84 FR 7549).</P>
                    <P>Second, we proposed that the actor must not require the licensee or its agents or contractors to deal exclusively with the actor in any product, service, or market, including markets for goods and services, technologies, and research and development (84 FR 7549).</P>
                    <P>
                        Third, we proposed that the actor must not require the licensee or its agents or contractors to obtain additional licenses, products, or services that are not related to or can be unbundled from the requested interoperability elements. We explained that without this condition, we believe that an actor could require a licensee to take a license to additional interoperability elements that the licensee does not need or want, which could enable the actor to extract royalties that are inconsistent with its RAND obligations under this exception. We clarified that this condition would not preclude an actor and a willing licensee from agreeing to such an arrangement, so long as the arrangement was not 
                        <E T="03">required</E>
                         (84 FR 7549).
                    </P>
                    <P>
                        Fourth, we proposed that the actor must not condition the use of interoperability elements on a requirement or agreement to license, grant, assign, or transfer the licensee's own IP to the actor. We explained that it would raise information blocking concerns for an actor to use its control over interoperability elements as leverage to obtain a “grant back” of IP rights or other consideration whose value may exceed that of a reasonable royalty. We proposed that, consistent with our approach under other conditions of this exception, this condition would not preclude an actor 
                        <PRTPAGE P="25897"/>
                        and a willing licensee from agreeing to a cross-licensing, co-marketing, or other agreement if they so choose. However, the actor could not 
                        <E T="03">require</E>
                         the licensee to enter into such an agreement. We proposed that the actor must offer the option of licensing the interoperability elements without a promise to provide consideration beyond a reasonable royalty (84 FR 7549).
                    </P>
                    <P>Finally, we proposed that the actor must not condition the use of interoperability elements on a requirement or agreement to pay a fee of any kind whatsoever unless the fee meets either the narrowly crafted condition to this exception for a reasonable royalty, or, alternatively, the fee satisfies the separate exception in § 171.302, which permits the recovery of certain costs reasonably incurred (84 FR 7549).</P>
                    <P>We requested comment on these categorical exclusions. In particular, we encouraged commenters to weigh in on our assumption that these practices are inherently likely to interfere with access, exchange, or use of EHI. We also encouraged commenters to suggest any conceivable benefits that these practices might offer for interoperability or for competition and consumers that we might have overlooked. Again, we asked that to the extent possible commenters provide detailed economic rationale in support of their comments (84 FR 7549).</P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter noted that situations exist where licensors do not have the ability to lawfully confer rights or licenses to information or products without the agreement of a third party. The commenter recommended that we add “except as required by law” to the collateral terms provisions in order to clarify that the expectation is not that an actor must obtain such rights on behalf of the requestor.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this comment, but have decided not to make the suggested edit because we do not believe such an addition is necessary. The collateral terms provisions do not address whether an actor is expected to obtain rights from a third party to lawfully confer rights or licenses to interoperability elements. Instead, the collateral terms provisions describe conditions that the actors must 
                        <E T="03">not</E>
                         require of the licensee or its agents or contractors to do because such conditions are inherently likely to interfere with access, exchange, or use of EHI. We note that we have revised the definition of “interoperability element” (see § 171.102) to clarify that in order to meet the definition, the element must be “controlled by the actor,” which addresses the commenter's concern. We have also defined “controlled by the actor” in § 171.102 in the context of the interoperability element definition for clarity. If the actor could not lawfully confer a right or authorization, the actor would not have the requisite “control” under the “interoperability element.” Last, we emphasize that in situations when an actor does not have the ability to lawfully confer rights or licenses to enable the access, exchange, or use of EHI, the actor could seek coverage under the Infeasibility Exception (see § 171.204(a)(3)) or the Content and Manner Exception (see § 171.301(b)).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any other comments regarding the proposed collateral terms proposals except those noted in the comment summary above.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have finalized the collateral terms as proposed.
                    </P>
                    <HD SOURCE="HD3">Non-Disclosure Agreement</HD>
                    <P>We proposed that an actor would be permitted under this exception to require a licensee to agree to a confidentiality or non-disclosure agreement (NDA) to protect the actor's trade secrets, provided that the NDA is no broader than necessary to prevent the unauthorized disclosure of the actor's trade secrets. Further, we proposed that the actor would have to identify (in the NDA) the specific information that it claims as trade secrets, and that such information would have to meet the definition of a trade secret under applicable law. We noted that if the actor is a health IT developer of certified health IT, it may be subject to the Condition of Certification that prohibits certain health IT developer prohibitions and restrictions on communications about a health IT developer's technology and business practices. We emphasized that the exception would not in any way abrogate the developer's obligations to comply with that condition. We encouraged comment on this condition of the proposed exception (84 FR 7549).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a couple of comments regarding the proposed NDA provision. One commenter recommended that we state in the final rule that interoperability elements themselves may not be protected as trade secrets. Another commenter expressed concern that this exception acts to require NDAs in certain circumstances. The commenter also suggested edits to preamble language that would allow the actor to “generally” identify the information that it claims as trade secrets, as opposed to the proposed language of identifying the “specific” information that it claims as trade secrets.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these thoughtful comments. We clarify that interoperability elements may be protected as trade secrets. Trade secrets are a type of IP that consist of information and can include a formula, pattern, compilation, program, device, method, technique or process,
                        <SU>190</SU>
                        <FTREF/>
                         and could fall within the definition of “interoperability element” (see § 171.102). We note, as discussed in more detail in VIII.C.5.b, that we have leveraged the definition of “health information technology” from section 3000(5) of the PHSA for the definition of “interoperability element” in § 171.102, and that IP is included in that definition of “health information technology.” The PHSA defines “health information technology” as “hardware, software, integrated technologies or related licenses, 
                        <E T="03">intellectual property,</E>
                         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>
                    <FTNT>
                        <P>
                            <SU>190</SU>
                             USPTO, Trade Secret Policy, 
                            <E T="03">https://www.uspto.gov/patents-getting-started/international-protection/trade-secrets-policy</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        In response to the commenter that expressed concern that this exception acts to require NDAs in certain circumstances, we emphasize that we are 
                        <E T="03">not</E>
                         requiring NDAs. We included this provision in order to help actors protect their IP and actors may draft the NDA in a manner that best suits their needs so long as the NDA meets the requisite conditions in § 171.303(b)(5). We have decided not to allow actors to “generally” identify the information that they claim as trade secrets because such a change could enable actors to make broad assertions of trade secret protection that exceed the 
                        <E T="03">actual</E>
                         trade secrets. The safeguards we have finalized in the NDA provision (
                        <E T="03">e.g.,</E>
                         that the agreement is no broader than necessary to prevent unauthorized disclosure of the actor's trade secrets and the agreement states with particularity all information the actor claims as trade secrets) are necessary to ensure that the NDA is not used to impose restrictions or burdensome requirements that are not actually necessary to protect the actor's trade secrets and that impede the use of the interoperability elements. We emphasize that the use of an NDA for such purposes would preclude an actor from qualifying for this exception and would implicate the information blocking provision.
                        <PRTPAGE P="25898"/>
                    </P>
                    <HD SOURCE="HD3">iii. Additional Requirements Relating to the Provision of Interoperability Elements</HD>
                    <P>We proposed that an actor's practice would need to comply with additional conditions that ensure that actors who license interoperability elements on RAND terms do not engage in separate practices that impede the use of those elements or otherwise undermine the intent of this exception. We explained that these conditions are analogous to the conditions described in our proposal concerning collateral terms but address a broader range of practices that may not be effected through the license agreements themselves or that occur separately from the licensing negotiations and other dealings between the actor and the licensee. Specifically, we proposed that an actor would not qualify for this exception if it engaged in a practice that had the purpose or effect of impeding the efficient use of the interoperability elements to access, exchange, or use EHI for any permissible purpose; or the efficient development, distribution, deployment, or use of an interoperable product or service for which there is actual or potential demand. We explained that the exception would not apply if the developer licensed its proprietary APIs for use by third-party apps but then prevented or delayed the use of those apps in production environments by, for example, restricting or discouraging customers from enabling the use of the apps, or engaging in “gate keeping” practices, such as requiring apps to go through a vetting process and then applying that process in a discriminatory or unreasonable manner. Finally, to ensure the actor's commitments under this exception are durable, we proposed one additional safeguard: An actor could not avail itself of this exception if, having licensed the interoperability elements, the actor makes changes to the elements or its technology that “break” compatibility or otherwise degrade the performance or interoperability of the licensee's products or services (84 FR 7549 and 7550).</P>
                    <P>
                        We emphasized that this proposed condition would in 
                        <E T="03">no way</E>
                         prevent an actor from making improvements to its technology or responding to the needs of its own customers or users. However, to benefit from the exception, the actor's practice would need to be necessary to accomplish these purposes and the actor must have afforded the licensee a reasonable opportunity under the circumstances to update its technology to maintain interoperability (84 FR 7550).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         One commenter stated that the proposed restriction regarding breaking compatibility or otherwise degrading the performance or interoperability of the licensee's products or services is too broad. The commenter suggested that ONC add procedural safeguards to avoid misuse and unpredictable enforcement. Specifically, the commenter recommended that ONC: (1) Institute a grace period for licensors to provide fixes where interoperability elements are inadvertently unavailable due to software changes; (2) permit health IT developers to maintain their existing processes to notify customers about upgraded standards on a reasonable timeframe; (3) allow, with a year's notice, retirement of functionality in future versions of the software; (4) acknowledge that the use of interoperability elements will always require some initial work and ongoing upkeep by the licensee, such as testing and continuous work to deploy technology at health systems with different workflows; and (5) the ONC-administered advisory opinion process should account for review of RAND licensing terms to provide clarity to the regulated actors.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We agree with the commenter that it is critical that the final exceptions are transparent and cannot be misused. Each exception should clearly explain what conduct would be covered by the exception and what conduct falls outside the scope of the exception. In response to the commenter, we note that we have not prevented health IT developers from maintaining their existing processes to notify customers about upgraded standards on a reasonable timeframe, nor have we instituted any new policies regarding the retirement of functionality in future versions of software. Further, we acknowledge that the use of interoperability elements may require some initial work and ongoing upkeep by the licensee, such as testing and continuous work to deploy technology in health systems with different workflows. However, we emphasize that such initial work, ongoing upkeep, or any additional burden on licensees must meet all the conditions of this exception as all relevant times.
                    </P>
                    <P>We have decided not to institute a grace period for licensors to provide fixes where interoperability elements are inadvertently unavailable due to software changes because we do not believe such a grace period is necessary. Having consulted with OIG, we note that OIG generally does not pursue civil monetary penalties for actors who make innocent mistakes or for accidental conduct. Future notice and comment rulemaking by OIG will provide more additional detail regarding information blocking enforcement.</P>
                    <P>We may consider developing materials in the future regarding the application of the exceptions should the need arise. However, we believe the final rule clearly describes the conditions actors must meet in order to be covered by each exception, and informational materials are not necessary at this time.</P>
                    <HD SOURCE="HD3">iv. Compliance With Conditions of Certification</HD>
                    <P>As a final condition of the proposed exception, we proposed that health IT developers of certified health IT who are subject to the Conditions of Certification proposed in §§ 170.402, 170.403, and 170.404 must comply with all requirements of those Conditions of Certification for all practices and at all relevant times (84 FR 7550).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments on this proposed condition.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have removed this proposed condition from the final rule for consistency with other exceptions and for clarity, as the condition is not necessary.
                    </P>
                    <HD SOURCE="HD2">E. Additional Exceptions—Request for Information</HD>
                    <HD SOURCE="HD3">1. Exception for Complying With Common Agreement for Trusted Exchange</HD>
                    <P>
                        In the Proposed Rule, we included a request for information (RFI) regarding whether we should propose, in a future rulemaking, a narrow exception to the information blocking provision for practices that are necessary to comply with the requirements of the Common Agreement (84 FR 7552). The most recent draft Trusted Exchange Framework and Common Agreement was released for public comment on April 19, 2019.
                        <SU>191</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>191</SU>
                             ONC, 
                            <E T="03">Draft 2 Trusted Exchange Framework and Common Agreement, https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Comments.</E>
                         We received over 40 comment submissions on this RFI expressing various viewpoints on the purpose, need, and structure of a TEFCA exception.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their feedback. As noted in the Proposed Rule, we may use this feedback to inform a future rulemaking.
                    </P>
                    <HD SOURCE="HD3">2. New Exceptions</HD>
                    <P>
                        In the Proposed Rule, we included an RFI regarding any potential new exceptions we should consider for future rulemaking (84 FR 7552).
                        <PRTPAGE P="25899"/>
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a number of requests for a new exception to cover sensitive and/or privileged information. A health IT developer suggested a new exception to allow actors to withhold sensitive information. The commenter expressed concern that EHI at a certain data class or data element level will require health care providers to exert substantial manual effort to mediate disclosure. Health care providers and provider organizations suggested an exception that would exempt actors from the information blocking provision if they are protecting privileged information. One commenter expressed concern about providing access, exchange, or use of quality program and reporting data. A hospital suggested that requiring providers to waive privilege in order to avoid information blocking would have a detrimental effect on peer reviews and safety assessments that help providers resolve adverse events.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these suggestions. We first note that the health information must fall within the EHI definition, which aligns with the ePHI definition contained in the HIPAA Rules. We note that actors faced with a request to access, exchange, We note that actors faced with a request to access, exchange, or use sensitive and/or privileged information can seek coverage under the exceptions for preventing harm (§ 171.201), promoting the privacy of EHI (§ 171.202), promoting the security of EHI (§ 171.203), or infeasibility (§ 171.204), depending on the specific information at issue and the circumstances of the case. We refer readers to those exceptions, as well as the preamble discussions at sections VIII.D.1 (Preventing Harm Exception), VIII.D.2 (Privacy Exception), VIII.D.3 (Security Exception), and VIII.D.4 (Infeasibility Exception). We also note that an actor would not be required to share EHI if the interference with access, exchange, or use of the EHI is explicitly required by State or Federal law (see the discussion regarding “required by law” at section VIII.C.1 of this preamble). We emphasize that this final rule does 
                        <E T="03">not</E>
                         require actors to waive privilege provided by law.
                    </P>
                    <P>
                        <E T="03">Comment</E>
                        s. Some commenters expressed concern about the effect of the information blocking provision on research. Public health organizations proposed an exception to exclude research (as defined by 45 CFR 164.501) and non-direct clinical care conducted by public health authorities, from implicating the information blocking provision. A hospital requested that we establish a new sub-exception under the exception for preventing harm that would allow health care providers who conduct research at their institutions to require that other providers who request EHI are also collaborators in that research. One commenter suggested an exception for health care providers who cannot send data to a public health registry when the public health agency is not ready to onboard the provider due factors outside of the provider's control (
                        <E T="03">e.g.,</E>
                         lack of resources or a backup in the onboarding queue).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for these suggestions. We note that actors faced with a request to access, exchange, or use EHI related to research can seek coverage under the exceptions for promoting the privacy of EHI (§ 171.202) or infeasibility (§ 171.204), depending on the specific research being conducted and EHI at issue. We refer readers to those exceptions, as well as the preamble discussions at sections VIII.D.2 (Privacy Exception) and VIII.D.4 (Infeasibility Exception). We also note that an actor would not be required to share EHI if the interference with access, exchange, or use of the EHI is explicitly required by State or Federal law (see the discussion regarding “required by law” at section VIII.C.1 of this preamble).
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Some commenters requested a new exception to protect actors who seek independent opinions from external validators regarding their business practices, in case one of those practices falls within the definition of information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this suggestion. With regard to private “external validators,” we note that we are not restricting an actor's ability to hire private companies to assess its business practices.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         A commenter recommended an exception for standard business practices. The commenter explained that examples of such conduct include suspending the access of any health IT developer or e-prescribing application that is not compliant with State laws or uses the provider's technology platform for reasons that compromises the integrity of the provider's network (
                        <E T="03">e.g.,</E>
                         using the network for commercial messaging).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We appreciate this suggestion. While we would need more facts to properly assess these scenarios, we believe that such situations could likely be covered by either the exception for promoting the privacy of EHI (§ 171.202) or the exception for promoting the security of EHI (§ 171.203). We refer readers to those exceptions, as well as the preamble discussions at sections VIII.D.2 (Privacy Exception) and VIII.D.3 (Security Exception). We also note that the actor would not be required to share EHI if the interference with access, exchange, or use of the EHI is explicitly required by State or Federal law (see the discussion regarding “required by law” at section VIII.C.1 of this preamble).
                    </P>
                    <HD SOURCE="HD2">F. Complaint Process</HD>
                    <P>We explained in the Proposed Rule that section 3022(d)(3)(A) of the PHSA directs the National Coordinator to implement a standardized process for the public to submit reports on claims of information blocking (84 FR 7552). Section 3022(d)(3)(B) further requires that the complaint process provide for the collection of such information as the originating institution, location, type of transaction, system and version, timestamp, terminating institution, locations, system and version, failure notice, and other related information.</P>
                    <P>
                        In the Proposed Rule, we stated that we intend to implement and evolve the complaint process by building on existing mechanisms, including the process for providing feedback and expressing concerns about health IT that is currently available at 
                        <E T="03">https://www.healthit.gov/healthit-feedback</E>
                         (84 FR 7553). We requested comment on this approach and any alternative approaches that would best effectuate this aspect of the Cures Act. In addition to any other comments that the public may have wished to submit, we specifically requested comment on several specific questions. The scope of these questions was specific to the information blocking complaint submission process and the information collection necessary to enable effective investigations and safeguard the confidentiality of information submitted through the complaint process.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         We received over 25 comment submissions that included suggestions for the information blocking complaint process. A few commenters responded to one or more of the specific questions in the Proposed Rule, offering suggestions for specific data elements that complainants should be able to enter as part of a complaint. Some commenters suggested specific features such as: A dedicated secure online portal for entry of information blocking complaints and any supporting documents; a dedicated email box or toll-free phone number for submission of information blocking complaints; the ability to batch multiple instances of potential information blocking activity by the same actor into one complaint submission; and a user interface of pick-lists to help submitters more easily categorize their concerns and/or mark specific portions of or attachments to 
                        <PRTPAGE P="25900"/>
                        their complaints according to their level of sensitivity or requested confidentiality. Numerous commenters expressed support for the existence of a publicly available, user-friendly complaint process and recommended that the development and publication of the complaint process include robust educational and informational materials. A few commenters requested an opportunity for public comment on the complaint process's operational details prior to it going live.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We note that the complaint process is not required by statute to be established through rulemaking and we did not intend to give an impression that it would by including the request for information about the complaint process in the Proposed Rule. Rather, as was the intended outcome, we have received thoughtful suggestions that have informed our initial rollout of the information blocking complaint process as well as have provided considerations for further evolution of the process.
                    </P>
                    <P>
                        We have identified several themes and specific suggestions in the comments that we will address below for the purposes of transparency and to inform stakeholders. We have developed a dedicated complaint process that is based upon and informed by our experience with our current health IT feedback process and the comments received on the Proposed Rule. We also plan to publish informational materials to accompany the rollout of this dedicated information blocking complaint process so that potential complainants across the affected stakeholder categories can successfully use it to submit complaints where they believe they have experienced or observed conduct that constitutes information blocking. While we do not anticipate publishing potential operational details of the complaint process and submission mechanism in advance of its rollout, we would like to amplify a point we noted in the Proposed Rule, which is that we intend to implement 
                        <E T="03">and evolve</E>
                         the complaint process. After we launch the information blocking complaint process, we anticipate using our own experience and users' feedback about the information blocking complaint process to identify opportunities to further evolve and enhance all aspects of the information blocking complaint process, including but not limited to its associated informational materials.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that all information blocking complaints be publicly posted and available. Conversely, many commenters were in strong support of ONC ensuring adequate confidentiality for those who submit information blocking complaints.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Section 3022(d)(2) of the PHSA exempts from public disclosure “any information that is received by the National Coordinator in connection with a claim or suggestion of possible information blocking and that could reasonably be expected to facilitate identification of the source of the information” except as may be necessary to carry out the purpose of PHSA section 3022. We believe the publishing of complaints could lead to the identification of the source of the information or reasonably facilitate identification of the source; therefore, we do not intend to make complaints publicly available. In specific reference to health IT developers of certified health IT, however, we note that we publish in the Certified Health IT Product List (CHPL) information about non-conformities with Program requirements, which would include any non-conformities with the Information Blocking Condition of Certification requirement. We also note that the information blocking complaint process offers the option for users to submit anonymously, explaining in multiple places types of submission information to exclude for those who would like to maintain confidentiality.
                    </P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters requested that complainants be required to submit sufficient evidence of 
                        <E T="03">intentional</E>
                         information blocking in the complaint submission process. Another commenter suggested complainants be required to meet particular qualifications in order to submit a formal complaint.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. However, we do not believe requiring a complaint submission to include more than the minimum information necessary to understand the complainant's concern would best serve the purpose of the complaint process. We believe that requiring that a complainant meet a proof, evidentiary, or qualification standard as a pre-requisite to them submitting a complaint would inappropriately discourage or prevent many individuals and organizations who are subjected to conduct that may meet the definition of information blocking from sharing their concerns with us.
                    </P>
                    <HD SOURCE="HD2">G. Disincentives for Health Care Providers—Request for Information</HD>
                    <P>Section 3022(b)(2)(B) of the PHSA provides that any health care provider determined by OIG to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable Federal law, as the Secretary sets forth through notice and comment rulemaking. We requested comment on potential disincentives and whether modifying disincentives already available under existing Department programs and regulations would provide for more effective deterrents (84 FR 7553).</P>
                    <P>We also sought information on the implementation of section 3022(d)(4) of the PHSA, which provides that in carrying out section 3022(d) of the PHSA, the Secretary shall, to the extent possible, not duplicate penalty structures that would otherwise apply with respect to information blocking and the type of individual or entity involved as of the day before December 13, 2016—enactment of the Cures Act.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received over 40 submissions on this RFI. We have organized and summarized the comments by topic below.
                    </P>
                    <HD SOURCE="HD3">Need for Disincentives</HD>
                    <P>Views on the need for additional disincentives generally diverged based on stakeholder type. Health care providers were generally opposed to additional disincentives. Provider organizations were opposed to any new disincentives. Nearly all these organizations stated that any additional disincentives would be duplicative of disincentives for information blocking put in place through the QPP and Promoting Interoperability Programs. In particular, hospitals noted concerns that they are already subject to a 75 percent negative adjustment to their market basket increase if they are unable to make the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA)-mandated attestation that they have not engaged in information blocking. However, a few provider organizations noted that any new disincentives would only be duplicative for providers that are eligible for these specific CMS-administered programs, recognizing that the existing disincentives under Medicare would not reach providers that do not participate in QPP or PI Programs.</P>
                    <P>Multiple provider organizations stated that additional disincentives would be duplicative of fines for HIPAA Rules violations and mentioned that the Office for Civil Rights (OCR) has expressed an intent to increase HIPAA Rules enforcement on providers.</P>
                    <P>A patient-facing app developer commented that the HIPAA Rule's disincentives, attestation, and public reporting are not enough to discourage information blocking.</P>
                    <P>
                        Several health IT developers were neutral on the topic, stating that it was 
                        <PRTPAGE P="25901"/>
                        unclear if additional disincentives would duplicate disincentives in other programs.
                    </P>
                    <P>One payer, one patient advocacy organization, and one HIN were supportive of additional provider disincentives.</P>
                    <P>
                        The HITAC recommended that ONC work with CMS to build information blocking disincentives into a broad range of CMS programs, and that ONC work with other Federal departments and agencies that contract with providers (
                        <E T="03">e.g.,</E>
                         Veterans Health Administration, Department of Defense Military Health System, Indian Health Service, Centers for Disease Control and Prevention) to similarly build information blocking disincentives into contracting and other programs. The HITAC also recommended that providers be required to attest to compliance with requirements to avoid information blocking as part of Conditions of Participation, Conditions for Coverage, contracts, and other similar relationships, covering fee-for-service (FFS), value-based care, and direct payment relationships. The HITAC noted that such an attestation requirement could potentially allow for pursuit of serious penalties should OIG find the provider engaged in information blocking.
                    </P>
                    <HD SOURCE="HD3">Magnitude of Penalties</HD>
                    <P>While health care providers were generally opposed to disincentives, some did offer recommendations for keeping penalties to a minimum. About half of the provider organizations commenting stated that any fines for providers should not be at the same level as those levied against health IT developers, HINs, and HIEs. Other provider organizations had more specific recommendations, including a tiered approach to penalties. One provider organization recommended a two-tiered approach, with more significant financial penalties for large hospitals and health systems and public reporting or QPP score reductions for physicians. Another provider organization recommended a tiered approach that mimics the approach used under HIPAA (as modified by HITECH), in which penalties increase based on the nature and extent of the violation and resulting harm. Another provider organization recommended that organizations found to engage in information blocking be disqualified from the PI category in QPP.</P>
                    <P>Some health IT developers recommended significant penalties for providers. Several health IT developers recommended that ONC work with CMS to utilize and enhance existing disincentive mechanisms, with one developer specifically recommending utilization of the Conditions of Participation, Conditions for Coverage, and Requirements for Participation. One app developer recommended that fines for information blocking be substantial and per record blocked. The HITAC stated that fines should be significant enough to discourage problematic behavior, encourage compliance, and incent providers to address and remediate problematic behavior. A payer commented that fines should be consistent with those levied against developers, HINs, and HIEs.</P>
                    <HD SOURCE="HD3">Enforcement</HD>
                    <P>Most health care providers and provider organizations recommended that providers be given the opportunity to become compliant before being subject to any fines, except in instances of clear, egregious violations. Some provider organizations recommended that there be an appeals process for disincentives or findings that health care providers had violated the information blocking provision, with one organization noting that an appeals process is especially needed for small and rural practices.</P>
                    <P>
                        <E T="03">Response.</E>
                         We have shared all the comments received with the appropriate agencies and offices within the Department for consideration in subsequent rulemaking to implement section 3022(b)(2)(B) and (d) of the PHSA.
                    </P>
                    <HD SOURCE="HD1">IX. Registries Request for Information</HD>
                    <P>In the Proposed Rule, we included a Request for Information (RFI) on how health IT solutions and the proposals in the Proposed Rule could aid bidirectional exchange with registries for a wide range of public health, quality reporting, and clinical quality improvement initiatives (84 FR 7553). We received 75 comments in response to this RFI. We thank commenters for their input and we may consider including this information in a future rulemaking.</P>
                    <HD SOURCE="HD1">X. Patient Matching Request for Information</HD>
                    <P>Patient matching is a critical component to interoperability and the nation's health IT infrastructure. In the Proposed Rule, we included a Request for Information (RFI) on additional opportunities that may exist in the patient matching space and ways that ONC can lead and contribute to coordination efforts with respect to patient matching (84 FR 7554). We received 128 comments in response to this RFI. We appreciate the input provided by commenters and may use this information to inform future rulemaking.</P>
                    <HD SOURCE="HD1">XI. Incorporation by Reference</HD>
                    <P>
                        The Office of the Federal Register has established requirements for materials (
                        <E T="03">e.g.,</E>
                         standards and implementation specifications) that agencies incorporate by reference in the Code of Federal Regulations (79 FR 66267; 1 CFR 51.5). Specifically, § 51.5(b) requires agencies to discuss, in the preamble of a final rule, the ways that the materials they incorporate by reference are reasonably available to interested parties and how interested parties can obtain the materials, and to summarize, in the preamble of the final rule, the material they incorporate by reference.
                    </P>
                    <P>To make the materials we intend to incorporate by reference reasonably available, we provide a uniform resource locator (URL) for the standards and implementation specifications. In many cases, these standards and implementation specifications are directly accessible through the URLs provided. In instances where they are not directly available, we note the steps and requirements necessary to gain access to the standard or implementation specification. In most of these instances, access to the standard or implementation specification can be gained through no-cost (non-monetary) participation, subscription, or membership with the adopted standards developing organization (SDO) or custodial organization. In certain instances, where noted, access requires a fee or paid membership. As an alternative, 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 IV of this preamble, we have followed the 
                        <PRTPAGE P="25902"/>
                        NTTAA and OMB Circular A-119 in adopting standards and implementation specifications for adoption, including describing any exceptions in the adoption of standards and implementation specifications. Over the years of adopting standards and implementation specifications for certification, we have worked with SDOs, such as HL7, to make the standards we adopt and incorporate by reference in the 
                        <E T="04">Federal Register</E>
                         available to interested stakeholders. 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 1 CFR 51.5(b), we provide summaries of the standards we have adopted and incorporate by reference in the Code of Federal Regulations (CFR). We also provide relevant information about these standards and implementation specifications throughout the preamble.</P>
                    <P>We have organized the standards and implementation specifications that we have adopted through this rulemaking according to the sections of the Code of Federal Regulation (CFR) in which they will be codified and cross-referenced for associated certification criteria and requirements that we have adopted.</P>
                    <HD SOURCE="HD2">Content Exchange Standards and Implementation Specifications for Exchanging Electronic Health Information—45 CFR 170.205</HD>
                    <HD SOURCE="HD3">• CMS Implementation Guide for Quality Reporting Document Architecture Category I Hospital Quality Reporting Implementation Guide for 2019, May 4, 2018</HD>
                    <P>
                        <E T="03">URL: https://ecqi.healthit.gov/system/files/QRDA_HQR_2019_CMS_IG_final_508.pdf</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This guide is a CMS Quality Reporting Document Architecture Category I (QRDA I) implementation guide to the 
                        <E T="03">HL7 Implementation Guide for CDA Release 2: Quality Reporting Document Architecture Category I, Release 1, STU Release 5 (published December 2017),</E>
                         and referred to as the HL7 QRDA IG STU R5 in this guide. This guide describes additional conformance statements and constraints for electronic health record (EHR) data submissions that are required for reporting information to the Centers for Medicare &amp; Medicaid Services (CMS) for the Hospital Inpatient Quality Reporting Program 2019 Reporting Period. The purpose of this guide is to serve as a companion to the base HL7 QRDA I STU R5 for entities such as Eligible Hospitals (EH), Critical Access Hospitals (CAH), and developers to submit QRDA I data for consumption by CMS systems including for Hospital Quality Reporting (HQR).
                    </P>
                    <HD SOURCE="HD3">• CMS Implementation Guide for Quality Reporting Document Architecture Category III Eligible Clinicians and Eligible Professionals Programs Implementation Guide for 2019, October 8, 2018</HD>
                    <P>
                        <E T="03">URL: https://ecqi.healthit.gov/system/files/2019_CMS_QRDA_III_Eligible_Clinicians_and_EP_IG-508.pdf.</E>
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Health Level Seven International (HL7) Quality Reporting Document Architecture (QRDA) defines constraints on the HL7 Clinical Document Architecture Release 2 (CDA R2). QRDA is a standard document format for the exchange of electronic clinical quality measure (eCQM) data. QRDA reports contain data extracted from EHRs and other information technology systems. The reports are used for the exchange of eCQM data between systems for quality measurement and reporting programs. This QRDA guide contains the CMS supplemental implementation guide to the 
                        <E T="03">HL7 Implementation Guide for CDA Release 2: Quality Reporting Document Architecture, Category III, STU Release 2.1 (June, 2017)</E>
                         for the 2019 performance period. This HL7 base standard is referred to as the HL7 QRDA-III STU R2.1.
                    </P>
                    <HD SOURCE="HD3">• Health Level 7 (HL7®) CDA R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2-US Realm, October 2019</HD>
                    <P>
                        <E T="03">URL: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=447</E>
                        .
                    </P>
                    <P>Access requires a “user account” and a license agreement. There is no monetary cost for a user account and license agreement.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The Companion Guide to Consolidated Clinical Document Architecture (C-CDA) R2, provides essential implementer guidance to continuously expand interoperability for clinical information shared via structured clinical notes. The guidance supplements specifications established in the Health Level Seven (HL7) CDA® R2.1 IG: C-CDA Templates for Clinical Notes. This additional guidance is intended to make implementers aware of emerging expectations and best practices for C-CDA document exchange. The objective is to increase consistency and expand interoperability across the community of data sharing partners who utilize C-CDA for information exchange.
                    </P>
                    <HD SOURCE="HD3">• National Council for Prescription Drug Programs (NCPDP), SCRIPT Standard Implementation Guide, Version 2017071 (Approval Date for ANSI: July 28, 2017)</HD>
                    <P>
                        <E T="03">URL: http://www.ncpdp.org/Standards/Standards-Info</E>
                        .
                    </P>
                    <P>Access requires registration, a membership fee, a user account, and a license agreement to obtain a copy of the standard.</P>
                    <P>
                        <E T="03">Summary:</E>
                         NCPDP SCRIPT standards are developed for transmitting prescription information electronically between prescribers, pharmacies, payers, and other entities for new prescriptions, changes of prescriptions, prescription refill requests, prescription fill status notifications, cancellation notifications, relaying of medication history, transactions for long-term care, electronic prior authorization and other transactions. New transactions in this update include Prescription drug administration message, New prescription requests, New prescription response denials, Prescription transfer message, Prescription fill indicator change, Prescription recertification, Risk Evaluation and Mitigation Strategy (REMS) initiation request, REMS initiation response, REMS request, and REMS response.
                    </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">• ASTM E2147-18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems, approved May 1, 2018</HD>
                    <P>
                        <E T="03">URL: https://www.astm.org/Standards/E2147.htm</E>
                        .
                    </P>
                    <P>This is a direct access link. However, a fee is required to obtain a copy of the standard.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This specification describes the security requirements involved in the development and implementation of audit and disclosure logs used in health information systems. It specifies how to design an access audit log to record all access to patient identifiable information maintained in computer systems, and includes principles for developing policies, procedures, and functions of health information logs to document all disclosure of confidential health care information to external users for use in manual and computer systems. This specification has two main purposes, namely: To define the nature, role, and function of system access audit logs and 
                        <PRTPAGE P="25903"/>
                        their use in health information systems as a technical and procedural tool to help provide security oversight; and to identify principles for establishing a permanent record of disclosure of health information to external users and the data to be recorded in maintaining such record of disclosure.
                    </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), February 2020, Version 1 (v1)</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.
                    </P>
                    <HD SOURCE="HD2">Application Programming Interface Standards—45 CFR 170.215</HD>
                    <HD SOURCE="HD3">• HL7 FHIR® US Core Implementation Guide STU 3.1.0, November 6, 2019</HD>
                    <P>
                        <E T="03">URL: http://hl7.org/fhir/us/core/STU3.1/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The US Core Implementation Guide STU 3.1.0 is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and the latest ONC United States Core Data for Interoperability (USCDI) provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4.
                    </P>
                    <HD SOURCE="HD3">• Health Level 7 (HL7) Version 4.0.1 Fast Healthcare Interoperability Resources Specification (FHIR) Release 4, October 30, 2019</HD>
                    <P>
                        <E T="03">URL: http://hl7.org/fhir/R4/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         The HL7 Version 4.0.1 Fast Healthcare Interoperability Resources (FHIR) Release 4, which also includes technical corrections to R4, provides the first set of normative FHIR resources. This normative designation means that the future changes will be backward compatible for the first time. These resources define the content and structure of core health data which can be used by developers to build standardized applications. Release 4 provides new standard operation on how to obtain data from multiple patients via FHIR. API services that focus on multiple patients would enable health care providers to manage various internal patient populations as well as external services a health care provider may contract for to support quality improvement, population health management, and cost accountability vis-à-vis the provider's partners (
                        <E T="03">e.g.,</E>
                         health plans).
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1), August 22, 2019</HD>
                    <P>
                        <E T="03">URL: http://hl7.org/fhir/uv/bulkdata/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This implementation specification defines a standardized, HL7 FHIR-based approach for exporting health information for multiple patients from a server compliant with the HL7 FHIR standard. This implementation specification is intended to be used by apps to request information on multiple patients. The implementation specification includes OperationDefinitions, which define how the multiple patient export operations are invoked by clients, and the SMART Backend Services: Authorization Guide, which describes how a client can register with and obtain an access token from a server compliant with the implementation specification.
                    </P>
                    <HD SOURCE="HD3">• HL7 FHIR SMART Application Launch Framework Implementation Guide Release 1.0.0, November 13, 2018</HD>
                    <P>
                        <E T="03">URL: http://hl7.org/fhir/smart-app-launch/</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         SMART on FHIR provides reliable, secure authorization for a variety of app architectures through the use of the OAuth 2.0 standard. This Authorization Guide supports the four use cases defined for Phase 1 of the Argonaut Project. This profile is intended to be used by developers of apps that need to access FHIR resources by requesting access tokens from OAuth 2.0 compliant authorization servers. The profile defines a method through which an app requests authorization to access a FHIR resource, and then uses that authorization to retrieve the resource. Other security mechanisms required by the HIPAA Security Rule, such as end-user authentication, session time-out, security auditing, and accounting of disclosures, are outside the scope of this profile.
                    </P>
                    <HD SOURCE="HD3">• OpenID Connect Core 1.0 Incorporating Errata Set 1, November 8, 2014</HD>
                    <P>
                        <E T="03">URL: http://openid.net/specs/openid-connect-core-1_0.html</E>
                        .
                    </P>
                    <P>This is a direct access link.</P>
                    <P>
                        <E T="03">Summary:</E>
                         OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables clients to verify the identity of the end user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end user in an interoperable and REST-like manner. This specification defines the core OpenID Connect functionality: Authentication built on top of OAuth 2.0 and the use of claims to communicate information about the end user. It also describes the security and privacy considerations for using OpenID Connect.
                    </P>
                    <HD SOURCE="HD2">Incorporation by Reference—45 CFR 170.599</HD>
                    <HD SOURCE="HD3">• ISO/IEC 17025:2017(E)—General Requirements for the Competence of Testing and Calibration Laboratories, (Third Edition), November 2017</HD>
                    <P>
                        <E T="03">URL: https://www.iso.org/standard/66912.html</E>
                        .
                    </P>
                    <P>This is a direct access link. However, a fee is required to obtain a copy of the standard.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This document has been developed with the objective of promoting confidence in the operation of laboratories. This document contains requirements for laboratories to enable them to demonstrate they operate competently and are able to generate valid results. Laboratories that conform to this document will also operate generally in accordance with the principles of ISO 9001. This document requires the laboratory to plan and implement actions to address risks and opportunities. Addressing both risks and opportunities establishes a basis for increasing the effectiveness of the management system, achieving improved results, and preventing negative effects. The laboratory is responsible for deciding which risks and opportunities need to be addressed. This third edition cancels and replaces the second edition (ISO/IEC 17025:2005), which has been technically revised.
                    </P>
                    <HD SOURCE="HD3">• ISO/IEC 17065:2012 (E)—Conformity Assessment—Requirements for Bodies Certifying Products, Processes and Services (First Edition), September 2012</HD>
                    <P>
                        <E T="03">URL: https://www.iso.org/standard/46568.html</E>
                        .
                        <PRTPAGE P="25904"/>
                    </P>
                    <P>This is a direct access link. However, a fee is required to obtain a copy of the standard.</P>
                    <P>
                        <E T="03">Summary:</E>
                         This International Standard specifies requirements, the observance of which is intended to ensure that certification bodies operate certification schemes in a competent, consistent and impartial manner, thereby facilitating the recognition of such bodies and the acceptance of certified products, processes, and services on a national and international basis and so furthering international trade.
                    </P>
                    <HD SOURCE="HD1">XII. 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, the PRA requires that we solicit comment on the following issues:
                    </P>
                    <P>1. Whether the information collection is necessary and useful to carry out the proper functions of the agency;</P>
                    <P>2. The accuracy of the agency's estimate of the information collection burden;</P>
                    <P>3. The quality, utility, and clarity of the information to be collected; and</P>
                    <P>4. Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.</P>
                    <P>Under the PRA, the time, effort, and financial resources necessary to meet the information collection requirements referenced in this section are to be considered. We solicited comment on these issues in the Proposed Rule (84 FR 7558 and 7559) for the matters discussed in detail below.</P>
                    <HD SOURCE="HD2">A. ONC-ACBs</HD>
                    <P>In the Proposed Rule, we proposed to add new ONC—Authorized Certification Bodies (ONC-ACB) collection and reporting requirements for the certification of health IT to the updated 2015 Edition (and any subsequent edition certification) in § 170.523(p), (q), (t), and § 170.550(1).</P>
                    <P>As stated in the Proposed Rule per § 170.550(l), ONC-ACBs would not be able to certify health IT until they review and verify health IT developers' attestations confirming that the developers are compliant with Conditions and Maintenance of Certification requirements. ONC-ACBs would also submit the health IT developer attestations to ONC per § 170.523(q).</P>
                    <P>As stated in the Proposed Rule for § 170.523(p)(3), ONC-ACBs would be required to collect and report certain information to ONC related to real world testing plans and results. ONC-ACBs would be required to verify that the health IT developer submits an annual, publicly available real world testing plan and perform a completeness check for both real world testing plans and results.</P>
                    <P>In the Proposed Rule, we stated for § 170.523(t), ONC-ACBs would ensure health IT developers opting to take advantage of the Standard Version Advancement Process flexibility per § 170.405(b) provide timely advance written notice to the ONC-ACB and all affected customers. ONC-ACBs would maintain a record of the date of issuance and the content of developers' notices, and timely post content of each notice received publicly on the CHPL attributed to the certified Health IT Module(s) to which it applies.</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).</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the new ONC-ACB collection and reporting requirements for the certification of health IT to the 2015 Edition (and any subsequent edition certification) in § 170.523(p), (q), (t), and § 170.550(1).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We continue to maintain our past determinations in that we estimate less than ten annual respondents for all of the regulatory “collection of information” requirements for ONC-ACBs under part 170 of title 45, including those previously approved by OMB and in this final rule, and that the regulatory “collection of information” requirements under the Program described in this section are not subject to the PRA under 5 CFR 1320.3(c). For the cost estimates of these new regulatory requirements, we refer readers to section XIII (Regulatory Impact Analysis) of this final rule.
                    </P>
                    <HD SOURCE="HD2">B. Health IT Developers</HD>
                    <P>We proposed two separate collections from health IT developers in the Proposed Rule. First, we proposed in 45 CFR 170.580(a)(2)(iii) that ONC may take action against a health IT developer for failure to comply with Conditions and Maintenance of Certification requirements. As stated in the Proposed Rule, we proposed to generally use the same processes previously codified in regulation (§§ 170.580 and 170.581) to take administrative enforcement action. These processes would require health IT developers to submit information to ONC to facilitate and conclude ONC's review. The PRA, however, exempts these information collections. We explained in the Proposed Rule that, specifically, 44 U.S.C. 3518(c)(1)(B)(ii) excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities.</P>
                    <P>Secondly, we proposed in 45 CFR 170.402(b)(1) that a health IT developer must, for a period of 10 years beginning from the date each of a developer's health IT is first certified under the Program, retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the Program for each health IT product. We stated in the Proposed Rule that it would take approximately two hours per week, on average, to comply with our proposed record retention requirement. We welcomed comments on whether more or less time should be included in our estimate.</P>
                    <PRTPAGE P="25905"/>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,12,12,12">
                        <TTITLE>Table 4—Estimated Annualized Total Burden Hours for Health IT Developers To Comply With Records and Information Retention Requirements</TTITLE>
                        <BOXHD>
                            <CHED H="1">Code of Federal Regulations section</CHED>
                            <CHED H="1">
                                Number of 
                                <LI>health IT </LI>
                                <LI>developers</LI>
                            </CHED>
                            <CHED H="1">
                                Average 
                                <LI>burden hours</LI>
                            </CHED>
                            <CHED H="1">Total</CHED>
                        </BOXHD>
                        <ROW RUL="n,s">
                            <ENT I="01">45 CFR 170.402(b)(1)</ENT>
                            <ENT>458</ENT>
                            <ENT>104</ENT>
                            <ENT>47,632</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Burden Hours</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>47,632</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to either collection of information from health IT developers or our corresponding PRA determinations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         For the first information collection, we continue to maintain that information collected pursuant to an administrative enforcement action is not subject to the PRA under 44 U.S.C. 3518(c)(1)(B)(ii), which excludes collection activities during the conduct of administrative actions or investigations involving the agency against specific individuals or entities. For the second information collection, we continue to believe it will take approximately two hours per week on average to comply with our records and information retention requirements as reflected in Table 4. We refer readers to section XIII (Regulatory Impact Analysis) of this final rule for the cost estimates of the second information collection.
                    </P>
                    <HD SOURCE="HD1">XIII. Regulatory Impact Analysis</HD>
                    <HD SOURCE="HD2">A. Statement of Need</HD>
                    <P>This final rule is necessary to meet our statutory responsibilities under the 21st Century Cures Act (Cures Act) and to advance HHS policy goals to promote interoperability and mitigate burden for stakeholders. The provisions finalized in this rule that could result in monetary costs for stakeholders include the: (1) Updates to the 2015 Edition health IT certification criteria; (2) Conditions and Maintenance of Certification requirements for a health IT developer; (3) oversight for the Conditions and Maintenance of Certification requirements; and (4) information blocking.</P>
                    <P>While much of the costs of this final rule will fall on health IT developers that seek to certify health IT under the ONC Health IT Certification Program (Program), we believe the implementation and use of health IT certified to the 2015 Edition (including the new and updated criteria in this final rule), compliance with the Conditions and Maintenance of Certification requirements, and the limited exceptions to information blocking would ultimately result in significant benefits for health care providers and patients. We outline some of these benefits below. We emphasize in this regulatory impact analysis (RIA) that we believe this final rule will create opportunities for health IT innovation through new market entrants and remove barriers to interoperability and electronic health information exchange. These efforts would greatly benefit health care providers and patients by increasing access to important health information and new technologies resulting in improvements in health care delivery and patient outcomes.</P>
                    <P>The provisions in this final rule seek to advance an interoperable health system that empowers individuals to use their electronic health information (EHI) to the fullest extent and enable health care providers and communities to deliver smarter, safer, and more efficient care. Given this goal, there will be instances where the benefits and costs are multifaceted and unquantifiable. We note in this RIA when we had difficulty quantifying benefits and costs due to lack of applicable research or data. Additionally, there are ongoing regulatory and policy activities outside of this final rule that might influence the rule's impact in an unquantifiable manner. When possible, we acknowledge these complexities as well. Unquantifiable costs and benefits identified in this rule are summarized in Table 31.</P>
                    <HD SOURCE="HD2">B. Alternatives Considered</HD>
                    <P>In the Proposed Rule, we noted that we were unable to identify alternatives to our proposals that would appropriately implement our responsibilities under the Cures Act and support interoperability. At the time, we assessed whether there were alternatives to our proposals, specifically our proposals concerning EHI export, application programming interfaces (APIs), and real world testing. We concluded that our proposals took the necessary steps to fulfill the mandates specified in the Public Health Service Act (PHSA), as amended by the Health Information Technology for Economic and Clinical Health (HITECH) Act and the Cures Act, in the least burdensome way. We welcomed comments on our assessment and any alternatives that we should consider.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received comments suggesting alternatives to our proposals. Specifically, some commenters stated that we should consider an alternative approach to the EHI export (§ 170.315(b)(10)) certification criterion's scope to align with other regulations and data standards, such as the USCDI. Other commenters requested we reconsider the adoption of the consent management for APIs (§ 170.315(g)(11)) certification criterion or use a different platform because the consent2share (C2S) platform was not mature enough. We also received comments requesting we consider alternative definitions for various information blocking terms and reconsider our approach to certain information blocking exceptions. Commenters recommended that we consider these alternatives in order to provide clarity to and reduce potential burden for the regulated community.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         Based on comments received, we considered and adopted revisions to our proposals that will substantially reduce real and perceived burden. For the certification criteria, we revised and narrowed the scope of the EHI export certification criterion so that it is more manageable and less administratively burdensome for health IT developers. The criterion will link the data exported to the focused definition of EHI as finalized (see section IV.B.6.c). We also reevaluated and determined, consistent with commenter input, that there is continued work to be done to ballot and field test the C2S platform and the Consent Implementation Guide and, therefore, did not adopt the consent management for APIs (§ 170.315(g)(11)) certification criterion in this final rule (see section IV.B.9.b).
                    </P>
                    <P>
                        Within the information blocking section, we have focused the scope of many terms to address commenter concerns and reduce potential burden on actors. We have focused the definition of EHI (§ 171.102) (see VIII.C.3). We have also focused the 
                        <PRTPAGE P="25906"/>
                        Health Information Network (HIN) definition in consideration of comments in four ways. First, we combined the definitions of HIN and Health Information Exchange (HIE) to create one functional definition that applies to both statutory terms in order to clarify the types of individuals and entities that would be covered. Second, we limited the types of actions that would be necessary for an actor to meet the definition of HIN or HIE. Third, we have revised the definition to specify that to be a HIN or HIE there must be exchange among more than two unaffiliated individuals or entities besides the HIN/HIE that are enabled to exchange with each other. Fourth, we focused the definition on treatment, payment, and health care operations, as each are defined in the HIPAA Rules (45 CFR 164.501) (see VIII.C.2.c). We have also clarified the scope of the “access,” “exchange,” and “use” definitions and refer readers to the discussion of those changes in section VIII.C.5.a.
                    </P>
                    <P>
                        We have also considered and finalized alternatives relating to the information blocking exceptions. Of note, we have finalized the new Content and Manner Exception (
                        <E T="03">see</E>
                         § 171.301 and the preamble discussion in section VIII.D.2.a), which will significantly reduce burden on actors. First, the 
                        <E T="03">content condition</E>
                         (§ 171.301(a)) establishes that, in order to satisfy the exception, for up to May 2, 2022, an actor must respond to a request to access, exchange, or use EHI with, at a minimum, the EHI identified by the data elements represented in the USCDI standard adopted in § 170.213. Second, the 
                        <E T="03">manner condition</E>
                         (§ 171.301(b)) explains acceptable alternative manners for fulfilling a request to access, exchange, or use EHI when an actor is technically unable to fulfill a request in any manner requested or cannot reach agreeable terms with the requestor to fulfill the request in any manner requested. This exception creates a transparent and flexible framework for actors to fulfill requests for access, exchange, or use of EHI. We refer readers to the discussion of the Content and Manner Exception in section VIII.D.2.a, as well as the broader discussion within the information blocking section where we discuss various other changes we have made in response to comments that will reduce burden (see section VIII.D).
                    </P>
                    <HD SOURCE="HD2">C. Overall Impact</HD>
                    <P>
                        We have examined the impact of this final rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs (January 30, 2017), the Regulatory Flexibility Act (5 U.S.C. 601 
                        <E T="03">et seq.</E>
                        ), section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999).
                    </P>
                    <HD SOURCE="HD3">1. Executive Order 13771—Reducing Regulation and Controlling Regulatory Costs</HD>
                    <P>Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs was issued on January 30, 2017 and directs agencies to repeal two existing regulations for each new regulation issued in fiscal year (FY) 2017 and thereafter. It further directs agencies, via guidance issued by the Office of Management and Budget (OMB), that the total incremental costs of all regulations should be no greater than zero in FY 2018. The analysis required by Executive Order 13771, as supplemented by Executive Order 13777, adds additional requirements for analysis of regulatory actions. The new requirements under Executive Orders 13771 and 13777 do not change or reduce existing requirements under Executive Orders 12866 or 13563. This final rule is an E.O. 13771 regulatory action. We estimate this rule generates $0.84 billion in annualized costs in 2016 dollars, discounted at 7 percent relative to year 2016 over a perpetual time horizon.</P>
                    <HD SOURCE="HD3">2. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis</HD>
                    <P>
                        Executive Orders 12866 on Regulatory Planning and Review and 13563 on Improving Regulation and Regulatory Review direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any one year). Pursuant to the Congressional Review Act (5 U.S.C. 801 
                        <E T="03">et seq.</E>
                        ), the Office of Information and Regulatory Affairs designated this rule as a `major rule' as defined by 5 U.S.C. 804(2). OIRA has also determined that this final rule is an economically significant rule as we have estimated the costs to implement this final rule may be greater than $100 million per year. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of this final rule.
                    </P>
                    <HD SOURCE="HD3">a. Costs and Benefits</HD>
                    <P>
                        We have estimated the monetary costs and benefits of this final rule for health IT developers, health care providers, patients, ONC—Authorized Certification Bodies (ONC-ACBs), ONC—Authorized Testing Laboratories (ONC-ATLs), and the Federal Government (
                        <E T="03">i.e.,</E>
                         ONC), and have broken those costs and benefits out into the following categories: (1) Deregulatory actions (no associated costs); (2) updates to the 2015 Edition health IT certification criteria; (3) Conditions and Maintenance of Certification requirements for a health IT developer; (4) oversight for the Conditions and Maintenance of Certification requirements; and (5) information blocking.
                    </P>
                    <P>In accordance with Executive Order 12866, we have included the RIA summary table as Table 30. In addition, we have included a summary to meet the regulatory reform analysis requirements under Executive Order 13771.</P>
                    <P>Cost and benefit calculations were performed in 2017 dollars, as this year was the most recent data available to address all cost and benefit estimates consistently. For summary tables 29 through 31, all estimates are rounded to the nearest dollar and expressed in 2016 dollars to meet regulatory reform analysis requirements under Executive Order 13771.</P>
                    <P>We 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 Final Rule” sections are used throughout this RIA.</P>
                    <P>
                        In this final rule, we used a number of methods to quantify direct and indirect benefits of our provisions. For provisions where no such research was available, we developed estimates based on a reasonable proxy. Interoperability, for example, can positively impact patient safety, care coordination, and improve health care processes and health outcomes.
                        <SU>192</SU>
                        <FTREF/>
                         However, achieving interoperability is a function of several factors, not just the capability of the technology used by health care providers. Therefore, to assess some of the benefits of this final rule, we used regression analysis to assess their 
                        <PRTPAGE P="25907"/>
                        respective effects on interoperability holding other factors constant.
                    </P>
                    <FTNT>
                        <P>
                            <SU>192</SU>
                             
                            <E T="03">https://www.qualityforum.org/Publications/2017/09/Interoperability_2016-2017_Final_Report.aspx</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        One example of this approach is the methodology used to quantify the benefits of our real world testing and API provisions on interoperability. We used regression analysis to calculate the impact of our real world testing and API provisions on interoperability. We assumed that the real world testing and API provisions would collectively have the same impact on interoperability as upgrading health IT certified to the 2014 Edition. Therefore, we estimated linear probability models that identified the impact of 2014 Edition certified health IT on hospitals' interoperability.
                        <SU>193</SU>
                        <FTREF/>
                         We used data from the 2014 and 2015 American Hospital Association (AHA) Annual Survey Information Technology Supplement (IT Supplement), which consists of an analytic sample of 4,866 observations of non-Federal acute care hospitals that responded to the IT Supplement.
                        <SU>194</SU>
                        <FTREF/>
                         We controlled for additional factors such as participation in a health information exchange organization, hospital characteristics, and urban/rural status. More specifically, we used the following explanatory variables:
                    </P>
                    <FTNT>
                        <P>
                            <SU>193</SU>
                             The interoperability dependent variable is a binary indicator for whether a hospital routinely sends, receives, and integrates summary of care records electronically outside of its system and finds any health information electronically outside of its system.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>194</SU>
                             American Hospital Association Health IT Supplement Survey, 
                            <E T="03">http://www.ahadata.com/aha-healthcare-database/</E>
                            .
                        </P>
                    </FTNT>
                    <EXTRACT>
                        <FP SOURCE="FP-2">Edition = 1 if a hospital adopted 2014 Edition EHR, 0 otherwise</FP>
                        <FP SOURCE="FP-2">RHIO = 1 if a hospital participates in health information exchange organization, 0 otherwise</FP>
                        <FP SOURCE="FP-2">Government = 1 if a hospital is publicly owned, 0 otherwise</FP>
                        <FP SOURCE="FP-2">Alt_teaching = 1 if a hospital is teaching, 0 otherwise</FP>
                        <FP SOURCE="FP-2">Nonprofit = 1 if a hospital is not for profit, 0 otherwise</FP>
                        <FP SOURCE="FP-2">Largebed = 1 if a hospital has more than 399 beds, 0 otherwise</FP>
                        <FP SOURCE="FP-2">Medbed = 1 if a hospital's number of beds is between 100 and 399, 0 otherwise</FP>
                        <FP SOURCE="FP-2">Urban_rural = 1 if a hospital is urban, 0 otherwise</FP>
                        <FP SOURCE="FP-2">CAH = 1 if a hospital is critical access, 0 otherwise</FP>
                        <FP SOURCE="FP-2">Year = year of the data (2014 and 2015)</FP>
                        <FP SOURCE="FP-2">S = state fixed effects</FP>
                    </EXTRACT>
                    <P>
                        We found a statistically significant marginal effect of using 2014 Edition certified health IT associated with a five percentage point increase in interoperability.
                        <SU>195</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>195</SU>
                             Results were similar when we used logit or Probit specifications. Note, the percentage point refers to the arithmetic difference between two percentages.
                        </P>
                    </FTNT>
                    <P>While we acknowledge that there might be shared benefits across provisions, we have taken steps to ensure that the benefits attributed to each provision is unique to the provision referenced. For example, in the case of assessing the impact of our real world testing and API provisions on interoperability, we assumed that the marginal effect is true and distributed the five percentage point benefit across our provisions at (0.1-1) to (1-4) percentage points respectively. Given data limitations, we believe this approach allowed us to estimate the benefits of our final provisions without double counting the impact each provision might have on interoperability.</P>
                    <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 of the final rule. 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 2017.
                        <SU>196</SU>
                        <FTREF/>
                         We have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages. Therefore, we have doubled the employee's hourly wage to account for overhead costs. We have concluded that a 100 percent expenditure on overhead costs which includes benefits is an appropriate estimate based on research conducted by HHS.
                        <SU>197</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>196</SU>
                             
                            <E T="03">https://www.opm.gov/policy-data-oversight/pay-leave/salaries-wages/salary-tables/pdf/2017/DCB_h.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>197</SU>
                             
                            <E T="03">See</E>
                             U.S. Department of Health and Human Services, Office of the Assistant Secretary for Planning and Evaluation (ASPE), 
                            <E T="03">Guidelines for Regulatory Impact Analysis,</E>
                             at 28-30 (2016), 
                            <E T="03">available at https://aspe.hhs.gov/system/files/pdf/242926/HHS_RIAGuidance.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We have used Bureau of Labor Statistics (BLS) data to calculate private sector employee wage estimates (
                        <E T="03">e.g.,</E>
                         health IT developers, health care providers, health information networks (HINs), attorneys, etc.), as we believe BLS provides the most accurate and comprehensive wage data for private sector positions. Just as with the General Schedule Federal Salary Classification calculations, we have assumed that overhead costs (including benefits) are equal to 100 percent of pre-tax wages.
                    </P>
                    <P>We estimated using 2016 dollars in the Proposed Rule. However, we stated in the Proposed Rule that we would consider using 2017 and even 2018 dollars, if available, for our cost and benefit estimates in the final rule. Therefore, in this final rule, we updated our estimates using 2017 dollars for the GS Federal Salary Classification and the BLS data.</P>
                    <HD SOURCE="HD3">Quantifying the Estimated Number of Health IT Developers and Products</HD>
                    <P>
                        We derived our estimates for the potential impact of the new 2015 criteria on the number of certified products in the health IT market. This analysis is based on the number of certified health IT products (
                        <E T="03">i.e.,</E>
                         Health IT Modules), product capability, and the number of health IT developers that left, merged, and/or entered the ONC Health IT Certification Program between the 2011 Edition health IT certification criteria (2011 Edition) and the implementation of the 2014 Edition health IT certification criteria (2014 Edition).
                        <SU>198</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>198</SU>
                             Availability of 2014 CEHRT for Meaningful Users Providers, Health IT Policy Committee Data Update (Sept. 9, 2015), 
                            <E T="03">available at http://www.healthit.gov/FACAS/sites/faca/files/HITPC_Data_Update_Presentation_Final_2015-09-09.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>In Table 5, we quantify the extent to which the certified health IT market consolidated between the 2011 Edition and 2014 Edition. We found that the number of health IT developers certifying products between the 2011 Edition and 2014 Edition decreased by 22.1 percent and the number of products available decreased by 23.2 percent.</P>
                    <PRTPAGE P="25908"/>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,12,12,12">
                        <TTITLE>Table 5—Certified Health IT Market Consolidation From the 2011 Edition to the 2014 Edition</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">2011 Edition</CHED>
                            <CHED H="1">2014 Edition</CHED>
                            <CHED H="1">
                                Market 
                                <LI>consolidation </LI>
                                <LI>(%)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Health IT Developers</ENT>
                            <ENT>1,017</ENT>
                            <ENT>792</ENT>
                            <ENT>−22.1</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Products Available</ENT>
                            <ENT>1,408</ENT>
                            <ENT>1,081</ENT>
                            <ENT>−23.2</ENT>
                        </ROW>
                        <TNOTE>
                            <SU>A</SU>
                             For the purposes of these market consolidation calculations, we included the total number of active or suspended health IT products and their developers. Withdrawn products and their developers were excluded from this total.
                        </TNOTE>
                    </GPOTABLE>
                    <P>Using the rates identified in Table 5, we then applied our estimate for market consolidation to estimate the number 2015 Edition certified health IT products and health IT developers that would be impacted by our policies in this final rule. Specifically, to estimate the number of 2015 Edition products and health IT developers in the market, we assumed:</P>
                    <P>
                        • 
                        <E T="03">Products capable of recording EHI will include new certification criteria.</E>
                         We assume that products capable of recording patient health data will be the types of products most likely to be impacted by and include the new certification criteria.
                    </P>
                    <P>
                        • 
                        <E T="03">Products capable of recording EHI data available in 2015 equal the number of products available in 2014.</E>
                         In 2014, there were 710 products by 588 developers capable of recording EHI. Since the new criteria involve the access to and movement and exchange of EHI, we used only products that record EHI as a basis for our estimates. We believe the 2014 totals reflect a realistic estimate of the currently available products and their developers that could include the new 2015 certification criteria.
                    </P>
                    <P>
                        • 
                        <E T="03">Market consolidation rates denoted in Table 5 hold constant.</E>
                         We assume that the rate of market consolidation for products (-23.2 percent) and health IT developers (-22.1 percent) from the 2011 Edition to the 2014 Edition holds constant for the 2015 Edition. Although we are using this number to estimate product availability, we are unable to assess how market consolidation might impact other production costs such as the supply and demand for personnel over time.
                    </P>
                    <P>As shown in Table 6, based on the assumptions, we have estimated the total number of 2015 products (545) and their developers (458).</P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,12,12">
                        <TTITLE>Table 6—Total Number of Health IT Developers and Products by Scenario</TTITLE>
                        <BOXHD>
                            <CHED H="1">Scenario</CHED>
                            <CHED H="1">
                                Estimated number of health IT 
                                <LI>developers</LI>
                            </CHED>
                            <CHED H="1">Estimated number of products</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">2015 Edition Projection—All Products</ENT>
                            <ENT>617</ENT>
                            <ENT>830</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">2015 Edition Projection—Products Capable of Recording EHI</ENT>
                            <ENT>458</ENT>
                            <ENT>545</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">Number of End Users That Might Be Impacted by ONC's Final Rule</HD>
                    <P>For the purpose of this analysis, the population of end users differs according to the regulatory action finalized. In many cases, the end-user population impacted is the number of hospitals and health care providers that possess certified health IT. Due to data limitations, our analysis regarding the number of hospitals and health care providers impacted by the regulatory action is based on the number of hospitals and health care providers that have historically participated in the Centers for Medicare &amp; Medicaid Services (CMS) EHR Incentive Programs (now Promoting Interoperability (PI) Programs).</P>
                    <P>
                        One limitation of this approach is that we are unable to account for the impact of our provisions on users of health IT that were ineligible or did not participate in the CMS EHR Incentive Programs. For example, in 2017, 78 percent of home health agencies and 66 percent of skilled nursing facilities reported adopting an EHR.
                        <SU>199</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>199</SU>
                             Henry, J., Pylypchuck, Y., &amp; Patel, V. (November 2018) Electronic Health Record Adoption and Interoperability among U.S. Skilled Nursing Facilities in 2017. ONC Data Brief, no. 41. Office of the National Coordinator for Health Information Technology: Washington, DC.
                        </P>
                    </FTNT>
                    <P>
                        Despite these limitations, participants in the CMS EHR Incentive Programs represent an adequate sample on which to base our estimates.
                        <SU>200</SU>
                        <FTREF/>
                         There were 439,187 health care providers 
                        <SU>201</SU>
                        <FTREF/>
                         in 95,470 clinical practices 
                        <SU>202</SU>
                        <FTREF/>
                         and 4,519 hospitals 
                        <SU>203</SU>
                        <FTREF/>
                         that participated in the CMS EHR Incentive Program. We estimate that these entities will be impacted by our rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>200</SU>
                             
                            <E T="03">See</E>
                             Office of the National Coordinator for Health Information Technology, 
                            <E T="03">Office-based Health Care Professionals Participating in the CMS EHR Incentive Programs</E>
                             (Aug. 2017), 
                            <E T="03">dashboard.healthit.gov/quickstats/pages/FIG-Health-Care-Professionals-EHR-Incentive-Programs.php</E>
                            ; Office of the National Coordinator for Health Information Technology, 
                            <E T="03">Hospitals Participating in the CMS EHR Incentive Programs</E>
                             (Aug. 2017), 
                            <E T="03">dashboard.healthit.gov/quickstats/pages/FIG-Hospitals-EHR-Incentive-Programs.php</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>201</SU>
                             This estimate is the total number of eligible providers that ever participated in the CMS Medicare and Medicaid Electronic Health Record Incentive Program.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>202</SU>
                             This number was estimated based on the de-duplicated number of practices that had at least one clinician participate in the CMS Medicare Electronic Health Record Incentive Program.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>203</SU>
                             This estimate is the total number of eligible hospitals that ever participated in the CMS Medicare Electronic Health Record Incentive Program.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">General Comments on the RIA</HD>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters expressed concern that the estimated costs and developer hours in the proposed rule were significantly underestimated. One commenter stated that the cost estimates did not accurately reflect provider implementations costs, including those related to ensuring compliance with the HIPAA Rules, 42 CFR part 2 and other Federal and State privacy laws. Some commenters were concerned about the impact of the requirements, as proposed in the Proposed Rule, on existing small health IT developers and their ability to 
                        <PRTPAGE P="25909"/>
                        compete with large developers, as well as the impact on potential new market entrants. One commenter stated that this environment will result in only a small number of health IT developers surviving while also limiting market entry. One commenter expressed concern that the Proposed Rule will provide unfettered access to the intellectual property of health IT developers while increasing their compliance costs, which will limit their potential investment returns and create barriers to market entry. A few commenters expressed concern that the costs incurred by health IT developers to improve interoperability and comply with other aspects of the rule as proposed will be passed on to providers and patients.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input regarding our estimated costs and developer hours in the Proposed Rule. We considered and adopted revisions to our proposals based on comments that would substantially reduce any real or perceived burden. We reanalyzed our approach and made adjustments for this final rule. For instance, we have included additional developer hours for the additional data elements we finalized in this final rule. We have also included additional costs for the bulk data standard support and API support. Lastly, with regards to the comment that the cost estimates did not accurately reflect implementation costs to providers, when possible ONC has quantified provider costs associated with the deployment of new certified health IT functionalities and the optional acquisition of emerging API technologies. Costs that are not quantifiable are noted in Table 31. However, costs related to ensuring compliance with the HIPAA Rules, 42 CFR part 2 and other Federal and State privacy laws, are beyond the scope of the certification criteria and are not included in the final rule.
                    </P>
                    <P>We understand commenters' concerns about the impact of the provisions as proposed on small health IT developers and the potential impact on new market entrants. However, we continue to believe that while much of the costs of the final rule will fall on health IT developers seeking to certify health IT under the Program, the implementation and use of health IT certified to the 2015 Edition (including the updated and new criteria in this final rule), compliance with the Conditions and Maintenance of Certification requirements, and the limited exceptions to information blocking would ultimately result in significant benefits for health care providers and patients. We also emphasize that we believe the final rule will create opportunities for new market entrants and will remove barriers to interoperability and electronic health information exchange, which will greatly benefit health care providers and patients as well.</P>
                    <HD SOURCE="HD3">(1) Deregulatory Actions</HD>
                    <HD SOURCE="HD3">Costs</HD>
                    <P>We do not expect incurred costs to be associated with the deregulatory actions in this final rule, but rather cost savings as detailed further in this Regulatory Impact Analysis.</P>
                    <HD SOURCE="HD3">Benefits</HD>
                    <P>We expect the deregulatory actions of the rulemaking to result in benefits for health IT developers, providers, ONC-ACBs, ONC-ATLs, and ONC.</P>
                    <HD SOURCE="HD3">(i) Removal of the Randomized Surveillance Minimum Threshold Requirements</HD>
                    <P>
                        In this final rule, we have revised §  170.556(c) to specify that ONC-ACBs 
                        <E T="03">may</E>
                         conduct in-the-field, randomized surveillance. We have removed § 170.556(c)(2), which specifies that ONC-ACBs must conduct randomized surveillance for a minimum of two percent of certified health IT products per year. Additionally, we have removed the requirement that ONC-ACBs make a good faith effort to complete randomized surveillance and the circumstances permitted for exclusion from the requirement found in §  170.556(c)(5).
                    </P>
                    <P>In the 2015 Edition final rule, we did not independently estimate the costs for randomized surveillance. Rather, we relied on prior regulatory cost estimates for all surveillance actions. One of our four ONC-ACBs charges a $3,000 annual fee per product for surveillance due to the new randomized surveillance requirements and to help normalize their revenue stream during down cycles between certification editions. Using this fee as a cost basis and assuming it would apply to all certified health IT (as opposed to the market-adjusted universe of health IT that is used in other calculations in this RIA), we estimated that the removal of the randomized surveillance “two percent minimum threshold” requirements will result in cost savings between $6.8 and $13.7 million for all stakeholders. To arrive at this estimate, we multiplied the $3000 annual fee per product for surveillance by the total number of products certified to the 2014 Edition which was 4,559 products at the time ($3,000*4,559 = $13.7 million). We anticipate the number of products certified for 2014 to decrease to a little as half of the original count over time. Therefore, we estimated the low end to be half of the $13.7 million (0.5*$13.7 million = $6.8 million). This estimate is based on feedback we received from our ONC-ATLs and ONC-ACBs. ONC-ACBs performed randomized surveillance an average of 22 times the first year the requirement was in effect. The following year surveillance was performed an average of two times. We cannot predict how many randomized surveillance events the ONC-ACBs will perform now that we are not enforcing the requirement. It will be completely at the discretion of the ONC-ACBs.</P>
                    <P>In the Proposed Rule, we noted that we considered other potential benefits that we were unable to quantify. For instance, we considered that health care provider burden may decrease from the elimination of the two percent minimum threshold requirements because a provider would previously aid the ONC-ACB in software demonstrations.</P>
                    <P>We welcomed comments on potential means, methods, and relevant comparative studies and data that we could use to better quantify these benefits.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the calculation of benefits of the elimination of the two percent minimum threshold requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have maintained our approach in calculating the benefits of this provision in this final rule. We believe the removal of the randomized surveillance minimum threshold requirements will reduce the burden on health care providers by reducing their exposure to randomized in-the-field surveillance of their health IT products. Health care providers previously expressed concern about the time commitment to support ONC-ACB randomized surveillance of health IT products, particularly if no non-conformities with certified health IT were found. Providers have generally stated that reactive surveillance (
                        <E T="03">e.g.,</E>
                         complaint-based surveillance) is a more logical and economical approach to surveillance of health IT products implemented in a health care setting. We also believe the removal of these requirements will provide health IT developers more time to focus on interoperability, and will provide ONC-ACBs more time to respond to reactive surveillance, including health care provider complaints about certified health IT.
                    </P>
                    <HD SOURCE="HD3">(ii) Removal of the 2014 Edition From the Code of Federal Regulations</HD>
                    <P>
                        We estimate that health IT developers would realize monetary savings from no 
                        <PRTPAGE P="25910"/>
                        longer supporting the 2014 Edition certification criteria due to a reduction in activities related to maintaining certification and surveillance. We are aware that one of our ONC-ACBs charges an inherited certified status (ICS) fee of $1,000. This fee has been applied over the last calendar year. Over that time period, the number of new, unique 2014 Edition products has been declining (24 products, and no new products in the last four months) compared to the number of ICS certifications (569). Just assuming the cost of continued ICS certification, health IT developers would be paying approximately $569,000 each year to keep their 2014 Edition products up to date. Based on recent analysis of the number of unique 2014 Edition products, our assumptions hold true.
                    </P>
                    <P>We are not aware of comparable fees charged by ONC-ATLs; however, based on our experience with the Program, we expect health IT developers would realize similar cost savings associated with ONC-ATL maintenance of the testing component associated with ICS. Thus, we estimate an additional $569,000 cost savings for health IT developers due to the reduced testing requirements.</P>
                    <P>We also attempted to identify a potential reduction in maintenance and administrative costs as a result of removing 2014 Edition certification criteria. We could not obtain data to conduct a full quantitative analysis specific to the reduction of health IT developer and health care provider costs related to supporting and maintaining the 2014 Edition. However, we invited comments on methods to quantify potential costs for maintaining and supporting products to previous editions.</P>
                    <P>
                        We did conduct a review of academic literature and qualitative analysis regarding potential savings from no longer supporting the 2014 Edition. We looked at data in IT industry systems as whole, which showed that upgrading outdated legacy systems saves resources otherwise spent on maintaining compatibilities to multiple systems and also increases quality and efficiency.
                        <SU>204</SU>
                        <FTREF/>
                         Furthermore, as technology evolves, newer software and products allow for smoother updates compared to their predecessors. Newer products provide better security features that can address both new and existing issues. In addition, older software has an increased risk of failure, which, in the health IT industry, increases risk to patient safety.
                    </P>
                    <FTNT>
                        <P>
                            <SU>204</SU>
                             James Crotty and Ivan Horrocks, 
                            <E T="03">Managing legacy system costs: A case study of a meta-assessment model to identify solutions in a large financial services company,</E>
                             Applied Computing and Informatics (2017), at 1-9.
                        </P>
                    </FTNT>
                    <P>
                        From the implementer's perspective, the research indicated that retaining legacy systems tends to inhibit scalability and growth for businesses. The perpetuity of outdated legacy systems increases connection and system integration costs and limits the ability to realize increased efficiency through IT implementation. Newer products are developed to current specifications and updated standards, which decreases barriers and marginal cost of ancillary product implementation and increases the accessibility of data in ancillary systems—including via mobile devices and the latest applications. Finally, office staff in a health care setting would no longer need to be trained to accommodate differing data access needs or workarounds required to integrate to the legacy product.
                        <SU>205</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>205</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        The research also indicates that retaining legacy software would not be beneficial or profitable to the health IT market. Prolonging backwards compatibility of newer products to legacy systems encourages market fragmentation.
                        <SU>206</SU>
                        <FTREF/>
                         We intend to encourage the health IT market to keep progressing with a baseline expectation of functionalities that evolve over time. This requires limiting fragmentation by no longer supporting outdated or obsolete legacy software.
                        <SU>207</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>206</SU>
                             Il-Horn Hann, Byungwan Koh, and Marius F. Niculescu, 
                            <E T="03">The Double-Edged Sword of Backward Compatibility: The Adoption of Multigenerational Platforms in the Presence of Intergenerational Services,</E>
                             Inform. Systems Res. (2016), at 112-30.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>207</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>We also estimate that additional savings could be realized by reducing regulatory complexity and burden caused by having two certification editions. We observed that the task of managing two different editions within different rules increases complexity and burden for ONC staff, contractors, ONC-ACBs, CMS programs referencing the certification criteria, and other stakeholders, as compared to removing the 2014 Edition certification criteria. However, we were unable to estimate these benefits because we have no means for quantifying the benefits gained from only using the 2015 Edition.</P>
                    <P>We also expect that health care providers would benefit from removing the 2014 Edition certification criteria because such action would likely motivate health IT developers to certify health IT products to the 2015 Edition, thus enabling providers to use the most up-to-date and supported systems to care for patients.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments specific to our methods for quantifying the potential costs for maintaining and supporting products to previous editions.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have maintained our approach for quantifying costs for health IT developers maintaining and supporting products to the previous 2014 Edition. We have also emphasized again that the research indicates that retaining legacy software would not be beneficial or profitable to the health IT market.
                    </P>
                    <HD SOURCE="HD3">(iii) Removal of the ONC-Approved Accreditor From the ONC Health IT Certification Program</HD>
                    <P>
                        We expect ONC to realize monetary cost savings from removing the ONC-Approved Accreditor (ONC-AA) from the Program. We expect ONC to realize costs savings from no longer: (1) Developing and publishing a 
                        <E T="04">Federal Register</E>
                         Notice and listserv; (2) monitoring the open application period and reviewing and making decisions regarding applications; and (3) oversight and enforcement of the ONC-AA. We have calculated the estimated annual cost savings for removing the ONC-AA from the Program, taking into consideration that the ONC-AA renewed its status every three years.
                    </P>
                    <P>For our calculations, we used the estimated hours for collaborating with and informing an ONC-AA in 2017 (using 2017 wage estimates). We estimated that ONC spent approximately 110 hours collaborating with the ONC-AA in 2017, which includes (all at the GS-13, Step 1 level): Annual assessments; providing appropriate guidance; implementing new requirements and initiatives; and consultations as necessary. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Therefore, we estimated the annual cost savings to be $3,337.</P>
                    <P>
                        We estimate that ONC would commit approximately eight hours of staff time to develop the 
                        <E T="04">Federal Register</E>
                         Notice, which would include approximately: Four hours for drafting and review by an analyst at the GS-13, Step 1 level; two hours for review and analysis by senior certification staff at the GS-14, Step 1 level; and two hours for review and submittal for publication by Immediate Office staff at the GS-15, Step 1 level. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. The hourly wage with benefits for a GS-14, Step 1 employee located in 
                        <PRTPAGE P="25911"/>
                        Washington, DC is approximately $107. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $126. Therefore, we estimate the annual cost savings to be $277. Additionally, we estimate a cost of $477 to publish each page in the 
                        <E T="04">Federal Register</E>
                        , which includes operational costs. The 
                        <E T="04">Federal Register</E>
                         Notice for ONC-AAs requires, on average, one page in the 
                        <E T="04">Federal Register</E>
                         (every three years), so we estimated an additional annual cost savings of $159.
                    </P>
                    <P>
                        We estimated that ONC will commit approximately two hours of staff time by an analyst at the GS-13, Step 1 level to draft, review, and publish the listserv to announce the 
                        <E T="04">Federal Register</E>
                         Notice. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Therefore, we estimate the annual cost savings to be $61.
                    </P>
                    <P>We estimated that ONC would commit approximately 25 hours of staff time to manage the open application process, review applications and reach application decisions, which would include approximately: 20 hours by an analyst at the GS-13, Step 1 level; three hours by senior certification staff at the GS-14, Step 1 level; and two hours for review and approval by Immediate Office staff at the GS-15, Step 1 level. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. The hourly wage with benefits for a GS-14, Step 1 employee located in Washington, DC is approximately $107. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $126. Therefore, we estimated the annual cost savings to be $798.</P>
                    <P>Taking all of these potential costs savings into consideration, we estimated the overall annual costs savings for removing the ONC-AA from the Program to be $4,632.</P>
                    <HD SOURCE="HD3">(iv) Removal of Certain 2015 Edition Certification Criteria</HD>
                    <P>In section III.B.4 of this final rule, we removed the following certification criteria from the 2015 Edition: § 170.315(b)(4) “Common Clinical Data Set summary—create;” (b)(5) “Common Clinical Data Set summary—receive” and § 170.315(a)(11) “Smoking status.” We did not finalize the proposal to remove of § 170.315(a)(10) “Drug formulary and preferred drug list checks,” § 170.315(a)(13) “Patient-specific education resources” and § 170.315(e)(2) “Secure messaging” but rather will only permit ONC-ACBs to issue certificates for these criteria until January 1, 2022 to align with requirements of the CMS Medicaid PI Program.</P>
                    <P>For determining calculations for the majority of the 2015 Edition certification criteria we removed, we used the following assumptions. (For the removal of § 170.315(b)(4) Common Clinical Data Set summary—create and (b)(5) Common Clinical Data Set summary—receive, we outlined the slightly different approach used).</P>
                    <P>In the 2015 Edition final rule, we estimated the costs for developing and preparing health IT to meet the 2015 Edition certification criteria. The development and preparation costs we estimated were derived through a health IT developer per criterion cost. We estimated the development and preparation costs over a four-year period, and we projected the costs would be unevenly distributed. In figuring out the cost savings for the deregulatory actions, we initially used the distribution from the 2015 Edition, but then adjusted the percentages of development and preparation costs due to current empirical and anecdotal evidence. The distribution was reevaluated to account for 2019 and we estimated the actual development and preparation distribution for 2018 to be 35 percent and for 2019 to be 15 percent. We took the average development and preparation cost estimates (low and high) per criterion from Table 14 of the 2015 Edition final rule (80 FR 62737). We then used our new distribution to identify the cost per year for years 2018 and 2019. We took the total estimated costs for 2018 and 2019 and divided that by 12 to determine the cost savings per month and took a range of 6 to 12 months. Based on analysis of recent data, our assumptions continue to hold true.</P>
                    <P>To determine the testing costs of the deregulatory actions, we took the number of health IT developers who develop products for certification for the identified criteria from the 2015 Edition final rule and then figured out the average cost per criterion. Based on the costs that one of the ONC-ATLs charges for testing, we estimated the average cost for testing per criterion and determined subsequent cost savings. In 2017, only about five to ten percent of products have been tested and certified compared to the number of certified 2014 Edition products. Therefore, up to 90 to 95 percent of products remain to be tested and certified to the 2015 Edition. Based on analysis of recent data, our assumptions continue to hold true.</P>
                    <P>We estimated the total cost savings by multiplying the number of health IT developers who developed products for certification to a certain criterion by the estimated cost per criterion, $475. We then took five percent of that number to identify the high end for the cost savings. We then took 10 percent to identify the low end. The five percent was derived from looking at the number of unique developers who have at least one active 2014 Edition product and the number of unique developers who have at least one active 2015 Edition. The denominator is the number of unique developers who have at least one active 2014 Edition product, which is 793. The numerator is the number of unique developers who have at least one active 2015 Edition product and one active 2014 edition product, which is 41. (41/793 = 0.0517024 or 5 percent).</P>
                    <HD SOURCE="HD3">(A) Common Clinical Data Set Summary Record Criteria</HD>
                    <P>In this final rule, we removed the Common Clinical Data Set summary—create (§ 170.315(b)(4)) and Common Clinical Data Set summary—receive (§ 170.315 (b)(5)) criteria.</P>
                    <P>Our expectation was for ONC to realize cost savings associated with internal infrastructure support and maintenance, which would include actions such as: (1) Developing and maintaining information regarding these criteria on the ONC website; (2) creating documents related to these criteria and making those documents 508 compliant; (3) updating, revising, and supporting Certification Companion Guides, test procedures, and test tools; and (4) responding to inquiries concerning these criteria. Based on ONC data on the number of inquiries received since early 2016, we estimated approximately 12 annual inquiries about § 170.315(b)(4) and (5) respectively, (24 total inquiries for two criteria). We estimate it will take an analyst at the GS-13, Step 1 level an average of two hours to conduct all tasks associated with each inquiry. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Based on analysis of recent data, our assumptions continue to hold true.</P>
                    <P>Therefore, we estimated the annual cost savings to be $4,360.</P>
                    <P>
                        We do not expect cost savings associated with software maintenance because both criteria incorporate the Common Clinical Data Set and essentially the same data input and validation requirements as the transitions of care criterion (§ 170.315(b)(1)). The removal of these two criteria would not affect the test data and software maintenance costs, as the same test data and software validation elements remain in 
                        <PRTPAGE P="25912"/>
                        § 170.315(b)(1) and the Common Clinical Data Set used in other criteria.
                    </P>
                    <P>ONC-ACBs could realize minimal savings, as they would need to conduct slightly less surveillance based on the two products that are currently certified to these criteria. We estimated the overall annual costs savings for removing the Common Clinical Data Set summary record certification criteria from the 2015 Edition to be $4,368.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments specific to the removal of the Common Clinical Data Set summary—create (§ 170.315(b)(4)) and Common Clinical Data Set summary—receive (§ 170.315 (b)(5)) criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintained our approach and estimates for removing the Common Clinical Data Set summary record certification criteria from the 2015 Edition. However, we did update estimates to 2017 dollars.
                    </P>
                    <HD SOURCE="HD3">(B) Smoking Status</HD>
                    <P>In this final rule, we removed the 2015 Edition “smoking status” criterion (§ 170.315(a)(11)), which would include removing it from the 2015 Edition Base EHR definition. To calculate the cost savings for removing this criterion, we used the 2015 Edition estimated costs of developing and preparing the criterion to the 2015 Edition, between $15,750 and $31,500 and estimated that 35 percent of developers would be newly certified in 2018 and 15 percent in 2019. We estimated the cost of development and preparation costs to be between $5,512.50 and $11,025 for 2018 and $2,362.50 and $4,725 for 2019. We calculated the cost per month for years 2018 and 2019 and using the high point estimates, estimated the development and preparation costs over a 6 to 12 month period between August 2018 and August 2019. We estimated the costs to be between $4,068.75 at six months and $6,825 at 12 months. Based on analysis of recent data, our assumptions continue to hold true.</P>
                    <P>To calculate the cost for testing for this criterion, five developers were estimated in the 2015 Edition to develop products to this criterion. We multiplied the five developers by our estimated cost to test per criterion of $475. This estimated cost per criterion was based on what one ONC-ATL charged for testing and averaged per criterion. To be conservative, we reduced the number by ten percent and five percent respectively resulting in $2,137.50 and $2,256.25.</P>
                    <P>Taking these estimated costs into account we expect the cost savings for removing the 2015 Edition “smoking status” criterion to be between $8,962.50 and $9,081.25.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments specific to the removal of the 2015 Edition “smoking status” criterion (§ 170.315(a)(11)).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain our approach and estimates for removing the 2015 Edition “smoking status” criterion (§ 170.315(a)(11)) from the 2015 Edition. However, we did update estimates to 2017 dollars.
                    </P>
                    <HD SOURCE="HD3">(v) Removal of Certain Certification Requirements</HD>
                    <P>In this final rule, we removed § 170.523(k)(1)(iii)(B), which requires ONC-ACBs to ensure that certified health IT includes a detailed description of all known material information concerning limitations that a user may encounter in the course of implementing and using the certified health IT, whether to meet “meaningful use” objectives and measures or to achieve any other use within the scope of the health IT's certification. We also removed § 170.523(k)(1)(iv)(B) and (C), which state that the types of information required to be disclosed include, but are not limited to: (B) Limitations, whether by contract or otherwise, on the use of any capability to which technology is certified for any purpose within the scope of the technology's certification; or in connection with any data generated in the course of using any capability to which health IT is certified; (C) limitations, including, but not limited to, technical or practical limitations of technology or its capabilities, that could prevent or impair the successful implementation, configuration, customization, maintenance, support, or use of any capabilities to which technology is certified; or that could prevent or limit the use, exchange, or portability of any data generated in the course of using any capability to which technology is certified.</P>
                    <P>To calculate the savings related to removing these two disclosure requirements, we estimated 830 products certified to the 2015 Edition. We did so by applying the market consolidation rate of −23.2 percent which was the rate observed between 2011 and 2014 Editions. If an ONC-ACB spends 1 hour on average reviewing costs, limitations and mandatory disclosures, we estimated the time saved by no longer having to review the limitations to be two-thirds of an hour. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91 and we assume this to be the hourly rate for an ONC-ACB reviewer. We multiplied 830, the projected number of certified products, by two-thirds of an hour and the assumed hourly rate and calculated the cost savings to be $50,353.</P>
                    <HD SOURCE="HD3">(2) Updates to the 2015 Edition Certification Criteria</HD>
                    <P>The following section details the costs and benefits for updates to the 2015 Edition health IT certification criteria, which includes costs and benefits to update certain 2015 Edition criteria to due to the adoption of the United States Core Data for Interoperability (USCDI) as a standard, and costs for new or revised 2015 Edition criteria for: EHI export, API, privacy and security transparency attestations, and security tags.</P>
                    <HD SOURCE="HD3">(i) United States Core Data for Interoperability</HD>
                    <P>In order to advance interoperability by ensuring compliance with new structured data and code sets that support the data, we have replaced the “Common Clinical Data Set” (CCDS) definition and its references with the “United States Core Data for Interoperability” (USCDI) standard, naming Version 1 (v1) in § 170.213 and incorporated it by reference in § 170.299. The USCDI will replace the CCDS 24 months after the publication date of this final rule. The USCDI v1 establishes a minimum set of data classes (including structured data) that are required for health IT to be interoperable nationwide and is designed to be expanded in an iterative and predictable way over time.</P>
                    <P>
                        The USCDI v1 adds three new data classes, “Allergies and Intolerances,” “Clinical Notes,” and “Provenance;” and adds to “Patient Demographics” the data elements “Previous Address,” “Phone Number,” “Phone Number Type,” and “Email Address” that were not defined in the CCDS. This requires updates to the Consolidated Clinical Document Architecture (C-CDA) standard and updates to the following certification criteria: § 170.315(b)(1) (transitions of care); (e)(1) (view, download, and transmit to 3rd party); (g)(6) (Consolidated CDA creation performance); (f)(5) (transmission to public health agencies—electronic case reporting); and (g)(9) (application access—all data request). From our analysis of the C-CDA standard, we concluded that the requirements of the “Provenance” data class are already met by the existing C-CDA standard and will not require any new development. Therefore, we have estimated the cost to health IT developers to add support for “Allergies and Intolerances” and “Clinical Notes” data classes and “Previous Address,” “Phone Number,” 
                        <PRTPAGE P="25913"/>
                        “Phone Number Type,” and “Email Address” data elements in C-CDA, and the necessary updates to the affected certification criteria. These estimates are detailed in Table 7 and are based on the following assumptions:
                    </P>
                    <P>
                        • 
                        <E T="03">Health IT developers will use the same labor costs and data models.</E>
                         Table 7 shows the estimated labor costs per product for a health IT developer to develop support for the additional USCDI data element in the C-CDA standard and 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 the costs noted in Table 7.
                    </P>
                    <P>
                        • 
                        <E T="03">A proxy is needed to project the number of 2015 Edition certified health IT products.</E>
                         As the 2015 Edition certification is ongoing, using the current count of developers and products would underestimate the overall costs and benefits, so we therefore use a proxy. We estimate that 545 products from 458 developers will be affected. Our proxy is based on the number of 2014 Edition certified health IT products that are capable of recording patient data.
                        <SU>208</SU>
                        <FTREF/>
                         There were 710 products by 588 developers with at least one 2014 Edition product capable of recording patient data. We then multiplied these numbers by our certified health IT market consolidation estimates of −22.1 percent and −23.2 percent to project the number of 2015 developers and products, respectively.
                    </P>
                    <FTNT>
                        <P>
                            <SU>208</SU>
                             We defined “products capable of recording patient data” as any 2014 Edition health IT product that was certified for at least one of the following criteria: Demographics ((a)(5)), Medication List ((a)(7)), Medication Allergy List ((a)(8)), Problem List ((a)(6)), and Family Health History ((a)(12)).
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">According to the May 2017 BLS occupational employment statistics,</E>
                         the mean hourly wage for a “Software Developer” is $53.74.
                        <SU>209</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>209</SU>
                             See “software developer, systems software”—
                            <E T="03">https://www.bls.gov/oes/2017/may/oes151133.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s50,r50,12,12,r50">
                        <TTITLE>Table 7—Costs to Health IT Developers To Develop Support for the Additional USCDI Data Element in C-CDA Standard and Affected Certification Criteria</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Tasks</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Lower bound hours</CHED>
                            <CHED H="1">Upper bound hours</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Update C-CDA creation</ENT>
                            <ENT>New development to support “Allergies and Intolerances,” “Clinical Notes,” “Previous Address,” “Phone Number,” “Phone Number Type,” and “Email Address” for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>1,200</ENT>
                            <ENT>2,400</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT already has developed C-CDA R2.1 into their system and only needs to be updated for new data elements.
                                <LI>(2) Upper bound estimates effort for organizations that are on older versions of C-CDA standard, for example C-CDA R1.1.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(b)(1) (transitions of care)</ENT>
                            <ENT>New development to support “Allergies and Intolerances,” “Clinical Notes,” “Previous Address,” “Phone Number,” “Phone Number Type,” and “Email Address” for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>Necessary updates to health IT to support the new data class to meet the criteria requirements.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">§ 170.315(e)(1) (view, download, and transmit to 3rd party)</ENT>
                            <ENT>New development to support “Allergies and Intolerances,” “Clinical Notes,” “Previous Address,” “Phone Number,” “Phone Number Type,” and “Email Address” for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>400</ENT>
                            <ENT>1,000</ENT>
                            <ENT>Necessary updates to health IT to support the new data class to meet the criteria requirements.</ENT>
                        </ROW>
                        <ROW RUL="n,n,s,s,n">
                            <ENT I="01">§ 170.315(g)(6) (Consolidated CDA creation performance)</ENT>
                            <ENT>New development to support “Allergies and Intolerances,” “Clinical Notes,” “Previous Address,” “Phone Number,” “Phone Number Type,” and “Email Address” for C-CDA and C-CDA 2.1 Companion Guide</ENT>
                            <ENT>200</ENT>
                            <ENT>600</ENT>
                            <ENT>§ 170.315(b)(1) and § 170.315(g)(6) are related and may be developed together.</ENT>
                        </ROW>
                        <ROW RUL="n,n,s,s,n">
                            <ENT I="03">Total Hours</ENT>
                            <ENT/>
                            <ENT>2,000</ENT>
                            <ENT>4,600</ENT>
                            <ENT/>
                        </ROW>
                        <ROW RUL="n,n,s,s,n">
                            <ENT I="03">Hourly Rate</ENT>
                            <ENT/>
                            <ENT>$107</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW RUL="n,n,s,s,n">
                            <ENT I="03">Cost per Product</ENT>
                            <ENT/>
                            <ENT>$214,000</ENT>
                            <ENT>$492,200</ENT>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost (545 products)</ENT>
                            <ENT/>
                            <ENT>$116.6 million</ENT>
                            <ENT>$268.2 million</ENT>
                            <ENT/>
                        </ROW>
                    </GPOTABLE>
                    <P>We estimated that the cost to a health IT developer to develop support for the additional USCDI data elements would range $214,000 to $492,200. Therefore, assuming 545 products, we estimate that the total annual cost to all health IT developers would, on average, range from $116.6 million to $268.2 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>
                    <P>
                        We believe this would benefit health care providers, patients, and the industry as a whole. Clinical notes and provenance were included in the draft USCDI v1 based on significant feedback from the industry, which highly 
                        <PRTPAGE P="25914"/>
                        regarded their desirability as part of interoperable exchanges. The free text portion of the clinical notes was most often relayed by clinicians as the data they sought, but were often missing during electronic health information exchange. Similarly, the provenance of data was also referenced by stakeholders as a fundamental need to improve the trustworthiness and reliability of the data being exchanged.
                    </P>
                    <P>
                        We expect improvements to interoperable exchange of information and data provenance to significantly benefit providers and patients. For example, in 2018, among individuals who had viewed their online medical record within the past year (representing 30 percent nationally), about half indicated that clinical notes were included in their online medical record.
                        <SU>210</SU>
                        <FTREF/>
                         Additionally, seven percent of individuals who viewed their online medical record requested a correction of inaccurate information. Thus, enabling patients to have access to their clinical notes might assist in reducing medical coding errors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>210</SU>
                             Patel V &amp; Johnson C. (May 2019). Trends in Individuals' Access and Use of Online Medical Records and Technology for Health Needs: 2017-2018. ONC Data Brief, no.48 Office of the National Coordinator for Health Information Technology: Washington DC.
                        </P>
                    </FTNT>
                    <P>
                        Patient matching is a barrier to interoperability. In 2017, 36 percent of non-Federal acute care hospitals reported difficulty matching or identifying the correct patient between systems.
                        <SU>211</SU>
                        <FTREF/>
                         The data elements “Previous Address,” “Phone Number,” “Phone Number Type,” and “Email Address” were included in the USCDI v1 based on feedback from industry, for their usage in accurate patient matching.
                    </P>
                    <FTNT>
                        <P>
                            <SU>211</SU>
                             Pylypchuk Y., Johnson C., Henry J. &amp; Ciricean D. (November 2018). Variation in Interoperability among U.S. Non-Federal Acute Care Hospitals in 2017. ONC Data Brief, no.42. Office of the National Coordinator for Health Information Technology: Washington DC.
                        </P>
                    </FTNT>
                    <P>However, we are not aware of an approach for quantifying these benefits and we welcomed comments on potential approaches to quantifying these benefits in the Proposed Rule.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments regarding an approach to quantify benefits. However, we did receive comment regarding estimation of the time and effort on behalf of health IT developers to update to the USCDI. Commenters stated that we have underestimated the number of hours necessary for health IT developers, suggesting that it is triple our estimates.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We maintain the approach we proposed in the Proposed Rule in regard to our estimates for updating the USCDI. This final rule constrains “provenance” to only the scope of data for which the health IT developer is the owner/steward. Hence, the scope is fairly limited and therefore, we believe our estimates to be accurate. We note the removal of “data export” (§ 170.315(b)(6)) from the cost estimate in Table 6, in alignment with our final policy decisions and no longer updating the criterion to USCDI. We did, however, increase the hour per developer based on additional data elements included in this final rule.
                    </P>
                    <HD SOURCE="HD3">(ii) Electronic Health Information Export</HD>
                    <P>In this final rule, we adopted a modified version of the “EHI export” criterion in § 170.315(b)(10). Notably, we have defined and further constrained the criterion's scope of data for export as EHI, as defined in § 171.102, that can be stored at the time of certification by the product, of which the Health IT Module is a part. The final criterion provides a focused set of data from a scope perspective and clarifies what a product with a certified Health IT Module must be capable of exporting. The intent of this criterion aims to provide Health IT Module users the functionality to efficiently export or direct the export of EHI for a single patient or a patient population in a computable, electronic format.</P>
                    <HD SOURCE="HD3">(A) Costs To Develop and Maintain EHI Export Criterion</HD>
                    <P>This section describes the estimated costs of the “EHI export” criterion. The cost estimates are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Health IT developers will use the same labor costs and data models.</E>
                         Table 8 shows the estimated labor costs per product for a health IT developer to develop and maintain the EHI export functionality. 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 8.
                    </P>
                    <P>
                        • 
                        <E T="03">A proxy is needed to project the number of 2015 Edition certified health IT products containing the “EHI export” criterion.</E>
                         We estimated that 545 products from 458 developers will contain the “EHI export” criterion. To develop these estimates, we first identified a proxy for the number of health IT developers that may create a 2015 Edition certified health IT product containing the “EHI export” criterion. Our proxy is based on the number of 2014 Edition certified health IT products that are capable of recording patient data.
                        <SU>212</SU>
                        <FTREF/>
                         We based our estimates on these products because data must be captured to be exported under the adopted criterion. There were 710 products by 588 developers with at least one 2014 Edition product capable of recording patient data. We then multiplied these numbers by our certified health IT market consolidation estimates of −22.1 percent and −23.2 percent to project the number of 2015 developers and products, respectively.
                    </P>
                    <FTNT>
                        <P>
                            <SU>212</SU>
                             We defined “products capable of recording patient data” as any 2014 Edition product that was certified for at least one of the following criteria: Demographics ((a)(5)), Medication List ((a)(7)), Medication Allergy List ((a)(8)), Problem List ((a)(6)), and Family Health History ((a)(12)).
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Wages are determined using BLS estimates.</E>
                         According to the May 2017 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $53.74.
                        <SU>213</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 $107.
                    </P>
                    <FTNT>
                        <P>
                            <SU>213</SU>
                             
                            <E T="03">https://www.bls.gov/oes/2017/may/oes151133.htm.</E>
                        </P>
                    </FTNT>
                    <PRTPAGE P="25915"/>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,r100">
                        <TTITLE>Table 8—Estimated Labor Costs To Develop and Maintain the EHI Export Criterion per Product</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Lower bound hours</CHED>
                            <CHED H="1">Upper bound hours</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 1:</E>
                                 Developing the Data Dictionary software capability to export EHI in a developer format (per product)
                            </ENT>
                            <ENT>160</ENT>
                            <ENT>1,600</ENT>
                            <ENT>
                                This is the effort to document all the data exported by the product for a single patient and for all patients.
                                <LI>
                                    The lower bound assumes that the health IT developer already has a standard format in which they are exporting the data for either case (
                                    <E T="03">e.g.,</E>
                                     C-CDA for single patient, CSV file or database dump for all data) and the effort is merely to publish it to the users. On the other hand, the upper bound reflects the case where the health IT has to develop the export capability de novo into their product and document the data output. This still assumes that the developer will be able to use the format of their choice.
                                </LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 2:</E>
                                 Updating the Data Dictionary and publishing the updated format (per product)
                            </ENT>
                            <ENT>80</ENT>
                            <ENT>500</ENT>
                            <ENT>This is the maintenance cost to update the data dictionary published by the product to ensure that the data dictionary is compatible with newer releases of the product. The lower bound estimate assumes the effort when there are only minor changes to the formats of the data stored by the product. The upper bound estimate assumes the effort when the product makes substantial changes to the formats of the data.</ENT>
                        </ROW>
                        <ROW RUL="n,s,s,n">
                            <ENT I="01">
                                <E T="03">Task 3:</E>
                                 Updating the software that performs EHI Export (per product)
                            </ENT>
                            <ENT>80</ENT>
                            <ENT>500</ENT>
                            <ENT>
                                This is the maintenance cost to upgrade the software that would generate the EHI export files. The lower bound estimates the cost to maintain the software when there are only minor changes to the product, including updates to underlying software (
                                <E T="03">e.g.,</E>
                                 database versions, operating systems, etc.). The upper bound estimate accounts for substantial reworking of the export software program to export in new formats or based on substantial changes made to the underlying storage system.
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Labor Hours</ENT>
                            <ENT>320</ENT>
                            <ENT>2,600</ENT>
                            <ENT/>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,12C,12C,12C">
                        <TTITLE>Table 9—Example Calculation for the Lower Bound Estimated Cost To Health IT Developers To Perform Task 1 for the EHI Export Criterion</TTITLE>
                        <TDESC>[2016 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated labor hours lower bound</CHED>
                            <CHED H="1">
                                Developer 
                                <LI>salary</LI>
                            </CHED>
                            <CHED H="1">Projected products</CHED>
                        </BOXHD>
                        <ROW RUL="s">
                            <ENT I="01">Task 1</ENT>
                            <ENT>160 hours</ENT>
                            <ENT>$107 per hour</ENT>
                            <ENT>545 products</ENT>
                        </ROW>
                        <ROW EXPSTB="03" RUL="s">
                            <ENT I="22">
                                <E T="03">Example Calculation</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="13">160 hours * $107 * 545 products = $9,330,400</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s200,12,12">
                        <TTITLE>Table 10—Total Cost To Develop and Maintain the EHI Export Criterion </TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (545 products)</ENT>
                            <ENT>$9,330,400</ENT>
                            <ENT>$93,304,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (545 products)</ENT>
                            <ENT>4,665,200</ENT>
                            <ENT>29,157,500</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 3 (545 products)</ENT>
                            <ENT>4,665,200</ENT>
                            <ENT>29,157,500</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (545 products)</ENT>
                            <ENT>18,660,800</ENT>
                            <ENT>151,619,000</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">(B) Costs To Implement and Support the EHI Export Criterion</HD>
                    <P>The cost estimates are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Health care providers will use the same costs and data models.</E>
                         Table 11 shows the estimated costs to implement and support the EHI Export criterion. The cost estimates used in this calculation were published by the Agency for Healthcare Research and Quality and were based on the average cost to implement an EHR for a clinical practice.
                        <SU>214</SU>
                        <FTREF/>
                         This publication was based on the implementation of an entire EHR system. We assume that all stakeholders impacted by this rule will already have a base EHR system implemented, therefore we discounted these estimates by a factor of 10 to better reflect the cost to implement an EHI Export module only. We did not have cost estimates for hospitals. Therefore, to estimate the cost for a hospital to implement an EHR system, we multiplied the estimate to 
                        <PRTPAGE P="25916"/>
                        implement an EHR for a clinical practice by a factor of 10. We believe this will better reflect the increased magnitude and complexity of implementing and supporting a new health IT module in a hospital compared to a clinical practice. We recognize that costs health care providers incur will vary; our estimates in this section assume health care providers incur the costs noted in Table 11.
                    </P>
                    <FTNT>
                        <P>
                            <SU>214</SU>
                             Fleming, N., Impact of Health Information Technology on Primary Care Workflow and Financial Measures AHRQ Publication No. 11-0081-4-EF, October 2011 
                            <E T="03">https://digital.ahrq.gov/sites/default/files/docs/page/Fleming_SS_508_20111021_d.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Hospitals and clinical practices that have participated in the CMS EHR Incentive Program will be impacted.</E>
                         We estimate that 95,470 clinical practices 
                        <SU>215</SU>
                        <FTREF/>
                         and 4,519 hospitals 
                        <SU>216</SU>
                        <FTREF/>
                         will be impacted by our rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>215</SU>
                             This number was estimated based on the de-duplicated number of practices that had at least one clinician participate in the CMS Medicare Electronic Health Record Incentive Program.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>216</SU>
                             This estimate is the total number of eligible hospitals that ever participated in the CMS Medicare Electronic Health Record Incentive Program.
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s50,r50,12,12,12,r100">
                        <TTITLE>Table 11—Estimated Cost to Hospitals and Clinical Practices To Implement and Support the EHI Export Criterion</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Task</CHED>
                            <CHED H="1">Entity type</CHED>
                            <CHED H="1">
                                Number of
                                <LI>entities</LI>
                            </CHED>
                            <CHED H="1">Cost per entity</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 1:</E>
                                 Implementation and Support
                            </ENT>
                            <ENT>Clinical Practices</ENT>
                            <ENT>95,470</ENT>
                            <ENT>$2,000</ENT>
                            <ENT>$4,000</ENT>
                            <ENT>This task would involve costs associated with staff support during implementation, workflow mapping and redesign, content development and customization, project management, and other technical deployment including networking.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>Hospitals</ENT>
                            <ENT>4,519</ENT>
                            <ENT>20,000</ENT>
                            <ENT>40,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 2:</E>
                                 Staff Training
                            </ENT>
                            <ENT>Clinical Practices</ENT>
                            <ENT>95,470</ENT>
                            <ENT>500</ENT>
                            <ENT>1,000</ENT>
                            <ENT>This task would involve staff training for implementation teams and staff end users.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>Hospitals</ENT>
                            <ENT>4,519</ENT>
                            <ENT>5,000</ENT>
                            <ENT>10,000</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,r50,15,15">
                        <TTITLE>Table 12—Total Cost To Implement and Support the EHI Export Criterion</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Task</CHED>
                            <CHED H="1"> </CHED>
                            <CHED H="1">Lower bound</CHED>
                            <CHED H="1">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 1:</E>
                                 Implementation and Support
                            </ENT>
                            <ENT>Clinical Practices</ENT>
                            <ENT>$190,940,000</ENT>
                            <ENT>$381,880,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>Hospitals</ENT>
                            <ENT>90,380,000</ENT>
                            <ENT>180,760,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 2:</E>
                                 Staff Training
                            </ENT>
                            <ENT>Clinical Practices</ENT>
                            <ENT>47,735,000</ENT>
                            <ENT>95,470,000</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="22"> </ENT>
                            <ENT>Hospitals</ENT>
                            <ENT>22,595,000</ENT>
                            <ENT>45,190,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost</ENT>
                            <ENT/>
                            <ENT>351,650,000</ENT>
                            <ENT>703,300,000</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>Based on the stated assumptions and costs outlined in Tables 8 and 10, the total estimated cost for health IT developers to develop products to the “EHI export” criterion will range from $18.7 million to $151.6 million. Assuming 458 health IT developers, there would be an average cost per health IT developer ranging from $40,744 to $331,045. We note that the development costs, which equal half of the total, would be a one-time cost and would not be perpetual. The total estimated cost for hospitals and clinical practices to implement and support the EHI Export will range from $351.7 million to $703.3 million. The midpoint of ranges stated is used as the primary estimate of costs.</P>
                    <HD SOURCE="HD3">(C) Benefits</HD>
                    <P>
                        Health care providers may choose to change their EHRs for a number of reasons. However, the steps and costs associated with switching one's EHR are complex. Market forces, such as health IT developers' business incentives, make it difficult and costly for EHR users to transfer system data from one developer to another. Data transfer costs vary depending on how contracts are structured.
                        <SU>217</SU>
                        <FTREF/>
                         Specifically, contracts might include high data-transfer fees or do not include conditions for data transfer. Providers may also pay fees for consultants or technical staff to help with the data-transfer process given differences in how data may be mapped from one developer to another. Hence, health care providers will experience benefits associated with the standardization proposed in the EHI export functionality.
                    </P>
                    <FTNT>
                        <P>
                            <SU>217</SU>
                             Pratt, Mary, The True Cost of Switching EHRs, Medical Economics, May 30, 2018, Volume: 96 Issue: 10.
                        </P>
                    </FTNT>
                    <P>Because of the EHI export functionality, providers will no longer incur the costs associated with mapping data from their health IT database into standard terms or exporting said data using a standardized format when switching EHRs. In our analysis, we calculated the benefits in terms of the reduced costs to providers as a result of our rule eliminating these two tasks. The benefit calculations below are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">On average, five percent of providers and hospitals switch their health IT annually.</E>
                         Using CMS Medicare EHR Incentive Program data from years 2013-2016, we estimate the rate of providers (hospitals and eligible professionals) that changed their health IT developer. We believe that the EHI export functionality would help alleviate the burden of switching between health IT systems by increasing portability of EHI that can be stored at the time of certification by the product, of which the Health IT Module is a part. Thus, the benefit calculations are based on assumptions regarding the number of clinical practices (n = 4,774) and hospitals (n = 226) that are projected to switch products in a year.
                        <PRTPAGE P="25917"/>
                    </P>
                    <P>
                        • 
                        <E T="03">Health IT consultants</E>
                         
                        <SU>218</SU>
                        <FTREF/>
                          
                        <E T="03">will use the same labor costs and data models.</E>
                         Table 13 shows the estimated labor costs per product for a hospital or health care provider to hire a health IT consultant to perform data export of EHI, as defined in 45 CFR 171.102, without the EHI export functionality. We recognize that these costs will vary based on the size of the hospital or clinical practice.
                    </P>
                    <FTNT>
                        <P>
                            <SU>218</SU>
                             “Health IT consultant” refers to a technical expert that a hospital or provider will hire to migrate their data from a legacy system to a new EHR.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Wages are determined using BLS estimates.</E>
                         According to the May 2017 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $53.74.
                        <SU>219</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 $107.
                    </P>
                    <FTNT>
                        <P>
                            <SU>219</SU>
                             
                            <E T="03">https://www.bls.gov/oes/2017/may/oes151133.htm.</E>
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,12,12,r100">
                        <TTITLE>Table 13—Cost per Provider To Perform Data Export Without EHI Export Functionality When Switching Health IT Products</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">
                                Estimated cost per health IT switch
                                <LI>(lower bound)</LI>
                                <LI>(hours)</LI>
                            </CHED>
                            <CHED H="1">
                                Estimated cost per health IT switch
                                <LI>(upper bound)</LI>
                                <LI>(hours)</LI>
                            </CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 1:</E>
                                 Understanding and mapping the data in health IT database into standard terms
                            </ENT>
                            <ENT>320</ENT>
                            <ENT>3,200</ENT>
                            <ENT>The lower bound is an estimate for a small provider practice using the standard instance of a certified health IT product with no customization and use of nationally recognized content standards. The upper bound estimates a medium to large practice with substantial local customization of content.</ENT>
                        </ROW>
                        <ROW RUL="n,s,s,n">
                            <ENT I="01">
                                <E T="03">Task 2:</E>
                                 Exporting the data from the health IT into a format that can be subsequently used to import
                            </ENT>
                            <ENT>160</ENT>
                            <ENT>1,600</ENT>
                            <ENT>The lower bound assumes that the certified health IT product is capable of exporting most of the data into standard output format such as C-CDA. The upper bound estimates the case where a large amount of data is not easily exported by the certified health IT product and therefore substantial one-off software needs to be written to export the data into a custom (de novo) format developed for the transition.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Labor Hours</ENT>
                            <ENT>480</ENT>
                            <ENT>4,800</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>Table 14 provides an example calculation for how we calculated our total costs presented in Table 15.</P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,15C,15C,15C">
                        <TTITLE>Table 14—Example Calculation for the Lower Bound Estimated Cost to Providers To Hire a Health IT Consultant To Perform Task 1 Without the EHI Export Criterion</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated labor hours lower bound</CHED>
                            <CHED H="1">Developer salary</CHED>
                            <CHED H="1">Estimated annual number of health IT switches</CHED>
                        </BOXHD>
                        <ROW RUL="s">
                            <ENT I="01">Task 1</ENT>
                            <ENT>320 hours</ENT>
                            <ENT>$107 per hour</ENT>
                            <ENT>5,000 switches</ENT>
                        </ROW>
                        <ROW EXPSTB="00">
                            <ENT I="22">
                                <E T="03">Example Calculation:</E>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="13">320 hours * $107 * 5000 switches = $171,200,000.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,15,15">
                        <TTITLE>Table 15—Total Cost to Providers To Perform Data Export Without the EHI Export Criterion When Switching Health IT Products</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1</ENT>
                            <ENT>$171,200,000</ENT>
                            <ENT>$1,712,000,000</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Task 2</ENT>
                            <ENT>85,600,000</ENT>
                            <ENT>856,000,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost Savings (5,000 switches)</ENT>
                            <ENT>256,800,000</ENT>
                            <ENT>2,568,000,000</ENT>
                        </ROW>
                    </GPOTABLE>
                    <PRTPAGE P="25918"/>
                    <P>We multiplied the costs to switch health IT by the estimated number of hospitals and clinical practices affected. Thus the estimated annual benefit, in terms of cost savings to hospitals and clinical practices, would range from $256.8 million to $2.6 billion.</P>
                    <HD SOURCE="HD3">(iii) Application Programming Interfaces</HD>
                    <P>The API requirements in this final rule reflect the full depth and scope of what we believe is necessary to implement the API Condition of Certification requirement described in section 4002 of the Cures Act. We have adopted new standards, new implementation specifications, a new certification criterion, and detailed Conditions and Maintenance of Certification requirements in §§ 170.213 and 170.215, 170.315, and 170.404, respectively. We also modified the Base EHR definition in § 170.201.</P>
                    <HD SOURCE="HD3">(A) Costs To Develop and Maintain Certified API Technology</HD>
                    <P>This section describes the potential costs of the API certification criterion. The cost estimates below are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Health IT developers will use labor costs and data models based on whether they have adopted aspects of the API certification criterion.</E>
                         Tables 16 A and 16 B show the estimated labor costs per product for a health IT developer to develop and maintain an API. We recognize that health IT developer costs will vary based on whether they have already implemented aspects of the API certification criterion; including adopting the Fast Healthcare Interoperability Resources (FHIR®) API. To account for this variation, we have estimated two cost tables. Table 16 A reflects the range of costs incurred for new products or those developers that have not previously certified to the API certification criteria. Table 16 B shows the cost for developers that have already implemented the API criteria. We have assumed in our calculations that all health IT developers will incur costs noted in either Table 16 A or Table 16 B.
                    </P>
                    <P>
                        • 
                        <E T="03">A proxy is needed to project the number of 2015 Edition certified health IT products containing the API certification criterion.</E>
                         We estimated that 459 products from 394 developers will contain the API criterion. We used a proxy to determine the number of health IT developers that may develop an API for the certification to the 2015 Edition. There were 598 products and 506 developers with at least one 2014 Edition certified health IT product that could perform transitions of care. We then multiplied this number by our certified health IT market consolidation estimates of −22.1 percent and −23.2 percent to project the number of 2015 developers and products, respectively. Some developers and products are already leveraging aspects of the API certification criterion. This could reduce their cost to implement the criterion. To determine the number of developers and products applicable to cost Table 16 A or 16 B, we calculated the proportion of products and developers that have already certified to API certification criterion. We then applied this estimate to the projected number of 2015 Edition certified health IT products. Specifically, we estimate that 50 percent of products (230) and 55 percent of developers (217) will incur costs reflected in Table 16 A because they have no prior experience with certifying to the API criteria. We believe this estimate serves as a reasonable proxy for products' capability to send patient data and the cost of implementation. The API functionality required by the 2015 Edition achieves a similar end by allowing providers to retrieve patient data from secure data servers hosted by other developers, as well as providing patients access to their medical records through third-party applications connected to these same secure servers.
                    </P>
                    <P>
                        • 
                        <E T="03">Wages are determined using BLS estimates.</E>
                         According to the May 2017 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $53.74.
                        <SU>220</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>220</SU>
                             
                            <E T="03">https://www.bls.gov/oes/2017/may/oes151133.htm</E>
                            .
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="05" OPTS="L2,i1" CDEF="s50,r100,12,12,r100">
                        <TTITLE>Table 16 A—Estimated Labor Hours To Develop and Maintain API—New Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 1:</E>
                                 Implementing security via SMART App Launch Framework IG (per product)
                            </ENT>
                            <ENT>
                                (1) New development to support OpenID Connect
                                <LI>(2) Implementation of the Smart Guide with support for refresh tokens and the core capabilities specified in the rule</LI>
                                <LI>(3) New development to respond to request for access token verification</LI>
                            </ENT>
                            <ENT>1000</ENT>
                            <ENT>1500</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT has already implemented security via SMART App Launch Framework IG and need to be updated to account for additional requirements in the rule including Support for additional “core” capabilities required by rule and Token Introspection.
                                <LI>(2) Upper bound assumes new development for implementation of SMART App Launch Framework IG, and additional requirements in the rule including Token Introspection.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 2:</E>
                                 Develop support for Fast Healthcare Interoperability Resources (FHIR®) API and associated IGs (per product)
                            </ENT>
                            <ENT>
                                (1) New development to support FHIR R4
                                <LI>(2) Implementation to the FHIR US Core IG</LI>
                            </ENT>
                            <ENT>2000</ENT>
                            <ENT>6000</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT already has developed FHIR DSTU2 2015 Edition for data classes that were specified in prior rule and only needs to be updated to R4 and new data classes specified in the rule
                                <LI>(2) Upper bound assumes new development of FHIR API for all resources</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25919"/>
                            <ENT I="01">
                                <E T="03">Task 3:</E>
                                 Develop API for Population Level Services (per product)
                                <LI>
                                    <E T="03">Note: One-time cost</E>
                                </LI>
                            </ENT>
                            <ENT>(1) New development to support FHIR Bulk Data Access IG</ENT>
                            <ENT>2000</ENT>
                            <ENT>4500</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT already has an existing API for population level services; and need to migrate to the standardized API specified in the rule.
                                <LI>(2) Upper bound assumes new development of FHIR Bulk Data Access IG.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 4:</E>
                                 Development of App registration Server and Portal (per developer)
                            </ENT>
                            <ENT>
                                (1) New registration server development (or updates to existing server) to support registration timeliness and publication of FHIR endpoints
                                <LI>(2) Development of portal and managing the application registration system</LI>
                            </ENT>
                            <ENT>1000</ENT>
                            <ENT>2500</ENT>
                            <ENT>
                                (1) Lower bound assumes that the developer already has existing application registration infrastructure in place, and only needs to update it to support the API Maintenance of Certification requirements.
                                <LI>(2) Upper bound is new development of an application registration service and portal.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 5:</E>
                                 Update Application Registration Server and Portal (per developer)
                            </ENT>
                            <ENT>(1) Yearly updates and maintenance to keep the portal running. We do not anticipate any major changes to the standard and will be primarily driven by usage and developer interest</ENT>
                            <ENT>400</ENT>
                            <ENT>1300</ENT>
                            <ENT>
                                (1) Lower bound estimates hours to keep it running with junior staff. 
                                <LI>(2) Upper bound estimates small updates.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 6:</E>
                                 Develop support for patients to revoke access to authorized app (per product).
                                <LI>
                                    <E T="03">Note: One-time cost</E>
                                </LI>
                            </ENT>
                            <ENT>
                                (1) Develop capability to identify apps authorized by registered users
                                <LI>(2) Provide capability to remove access at patient direction</LI>
                            </ENT>
                            <ENT>250</ENT>
                            <ENT>1500</ENT>
                            <ENT>
                                (1) Lower bound assumes that the developer already has a portal used by patients for managing their preferences and new development will be needed to provide patients with ability to view and revoke access to their authorized apps.
                                <LI>(2) Upper bound assumes that developer's current capability of managing registered patients need to be significantly enhanced to support enabling patients to revoke access to the authorized apps.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                Other costs (50% per product, 50% per developer) 
                                <SU>(2017 Dollars)</SU>
                                <LI>
                                    <E T="03">Note: One-time cost</E>
                                </LI>
                            </ENT>
                            <ENT>
                                (1) Server costs for application registration, sandbox, bulk data storage, and costs associated with making documentation publicly available
                                <LI>
                                    (2) Software costs (
                                    <E T="03">e.g.,</E>
                                     databases, application servers, portal technology)
                                </LI>
                            </ENT>
                            <ENT>$7,500</ENT>
                            <ENT>$30,000</ENT>
                            <ENT>(1) Estimated as monetized costs and not as hours; most of the costs would be one-time procurement costs plus yearly maintenance.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="05" OPTS="L2,i1" CDEF="s50,r100,12,12,r100">
                        <TTITLE>Table 16 B—Estimated Labor Hours To Develop and Maintain API—Currently Certified Products</TTITLE>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Details</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 1:</E>
                                 Implementing security via SMART App Launch Framework IG (per product)
                            </ENT>
                            <ENT>
                                (1) Development to support OpenID Connect
                                <LI>(2) Implementation of the Smart Guide with support for refresh tokens and the core capabilities specified in the rule</LI>
                                <LI>(3) Development to respond to request for access token verification</LI>
                            </ENT>
                            <ENT>800</ENT>
                            <ENT>1000</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT has already implemented security via SMART App Launch Framework IG and need to be updated to account for additional requirements in the rule.
                                <LI>(2) Upper bound assumes additional development for implementation of SMART App Launch Framework IG, and additional requirements in the rule.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 2:</E>
                                 Develop support for Fast Healthcare Interoperability Resources (FHIR®) API and associated IGs (per product)
                            </ENT>
                            <ENT>
                                (1) Development to support FHIR R4
                                <LI>(2) Implementation to the FHIR US Core IG</LI>
                            </ENT>
                            <ENT>1600</ENT>
                            <ENT>2000</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT already has developed FHIR R4 for data classes that were specified in prior rule and only needs to be updated to new data classes specified in the rule.
                                <LI>(2) Upper bound assumes health IT was originally developed for FHIR DSTU2 and needs additional development of FHIR API to support upgrading to FHIR R4 and new data classes.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25920"/>
                            <ENT I="01">
                                <E T="03">Task 3:</E>
                                 Develop API for Population Level Services (per product)
                                <LI>
                                    <E T="03">Note: One-time cost</E>
                                </LI>
                            </ENT>
                            <ENT>(1) New development to support FHIR Bulk Data Access IG</ENT>
                            <ENT>2000</ENT>
                            <ENT>4500</ENT>
                            <ENT>
                                (1) Lower bound assumes health IT already has an existing API for population level services; and need to migrate to the standardized API specified in the rule.
                                <LI>(2) Upper bound assumes new development of FHIR Bulk Data Access IG.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 4:</E>
                                 Development of App registration Server and Portal (per developer)
                            </ENT>
                            <ENT>
                                (1) New registration server development (or updates to existing server) to support registration timeliness and publication of FHIR endpoints
                                <LI>(2) Development of portal and managing the application registration system</LI>
                            </ENT>
                            <ENT>800</ENT>
                            <ENT>1000</ENT>
                            <ENT>
                                (1) Lower bound assumes that the developer already has existing application registration infrastructure in place, and only needs to update it to support the API Maintenance of Certification requirements.
                                <LI>(2) Upper bound assumes additional development to support requirements in rule.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 5:</E>
                                 Update Application Registration Server and Portal (per developer)
                            </ENT>
                            <ENT>(1) Yearly updates and maintenance to keep the portal running. We do not anticipate any major changes to the standard and will be primarily driven by usage and developer interest</ENT>
                            <ENT>320</ENT>
                            <ENT>400</ENT>
                            <ENT>
                                (1) Lower bound estimates hours to keep it running with junior staff.
                                <LI>(2) Upper bound estimates small updates.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 6:</E>
                                 Develop support for patients to revoke access to authorized app (per product)
                                <LI>
                                    <E T="03">Note: One-time cost</E>
                                </LI>
                            </ENT>
                            <ENT>
                                (1) Develop capability to identify apps authorized by registered users
                                <LI>(2) Provide capability to remove access at patient direction</LI>
                            </ENT>
                            <ENT>150</ENT>
                            <ENT>250</ENT>
                            <ENT>
                                (1) Lower bound assumes the developer provides this functionality based on 2015 ONC Edition and needs to perform minimum verification.
                                <LI>(2) Upper bound assumes that the developer already has a portal used by patients for managing their preferences and new development will be needed to provide patients with ability to view and revoke access to their authorized apps.</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                Other costs (50% per product, 50% per developer) 
                                <SU>(2017 Dollars)</SU>
                                <LI>
                                    <E T="03">Note: One-time cost</E>
                                </LI>
                            </ENT>
                            <ENT>
                                (1) Server costs for application registration, sandbox, bulk data storage, and costs associated with making documentation publicly available
                                <LI>
                                    (2) Software costs (
                                    <E T="03">e.g.,</E>
                                     databases, application servers, portal technology)
                                </LI>
                            </ENT>
                            <ENT>$6000</ENT>
                            <ENT>$7,500</ENT>
                            <ENT>(1) Estimated as monetized costs and not as hours; most of the costs would be one-time procurement costs plus yearly maintenance.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>Table 17 provides an example calculation for how we calculated our total costs presented in Tables 18 A and 18 B.</P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,r50,r50,r50">
                        <TTITLE>Table 17—Example Calculation for the Lower Bound Estimated Cost to New Products To Perform Task 1 in Table 13 A To Develop API</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated labor hours</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="1">Developer salary</CHED>
                            <CHED H="1">Projected products</CHED>
                        </BOXHD>
                        <ROW RUL="s">
                            <ENT I="01">Task 1</ENT>
                            <ENT>1,000 hours</ENT>
                            <ENT>$107 per hour</ENT>
                            <ENT>230 products.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">
                                <E T="03">Example Calculation:</E>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="13">1,000 hours * $107 * 230 products = $24,610,000.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s150,12,12">
                        <TTITLE>Table 18 A—Total Cost To Develop and Maintain API—New Products</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated lost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (230 products)</ENT>
                            <ENT>$24,556,500</ENT>
                            <ENT>$36,834,750</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (230 products)</ENT>
                            <ENT>49,113,000</ENT>
                            <ENT>147,339,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3 (230 products)</ENT>
                            <ENT>49,113,000</ENT>
                            <ENT>110,504,250</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25921"/>
                            <ENT I="01">Task 4 (217 developers)</ENT>
                            <ENT>23,186,900</ENT>
                            <ENT>57,967,250</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 5 (217 developers)</ENT>
                            <ENT>9,274,760</ENT>
                            <ENT>30,142,970</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 6 (230 products)</ENT>
                            <ENT>6,152,500</ENT>
                            <ENT>36,915,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Other Costs (230 products)</ENT>
                            <ENT>860,625</ENT>
                            <ENT>3,442,500</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Other Costs (217 developers)</ENT>
                            <ENT>812,625</ENT>
                            <ENT>3,250,500</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (230 products and 217 developers)</ENT>
                            <ENT>163,069,910</ENT>
                            <ENT>426,396,220</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s150,12,12">
                        <TTITLE>Table 18 B—Total Cost To Develop and Maintain API—Currently Certified Products</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Activity</CHED>
                            <CHED H="1">Estimated cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1 (229 products)</ENT>
                            <ENT>$19,645,200</ENT>
                            <ENT>$24,556,500</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2 (229 products)</ENT>
                            <ENT>39,290,400</ENT>
                            <ENT>49,113,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3 (229 products)</ENT>
                            <ENT>49,113,000</ENT>
                            <ENT>110,504,250</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4 (177 developers)</ENT>
                            <ENT>15,176,880</ENT>
                            <ENT>18,971,100</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 5 (177 developers)</ENT>
                            <ENT>6,070,752</ENT>
                            <ENT>7,588,440</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 6 (229 products)</ENT>
                            <ENT>3,675,450</ENT>
                            <ENT>6,125,750</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Other Costs (229 developers)</ENT>
                            <ENT>688,500</ENT>
                            <ENT>860,625</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Other Costs (177 products)</ENT>
                            <ENT>531,900</ENT>
                            <ENT>664,875</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total (229 products and 177 developers)</ENT>
                            <ENT>134,192,082</ENT>
                            <ENT>218,384,540</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>We note that we have adopted in § 170.404(b)(3) a specific requirement that an API Technology Supplier must support the publication of Service Base URLs for all of its customers that are centrally managed by the Certified API Developer, and make such information publicly available (in a computable format) at no charge. Thus, we are placing the responsibility of publishing the URLs on health IT developers and those costs are captured in the registration portal cost estimation in this RIA.</P>
                    <P>Based on the stated assumptions and costs outlined in Tables 16 A and 16 B, the total estimated costs for health IT developers to develop and maintain a product to the API criterion would range from $297.3 million to $644.8 million with an average cost per developer ranging from $0.75 million to $1.64 million. We note that the “other costs” and costs associated with tasks 3 and 6, which account for $110.9 million to $272.3 million of this total, are one-time costs and are not perpetual.</P>
                    <HD SOURCE="HD3">(B) Optional Cost To Acquire and Use Applications That Interact With Certified API Technology</HD>
                    <P>
                        We believe the API certification criterion and associated Condition and Maintenance of Certification requirements finalized in this rule will create an environment that promotes innovation for software developers to connect new tools and services that create efficiencies for health care providers throughout their course of care delivery. Software applications that connect to APIs is an emerging market that we believe will be further enhanced by the standards, transparency, and pro-competitive requirements finalized in this rule. As of October 25, 2018, researchers identified nearly 300 software applications being marketed on EHR vendors' app stores. The majority of these applications are designed for health care providers to help support use cases for population health analytics, clinical decision support, patient education, as well as to conduct administrative and financial tasks.
                        <SU>221</SU>
                        <FTREF/>
                         Although not required under this rule, this section describes the potential costs of health care providers to acquire and use new software applications that interact with certified API technology. The cost estimates are based on the following assumptions:
                    </P>
                    <FTNT>
                        <P>
                            <SU>221</SU>
                             Dullabh P, Hovey L, Heaney-Huls K, Rajendron N, Wright A, Sittig D. Application Programming Interfaces in Health Care: Findings from a Current-State Sociotechnical Assessment. Applied Clinical Informatics. 2020; 11(01): 059-069.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Health care providers will use the same costs and data models.</E>
                         Table 19 shows the estimated costs to acquire and use software applications that interact with certified API technology. We recognize that costs health care providers incur will vary based on several factors including, but not limited to, size of the health care entity, application usage, and complexity of deployment and maintenance. However, our estimates in this section assume health care providers incur the costs noted in Table 19.
                    </P>
                    <P>
                        • 
                        <E T="03">Hospitals and clinical practices that have participated in the CMS EHR Incentive Program will be impacted.</E>
                         We estimate that 95,470 clinical practices 
                        <SU>222</SU>
                        <FTREF/>
                         and 4,519 hospitals 
                        <SU>223</SU>
                        <FTREF/>
                         will be impacted by our rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>222</SU>
                             This number was estimated based on the de-duplicated number of practices that had at least one clinician participate in the CMS Medicare Electronic Health Record Incentive Program.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>223</SU>
                             This estimate is the total number of eligible hospitals that ever participated in the CMS Medicare Electronic Health Record Incentive Program.
                        </P>
                    </FTNT>
                    <PRTPAGE P="25922"/>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s100,12,12,12,12,12">
                        <TTITLE>Table 19—Estimated Cost to Hospitals and Clinical Practices To Acquire and Use Software Applications That Engage With Certified API Technology</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Entity type</CHED>
                            <CHED H="1">
                                Number of
                                <LI>entities</LI>
                            </CHED>
                            <CHED H="1">Cost per entity</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                            <CHED H="1">Total cost</CHED>
                            <CHED H="2">Lower bound</CHED>
                            <CHED H="2">Upper bound</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Clinical Practices</ENT>
                            <ENT>95,470</ENT>
                            <ENT>$1,000</ENT>
                            <ENT>$5,000</ENT>
                            <ENT>$95,470,000</ENT>
                            <ENT>$477,350,000</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Hospitals</ENT>
                            <ENT>4,519</ENT>
                            <ENT>10,000</ENT>
                            <ENT>100,000</ENT>
                            <ENT>45,190,000</ENT>
                            <ENT>451,900,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>140,660,000</ENT>
                            <ENT>929,250,000</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>The total cost to health care providers to acquire and use software applications that engage with certified API technology would range from $140.6 million to $929.3 million. The midpoint of ranges stated is used as the primary estimate of costs.</P>
                    <HD SOURCE="HD3">(C) Benefits</HD>
                    <P>
                        The Medicare Access and CHIP Reauthorization Act (MACRA), (Pub. L. 114-10), tasks ONC with measuring interoperability in the health IT industry.
                        <SU>224</SU>
                        <FTREF/>
                         The measurement concepts developed include a multi-part approach analyzing not only adoption of health IT functionalities supporting information exchange but the downstream impact of these technologies on data completeness, data integration, and supports for core functions of patient care. The benefits of our API proposal are similarly multifaceted.
                    </P>
                    <FTNT>
                        <P>
                            <SU>224</SU>
                             Health IT Buzz Blog, 
                            <E T="03">Measuring Interoperability: Listening and Learning, https://www.healthit.gov/buzz-blog/electronic-health-and-medical-records/interoperability-electronic-health-and-medical-records/measuring-interoperability-listening-learning/.</E>
                        </P>
                    </FTNT>
                    <P>
                        Our API proposal will increase interoperability by ensuring that more data is available and shared between EHR users. The proposal will also make data more widely available to software developers outside of those specializing in EHR development. As a result, this data will lead to greater innovation in the app market resulting in new technologies for health care providers and patients alike. In the analysis, we quantify benefits in the following three areas: First, provider time saved as a result of new efficiencies in care delivery due to new technologies, such as provider facing apps. Second, the effects of interoperability on cost-savings associated with reductions in duplicate lab tests, readmissions, emergency room (ER) visits, and adverse drug events. We focused on these outcomes for two reasons: Evidence in literature indicates that health information exchange impacts the chosen measures; and cost of care associated with these measures is high and the impact of health information exchange is likely to result in significant benefits in the form of a cost reduction.
                        <SU>225</SU>
                        <FTREF/>
                         Finally, we quantify an increase in the number of individuals with access to their health information through a mechanism of their choice such as apps.
                    </P>
                    <FTNT>
                        <P>
                            <SU>225</SU>
                             Analyzing the Public Benefit Attributable to Interoperable Health Information Exchange 
                            <E T="03">https://aspe.hhs.gov/pdf-report/analyzing-public-benefit-attributable-interoperable-health-information-exchange.</E>
                        </P>
                    </FTNT>
                    <P>The benefit calculations are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Benefits noted in academic literature are assumed accurate.</E>
                         Estimates of the benefits are based on estimates obtained from peer reviewed academic literature. ONC reviewed academic articles for validity; however, models were not replicated.
                    </P>
                    <P>
                        • 
                        <E T="03">Hospitals and eligible professionals that have participated in the CMS EHR Incentive Programs will be impacted:</E>
                         Estimates assume that 439,187 health care providers and/or 4,519 hospitals would be affected by this regulatory action.
                    </P>
                    <HD SOURCE="HD3">(D) Benefits: Provider Time Saved as a Result of New Efficiencies in Care Delivery Due to the Optional Purchase of New Technologies, Such as Provider Facing Apps</HD>
                    <P>
                        Improvements in technology result in benefits for consumers and producers through increased production efficiencies (Stoneman 2018).
                        <SU>226</SU>
                        <FTREF/>
                         The introduction of EHRs into the health care industry is an example of this. Sinsky (2016) found physicians spend 27 percent of their total time on direct clinical face time with patients, and 49.2 percent of their time on EHR and desk work.
                        <SU>227</SU>
                        <FTREF/>
                         Outside of office hours, physicians spend another one to two hours of personal time each night doing additional computer and other clerical work. Despite the number of hours providers spend in their EHR, there is evidence that the introduction of EHRs is associated with time saved. Adler-Milstein (2013) found that EHR use compared to non-EHR use resulted in a 5.3 percent increase in work relative value units per clinician work day.
                        <SU>228</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>226</SU>
                             Stoneman P, Bartoloni E., Baussola M. The Microeconomics of Product Innovation. Oxford, United Kingdom: Oxford University Press, 2018.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>227</SU>
                             Christine Sinsky et al., 
                            <E T="03">Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialtie</E>
                            s, Ann Intern Med. (Dec. 6, 2016), at 753-60.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>228</SU>
                             Julia Adler-Milstein and Robert S. Huckman, The Impact of Electronic Health Record Use on Physician Productivity, Am J Manag Care (Nov. 19, 2013).
                        </P>
                    </FTNT>
                    <P>
                        Improved efficiencies are not limited to the installation of an EHR. Providers also benefit from the use of emerging technologies. Amusan (2008) found that EHR and computerized provider order entry (CPOE) implementation was associated with 3.69 minutes of time saved five months post implementation.
                        <SU>229</SU>
                        <FTREF/>
                         Similarly, Helmons (2015) found that the impact of suppressing clinically irrelevant alerts and adding clinical-decision support to EHRs saved providers about two percent of their time.
                    </P>
                    <FTNT>
                        <P>
                            <SU>229</SU>
                             Amusan, Tongen, Speedie, and Mellin, A time-motion study to evaluate the impact of EMR and CPOE implementation on physician efficiency, J. Healthcare Inf. Manag. (Fall 2008), at 31-7.
                        </P>
                    </FTNT>
                    <P>
                        To measure the benefits of the API provision on providers' time as a result of new technologies, we examined the literature on the impact of IT on productivity across various industries. As explained in Bartel (2007), improvements in IT could affect productivity through multiple mechanisms that are not necessarily associated with the underlying intention of that technology.
                        <SU>230</SU>
                        <FTREF/>
                         When examining the effect of IT in manufacturing, researchers found that adoption of IT affected production plants' composition of products, reduced time of production processes, and increased hiring of skilled workers. We adopt the same logic here. Specifically, we assume that the impact of the data made available under our API provisions will not be 
                        <PRTPAGE P="25923"/>
                        through a single mechanism, such as an EHR, but will have multiple spillover effects. For example, data made available through an API could be used by a software developer to create tools to improve patient scheduling and billing processes. Use of this tool could result in improvements in the providers' workflow. Thus, is important to quantify the impacts of data made available through APIs on the future health IT market.
                    </P>
                    <FTNT>
                        <P>
                            <SU>230</SU>
                             Bartel, Ann &amp; Ichniowski, Casey &amp; Shaw, Kathryn. (2007). How Does Information Technology Affect Productivity? Plant-Level Comparisons of Product Innovation, Process Improvement, and Worker Skills. The Quarterly Journal of Economics. 122. 1721-1758. 10.1162/qjec.2007.122.4.1721.
                        </P>
                    </FTNT>
                    <P>Table 20 provides a summary of the results of the literature review used to quantify this benefit.</P>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s50,r150,12">
                        <TTITLE>Table 20—Findings From Literature on the Impact of Information Technology on Productivity</TTITLE>
                        <BOXHD>
                            <CHED H="1">Study</CHED>
                            <CHED H="1">Description</CHED>
                            <CHED H="1">
                                Findings: 
                                <LI>(%)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Bartel et al (2007)</ENT>
                            <ENT>Identify impact in improvements in information technology on production time of valve manufacturing. IT is defined as adoption of separated information system that enable various automations</ENT>
                            <ENT>4-8</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Lee et al (2013)</ENT>
                            <ENT>Identified impact of IT capital on hospital productivity where IT capital is defined as hospital expenditure on IT</ENT>
                            <ENT>3-6</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Shao and Lin (2002)</ENT>
                            <ENT>Identifies impact of IT expense on productivity of fortune 500 firms</ENT>
                            <ENT>2-7</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Adler-Milstein et al (2013)</ENT>
                            <ENT>Identifies the impact of the introduction of the EHR on providers' time compared to non-EHR users</ENT>
                            <ENT>5</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Helmons et al (2015)</ENT>
                            <ENT>Identifies impact of suppressing clinically irrelevant alerts and adding clinical-decision support to EHRs on time saved</ENT>
                            <ENT>2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Wagholikar KB, et al (2015)</ENT>
                            <ENT>Identifies impact of clinical-decision support on time saved among primary care providers</ENT>
                            <ENT>1</ENT>
                        </ROW>
                        <TNOTE>
                            <E T="03">Sources:</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>a</SU>
                             Jinhyung Lee Jeffrey S. McCullough Robert J. Town. The impact of health information technology on hospital productivity. The RAND Journal of Economics 44(3):545.
                        </TNOTE>
                        <TNOTE>
                            <SU>b</SU>
                             Shao, W. Lin, Technical efficiency analysis of information technology investments: a two-stage empirical investigation, Information and Management 39, 2002, pp. 391-401.
                        </TNOTE>
                        <TNOTE>
                            <SU>c</SU>
                             Adler-Milstein, J. and Huckman, R, The Impact of Electronic Health Record Use on Physician Productivity, AM J Manage Care, Nov. 19, 2013.
                        </TNOTE>
                        <TNOTE>
                            <SU>d</SU>
                             Helmons PJ1, Suijkerbuijk BO2, Nannan Panday PV3, Kosterink JG4. Drug-drug interaction checking assisted by clinical decision support: a return on investment analysis. J Am Med Inform Assoc. 2015 Jul; 22(4):764-72. doi: 10.1093/jamia/ocu010. Epub 2015 Feb 10.
                        </TNOTE>
                        <TNOTE>
                            <SU>e</SU>
                             Wagholikar KB1, Hankey RA2, Decker LK2, Cha SS2, Greenes RA3, Liu H2, Chaudhry R2. Evaluation of the effect of decision support on the efficiency of primary care providers in the outpatient practice. J Prim Care Community Health. 2015 Jan;6(1):54-60. doi: 10.1177/2150131914546325. Epub 2014 Aug 25.
                        </TNOTE>
                    </GPOTABLE>
                    <P>
                        As illustrated in the Table 20, the incremental effects of improvements in IT on productivity range from one percent to eight percent. Based on these findings, we assume the impact of the API provision on providers' time ranges between one percent and five percent. The lower bound estimate of one percent assumes that, at a minimum, providers will use one new app created as a result of the data made available under the API provision. We assume that this app will save providers time equivalent to the introduction of clinical decision support tools found in Wagholikar (2015). The upper bound estimate of five percent assume that, at a maximum, providers will use multiple apps created such that the combination will result in an increase in productivity. Furthermore, we assume that the API provision will affect only providers with certified EHRs and those that participated in the CMS EHR Incentive Program (439,187). Given that an average provider spends six hours with an EHR per day,
                        <SU>231</SU>
                        <FTREF/>
                         earns $97.85 per hour, and works 260 days per year, physicians' time saved attributed to API technology range from $670 million to $3.4 billion per year.
                    </P>
                    <FTNT>
                        <P>
                            <SU>231</SU>
                             Christine Sinsky et al., 
                            <E T="03">Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialtie</E>
                            s, Ann Intern Med. (Dec. 6, 2016), at 753-60.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(E) Benefits: Reduced Costs Associated With the Impact of Interoperability on Health Outcomes</HD>
                    <P>
                        To identify the impact of the API proposal on interoperability and therefore identified health outcomes, we used regression analysis. Specifically, we estimated linear probability models that identified the impact of 2014 Edition certified EHR on hospitals' interoperability (whether a hospital sends, receives, finds, and integrates summary of care records). Using data from the American Hospital Association (AHA) 
                        <SU>232</SU>
                        <FTREF/>
                         from years 2014 to 2015 in the model, we controlled for hospital size, profit status, participation in a health information organization, and state and year fixed effects. The marginal effect of using a 2014 Edition certified health IT equated to a five percent increase in interoperability. This is an upper bound estimate. For the purpose of this analysis, we assume that one to four percentage points would be a reasonable range for API's marginal impact on interoperability.
                    </P>
                    <FTNT>
                        <P>
                            <SU>232</SU>
                             American Hospital Association Health IT Supplement Survey, 
                            <E T="03">http://www.ahadata.com/aha-healthcare-database/</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        As noted previously, there might be shared benefits across certain provisions, and we have taken steps to ensure that the benefits attributed to each provision are unique to the specific provision. We assumed that the collective impact of real world testing and API proposals on interoperability would not exceed the impact of 2014 Edition certified health IT (estimated at five percent). We distributed the five percent benefit across our real world testing and API proposals at (0.1-1 percent) to (1-4 percent) respectively. Moreover, the number of providers impacted is specific to each provision. Thus, to finalize our calculations of the reduced costs related to reductions in duplicate lab tests, readmissions, emergency room (ER) visits, and adverse drug events due to increased interoperability, we leveraged evidence from the literature that found an association between providers' rates of interoperability and applied the estimated marginal effect of each proposal on interoperability. Given data limitations, we believe this approach allows us to estimate the benefits of our final rule without double counting the impact each provision might have on interoperability.
                        <PRTPAGE P="25924"/>
                    </P>
                    <GPOTABLE COLS="9" OPTS="L2,p6,6/7,i1" CDEF="s75,r25,xs60,6,6,r25,12,r25,r25">
                        <TTITLE>Table 21—Benefit of API on Health Care Outcomes</TTITLE>
                        <TDESC>[2017 dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Benefit type</CHED>
                            <CHED H="1">
                                Number 
                                <LI>affected</LI>
                            </CHED>
                            <CHED H="1">
                                Overall interop impact 
                                <LI>(marginal effect)</LI>
                            </CHED>
                            <CHED H="1">Impact of API</CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                            <CHED H="1">Total cost</CHED>
                            <CHED H="1">
                                Percentage of 
                                <LI>total cost </LI>
                                <LI>impacted</LI>
                            </CHED>
                            <CHED H="1">
                                Total benefit 
                                <SU>a</SU>
                            </CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Duplicate testing</ENT>
                            <ENT>439,187 providers</ENT>
                            <ENT>
                                0.09 
                                <SU>b</SU>
                            </ENT>
                            <ENT>0.01</ENT>
                            <ENT>0.04</ENT>
                            <ENT>
                                $200 billion 
                                <SU>c</SU>
                            </ENT>
                            <ENT>100</ENT>
                            <ENT>$185 million per year</ENT>
                            <ENT>$742 million per year.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Avoidable hospitalizations and readmissions</ENT>
                            <ENT>4,519 hospitals</ENT>
                            <ENT>
                                0.09 
                                <SU>b</SU>
                            </ENT>
                            <ENT>0.01</ENT>
                            <ENT>0.04</ENT>
                            <ENT>
                                $41 billion 
                                <SU>d</SU>
                            </ENT>
                            <ENT>100</ENT>
                            <ENT>$38 million per year</ENT>
                            <ENT>$152 million per year.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">ER visits</ENT>
                            <ENT>
                                131 million visits 
                                <SU>e</SU>
                            </ENT>
                            <ENT>
                                0.03 
                                <SU>b</SU>
                            </ENT>
                            <ENT>0.01</ENT>
                            <ENT>0.04</ENT>
                            <ENT>$1,233 per ER visit</ENT>
                            <ENT>100</ENT>
                            <ENT>$50 million per year</ENT>
                            <ENT>$200 million per year.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Adverse drug events</ENT>
                            <ENT>20 of events affected</ENT>
                            <ENT>
                                22 
                                <SU>f</SU>
                            </ENT>
                            <ENT>0.01</ENT>
                            <ENT>0.04</ENT>
                            <ENT>
                                $30 billion 
                                <SU>g</SU>
                            </ENT>
                            <ENT>20</ENT>
                            <ENT>$14 million per year</ENT>
                            <ENT>$54 million per year.</ENT>
                        </ROW>
                        <TNOTE>
                            <SU>a</SU>
                             Total benefit is a product of 
                            <E T="03">total cost, percent of total cost impacted, overall impact of interoperability, and impact of API, adjusted for inflation (1.03).</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>b</SU>
                             Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health information exchange adoption on ambulatory testing rates, J. Am. Med. Inform. Assoc. (2013), at 1137-1142; Bridget A. Stewart, Susan Fernandes, Elizabeth Rodriguez-Huertas, and Michael Landzberg, A preliminary look at duplicate testing associated with lack of electronic health record interoperability for transferred patients, J. of the Am. Med. Informatics Assoc. (2010), at 341-344; Sezgin Ayabakan, Indranil R. Bardhan, Zhiqiang (Eric) Zheng, and Kirk Kirksey Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals, MIS Quarterly (Jan. 1, 2017); Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, Does health information exchange reduce redundant imaging? Evidence from emergency departments, Med Care (Mar. 2014), at 227-34.
                        </TNOTE>
                        <TNOTE>
                            <SU>c</SU>
                             National Academy of Medicine. (2016), 
                            <E T="03">http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>d</SU>
                             Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), https://www.hcup-us.ahrq.gov/reports/statbriefs/sb199-Readmissions-Payer-Age.pdf; AHRQ Statistical Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), 
                            <E T="03">https://www.hcup-us.ahrq.gov/reports/statbriefs/sb72.pdf.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>e</SU>
                             National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016),
                            <E T="03"> https://www.cdc.gov/nchs/data/databriefs/db252.pdf</E>
                            ; Nolan Caldwell, Tanja Srebotnjak, Tiffany Wang, and Renee Hsia, “How Much Will I Get Charged for This?” Patient Charges for Top Ten Diagnoses in the Emergency Department (2013), 
                            <E T="03">https://doi.org/10.1371/journal.pone.0055491.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>f</SU>
                             M.F. Furukawa, W.D. Spector, M.R. Limcangco, and W.E. Encinosa, Meaningful use of health information technology and declines in in-hospital adverse drug events, J. of the Am. Med. Informatics Assoc. (2017).
                        </TNOTE>
                        <TNOTE>
                            <SU>g</SU>
                             Janet Sultana, Paola Cutroneo, and Gianluca Trifirò, 
                            <E T="03">Clinical and economic burden of adverse drug reactions.</E>
                        </TNOTE>
                    </GPOTABLE>
                    <P>Based on this analysis, the benefits of the API provision on reduced costs on health outcomes range from $287 million to $1.1 billion.</P>
                    <HD SOURCE="HD3">(F) Benefits: Increase in Percent of Individuals With Access to Their Health Information</HD>
                    <P>
                        This provision will also provide individuals with better access to their data. APIs make it easier for patients to transmit data to smartphone health applications. According to the Health Information National Trends Survey,
                        <SU>233</SU>
                        <FTREF/>
                         nearly 20 percent of Americans were offered access and viewed their online medical record using smartphone health applications in 2019. The proportion of individuals accessing their online medical records using smartphone health applications is expected to grow as APIs become more widespread. This will result in cost savings to patients. Specifically, patients who use new applications to access copies of their medical record instead of contacting their provider will have cost savings.
                    </P>
                    <FTNT>
                        <P>
                            <SU>233</SU>
                             These estimates were derived from Health Information National Trends Survey 5, Cycle 1 (2017).
                        </P>
                    </FTNT>
                    <P>Under the HIPAA Privacy Rule, individuals have the right to access their Protected Health Information (PHI) (45 CFR 164.524), and 45 CFR 164.524(c)(4) sets forth implementation specifications for fees that covered entities may charge individuals for access to their PHI. Under 45 CFR 164.524(c)(4), a covered entity may impose a reasonable, cost-based fee (consistent with the conditions in § 164.524(c)(4)(i) through (iv)). For purposes of this analysis, we assume covered entities can charge a flat fee not to exceed $6.50 (inclusive of all labor, supplies, and any applicable postage). The API Condition and Maintenance of Certification requirements finalized in § 170.404 do not allow for a “Certified API Developer” (as defined in § 170.404(c)) to charge patients for connecting to an API to access, exchange, or use their EHI. A Certified API Developer is permitted to charge fees to an API Information Source related to the use of certified API technology. The fees must be limited to the recovery of incremental costs reasonably incurred by the Certified API Developer when it hosts certified API technology on behalf of the API Information Source (§ 170.404). Thus, patients would ultimately see cost savings by accessing their online medical record using a smartphone health application instead of contacting their provider for an electronic copy.</P>
                    <P>
                        To identify the potential cost savings this rule will have for patients, we used data from the Health Information National Trends Survey to estimate the proportion of individuals who reported having to bring a test result to a doctor's appointment at least once in the past year. In 2018, approximately 81 percent of Americans reported that they saw a doctor in the past year and about 19 percent of these individuals reporting having to bring a test result to an appointment. Therefore, using Census data from December 31, 2017, we conducted the following calculation (total U.S. population 325.9M) * (81 percent of individuals saw a doctor in the past year) * (19 percent of individuals who had to bring a test result to an appointment). This resulted in an estimate of 50.2 million Americans who bring test results to a doctor's appointment each year. We recognize that not all of these individuals will have the capability to access an online medical record using a smartphone health application. Therefore, we discounted this estimate based on the proportion of individuals who currently access their online medical records using a smartphone health applications (14 percent), as our lower bound. Our upper bound is the proportion of individuals who reported being offered access to an online medical record by a health care provider or insurer (58 percent). These calculations are in Table 22.
                        <PRTPAGE P="25925"/>
                    </P>
                    <GPOTABLE COLS="7" OPTS="L2,i1" CDEF="s100,r50,r25,r25,r50,r50,r50">
                        <TTITLE>Table 22—Benefit of API on Patients Having Access To their Health Information</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Benefit type</CHED>
                            <CHED H="1">Number affected</CHED>
                            <CHED H="1">
                                Proportion of 
                                <LI>individuals impacted</LI>
                            </CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                            <CHED H="1">Total cost savings</CHED>
                            <CHED H="1">Total benefit</CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Cost savings to patients for requesting an electronic copy of their medical record</ENT>
                            <ENT>
                                50,156,010 
                                <SU>a</SU>
                                 patients
                            </ENT>
                            <ENT>
                                14% 
                                <SU>b</SU>
                            </ENT>
                            <ENT>
                                58% 
                                <SU>b</SU>
                            </ENT>
                            <ENT>
                                $6.50 
                                <SU>c</SU>
                                 per patient
                            </ENT>
                            <ENT>$45.8 million per year</ENT>
                            <ENT>$189.8 million per year.</ENT>
                        </ROW>
                        <TNOTE>
                            <SU>a</SU>
                             This represents the number of individuals who had to bring a medical test result to an appointment with a health care provider in the past year. Calculation: US Population on December 31, 2017 (325.9M)*81 percent who saw a doctor in the past year*19 percent who had to bring a test result to an appointment. Sources: (1) 
                            <E T="03">https://www.census.gov/popclock/;</E>
                             (2) 
                            <E T="03">https://dashboard.healthit.gov/quickstats/pages/consumers-gaps-in-information-exchange.php.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>b</SU>
                             Lower bound represents the proportion of individuals nationwide who were offered access to their online medical record by a health care provider or insurer. Upper bound represents the proportion of individuals nationwide who were offered access and subsequently viewed their online medical record using a smartphone health app. Source: Johnson C. &amp; Patel V. The Current State of Patients' Access and Using their Electronic Health Information. Presented at the ONC Annual Meeting on January 27, 2020.
                        </TNOTE>
                        <TNOTE>
                            <SU>c</SU>
                             We assume that providers charge individuals a flat fee for all requests for electronic copies of PHI maintained electronically, provided the fee does not exceed $6.50, inclusive of all labor, supplies, and any applicable postage.
                        </TNOTE>
                    </GPOTABLE>
                    <P>Based on the above calculations, we estimated the annual benefit to health care providers for the use of these API capabilities would, on average, range from $6.7 million to $140 million. We estimated the annual benefit due to improved health outcomes would, on average, range from $287 million to $1.1 billion. We estimated the annual benefit to patients having access to their online medical record would, on average, range from $45.8 million and $189.8 million. Therefore, we estimated the total annual benefit of APIs, on average, to range from $0.34 billion to $1.43 billion.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments specific to our approach to estimating the benefits of API support.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have maintained our overall approach for the costs and benefits associated with the API provisions of this rule. As discussed in section IV.B.7 of this final rule preamble, we have added a new requirement in the finalized § 170.315(g)(10) that gives patients the capability to revoke access to an authorized application. Cost estimates for this new requirement were added to cost tables 16 A and 16 B as task six. The task of meeting this additional finalized requirement increased the overall cost estimate for the API provisions by $9.8 million to $43 million. Due to this increase in cost, we re-evaluated our benefits estimates associated with increasing patients' access to their health information. In the Proposed Rule, we qualitatively discussed benefits of patients having increased access to their health information. However, upon further consideration, and additional data sources, we were able to estimate cost savings to patients for requesting electronic copies of their medical record. These estimates are reflected in Table 22. We provided additional rationale to substantiate our approach and we updated estimates to 2017 dollars.
                    </P>
                    <HD SOURCE="HD3">(iv) New Privacy and Security Certification Criteria</HD>
                    <P>As specified in section IV.C.3 of this final rule, we have adopted two new privacy and security transparency attestation certification criteria in § 170.315(d)(12) and (13) that are part of the 2015 Edition privacy and security certification framework. The criteria will serve to identify whether certified health IT supports encrypting authentication credentials and/or multi-factor authentication (MFA). They do not require new development or implementation to take place in order to be met. However, certification to these criteria will provide increased transparency and, perhaps, motivate the small percentage of health IT developers that do neither to encrypt authentication credentials and/or support multi-factor authentication, which will help prevent exposure to unauthorized persons/entities.</P>
                    <HD SOURCE="HD3">(A) Costs</HD>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comment specific to any method we could use to quantify the costs of the new privacy and security certification criteria, encrypt authentication credentials (§ 170.315(d)(12)) and multi-factor authentication (MFA) (§ 170.315 (d)(13)), and requiring health IT developers to assess their Health IT Modules' capabilities and attest “yes” or “no” to the certification criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have maintained our estimates of the costs of this provision in the final rule.
                    </P>
                    <HD SOURCE="HD3">(B) Benefits</HD>
                    <P>As stated previously, we have not required health IT developers to encrypt authentication credentials or support multi-factor authentication (MFA). Instead, we have required that they attest to whether or not they support the certification criteria. By requiring an attestation, we are promoting transparency, which might motivate some health IT developers that do not currently encrypt authentication credentials or support MFA to do so. If health IT developers are motivated by these criteria and ultimately do encrypt authentication credentials and/or support MFA, we acknowledge that there would be costs to do so; however, we assume that the benefits will substantially exceed the costs. Such encryption and adopting MFA would reduce the likelihood that authentication credentials would be compromised and would eliminate an unnecessary use of IT resources. Encrypting authentication credentials and adopting MFA could directly reduce providers' operating and support costs, which will reduce their administrative and financial burden. Encrypting authentication credentials will also help decrease costs and burdens by reducing the number of password resets due to possible phishing or other vulnerabilities.</P>
                    <P>
                        According to Verizon's 2017 Data Breach Investigations Report, 81 percent of hacking-related breaches leveraged either stolen and/or weak passwords.
                        <SU>234</SU>
                        <FTREF/>
                         The Verizon report encourages customers to vary their passwords and use two-factor authentication. Also, National Institute of Standards and Technology (NIST) Special Publication 800-63B: Digital Identity Guidelines, 
                        <E T="03">
                            Authentication and Lifecycle 
                            <PRTPAGE P="25926"/>
                            Management,
                        </E>
                        <SU>235</SU>
                        <FTREF/>
                         recommends the use of, and provides the requirements for multi-factor authenticators.
                    </P>
                    <FTNT>
                        <P>
                            <SU>234</SU>
                             
                            <E T="03">https://enterprise.verizon.com/resources/reports/2017_dbir.pdf.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>235</SU>
                             
                            <E T="03">https://pages.nist.gov/800-63-3/sp800-63b.html.</E>
                        </P>
                    </FTNT>
                    <P>Based on these reports and other anecdotal evidence, we believe encrypting authentication credentials and supporting MFA are established best practices among industry developers, including health IT developers. As described above, in this final rule, we required health IT developers to attest to whether they encrypt authentication credentials. We do not have access to published literature that details how health IT developers are already encrypting authentication credentials and supporting MFA industry-wide, but we believe most health IT developers, or around 80 percent, are taking such actions. We assume that building this functionality is in the future project plans for the remaining 20 percent because, as noted previously, adopting these capabilities is an industry best practice. Health IT developers that have not yet adopted these capabilities are likely already making financial investments to get up to speed with industry standards. We believe the adoption of these criteria will motivate these health IT developers to speed their implementation process, but we have not attributed a monetary estimate to this potential benefit because our rule is not a direct cause of health IT developers adopting these capabilities. We anticipate that when we release this final rule, many more, or perhaps all, health IT developers will likely already be encrypting authentication credentials and supporting MFA. We welcomed comments on this expectation and any means or methods we could use to quantify these benefits.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comment specific to any means or methods we could use to quantify the costs and benefits of having the new privacy and security transparency attestation certification criteria, encrypt authentication credentials (§ 170.315(d)(12)) and multi-factor authentication (MFA) (§ 170.315(d)(13)), and requiring health IT developers to assess their Health IT Modules' capabilities and attest “yes” or “no” to the certification criteria.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain our estimates of the costs and benefits of this provision in the final rule. We also continue to believe that the adoption of these criteria will motivate these health IT developers to speed their implementation process.
                    </P>
                    <HD SOURCE="HD3">(v) Security Tags—Summary of Care—Send and Security Tags—Summary of Care—Receive</HD>
                    <P>In this final rule, we updated the 2015 Edition Data Segmentation for Privacy (DS4P) certification criteria in § 170.315(b)(7) and (8) to support a more granular approach to privacy tagging data for health information exchange. We also renamed the criteria to reduce confusion and better align with the criteria, “Security tags—Summary of Care—send” and “Security tags—Summary of Care—receive.” The criteria will remain based on the C-CDA and the HL7 DS4P standard. These criteria will include capabilities for applying the DS4P standard at the document, section, and entry level. In the Proposed Rule, we proposed to adopt a third 2015 Edition DS4P certification criterion, “consent management for APIs” (§ 170.315(g)(11)), that requires health IT to be capable of responding to requests for data through an API in accordance with the Consent Implementation Guide, which we did not finalize.</P>
                    <HD SOURCE="HD3">(A) Costs</HD>
                    <P>We anticipate these updated criteria will result in up-front costs to health IT developers as health IT would be required to support all three levels—document, section, and entry—as specified in the current DS4P standard. However, we note that these criteria are not being required in any program at this time. As of the beginning of the fourth quarter of the 2019 calendar year, only about 30 products (products with multiple certified versions were counted once) were certified to the current 2015 Edition DS4P certification criteria. We estimated that 10 to 15 products will implement the new DS4P criteria. Developers may need to perform fairly extensive health IT upgrades to support the more complex and granular data tagging requirements under these criteria. We anticipate developers will need approximately 1,500 to 2,500 hours to upgrade databases and/or other backend infrastructure to appropriately apply security tags to data and/or develop access control capabilities. Moreover, developers will likely incur costs to upgrade health IT to generate a security-labeled C-CDA conforming to the DS4P standard. We estimated developers will need 400 to 600 hours per criterion to make these upgrades on systems that had previously certified to the document-level DS4P criteria, or 720 to 1220 hours per criterion for systems that are implementing these criteria for the first time. We believe this work would be performed by a “Software Developer.” According to the May 2017 BLS occupational employment statistics, the mean hourly wage for software developer is $53.74. 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 $107. Therefore, we estimated the total cost to developers could range from $2,910,400 to $6,933,600. We note that this would be a one-time cost. The midpoint of ranges stated is used as the primary estimate of costs.</P>
                    <P>Additionally, we proposed that the health IT support the capability to respond to requests for patient consent information through an API compatible with FHIR Release 3. However, we did not finalize that proposal. Therefore, we did not include an estimate in this final rule.</P>
                    <P>We have estimated costs using the following assumptions:</P>
                    <P>• For the two Security tags—Summary of Care criteria, we anticipate developers will need approximately 1,500 to 2,500 hours to upgrade databases and/or other backend infrastructure to appropriately apply security tags to data and/or develop access control capabilities. We expect that this would be a one-time cost.</P>
                    <P>• According to the May 2017 BLS occupational employment statistics, the mean hourly wage for a “Software Developer” is $53.74.</P>
                    <P>
                        Our cost estimates are explained in the Table 23.
                        <PRTPAGE P="25927"/>
                    </P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s100,xs60,xs60,r100">
                        <TTITLE>Table 23—Costs Related to Security Tags—Summary of Care Criteria </TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Tasks</CHED>
                            <CHED H="1">Lower bound</CHED>
                            <CHED H="1">Upper bound</CHED>
                            <CHED H="1">Remarks</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">
                                <E T="03">Task 1:</E>
                                 Enhancements to health IT to upgrade databases and/or other backend infrastructure to appropriately apply security tags to data and/or develop access control capabilities
                            </ENT>
                            <ENT>1,500 hours</ENT>
                            <ENT>2,500 hours</ENT>
                            <ENT>
                                This is a 
                                <E T="03">one-time cost</E>
                                 for health IT systems to support data segmentation for discrete data.
                            </ENT>
                        </ROW>
                        <ROW RUL="n,s,s,n">
                            <ENT I="03">Total Labor Hours</ENT>
                            <ENT>1,500 hours</ENT>
                            <ENT>2,500 hours</ENT>
                        </ROW>
                        <ROW RUL="s,s,s,n">
                            <ENT I="03">Hourly Rate</ENT>
                            <ENT A="01">$107 per hour</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Cost per Product</ENT>
                            <ENT>$160,500</ENT>
                            <ENT>$267,500</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost (23 products)</ENT>
                            <ENT>$3,691,500</ENT>
                            <ENT>$6,152,500</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>We believe the voluntary nature of these criteria would significantly mitigate health IT developer costs. We also expect developers to see a return on their investment in developing and preparing their health IT for these certification criteria given the benefits to interoperable exchange.</P>
                    <P>We anticipate potential costs for ONC related to the updated DS4P criteria (Security tags—Summary of Care—send and Security tags—Summary of Care—receive) associated with: (1) Developing and maintaining information regarding these updated criteria on the ONC website; (2) creating documents related to these updated criteria and making those documents 508 compliant; (3) updating, revising, and supporting Certification Companion Guides, test procedures, and test tools; and (4) responding to inquiries concerning these criteria. We estimate an ONC analyst at the GS-13, Step 1 level staff would devote, on average, 200 hours to the above tasks annually. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Therefore, we estimate the annual costs to be $18,200.</P>
                    <HD SOURCE="HD3">(B) Benefits</HD>
                    <P>We believe leveraging the DS4P standard's ability to allow for both document level and more granular tagging would offer functionality that is more valuable to providers and patients, especially given the complexities of the privacy landscape for multiple care and specialty settings. The updated DS4P criteria (Security tags—Summary of Care—send and Security tags—Summary of Care—receive) would benefit providers, patients, and ONC because it would support more complete records, contribute to patient safety, and enhance care coordination. We believe this will also reduce burden for providers by enabling an automated option, rather relying on case-by-case manual redaction and subsequent workarounds to transmit redacted documents. Implementing security tags enables providers to more effectively share patient records with sensitive information, thereby protecting patient privacy while still delivering actionable clinical content. We emphasize that health care providers already have processes and workflows to address their existing compliance obligations, which could be made more efficient and cost effective through the use of health IT. We expect these benefits for providers, patients, and ONC to be significant; however, we are unable to quantify these benefits at this time because we do not have adequate information to support quantitative estimates. We welcomed comments regarding potential approaches for quantifying these benefits.</P>
                    <P>
                        <E T="03">Comments.</E>
                         Several commenters indicated there would be cost burden associated with our proposal of adopting two new DS4P certification criteria and a consent management for API criterion. Commenters stated that ONC needs to quantify and include the cost of this burden in our impact analysis section. Another commenter conducted their own analysis and indicated a cost of $5-6 billion with a multi-year implementation timeframe. Commenters stated there could be significant upfront costs and ongoing costs for maintenance of the systems necessary to comply with these criteria and one commenter further explained that segmenting data at the document, section, and entry level as opposed to the document level only, would significantly increase costs and could potentially impact system performance. One commenter was specifically concerned that the proposal would broadly impact HIEs both in terms of administration and implementation but did not state specifics.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. We did not finalize the consent management for API criterion. For the DS4P-related criteria (Security tags—Summary of Care—send and Security tags—Summary of Care—receive), the developer costs were estimated for supporting DS4P IG enhancements to include tagging the data at the section and entry level when exchanged using the C-CDA. The lower bound estimates include developers who are already supporting the DS4P IG for tagging data at “document” level and estimates additional effort to support tagging at “section” and “entry” level. The criteria do not require the capability to segment the data, only to tag the data.
                    </P>
                    <P>The certification criteria does not make any additional expectations around compliance beyond what the providers are currently expected to do, nor does it add any additional requirements for developers around how they handle the data received with the tags. Therefore, we disagree with the commenters about underestimating the cost. Rather, the commenters may be suggesting implementation costs which are beyond the costs associated with the certification criteria itself. These costs are unquantifiable and are noted in Table 31.</P>
                    <HD SOURCE="HD3">(3) Conditions and Maintenance of Certification Requirements</HD>
                    <HD SOURCE="HD3">(i) Information Blocking</HD>
                    <P>For a discussion of the costs and benefits of the exceptions to information blocking, please see section (5) of this RIA.</P>
                    <HD SOURCE="HD3">(ii) Assurances</HD>
                    <P>
                        In this final rule, we included a provision that requires health IT developers to make certain assurances as Conditions and Maintenance of Certification requirements: (1) Assurances regarding the “EHI export” certification criterion in § 170.315(b)(10) and (2) assurances regarding retaining records and information in 170.402(b)(1)(i)-(ii).
                        <PRTPAGE P="25928"/>
                    </P>
                    <HD SOURCE="HD3">(A) Electronic Health Information Export</HD>
                    <P>Alongside the criterion revisions in § 170.315(b)(10), we have finalized in § 170.402(a)(4), that a health IT developer of a certified health IT Modules that is part of a health IT product which electronically stores EHI must certify to the certification criterion in § 170.315(b)(10). We have finalized in § 170.402(b)(2) that within 36 months from the final rule's publication date, a health IT developer that must comply with the requirements of paragraph § 170.402(a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10). We also finalized that on and after 36 months from the publication of this final rule, health IT developers that must comply with the requirements of § 170.402(a)(4) must provide all of their customers of certified health IT with health IT certified to § 170.315(b)(10). In addition, a health IT developer must attest accurately in accordance with § 170.402(a)(4) and (b)(2) if the Health IT Module presented for certification is part of a heath IT product which can electronically store EHI. If the product stores such information, the health IT developer must ensure all EHI is available for export in accordance with § 170.315(b)(10).</P>
                    <P>For a detailed discussion of the costs and benefits of the assurances regarding the criterion in § 170.315(b)(10), please see section (2)(ii) (EHI export) of this RIA above.</P>
                    <HD SOURCE="HD3">(B) Records and Information Retention</HD>
                    <P>As a Maintenance of Certification requirement in § 170.402(b)(1), a health IT developer must, for a period of 10 years beginning from the date of certification, retain all records and information necessary that demonstrate initial and ongoing compliance with the requirements of the ONC Health IT Certification Program. In an effort to reduce administrative burden, we also finalized that in situations where applicable certification criteria are removed from the Code of Federal Regulations before the 10 years have expired, records must only be kept for three years from the date of removal for those certification criteria and related Program provisions unless that timeframe would exceed the overall 10-year retention period. This “three-year from the date of removal” records retention period also aligns with the records retention requirements for ONC-ACBs and ONC-ATLs under the Program.</P>
                    <P>As stated in the Proposed Rule, currently, there are no existing regulatory requirements regarding record and information retention by health IT developers. We expect there are costs to developers to retain the records and information described above but they may be mitigated due to other factors. For example, we expect that health IT developers are already keeping most of their records and information in an electronic format. We also expect that some developers may already be retaining records and information for extended periods of time due to existing requirements of other programs, including for those programs their customers participate in. For instance, Medicaid managed care companies are required to keep records for 10 years from the effective date of a contract.</P>
                    <P>
                        We estimated that each health IT developer will, on average, spend two hours each week to comply with our proposed record retention requirement. We expect that a health IT developer's office clerk could complete the record retention responsibilities. According to the May 2017 BLS occupational employment statistics, the mean hourly wage for an office clerk is $16.30.
                        <SU>236</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 $32.
                    </P>
                    <FTNT>
                        <P>
                            <SU>236</SU>
                             
                            <E T="03">See</E>
                              
                            <E T="03">https://www.bls.gov/oes/2017/may/oes439061.htm.</E>
                        </P>
                    </FTNT>
                    <P>Therefore, we estimated the annual cost per developer on average, would be $3,328 and the total annual cost for all health IT developers (458 health IT developers have products certified to the 2015 Edition that are capable of recording patient health data) on average, would be $1.5 million. We note that this is a perpetual cost.</P>
                    <HD SOURCE="HD3">(iii) Prohibition or Restriction of Communications</HD>
                    <HD SOURCE="HD3">(A) Costs</HD>
                    <P>
                        Health IT developers need to notify their customers about the unenforceability of communications and contract provisions that violate the Communications Condition of Certification requirements in § 170.403(a). Generally, health IT developers already have mechanisms in place, whether via online postings, email, mail, or phone, for alerting customers to changes in their policies and procedures. Such alerts should be standard practice. However, we have estimated the potential costs for health IT developers to draft the notice and mail the notice as appropriate. We estimated that a health IT developer's office clerk will commit (overall) approximately 40 hours to drafting and mailing notices when necessary. According to the May 2017 BLS occupational employment statistics, the mean hourly wage for an office clerk is $16.30.
                        <SU>237</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 $32. Therefore, we estimated the annual cost per developer to be $1,280 and the total cost for all health IT developers (792 health IT developers certified to the 2014 Edition) to be $1 million. We note that a developer must notify all customers annually until any contracts contravening the Condition are amended.
                    </P>
                    <FTNT>
                        <P>
                            <SU>237</SU>
                             
                            <E T="03">See</E>
                              
                            <E T="03">https://www.bls.gov/oes/2017/may/oes439061.htm.</E>
                        </P>
                    </FTNT>
                    <P>We also note that mailing is one option for delivery, along with other means such as email. We do not have information concerning how health IT developers will deliver their notices. We have estimated a total cost for all developers to mail the initial notices (including postage) to be $80,000. As noted above, this notice may have to be provided annually, depending on when contracts contravening this provision are amended.</P>
                    <P>
                        In order to meet the Cures Act requirement that health IT developers do not prohibit or restrict communication regarding health IT, some health IT developers will eventually need to amend their contracts to reflect such a change. Many standard form health IT contracts limit the ability of users to voluntarily discuss problems or report usability and safety concerns that they experience when using their health IT. This type of discussion or reporting is typically prohibited through broad confidentiality, nondisclosure, and intellectual property provisions in the developer's standard form health IT contract. Some standard form health IT contracts may also include non-disparagement clauses that prohibit customers from making statements that could reflect negatively on the health IT developer. These practices are often referred to colloquially in the industry as “gag clauses.” We expect amendments to these clauses to be accomplished in the normal course of business, such as when renegotiating contracts or updating them for HIPAA Rules or other compliance requirements outside of the ONC Health IT Certification Program. As such, we do not estimate any direct or indirect costs 
                        <PRTPAGE P="25929"/>
                        for health IT developers to amend their contracts to comply with this Condition of Certification requirement.
                    </P>
                    <HD SOURCE="HD3">(B) Benefits</HD>
                    <P>We expect health care providers to benefit from this provision. There is growing recognition that these practices of prohibiting or restricting communication do not promote health IT safety or good security hygiene and that health IT contracts should support and facilitate the transparent exchange of information relating to patient care. We were unable to estimate these benefits because we do not have adequate information to determine the prevalence of gag clauses and other restrictive practices, nor do we have a means to quantify the value to providers of being able to freely communicate and share information. We welcomed comments on approaches to quantify these benefits.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comments specific to our approach of quantifying the benefits of our provision to inform customers regarding the prohibition or restriction of communications. We did receive several comments stating that our notification and contract revision estimates underestimate the volume of agreements for large developers and the cost of compliance. We also received several comments that the burden for revising contracts could be significant and costly, particularly in the timeframe originally proposed, with one comment adding that the cost for revising contracts should be included in the impact analysis.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain that we were unable to estimate the benefits of the provision due to inadequate information however, we believe that prohibiting or restricting communication does not promote health IT safety or good security hygiene and that health IT contracts should support and facilitate the transparent exchange of information relating to patient care. We maintain our notification estimates as we believe that large developers would have efficient means of sending notifications 
                        <E T="03">i.e.</E>
                         by email. We reiterate that we expect revision of contracts to be accomplished in the normal course of business and do not estimate any direct or indirect costs for health IT developers to amend their contracts to comply.
                    </P>
                    <HD SOURCE="HD3">(iv) Application Programming Interfaces</HD>
                    <P>For a discussion of the costs and benefits of the new API criterion in § 170.315(g)(10), please see section (2)(iii) of this RIA.</P>
                    <HD SOURCE="HD3">(A) Transparency Requirements for Application Programming Interfaces</HD>
                    <P>In this final rule, as part of the Conditions and Maintenance of Certification requirements in § 170.404, we have required that API Technology Suppliers make specific business and technical documentation necessary to interact with the APIs in production freely and publicly accessible. We expect that the API Technology Suppliers will perform the following tasks related to transparency of business and technical documentation and would devote the following number of hours annually to such tasks: (1) Health Level 7's (HL7®) Fast Healthcare Interoperability Resources (FHIR®) API documentation (the developer would most likely point to the HL7 FHIR standard for API documentation) (estimated eight hours); (2) patient application registration documentation, which will include a development effort to create a website that manages the application registration activity (estimated 40 hours); (3) publication of the FHIR Endpoint—Base URLs for all centrally managed providers (estimated 40 hours); (4) publication of FHIR Endpoints for provider-managed APIs (estimated 160 hours); and (5) API cost information documentation, which will typically be documented as a tiered rate based on usage or some form of monthly rate (estimated 40 hours).</P>
                    <P>
                        We believe each of the above tasks would be performed by a “Software Developer.” According to the May 2017 BLS occupational employment statistics, the mean hourly wage for software developer is $53.74.
                        <SU>238</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 $107. Therefore, we estimated the cost per developer to be $30,816. As noted in section (2)(iii) of this RIA, we estimated that 459 products from 394 developers will contain the API criterion. Therefore, we estimated the total developer cost would be $12.1 million. We note that this is a one-time cost and would not be perpetual. We did not receive comments on this discussion and have therefore finalized our figures.
                    </P>
                    <FTNT>
                        <P>
                            <SU>238</SU>
                             
                            <E T="03">See</E>
                              
                            <E T="03">https://www.bls.gov/oes/2017/may/oes439061.htm.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(v) Real World Testing</HD>
                    <P>The objective of real world testing in § 170.405 is to verify the extent to which deployed health IT products in operational production settings are demonstrating compliance to certification criteria and functioning with the intended use cases for continued maintenance of certification requirements. Real world testing should ensure certified health IT products have the ability to share electronic health information between systems. Real world testing should assess that the certified health IT is meeting the intended use case(s) of the certification criteria to which it is certified within the workflow, health IT architecture, and care/practice setting in which the health IT is implemented. We note that we expect real world testing would take about three months of the year to perform.</P>
                    <HD SOURCE="HD3">(A) Costs</HD>
                    <P>This section describes the potential costs of the real world testing requirements in this final rule. The costs estimates are based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Health IT developers will use the same labor costs.</E>
                         Table 24 shows the estimated labor costs for a health IT developer to perform real world testing. We recognize that health IT developer costs will vary; however, our estimates in this section assume all developers will incur the costs noted in Table 24.
                    </P>
                    <P>
                        • 
                        <E T="03">Proxy needed to project the number of 2015 Edition products impacted by real world testing.</E>
                         We estimated that 523 products from 429 developers will be impacted by real world testing. We used a proxy to determine developers that would be subject to real world testing. There were 681 products and 551 developers with at least one of its 2014 Edition certified products that could perform transitions of care and/or send any type of public health data. We then multiplied these numbers by our estimates for certified health IT market consolidation by −22.1 percent and −23.2 percent to project the number of 2015 developers and products, respectively. We believe this estimate serves as a reasonable proxy for products impacted by real world testing, as these products primarily focus on interoperability.
                    </P>
                    <P>
                        The tables below describe the various costs to health IT developers to perform real world testing by task.
                        <PRTPAGE P="25930"/>
                    </P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s150,12,12,12">
                        <TTITLE>Table 24—Estimated Cost to Health IT Developers To Perform Real World Testing </TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Tasks and labor category</CHED>
                            <CHED H="1">Hours</CHED>
                            <CHED H="1">Rate</CHED>
                            <CHED H="1">Total</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1: Design Real world Testing Approach and Submit Plan (per developer)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>$34,560</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1133 Software Developers, Systems Software</ENT>
                            <ENT>80</ENT>
                            <ENT>107</ENT>
                            <ENT>8,560</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1143 Computer Network Architects</ENT>
                            <ENT>120</ENT>
                            <ENT>104</ENT>
                            <ENT>12,480</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1121 Computer Systems Analysts</ENT>
                            <ENT>80</ENT>
                            <ENT>89</ENT>
                            <ENT>7,120</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1199 Computer Occupations, All Other</ENT>
                            <ENT>40</ENT>
                            <ENT>88</ENT>
                            <ENT>3,520</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">27-3042 Technical Writers</ENT>
                            <ENT>40</ENT>
                            <ENT>72</ENT>
                            <ENT>2,880</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2: Prepare Staff and Environments (per developer)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>14,920</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1121 Computer Systems Analysts</ENT>
                            <ENT>40</ENT>
                            <ENT>89</ENT>
                            <ENT>3,560</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1142 Network and Computer Systems Administrators</ENT>
                            <ENT>40</ENT>
                            <ENT>83</ENT>
                            <ENT>3,320</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1152 Computer Network Support Specialists</ENT>
                            <ENT>40</ENT>
                            <ENT>65</ENT>
                            <ENT>2,600</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1199 Computer Occupations, All Other</ENT>
                            <ENT>40</ENT>
                            <ENT>88</ENT>
                            <ENT>3,520</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1122 Information Security Analysts</ENT>
                            <ENT>20</ENT>
                            <ENT>96</ENT>
                            <ENT>1,920</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3: Perform Testing (per product)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>32,240</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1121 Computer Systems Analysts</ENT>
                            <ENT>80</ENT>
                            <ENT>89</ENT>
                            <ENT>7,120</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1133 Software Developers, Systems Software</ENT>
                            <ENT>40</ENT>
                            <ENT>107</ENT>
                            <ENT>4,280</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1199 Computer Occupations, All Other</ENT>
                            <ENT>160</ENT>
                            <ENT>88</ENT>
                            <ENT>14,080</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1142 Network and Computer Systems Administrators</ENT>
                            <ENT>40</ENT>
                            <ENT>83</ENT>
                            <ENT>3,320</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1141 Database Administrators</ENT>
                            <ENT>40</ENT>
                            <ENT>86</ENT>
                            <ENT>3,440</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4: Collect Results and Prepare-Submit Report (per developer)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>20,560</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1199 Computer Occupations, All Other</ENT>
                            <ENT>120</ENT>
                            <ENT>88</ENT>
                            <ENT>10,560</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">15-1121 Computer Systems Analysts</ENT>
                            <ENT>80</ENT>
                            <ENT>89</ENT>
                            <ENT>7,120</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="03">27-3042 Technical Writers</ENT>
                            <ENT>40</ENT>
                            <ENT>72</ENT>
                            <ENT>2,880</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Labor Hours</ENT>
                            <ENT>1,140</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="05">Other Direct Costs—printing, publishing (per product)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>150.00</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="3" OPTS="L2,i1" CDEF="s100,r50,12">
                        <TTITLE>Table 25—Real World Testing Total Annual Cost</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Task</CHED>
                            <CHED H="1">Calculation</CHED>
                            <CHED H="1">Total cost</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Task 1</ENT>
                            <ENT>$34,560 * 429 developers</ENT>
                            <ENT>$14,826,240</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 2</ENT>
                            <ENT>$14,920 * 429 developers</ENT>
                            <ENT>6,400,680</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 3</ENT>
                            <ENT>$32,240 * 523 products</ENT>
                            <ENT>16,861,520</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Task 4</ENT>
                            <ENT>$20,560 * 429 developers</ENT>
                            <ENT>8,820,240</ENT>
                        </ROW>
                        <ROW RUL="n,s">
                            <ENT I="01">Other Direct Costs</ENT>
                            <ENT>$150 * 523 products</ENT>
                            <ENT>78,450</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Cost</ENT>
                            <ENT/>
                            <ENT>46,987,130</ENT>
                        </ROW>
                    </GPOTABLE>
                    <P>Based on the stated assumptions and costs outlined in the above tables, we estimated the total annual cost for real world testing would, on average, be $47 million with an average cost per developer of $109,557.</P>
                    <HD SOURCE="HD3">(B) Benefits</HD>
                    <P>There are several benefits that can be attributed to real world testing. Real world testing may impact the effective integration of varied health IT systems, including integration of certified health IT with non-certified and ancillary technologies such as picture archiving and communications systems (PACS) or specialty-specific interfaces. This could result in greater interoperability among health IT systems. For providers that are currently dissatisfied with how their health IT is performing, real world testing might also influence the effective implementation of workflows in a clinical setting. In this analysis, we calculated the benefits in the following categories: For providers that have complained about their EHR system, time saved documenting in their EHR due to improved usability; for providers that are dissatisfied with their EHR, increased provider satisfaction resulting in fewer providers incurring the costs of switching products; and benefits related to reductions in duplicate lab tests, readmissions, ER visits, and adverse drug events due to increased interoperability. We focused on these outcomes for two reasons: (i) Evidence in literature indicates that health information exchange impacts the chosen measures; and (ii) cost of care associated with these measures is high and the impact of health information exchange is likely to result in significant benefits in the form of reduced costs.</P>
                    <P>The benefit calculations were based on the following assumptions:</P>
                    <P>
                        • 
                        <E T="03">Benefits noted in academic literature are assumed accurate and results were not externally validated.</E>
                    </P>
                    <P>
                        • 
                        <E T="03">Hospitals and eligible professionals that participate in the CMS Promoting Interoperability Programs will be impacted.</E>
                         Estimates were based on the assumption that 439,187 health care providers and/or 4,519 hospitals will be affected by this regulatory action.
                    </P>
                    <P>
                        • 
                        <E T="03">Estimates of the impact of real world testing on rates of interoperability (0.1 to 1 percent) are based on ONC analysis.</E>
                         To identify the impact of real world testing on interoperability, we used regression analysis. Specifically, we estimated linear probability models that identified impact of 2014 Edition certified EHR on hospitals' interoperability (whether a hospital sends, receives, finds, and integrates summary of care records). Using data from the AHA from years 2014 and 2015 in the model, we controlled for hospital size, profit status, participation in a health information organization, and state and year fixed effects. The marginal effect of using a 2014 Edition was a five percentage point increase in interoperability. This is an upper bound estimate. For the purpose of this 
                        <PRTPAGE P="25931"/>
                        analysis, we assume 0.1 percent to 1 percent would be a reasonable range for real world testing to impact interoperability.
                    </P>
                    <P>
                        • 
                        <E T="03">Impact of real world testing is also based on the estimated number of providers that switch health IT developers (rate = five percent) and are dissatisfied with their current EHR (44 percent).</E>
                         To calculate the number of providers that are likely to switch their EHR due to dissatisfaction with their system, we estimate the rate of switching using CMS Medicare EHR Incentive Program data from years 2013 to 2016. This results in 4,774 clinical practices and 226 hospitals that are projected to switch products in a year. We then leverage results from Stanford Medicine's research conducted by The Harris Poll which reports that nearly 44 percent of providers are not satisfied with their EHR.
                        <SU>239</SU>
                        <FTREF/>
                         Based on this research, we assume that approximately 2,195 providers are less likely to switch their EHR with real world testing.
                    </P>
                    <FTNT>
                        <P>
                            <SU>239</SU>
                             How Doctors Feel About Electronic Health Records National Physician Poll by The Harris Poll 
                            <E T="03">http://med.stanford.edu/content/dam/sm/ehr/documents/EHR-Poll-Presentation.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Estimates of the rate of eligible professionals (10 percent) and hospitals (five percent) that will be impacted by real world testing are based on ONC complaint data.</E>
                         We recognize that the benefits of real world testing are limited to those providers that have systems that might be underperforming. Therefore, we estimated that the providers impacted by this rule are limited to the proportion of providers that have issued complaints about their system to ONC.
                    </P>
                    <P>
                        As noted previously in this analysis, we acknowledge that there might be shared benefits across certain provisions and have taken steps to ensure that the benefits attributed to each provision are unique to the provision referenced. Specifically, we used regression analysis to calculate the impact of our real world testing and API provisions on interoperability. We assumed that the real world testing and API provisions would collectively have the same impact on interoperability as use of 2014 Edition certified health IT. Therefore, we estimated linear probability models that identified the impact of 2014 Edition certified health IT on hospitals' interoperability.
                        <SU>240</SU>
                        <FTREF/>
                         We controlled for additional factors such as participation in a health information exchange organization, hospital characteristics, and urban/rural status. We found the marginal effect of using 2014 Edition certified health IT was a five percentage point increase in interoperability.
                    </P>
                    <FTNT>
                        <P>
                            <SU>240</SU>
                             American Hospital Association Health IT Supplement Survey, 
                            <E T="03">http://www.ahadata.com/aha-healthcare-database.</E>
                        </P>
                    </FTNT>
                    <P>We assumed that this marginal effect is true for our provisions and distributed the five percent benefit across our real world testing and API provisions at (0.1 to 1 percent) to (1 to 4 percent) respectively. Moreover, the number of providers impacted is provision specific. Given data limitations, we believe this approach allows us to estimate the benefits of our provisions without double counting the impact each provision might have on interoperability.</P>
                    <P>Table 26 shows the benefits of real world testing for providers. We quantified the monetary benefits of real world testing based on a reduction in the amount of time a provider spends on their EHR by improving its usability or the cost-savings associated with switching from an underperforming EHR system. Note, these benefits are limited to providers who have expressed dissatisfaction with their EHR and only represent a fraction of all health care providers. Table 27 quantifies the benefits associated with improved interoperability for these providers. This is primarily because provider behavior is more directly affected by improvements in interoperability.</P>
                    <GPOTABLE COLS="9" OPTS="L2,p7,7/8,i1" CDEF="s50,r30,12,12,12,12,12,r25,r25">
                        <TTITLE>Table 26—Benefit of Real World Testing for Providers</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Benefit type</CHED>
                            <CHED H="1">
                                Number 
                                <LI>affected</LI>
                            </CHED>
                            <CHED H="1">Hourly wage</CHED>
                            <CHED H="1">
                                Hours saved 
                                <LI>
                                    (percent) 
                                    <E T="0731">A B</E>
                                </LI>
                            </CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                            <CHED H="1">Hours per day with EHR</CHED>
                            <CHED H="1">Number of working days in a year</CHED>
                            <CHED H="1">
                                Total benefit 
                                <E T="0731">C</E>
                                <LI> </LI>
                            </CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Reduction in provider time spent in health IT by improving usability and interoperability</ENT>
                            <ENT>
                                43,919 providers or 10% 
                                <E T="0731">D</E>
                                 (based on complaint data)
                            </ENT>
                            <ENT>$97.85</ENT>
                            <ENT>1</ENT>
                            <ENT>5</ENT>
                            <ENT>
                                6 
                                <E T="0731">E</E>
                            </ENT>
                            <ENT>260</ENT>
                            <ENT>$65 million per year</ENT>
                            <ENT>$335 million per year.</ENT>
                        </ROW>
                        <ROW RUL="n,n,n,n,n,n,n,s">
                            <ENT I="01">
                                Number of providers switching health IT 
                                <E T="0731">F</E>
                            </ENT>
                            <ENT O="xl">
                                2,195; Cost of Switching.
                                <LI O="xl">Min = $15,000</LI>
                                <LI O="xl">Max = $70,000</LI>
                            </ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>$34M per year</ENT>
                            <ENT>$158M per year.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Benefit</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>$99M per year</ENT>
                            <ENT>$493M per year.</ENT>
                        </ROW>
                        <TNOTE>
                            <SU>A</SU>
                             Julia Adler-Milstein and Robert S. Huckman, 
                            <E T="03">The Impact of Electronic Health Record Use on Physician Productivity,</E>
                             Am J Manag Care (Nov. 19, 2013).
                        </TNOTE>
                        <TNOTE>
                            <SU>B</SU>
                             Amusan, Tongen, Speedie, and Mellin, 
                            <E T="03">A time-motion study to evaluate the impact of EMR and CPOE implementation on physician efficiency,</E>
                             J. Healthcare Inf. Manag. (Fall 2008), at 31-7.
                        </TNOTE>
                        <TNOTE>
                            <SU>C</SU>
                             Total benefits for the provider and administrative time spent in health IT by improving usability and interoperability. Total benefits from switching EHR developer is a product of the number providers switching and cost of EHR.
                        </TNOTE>
                        <TNOTE>
                            <SU>D</SU>
                             The estimate is based on the number of providers that currently possess products with complaints. This is identified by flagging health IT developers and products about whom/which complaints are logged on ONC's database. These health IT developers are then matched to physicians using the Meaningful Use database.
                        </TNOTE>
                        <TNOTE>
                            <SU>E</SU>
                             Christine Sinsky et al., 
                            <E T="03">Allocation of Physician Time in Ambulatory Practice: A Time and Motion Study in 4 Specialties,</E>
                             Ann Intern Med. (Dec. 6, 2016), at 753-60. Physician Practice, 
                            <E T="03">Calculating the Right Number of Staff for Your Medical Practice, available at http://www.physicianspractice.com/blog/calculating-right-number-staff-your-medical-practice</E>
                            .
                        </TNOTE>
                        <TNOTE>
                            <SU>F</SU>
                             This estimate was obtained from Meaningful Use data from years 2013-2016. “Switching” is defined as an annual change in all health IT developers by providers/hospitals.
                        </TNOTE>
                    </GPOTABLE>
                    <PRTPAGE P="25932"/>
                    <GPOTABLE COLS="9" OPTS="L2,p7,7/8,i1" CDEF="s25,r25,12,12,12,r25,12,r25,r25">
                        <TTITLE>Table 27—Benefit of Real World Testing for Patients and Payers</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Benefit type</CHED>
                            <CHED H="1">
                                Population 
                                <LI>affected</LI>
                            </CHED>
                            <CHED H="1">
                                Overall interop impact 
                                <LI>(marginal </LI>
                                <LI>effect)</LI>
                            </CHED>
                            <CHED H="1">Impact of real world testing</CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                            <CHED H="1">Total cost</CHED>
                            <CHED H="1">
                                Percentage of total cost
                                <LI>impacted</LI>
                            </CHED>
                            <CHED H="1">
                                Total benefit 
                                <E T="0731">A</E>
                            </CHED>
                            <CHED H="2">Min</CHED>
                            <CHED H="2">Max</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Duplicate testing</ENT>
                            <ENT>35,607 providers</ENT>
                            <ENT>
                                <E T="0731">B</E>
                                 0.09
                            </ENT>
                            <ENT>0.001</ENT>
                            <ENT>0.01</ENT>
                            <ENT>
                                $200 billion 
                                <E T="0731">C</E>
                            </ENT>
                            <ENT>10</ENT>
                            <ENT>$1.9 million per year</ENT>
                            <ENT>$18.5 million per year.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Avoidable hospitalizations and readmissions</ENT>
                            <ENT O="xl">5% of hospitals (n = 226).</ENT>
                            <ENT>
                                <E T="0731">B</E>
                                 0.09
                            </ENT>
                            <ENT>0.001</ENT>
                            <ENT>0.01</ENT>
                            <ENT>
                                $41 billion 
                                <E T="0731">D</E>
                            </ENT>
                            <ENT>5</ENT>
                            <ENT>$0.2 million per year</ENT>
                            <ENT>$1.9 million per year.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">ER visits</ENT>
                            <ENT>5% of visits affected (n = 131 million)</ENT>
                            <ENT>
                                <E T="0731">B</E>
                                 0.03
                            </ENT>
                            <ENT>0.001</ENT>
                            <ENT>0.01</ENT>
                            <ENT>
                                $1,233, Per ER visit 
                                <E T="0731">E</E>
                            </ENT>
                            <ENT>5</ENT>
                            <ENT>$0.2 million per year</ENT>
                            <ENT>$2.54 million per year.</ENT>
                        </ROW>
                        <ROW RUL="n,n,n,n,n,n,n,s">
                            <ENT I="01">Adverse drug events</ENT>
                            <ENT>5% of events affected</ENT>
                            <ENT>
                                <E T="0731">F</E>
                                 0.22
                            </ENT>
                            <ENT>0.001</ENT>
                            <ENT>0.01</ENT>
                            <ENT>
                                $30 billion 
                                <E T="0731">G</E>
                            </ENT>
                            <ENT>5</ENT>
                            <ENT>$0.3 million per year</ENT>
                            <ENT>$3.4 million per year.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Total Benefit</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>$2.6 million</ENT>
                            <ENT>$26.3 million.</ENT>
                        </ROW>
                        <TNOTE>
                            <SU>A</SU>
                             Total benefit is a product of 
                            <E T="03">total cost, percent of total cost impacted, overall impact of interoperability, and impact of real world testing</E>
                            .
                        </TNOTE>
                        <TNOTE>
                            <SU>B</SU>
                             Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., Effects of health information exchange adoption on ambulatory testing rates, J. Am. Med. Inform. Assoc. (2013), at 1137-1142; Bridget A. Stewart, Susan Fernandes, Elizabeth Rodriguez-Huertas, and Michael Landzberg, A preliminary look at duplicate testing associated with lack of electronic health record interoperability for transferred patients, J. of the Am. Med. Informatics Assoc. (2010), at 341-344; Sezgin Ayabakan, Indranil R. Bardhan, Zhiqiang (Eric) Zheng, and Kirk Kirksey Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals, MIS Quarterly (Jan. 1, 2017); Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, Does health information exchange reduce redundant imaging? Evidence from emergency departments, Med Care (Mar. 2014), at 227-34.
                        </TNOTE>
                        <TNOTE>
                            <SU>C</SU>
                             National Academy of Medicine. (2016), 
                            <E T="03">http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html</E>
                            .
                        </TNOTE>
                        <TNOTE>
                            <SU>D</SU>
                             Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), 
                            <E T="03">https://www.hcup-us.ahrq.gov/reports/statbriefs/sb199-Readmissions-Payer-Age.pdf</E>
                            ; AHRQ Statistical Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), 
                            <E T="03">https://www.hcup-us.ahrq.gov/reports/statbriefs/sb72.pdf</E>
                            .
                        </TNOTE>
                        <TNOTE>
                            <SU>E</SU>
                             National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016), 
                            <E T="03">https://www.cdc.gov/nchs/data/databriefs/db252.pdf</E>
                            ; Nolan Caldwell, Tanja Srebotnjak, Tiffany Wang, and Renee Hsia, “How Much Will I Get Charged for This?” Patient Charges for Top Ten Diagnoses in the Emergency Department (2013), 
                            <E T="03">https://doi.org/10.1371/journal.pone.0055491</E>
                            .
                        </TNOTE>
                        <TNOTE>
                            <SU>F</SU>
                             M.F. Furukawa, W.D. Spector, M.R. Limcangco, and W.E. Encinosa, 
                            <E T="03">Meaningful use of health information technology and declines in in-hospital adverse drug events,</E>
                             J. of the Am. Med. Informatics Assoc. (2017).
                        </TNOTE>
                        <TNOTE>
                            <SU>G</SU>
                             Janet Sultana, Paola Cutroneo, and Gianluca Trifirò, 
                            <E T="03">Clinical and economic burden of adverse drug reactions</E>
                             (Dec. 2013).
                        </TNOTE>
                    </GPOTABLE>
                    <P>Based on the stated assumptions and benefits outlined in Table 26, we estimate the total annual benefit for real world testing to providers would range, on average, from $99 million to $493 million. Based on the stated assumptions and benefits outlined in Table 27, we estimate the total annual benefit for patients and payers would range, on average, from $2.6 million to $26.3 million. Therefore, we estimate the total benefit of real world testing would range, on average, from $101.6 million to $519.3 million.</P>
                    <P>We recognize that health IT developers may deploy their systems in a number of ways, including cloud-based deployments, and requested comment on whether our cost estimates of real world testing should factor in such methods of system deployment. For example, we requested feedback about whether health IT developers would incur reduced real world testing costs through cloud-based deployments as opposed to other deployment methods. We specifically solicited comment on the general ratio of cloud-based to non-cloud-based deployments within the health care ecosystem and specific cost variations in performing real world testing based on the type of deployment. We also requested comment on our assumptions about the burden to providers in time spent assisting health IT developers since we encourage health IT developers to come up with ways to perform real world testing that mitigate provider disruption.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comment specific to whether health IT developers would incur reduced real world testing costs through cloud-based deployments as opposed to other deployment methods. We also did not receive comments regarding the ratio of cloud-based to non-cloud based deployments and cost variations regarding different types of deployments. We also did not receive comments regarding the burden to providers in time spent assisting health IT developers.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain our assumptions and estimates as proposed regarding real world testing.
                    </P>
                    <HD SOURCE="HD3">(C) Real World Testing Maintenance Requirements</HD>
                    <P>In this final rule, we revised the Principle of Proper Conduct in § 170.523(m) to require ONC-ACBs to collect, no less than quarterly, all updates successfully made to standards in certified health IT pursuant to the developers having opted to avail themselves of the Standards Version Advancement Process flexibility under the real world testing Condition of Certification requirement. Under § 170.523(p), ONC-ACBs will be responsible for: (1) Reviewing and confirming that applicable health IT developers submit real world testing plans in accordance with § 170.405(b)(1); (2) reviewing and confirming that applicable health IT developers submit real world testing results in accordance with § 170.405(b)(2); and (3) submitting real world testing plans by December 15 and results by March 15 of each calendar year to ONC for public availability. In addition, under § 170.523(t), ONC-ACBs will be required to: (1) Maintain a record of the date of issuance and the content of developers' notices; and (2) timely post content of each notice on the CHPL.</P>
                    <P>Using the information from the “Real World Testing Costs” section of this RIA, we estimated that 429 developers will be impacted by real world testing. We estimate that, on average, it will take an ONC-ACB employee at the GS-13, Step 1 level approximately 30 minutes to collect all updates made to standards in Health IT Modules in accordance with § 170.523(m). The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Since the collection must occur no less than quarterly, we assume it occurs, on average, four times per year. Therefore, we estimate the annual cost to ONC-ACBs to comply with the collection requirements under § 170.523(m) to be $78,078.</P>
                    <P>
                        We estimated that, on average, it will take an ONC-ACB employee at the GS-
                        <PRTPAGE P="25933"/>
                        13, Step 1 level approximately one hour to review and confirm that applicable health IT developers submit real world testing plans in accordance with § 170.405(b)(1). We estimate that, on average, it will take an ONC-ACB employee at the GS-13, Step 1 level approximately 30 minutes to review and confirm that applicable health IT developers submit real world testing results in accordance with § 170.405(b)(2). We estimate that, on average, it will take an ONC-ACB employee at the GS-13, Step 1 level approximately 30 minutes to submit real world testing plans and results to ONC for public availability. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Therefore, we estimate the annual cost to ONC-ACBs to comply with the submission and reporting requirements under §§ 170.523(m) and 170.550(l) to be $156,156.
                    </P>
                    <P>Throughout the RIA we have used 830 products as our 2015 Edition projection. We came up with this projection by multiplying a −23.2 percent market consolidation rate from the total number of products certified to 2014 Edition. This assumption was based on the market consolidation rate observed between the 2011 and 2014 Editions. We have estimated the number of 2015 Edition products that will certify each criterion included in the real world testing Condition of Certification requirement. We assume that there will be a cost associated with a notice for each certified criterion (even if an individual product were to update the same standard across multiple criteria that use that standard). This estimation was calculated by multiplying the current percent of 2015 Edition products that certify a criterion by the estimated number of total 2015 Edition products (830). For example, we calculated that 43 percent of 2015 Edition products certified 170.315(b)(1); we then multiplied this percentage by 830—the predicted number of 2015 Edition products. Thus, based on this calculation, for 2015 Edition, we predict that 359 products will certify the 170.315(b)(1) criterion. This method was used across all criteria included in the real world testing Condition of Certification requirement.</P>
                    <P>We assume that the amount of time for an ONC-ACB staff person to: (1) Maintain a record of the date of issuance and the content of developers' notices; and (2) to timely post content of each notice on the CHPL can be anywhere from 30 minutes to one hour.</P>
                    <P>The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. This was the hourly rate we used for this RIA, so it is consistent with prior calculations. This wage is used to determine the ONC-ACB time cost to complete this requirement under § 170.523(t). For this estimate, we take half the hourly rate and multiply it by the number of products predicted to certify each of the applicable criteria. For each criterion, we estimate a lower bound and upper bound prediction. The lower bound assumes that 25 percent of certified products update any of the applicable standards. The upper bound prediction assumes that all certified products update any of the applicable standards. These estimates are calculated for each criterion and then the cumulative sum of all the individual criterion calculations is made. We estimate, at 30 minutes per notice, it will cost $60,606 if 25 percent of certified products update any of the applicable standards across all criteria, and if all products update any of the applicable standards, we estimate it will cost $242,424. Our maximum estimate for time to comply is one hour per notice.</P>
                    <P>Using the same methodology explained above, we estimate, at 60 minutes per notice, it will cost $121,212 if 25 percent of certified products update any of the applicable standards across all criteria, and if all products update any of the applicable standards, we estimate it will cost $484,848. Our lower bound estimate for the cost of this requirement is $60,606. Our upper bound estimate for the cost of this requirement is $484,848.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We received a comment recommending that ONC add accountability to the real world testing process by having ONC-ACBs review a randomly selected percentage of submitted results for potential non-conformity with certification requirements.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We thank commenters for their input. It is within ONC-ACBs' rights and interests to randomly select certified Health IT Modules that have been real world tested as part of their surveillance activities. ONC will be working closely with ONC-ACBs to provide direction on how ONC-ACBs can leverage existing Program and ISO/IEC 17065 requirements to provide oversight without increasing burden by setting a minimum expectation in regulation. Setting a regulatory quota could potentially create burden as workloads amongst the different ONC-ACBs vary. Additionally, it limits ONC-ACBs to what is adopted in the final rule and prevents future adjustments that may be needed to improve efficiency without additional rulemaking. We have finalized our estimates.
                    </P>
                    <HD SOURCE="HD3">(vi) Attestations</HD>
                    <P>The Cures Act requires that a health IT developer, as a Condition and Maintenance of Certification requirement under the Program, provide to the Secretary an attestation to all the Conditions and Maintenance of Certification requirements specified in the Cures Act, except for the “EHR Reporting Program” Condition of Certification requirement. It also requires that a health IT developer attest that its health IT allows for health information to be exchanged, accessed, and used in the manner described by the API Condition of Certification requirement. We have finalized our proposal to implement the Cures Act “attestations” requirement in § 170.406 by requiring health IT developers to attest to the aforementioned Conditions. For the purposes of estimating the potential burden of these attestations on health IT developers, ONC-ACBs, and ONC, we estimate that all health IT developers under the Program will submit an attestation biannually. As noted previously in this RIA, there are 792 health IT developers certified to the 2014 Edition.</P>
                    <P>
                        We estimated it would take a health IT developer employee approximately one hour on average to prepare and submit each attestation to the ONC-ACB. According to the May 2017 BLS occupational employment statistics, the mean hourly wage for a software developer is $53.74.
                        <SU>241</SU>
                        <FTREF/>
                         Therefore, we estimated the annual cost including overhead costs to be $84,744. We have finalized that attestations will be submitted to ONC-ACBs on behalf of ONC and the Secretary. We assume there will be four ONC-ACBs as this is the current number of ONC-ACBs, and we also assume an equal distribution in responsibilities among ONC-ACBs. ONC-ACBs would have two responsibilities related to attestations. One responsibility we finalized in § 170.523(q) is that an ONC-ACB must review attestations for completion and submit the health IT developers' attestations to ONC. We estimate it will take an ONC-ACB employee at the GS-13, Step 1 level approximately 30 minutes on average to review and submit each attestation to ONC. The other responsibility we are finalizing in § 170.550(l) is that an ONC-ACB would need to ensure that the health IT developer of the Health IT Module has 
                        <PRTPAGE P="25934"/>
                        met its responsibilities related to the Conditions and Maintenance of Certification requirements as solely evidenced by its attestation. We estimate it will take an ONC-ACB employee at the GS-13, Step 1 level approximately one hour on average to complete this task. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Therefore, we estimate the annual cost to ONC-ACBs to be $108,108.
                    </P>
                    <FTNT>
                        <P>
                            <SU>241</SU>
                             
                            <E T="03">See</E>
                              
                            <E T="03">https://www.bls.gov/oes/2017/may/oes439061</E>
                            .
                        </P>
                    </FTNT>
                    <P>We have finalized that we would make the attestations publicly available on the CHPL once they are submitted by the ONC-ACBs. ONC posts information regularly to the CHPL and we estimate the added costs to post the attestation will be de minimis.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive comment specific to the methods related to the estimates for posting attestations.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain our assumptions and estimates as proposed regarding attestations.
                    </P>
                    <HD SOURCE="HD3">(4) Oversight for the Conditions and Maintenance of Certification Requirements</HD>
                    <P>Our processes for overseeing the Conditions and Maintenance of Certification requirements will, for the most part, mirror our processes for direct review of non-conformities in certified health IT as described in current § 170.580. We may directly review a health IT developer's actions to determine whether they conform to the Conditions and Maintenance of Certification requirements finalized in this final rule. The estimated costs and benefits for such oversight and review are detailed below.</P>
                    <HD SOURCE="HD3">(i) Costs</HD>
                    <P>We estimated the potential monetary costs of allowing ONC to directly review a health IT developer's actions to determine whether the actions conform to the requirements of the Program as follows: (1) Costs for health IT developers to correct non-conforming actions identified by ONC; (2) costs for health IT developers and ONC costs related to ONC review and inquiry into non-conforming actions by the health IT developer; and (3) costs for ONC-ACBs related to the new reporting requirement in the Principles of Proper Conduct in § 170.523(s).</P>
                    <HD SOURCE="HD3">(A) Costs for Health IT Developers to Correct Non-Conforming Actions Identified by ONC</HD>
                    <P>
                        We do not believe health IT developers face additional direct costs for the ONC direct review of health IT developer actions (
                        <E T="03">see</E>
                         cost estimates for the Conditions and Maintenance of Certification requirements). However, we acknowledge that this final rule may eventually require health IT developers to correct certain actions or non-conformities with their health IT that do not conform to the Conditions and Maintenance of Certification requirements.
                    </P>
                    <P>If we identify a non-conforming action by a health IT developer, the costs incurred by the health IT developer to bring its actions into conformance will be determined on a case-by-case basis. Factors that will be considered include, but are not limited to: (1) The extent of customers and/or business affected; (2) how pervasive the action(s) is across the health IT developer's business; (3) the period of time that the health IT developer was taking the action(s) in question; and (4) the corrective action required to resolve the issue. We are unable to reliably estimate these costs as we do not have cost estimates for a comparable situation. We requested comment on existing relevant data and methods we could use to estimate these costs.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the relevant data and methods used to estimate the costs to correct non-conforming actions identified by ONC.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain our approach used to estimate the costs to correcting identified non-conformities.
                    </P>
                    <HD SOURCE="HD3">(B) Costs for Health IT Developers and ONC Costs Related to ONC Review and Inquiry Into Health IT Developer Actions</HD>
                    <P>
                        In order to calculate the potential costs to health IT developers and ONC related to ONC review and inquiry into health IT developer actions, we have created the following categories for potential costs: (1) ONC review and inquiry prior to the issuance of a notice of non-conformity; (2) ONC review and inquiry following the issuance of a notice of non-conformity and the health IT developer does not contest ONC's findings (
                        <E T="03">i.e.,</E>
                         no appeal); and (3) ONC review and inquiry following the issuance of a notice of non-conformity and the health IT developer contests ONC's findings (
                        <E T="03">i.e.,</E>
                         appeal).
                    </P>
                    <HD SOURCE="HD3">(C) ONC Review and Inquiry Prior to the Issuance of a Notice of Nonconformity</HD>
                    <P>We anticipate that ONC will receive, on average, between 100 and 200 complaints per year concerning the Conditions and Maintenance of Certification requirements that will warrant review and inquiry by ONC. We estimate that such initial review and inquiry by ONC will require, on average, two to three analysts at the GS-13 level working one to two hours each per complaint. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Therefore, we estimate each review and inquiry will cost ONC, on average, between $182 and $546. We estimate the total annual cost to ONC will, on average, range from $18,200 and $109,200. This range takes into account both the low end of reviews that are resolved quickly and the high end in which staff will need to discuss issues with ONC leadership or in some cases, HHS senior leadership including the Office of General Counsel. We have not estimated health IT developer costs associated with ONC review prior to the issuance of a notice of non-conformity because, in most cases, health IT developers are not required to take action prior to the notice of non-conformity.</P>
                    <HD SOURCE="HD3">(D) ONC Review and Inquiry Following the Issuance of a Notice of Non-Conformity and the Health IT Developer Does Not Contest ONC's Findings</HD>
                    <P>This category captures cases that require review and inquiry following ONC's issuance of a notice of non-conformity, but that do not proceed to the appeals process. Examples of such situations would include, but not be limited to: (1) A health IT developer violates a Condition of Certification requirement and does not contest ONC's finding that it is in violation of the Condition of Certification requirement; or (2) a health IT developer fails to meet a deadline, such as for its corrective action plan (CAP). We estimate that ONC will, on average, conduct between 12 and 18 of these reviews annually.</P>
                    <P>
                        We estimate that a health IT developer may commit, on average and depending on complexity, between 10 and 40 hours of staff time per case to provide ONC with all requested records and documentation that ONC would use to review and conduct an inquiry into health IT developer actions, and, when necessary, make a certification ban and/or termination determination. We assumed that the work will be performed by a “Computer Systems Analyst.” According to the May 2017 BLS occupational employment statistics, the mean hourly wage for computer systems analyst is $44.59.
                        <SU>242</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 would be $89. Therefore, 
                        <PRTPAGE P="25935"/>
                        we estimate the average annual cost for health IT developers would range from $10,680 to $64,080. We note that some health IT developers' costs are expected to be less and some health IT developers' costs are expected to be more than this estimated cost range. Further, we note that these costs would be perpetual.
                    </P>
                    <FTNT>
                        <P>
                            <SU>242</SU>
                             
                            <E T="03">https://www.bls.gov/oes/2017/May/oes151121.htm.</E>
                        </P>
                    </FTNT>
                    <P>We estimate that ONC may commit, on average and depending on complexity, between eight and 80 hours of staff time to complete a review and inquiry into health IT developer actions. We assume that the expertise of a GS-15, Step 1 Federal employee(s) will be necessary. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $126. Therefore, based on the estimate of between 12 and 18 cases each year, we estimate ONC's annual costs would range, on average, from $12,096 to $181,440. We note that some reviews and inquiries may cost less and some may cost more than this estimated cost range. Further, we note that these costs would be perpetual.</P>
                    <P>We welcomed comments on our estimated costs and any comparable processes and costs that we could use to improve our estimates.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the relevant data and methods used to estimate the costs to: (1) ONC review and inquiry prior to the issuance of a notice of non-conformity; (2) ONC review and inquiry following the issuance of a notice of non-conformity and the health IT developer does not contest ONC's findings (
                        <E T="03">i.e.,</E>
                         no appeal); and (3) ONC review and inquiry following the issuance of a notice of non-conformity and the health IT developer contests ONC's findings (
                        <E T="03">i.e.,</E>
                         appeal).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain our approach used to estimate the costs to health IT developers and to ONC, related to ONC review and inquiry into health IT developer actions.
                    </P>
                    <HD SOURCE="HD3">(E) ONC Review and Inquiry Following the Issuance of a Notice of Non-Conformity and the Health IT Developer Contests ONC's Findings</HD>
                    <P>As discussed in section VII.C of this preamble, we permit a health IT developer to appeal an ONC determination to issue a certification ban and/or terminate a certification under § 170.580(a)(2)(iii). This category of cost calculations captures cases that require review and inquiry following ONC's issuance of a notice of non-conformity and where the health IT developer contests ONC's finding and files an appeal. We estimate that ONC will, on average, conduct between three and five of these reviews annually.</P>
                    <P>
                        We estimated that a “Computer Systems Analyst” for the health IT developer may commit, on average and depending on complexity, between 20 and 80 hours to provide the required information to appeal a certification ban and/or termination under § 170.580(a)(2)(iii) and respond to any requests from the hearing officer. According to the May 2017 BLS occupational employment statistics, the mean hourly wage for a computer systems analyst is $44.59.
                        <SU>243</SU>
                        <FTREF/>
                         Assuming that overhead costs (including benefits) are equal to 100 percent of pre-tax wages, the hourly wage including overhead costs is $89. Therefore, we estimate the annual cost, including overhead costs, for a health IT developer to appeal a certification ban and/or termination under § 170.580(a)(2)(iii) would, on average, range from $5,340 to $35,600. We note that some health IT developers' costs are expected to be less and some health IT developers' costs are expected to be more than this estimated cost range. Further, we note that these costs would be perpetual.
                    </P>
                    <FTNT>
                        <P>
                            <SU>243</SU>
                             
                            <E T="03">See https://www.bls.gov/oes/2017/May/oes151121.htm.</E>
                        </P>
                    </FTNT>
                    <P>We estimated that ONC would commit, on average and depending on complexity, between 40 and 160 hours of staff time to conduct each appeal. This will include the time to represent ONC in the appeal and support the costs for the hearing officer. We assume that the expertise of a GS-15, Step 1 Federal employee(s) would be necessary. The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $126. Therefore, based on the estimate of between three and five cases each year, we estimate the cost for ONC to conduct an appeal would range, on average, from $15,120 to $100,800. We note that some appeals may cost less and some may cost more than this estimated cost range. Further, we note that these costs would be perpetual.</P>
                    <P>Based on the above estimates, we estimated the total annual costs for health IT developers related to ONC review and inquiry into health IT developer actions would range, on average, from $16,020 to $99,680. We estimated the total annual costs for ONC related to ONC review and inquiry into health IT developer actions would range, on average, from $44,603 to $383,345.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments specific to the relevant data and methods used to estimate the costs of (1) ONC review and inquiry prior to the issuance of a notice of non-conformity; (2) ONC review and inquiry following the issuance of a notice of non-conformity and the health IT developer does not contest ONC's findings (
                        <E T="03">i.e.,</E>
                         no appeal); and (3) ONC review and inquiry following the issuance of a notice of non-conformity and the health IT developer contests ONC's findings (
                        <E T="03">i.e.,</E>
                         appeal).
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We maintain our approach used to estimate the costs to health IT developers and to ONC, related to ONC review and inquiry into health IT developer actions.
                    </P>
                    <HD SOURCE="HD3">(F) Costs for ONC-ACBs</HD>
                    <P>We also note that ONC-ACBs could realize costs associated with the new reporting requirement in the Principles of Proper Conduct in § 170.523(s) that they report, at a minimum, no later than a week after becoming aware of, any information that could inform whether ONC should exercise direct review under § 170.580(a). We estimate that, on average, it will take an ONC-ACB employee at the GS-13, Step 1 level approximately 30 minutes to prepare the report. The hourly wage with benefits for a GS-13, Step 1 employee located in Washington, DC is approximately $91. Since the collection must occur no less than weekly, we will assume it occurs, on average, 52 times per year. Therefore, given that there are currently three ONC-ACBs, we estimate the annual cost to ONC-ACBs to comply with the reporting requirement under § 170.523(s) would, on average, be $7,098. We did not receive comments regarding our calculations. We have finalized these estimates.</P>
                    <HD SOURCE="HD3">(ii) Benefits</HD>
                    <P>
                        This final rule's provisions for ONC direct review of the Conditions and Maintenance of Certification requirements would promote health IT developers' accountability for their actions and ensure that health IT developers' actions conform with the requirements of the Cures Act and Conditions and Maintenance of Certification requirements in §§ 170.400-406. Specifically, ONC's direct review of health IT developer actions will facilitate ONC's ability to require comprehensive corrective action by health IT developers to address non-conforming actions determined by ONC. If ONC ultimately implements a certification ban and/or terminates a certification(s), such action will serve to protect the integrity of the Program and users of health IT. While we do not have available means to quantify the benefits of ONC direct review of health IT developer actions, we note that ONC 
                        <PRTPAGE P="25936"/>
                        direct review supports and enables the National Coordinator to fulfill his responsibilities under the HITECH Act and Cures Act, instills public confidence in the Program, and protects public health and safety. We did not receive comments regarding our calculations. We have finalized these estimates. (5) Information Blocking
                    </P>
                    <HD SOURCE="HD3">(i) Costs</HD>
                    <P>We expect ONC to incur an annual cost for issuing educational resources related to the information blocking “reasonable and necessary” exceptions. We estimate that ONC issues educational resources each quarter, therefore, four per year. We assume that the educational resources would be provided by ONC staff with the expertise of a GS-15, Step 1 Federal employee(s). The hourly wage with benefits for a GS-15, Step 1 employee located in Washington, DC is approximately $126. We estimate it would take ONC staff between 200 and 400 hours to develop the guidance. Therefore, we estimate the annual cost to ONC would range, on average, from $100,800 to $201,600.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments regarding the specific costs associated with information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         We have adopted our estimates as proposed. We note that we did receive comments regarding “burden” on various stakeholder groups related to our information blocking proposals, and those comments are addressed throughout the information blocking section (section VIII) of this final rule.
                    </P>
                    <HD SOURCE="HD3">(ii) Benefits</HD>
                    <P>Information blocking not only interferes with effective health information exchange, but also negatively impacts many important aspects of health and health care. For a detailed discussion of the negative impacts of information blocking, we refer readers to section XIV.C.2.a(2) of the Proposed Rule (84 FR 7584).</P>
                    <P>The exceptions to the information blocking definition adopted in this final rule create clear guidelines for industry regarding pro-competitive and other beneficial activities and will enable stakeholders to determine more easily and with greater certainty whether their activities are excepted from the information blocking definition. Overall, the finalized exceptions are accommodating to legitimate industry practices for health IT developers, hospitals, and health care providers and, we believe, will ease the burden and compliance costs for these parties.</P>
                    <P>
                        To estimate the benefits of information blocking, we first examined existing data sources to identify a proxy that will indicate the extent to which information blocking is occurring. According to analysis of data from the American Hospital Association IT Supplement survey, 53 percent of non-Federal acute care hospitals reported that they had challenges with exchanging data across different vendor platforms.
                        <SU>244</SU>
                        <FTREF/>
                         Moreover, 31 percent reported that they must pay additional costs to exchange information with organizations outside of the system. Nearly one in four hospitals reported that they had to develop customized interfaces to electronically exchange information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>244</SU>
                             Pylypchuk Y., Johnson C., Henry J. &amp; Ciricean D. (November 2018). Variation in Interoperability among U.S. Non-Federal Acute Care Hospitals in 2017. ONC Data Brief, no.42. Office of the National Coordinator for Health Information Technology: Washington DC.
                        </P>
                    </FTNT>
                    <P>To quantify the magnitude of information blocking and the benefits of restricting information blocking, we estimated the following, which gives us the imposed cost of information blocking for each health outcome: [Percent of providers that engage in cross-vendor exchange] * [marginal effect (ME) of information blocking on interoperability] * [ME effect of interoperability on the health outcome] * [total cost of health outcome].</P>
                    <P>
                        We extracted the “ME effect of interoperability on the health outcome” and “cost of health outcomes” from academic literature (
                        <E T="03">see</E>
                         citations in Table 24). We then determined a proxy for the number of providers that engage in cross-vendor exchange. We did this by leveraging hospital referral data from 2015 to determine the proportion of hospitals that referred patients to a provider outside of their system where the receiving provider used a different EHR vendor. We determined that 82 percent of hospitals engaged in cross-vendor exchange. This estimate was used as the proxy for “providers that engaged in cross-vendor exchange.”
                    </P>
                    <P>We estimated the “ME of information blocking on interoperability” through the following research design:</P>
                    <FP SOURCE="FP-2">Y = b1InforBlock + X'B + e</FP>
                    <P>Where y = 1 if a hospital routinely engages in four domains of interoperability—sending, receiving, finding, and integrating data, 0 otherwise. The variable InforBlock is a binary indicator for whether a hospital reported experiencing challenges with exchanging data across different vendor platforms. We assume the impact of reporting this barrier is a proxy for the extent to which vendors hinder a hospital's interoperability. In the model, we control for the following: Hospital's primary vendor, participation in health exchange organization, participation in five different networks, system ownership, level of system centralization, bed size, profit status, public status, region, location in urban area. The marginal effect of b is 0.04. We assume that this effect may capture other reasons not related to information blocking, so we use half of this estimate for our benefit calculations—0.02.</P>
                    <GPOTABLE COLS="7" OPTS="L2,i1" CDEF="s100,r50,r50,12,12,12,12">
                        <TTITLE>Table 28—Benefits of Prohibiting and/or Deterring Information Blocking</TTITLE>
                        <TDESC>[2017 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Benefit type</CHED>
                            <CHED H="1">Total cost impacted</CHED>
                            <CHED H="1">Total cost</CHED>
                            <CHED H="1">
                                Overall interop impact
                                <LI>(marginal</LI>
                                <LI>effect)</LI>
                            </CHED>
                            <CHED H="1">
                                Percent of
                                <LI>providers</LI>
                                <LI>susceptible to</LI>
                                <LI>information</LI>
                                <LI>blocking</LI>
                            </CHED>
                            <CHED H="1">
                                Marginal effect of information blocking
                                <LI>(percentage points)</LI>
                            </CHED>
                            <CHED H="1">
                                Benefit
                                <LI>
                                    benefit 
                                    <E T="0731">A</E>
                                </LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Duplicate testing</ENT>
                            <ENT>100%</ENT>
                            <ENT>
                                200 billion 
                                <E T="0731">B</E>
                            </ENT>
                            <ENT>
                                <E T="0731">C</E>
                                 0.09
                            </ENT>
                            <ENT>82</ENT>
                            <ENT>0.02</ENT>
                            <ENT>$295,200,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Avoidable hospitalizations and readmissions</ENT>
                            <ENT>100%</ENT>
                            <ENT>
                                $41 billion 
                                <E T="0731">D</E>
                            </ENT>
                            <ENT>0.09</ENT>
                            <ENT>82</ENT>
                            <ENT>0.02</ENT>
                            <ENT>60,516,000</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">ER visits</ENT>
                            <ENT>
                                131 million visits 
                                <E T="0731">E</E>
                            </ENT>
                            <ENT>Cost per ER visit $1,233</ENT>
                            <ENT>0.03</ENT>
                            <ENT>82</ENT>
                            <ENT>0.02</ENT>
                            <ENT>79,469,316</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Adverse drug events</ENT>
                            <ENT>20%</ENT>
                            <ENT>
                                $30 billion 
                                <E T="0731">F</E>
                            </ENT>
                            <ENT>0.22</ENT>
                            <ENT>82</ENT>
                            <ENT>0.02</ENT>
                            <ENT>21,648,000</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25937"/>
                            <ENT I="03">Total benefit per year</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                            <ENT>$456,833,316 </ENT>
                        </ROW>
                        <TNOTE>
                            <SU>A</SU>
                             Total benefit would be a product of 
                            <E T="03">% of total cost impacted, total cost, overall interop impact, percent of providers susceptible to information blocking, and marginal effect of information blocking;</E>
                             however, no reasonable estimate of the marginal effect of information blocking is currently available.
                        </TNOTE>
                        <TNOTE>
                            <SU>B</SU>
                             National Academy of Medicine (2016), 
                            <E T="03">http://money.cnn.com/2017/05/20/news/economy/medical-tests/index.html.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>C</SU>
                             Stephen E. Ross, Tiffany A. Radcliff, William G. Leblanc, L. Miriam Dickinson, Anne M. Libby, and Donald E. Nease Jr., 
                            <E T="03">Effects of health information exchange adoption on ambulatory testing rates,</E>
                             J. Am. Med. Inform. Assoc. (2013), at 1137-1142; Bridget A. Stewart, Susan Fernandes, Elizabeth Rodriguez-Huertas, and Michael Landzberg, 
                            <E T="03">A preliminary look at duplicate testing associated with lack of electronic health record interoperability for transferred patients,</E>
                             J. of the Am. Med. Informatics Assoc. (2010), at 341-344; Sezgin Ayabakan, Indranil R. Bardhan, Zhiqiang (Eric) Zheng, and Kirk Kirksey 
                            <E T="03">Value of health information sharing in reducing healthcare waste: An analysis of duplicate testing across hospitals,</E>
                             MIS Quarterly (Jan. 1, 2017); Eric J. Lammers, Julia Adler-Milstein, and Keith E. Kocher, 
                            <E T="03">Does health information exchange reduce redundant imaging? Evidence from emergency departments,</E>
                             Med Care (Mar. 2014), at 227-34.
                        </TNOTE>
                        <TNOTE>
                            <SU>D</SU>
                             Agency for Healthcare Research and Quality (AHRQ) Statistical Brief #199 (Dec. 2015), 
                            <E T="03">https://www.hcup-us.ahrq.gov/reports/statbriefs/sb199-Readmissions-Payer-Age.pdf;</E>
                             AHRQ Statistical Brief #72, Nationwide Frequency and Costs of Potentially Preventable Hospitalizations (Apr. 2009), 
                            <E T="03">https://www.hcup-us.ahrq.gov/reports/statbriefs/sb72.pdf.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>E</SU>
                             National Center for Health Statistics (NCHS) Data Brief No. 252 (June 2016), 
                            <E T="03">https://www.cdc.gov/nchs/data/databriefs/db252.pdf;</E>
                             Nolan Caldwell, Tanja Srebotnjak, Tiffany Wang, and Renee Hsia, “How Much Will I Get Charged for This?” Patient Charges for Top Ten Diagnoses in the Emergency Department (2013), 
                            <E T="03">https://doi.org/10.1371/journal.pone.0055491.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>F</SU>
                             Janet Sultana, Paola Cutroneo, and Gianluca Trifirò, 
                            <E T="03">Clinical and economic burden of adverse drug reactions.</E>
                        </TNOTE>
                    </GPOTABLE>
                    <P>As a result of this calculation, we estimate that the benefit of the information blocking provision is $456 million.</P>
                    <P>
                        <E T="03">Comments.</E>
                         We did not receive any comments regarding our approach to estimating benefits or the specific benefit estimates associated with information blocking.
                    </P>
                    <P>
                        <E T="03">Response.</E>
                         ONC has revised its methodological approach to quantifying the benefits of our information blocking provision. This new methodology is described in the RIA.
                    </P>
                    <HD SOURCE="HD3">(6) Total Annual Cost Estimate</HD>
                    <P>
                        The total annual cost estimate is expressed in 2016 dollars to meet regulatory reform analysis requirements under Executive Order 13771. We estimated that the total cost for this final rule for the first year after it is finalized (including one-time costs), based on the cost estimates outlined above and throughout this RIA, would range, on average, from $953 million to $2.6 billion with an average annual cost of $1.8 billion. We estimated that the total perpetual cost for this final rule (starting in year two), based on the cost estimates outlined above, would range, on average, from $366 million to $1.3 billion with an average annual cost of $840 million. We also included estimates based on the stakeholder groups affected. We estimated the total costs to health IT developers to be between $483 million and $1.1 billion (including one-time and perpetual costs) with $633,000 in cost savings from deregulatory actions. Assuming that 458 health IT developers will be impacted, the cost per developer will range from $1.1 million to $2.4 million. Based on previous participation in the CMS EHR Incentive Program, we estimated that 439,187 health care providers in 95,470 clinical practices and 4,519 hospitals that participated in the CMS EHR Incentive Program will be impacted by this final rule. We estimated the total cost to health care providers to be between $478 million to $1.6 billion. We did not calculate per entity costs for health care providers. We acknowledged that costs may be passed from health IT developers to their customers (
                        <E T="03">i.e.</E>
                         health care providers) during the licensing of their health IT modules. We estimated the total costs to ONC-ACBs to be between $391,000 and $792,000. We estimated the government costs (through labor hours of ONC staff) to be between $159,000 and $586,000 with $4,497 in cost savings from deregulatory actions. In addition to the above-mentioned cost savings that are attributable to specific stakeholder groups, we estimated an additional cost savings of $6.6 million to $13.3 million to all stakeholders affected by this provision. We are unable to attribute these amounts to specific stakeholder groups. We did not receive comment regarding these calculations. We have finalized our estimates.
                    </P>
                    <HD SOURCE="HD3">(7) Total Annual Benefit Estimate</HD>
                    <P>The total annual benefit estimate is expressed in 2016 dollars to meet regulatory reform analysis requirements under Executive Order 13771. We estimated the total annual benefit for this final rule, based on the benefit estimates outlined above, would range from $1.2 billion to $5.0 billion with primary estimated annual benefit of $3.1 billion. Our estimates include benefits attributed to the entire health care system, including hospitals, clinicians, payers and patients.(8) Total Annualized Net Benefit</P>
                    <P>The total annualized net benefit is expressed in 2016 dollars to meet regulatory reform analysis requirements under Executive Order 13771. We estimate the total annualized net benefit for this final rule, based on the estimates outlined above, would range from $191 million to $2.3 billion with a primary net benefit estimate of $1.3 billion.</P>
                    <HD SOURCE="HD3">b. Accounting Statement and Table</HD>
                    <P>
                        When a rule is considered an economically significant rule under Executive Order 12866, we are required to develop an accounting statement indicating the classification of the expenditures associated with the provisions of the proposed rule. Monetary annual benefits are presented as discounted flows using three percent and seven percent factors in Table 29. We are not able to explicitly define the universe of all costs, but have provided an average of likely costs of this final rule as well as a high and low range of likely costs. Unquantifiable costs and benefits are noted in Table 31. This final rule requires no Federal transfers, but it might bring about a reduction in fraudulent payments to providers by the 
                        <PRTPAGE P="25938"/>
                        Federal Government and other payers.
                        <SU>245</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>245</SU>
                             Parente, Stephen T., Karen Mandelbaum, Susan P. Hanson, Bonnie S. Cassidy and Donald W. Simborg. “Crime and Punishment: Can the NHIN Reduce the Cost of Healthcare Fraud?” 
                            <E T="03">Journal of Healthcare Information Management</E>
                             22(3): 42-51. June 2008.
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="7" OPTS="L2,i1" CDEF="s100,12,12,12,12,12,12">
                        <TTITLE>Table 29—EO 12866 Summary Table</TTITLE>
                        <TDESC>[In $ millions, 2016 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">
                                Primary
                                <LI>(3%)</LI>
                            </CHED>
                            <CHED H="1">
                                Lower bound
                                <LI>(3%)</LI>
                            </CHED>
                            <CHED H="1">
                                Upper bound
                                <LI>(3%)</LI>
                            </CHED>
                            <CHED H="1">
                                Primary
                                <LI>(7%)</LI>
                            </CHED>
                            <CHED H="1">
                                Lower bound
                                <LI>(7%)</LI>
                            </CHED>
                            <CHED H="1">
                                Upper bound
                                <LI>(7%)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Present Value of Quantified Costs</ENT>
                            <ENT>6,454</ENT>
                            <ENT>2,966</ENT>
                            <ENT>9,943</ENT>
                            <ENT>4,574</ENT>
                            <ENT>2,120</ENT>
                            <ENT>7,028</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Present Value of Quantified Benefits</ENT>
                            <ENT>23,411</ENT>
                            <ENT>8,831</ENT>
                            <ENT>37,991</ENT>
                            <ENT>16,552</ENT>
                            <ENT>6,244</ENT>
                            <ENT>26,859</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Present Value of Net Benefits</ENT>
                            <ENT>16,957</ENT>
                            <ENT>5,865</ENT>
                            <ENT>28,049</ENT>
                            <ENT>16,552</ENT>
                            <ENT>4,124</ENT>
                            <ENT>19,832</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annualized Quantified Costs</ENT>
                            <ENT>852</ENT>
                            <ENT>391</ENT>
                            <ENT>1,312</ENT>
                            <ENT>854</ENT>
                            <ENT>396</ENT>
                            <ENT>1,312</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annualized Quantified Benefits</ENT>
                            <ENT>3,089</ENT>
                            <ENT>1,165</ENT>
                            <ENT>5,013</ENT>
                            <ENT>2,184</ENT>
                            <ENT>824</ENT>
                            <ENT>3,544</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annualized Net Quantified Benefits</ENT>
                            <ENT>2,237</ENT>
                            <ENT>774</ENT>
                            <ENT>3,701</ENT>
                            <ENT>1,330</ENT>
                            <ENT>428</ENT>
                            <ENT>2,232</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="6" OPTS="L2,i1" CDEF="s100,12,12,12,12,12">
                        <TTITLE>Table 30—E.O. 12866 Summary Table Non-Discounted Flows</TTITLE>
                        <TDESC>[2016 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">Year 1</CHED>
                            <CHED H="1">Year 2</CHED>
                            <CHED H="1">Year 3</CHED>
                            <CHED H="1">Year 4</CHED>
                            <CHED H="1">Year 5</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Costs</ENT>
                            <ENT>942,795,801</ENT>
                            <ENT>839,887,346</ENT>
                            <ENT>839,887,346</ENT>
                            <ENT>839,887,346</ENT>
                            <ENT>839,887,346</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Benefits</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="22"> </ENT>
                            <ENT O="oi0">Year 6</ENT>
                            <ENT O="oi0">Year 7</ENT>
                            <ENT O="oi0">Year 8</ENT>
                            <ENT O="oi0">Year 9</ENT>
                            <ENT O="oi0">Year 10</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Costs</ENT>
                            <ENT>839,887,346</ENT>
                            <ENT>839,887,346</ENT>
                            <ENT>839,887,346</ENT>
                            <ENT>839,887,346</ENT>
                            <ENT>839,887,346</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Benefits</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                            <ENT>3,088,980,583</ENT>
                        </ROW>
                    </GPOTABLE>
                    <GPOTABLE COLS="5" OPTS="L2,i1" CDEF="s100,12,12,12,12">
                        <TTITLE>Table 31—Non-Quantifiable Benefits</TTITLE>
                        <TDESC>[2016 Dollars]</TDESC>
                        <BOXHD>
                            <CHED H="1">Benefits</CHED>
                            <CHED H="1">
                                Present value of 10 years by discount rate
                                <LI>(in millions)</LI>
                            </CHED>
                            <CHED H="2">3 Percent</CHED>
                            <CHED H="2">7 Percent</CHED>
                            <CHED H="1">
                                Annualized value over 10 years by discount rate
                                <LI>(in millions)</LI>
                            </CHED>
                            <CHED H="2">3 Percent</CHED>
                            <CHED H="2">7 Percent</CHED>
                        </BOXHD>
                        <ROW RUL="s">
                            <ENT I="01">Quantified Benefits</ENT>
                            <ENT>23,411</ENT>
                            <ENT>16,552</ENT>
                            <ENT>3,089</ENT>
                            <ENT>2,184</ENT>
                        </ROW>
                        <ROW EXPSTB="04">
                            <ENT I="22">
                                <E T="03">Non-quantified Benefits:</E>
                            </ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="03">Impact on users of health IT that were ineligible or did not participate in the CMS EHR Incentive Programs; developer cost savings from no longer supporting the 2014 Edition; provider and patient benefit from implementation of USCDI and Security tags (DS4P) provisions due to improvements in interoperability; benefits associated with communication provision because we do not have adequate information to determine the prevalence of gag clauses and other such restrictive practices nor do we have a means to quantify the value to providers of being able to freely communicate and share information; benefit of ONC oversight on real world testing and non-conformance; external regulatory and policy activities.</ENT>
                        </ROW>
                        <ROW EXPSTB="00" RUL="s">
                            <ENT I="21">Costs</ENT>
                            <ENT O="oi0">3 Percent</ENT>
                            <ENT O="oi0">7 Percent</ENT>
                            <ENT O="oi0">3 Percent</ENT>
                            <ENT O="oi0">7 Percent</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Quantified Costs</ENT>
                            <ENT>6,454</ENT>
                            <ENT>4,574</ENT>
                            <ENT>852</ENT>
                            <ENT>396</ENT>
                        </ROW>
                        <ROW EXPSTB="04">
                            <ENT I="22">
                                <E T="03">Non-quantified Costs:</E>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Impact of provisions on health IT production costs such as the supply and demand for personnel over time; costs developers to correct non-conformities; ONC cost to review non-conformities, real-world testing maintenance by ACBs; additional provider implementation activities related to USCDI and DS4P; external regulatory and policy activities.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">3. 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>246</SU>
                        <FTREF/>
                         The entities that are likely to be directly affected by the requirements in this final rule are health IT developers. We note that the reasonable and necessary activities that do not constitute information blocking 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. These reasonable and necessary activities also take into account the potential burden on small entities to 
                        <PRTPAGE P="25939"/>
                        meet these “exceptions” to information blocking, such as with considering the size and resources of small entities when meeting security requirements to qualify for the “promoting the security of electronic health information” exception.
                    </P>
                    <FTNT>
                        <P>
                            <SU>246</SU>
                             The SBA references that annual receipts means “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>
                        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 in this final rule most likely fall under the North American Industry Classification System (NAICS) code 541511 “Custom Computer Programming Services.” 
                        <SU>247</SU>
                        <FTREF/>
                         The SBA size standard associated with this NAICS code is set at $27.5 million annual receipts or less. There is enough data generally available to establish that between 75 percent and 90 percent 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 percent of health IT developers that have had Complete EHRs and/or Health IT Modules certified to the 2011 Edition had less than 51 employees (80 FR 62741).
                    </P>
                    <FTNT>
                        <P>
                            <SU>247</SU>
                             
                            <E T="03">https://www.sba.gov/sites/default/files/files/Size_Standards_Table_2017.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        We estimated that the requirements in this final rule will have effects on health IT developers, some of which may be small entities, that have certified health IT or are likely to pursue certification of their health IT under the Program. We believe, however, that we have finalized the minimum amount of requirements necessary to accomplish our primary policy goal of enhancing interoperability. Further, as discussed in section XIII.B of this RIA above, there are no appropriate regulatory or non-regulatory alternatives that could be developed to lessen the compliance burden associated with this final rule because many of the provisions are derived directly from legislative mandates in the Cures Act. Additionally, we have attempted to offset some of the burden imposed on health IT developers in this final rule with cost saving provisions through deregulatory actions (
                        <E T="03">see</E>
                         section III). Additionally, the Secretary certifies that this final rule will not have a significant impact on a substantial number of small entities.
                    </P>
                    <HD SOURCE="HD3">4. Executive Order 13132—Federalism</HD>
                    <P>Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a final rule that imposes substantial direct requirement costs on State and local governments, preempts State law, or otherwise has federalism implications. Nothing in this final rule imposes substantial direct compliance costs on State and local governments, preempts State law, or otherwise has federalism implications. We are not aware of any State laws or regulations that are contradicted or impeded by any of the provisions in this final rule.</P>
                    <HD SOURCE="HD3">5. 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 $150 million. While the estimated potential cost effects of this final rule reach the statutory threshold, we do not believe this final rule imposes unfunded mandates on State, local, and tribal governments or the private sector.</P>
                    <P>OMB reviewed this final rule.</P>
                    <LSTSUB>
                        <HD SOURCE="HED">List of Subjects</HD>
                        <CFR>45 CFR Part 170</CFR>
                        <P>Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Health care, Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Reporting and recordkeeping requirements, Public health, Security.</P>
                        <CFR>45 CFR Part 171</CFR>
                        <P>Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Health care, Health care provider, Health information exchange, Health information technology, Health information network, Health insurance, Health records, Hospitals, Privacy, Reporting and recordkeeping requirements, Public health, Security.</P>
                    </LSTSUB>
                    <P>For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, is amended as follows:</P>
                    <PART>
                        <HD SOURCE="HED">PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY</HD>
                    </PART>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>1. The authority citation for part 170 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 553</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>2. Revise § 170.101 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.101 </SECTNO>
                            <SUBJECT>Applicability.</SUBJECT>
                            <P>The standards, implementation specifications, and certification criteria adopted in this part apply to Health IT Modules and the testing and certification of such Health IT Modules.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>3. Amend § 170.102 by:</AMDPAR>
                        <AMDPAR>a. Removing the definitions of “2014 Edition Base EHR” and “2014 Edition EHR certification criteria”;</AMDPAR>
                        <AMDPAR>b. Revising paragraph (3) in the definition of “2015 Edition Base EHR”;</AMDPAR>
                        <AMDPAR>c. Revising the definition of “Common Clinical Data Set”;</AMDPAR>
                        <AMDPAR>d. Removing the definition of “Complete EHR, 2014 Edition”; and</AMDPAR>
                        <AMDPAR>e. Adding in alphabetical order definitions for “Electronic Health Information”, “Fee”, “Health information technology”, “Interoperability”, and “Interoperability element”.</AMDPAR>
                        <P>The revisions and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.102 </SECTNO>
                            <SUBJECT>Definitions.</SUBJECT>
                            <STARS/>
                            <P>
                                <E T="03">2015 Edition Base EHR</E>
                                 * * *
                            </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), (a)(9), (a)(14), (b)(1), (c)(1), (g)(7) and (9), and (h)(1) or (2);</P>
                            <P>(ii) Section 170.315(g)(8) or (10) until May 2, 2022; and</P>
                            <P>(iii) Section 170.315(g)(10) on and after May 2, 2022.</P>
                            <STARS/>
                            <P>
                                <E T="03">Common Clinical Data Set</E>
                                 means the following data expressed, where indicated, according to the specified standard(s):
                            </P>
                            <P>(1) Patient name.</P>
                            <P>
                                (2) 
                                <E T="03">Sex:</E>
                                 The standard specified in § 170.207(n)(1).
                            </P>
                            <P>
                                (3) Date of birth.
                                <PRTPAGE P="25940"/>
                            </P>
                            <P>
                                (4) 
                                <E T="03">Race:</E>
                            </P>
                            <P>(i) The standard specified in § 170.207(f)(2); and</P>
                            <P>(ii) The standard specified in § 170.207(f)(1) for each race identified in accordance § 170.207(f)(2).</P>
                            <P>
                                (5) 
                                <E T="03">Ethnicity:</E>
                            </P>
                            <P>(i) The standard specified in § 170.207(f)(2); and</P>
                            <P>(ii) The standard specified in § 170.207(f)(1) for each ethnicity identified in accordance § 170.207(f)(2).</P>
                            <P>
                                (6) 
                                <E T="03">Preferred language:</E>
                                 The standard specified in § 170.207(g)(2).
                            </P>
                            <P>(7) Smoking status.</P>
                            <P>
                                (8) 
                                <E T="03">Problems:</E>
                                 At a minimum, the standard specified in § 170.207(a)(4).
                            </P>
                            <P>
                                (9) 
                                <E T="03">Medications:</E>
                                 At a minimum, the standard specified in § 170.207(d)(3).
                            </P>
                            <P>
                                (10) 
                                <E T="03">Medication allergies:</E>
                                 At a minimum, the standard specified in § 170.207(d)(3).
                            </P>
                            <P>
                                (11) 
                                <E T="03">Laboratory test(s):</E>
                                 At a minimum, the standard specified in § 170.207(c)(3).
                            </P>
                            <P>(12) Laboratory value(s)/result(s).</P>
                            <P>
                                (13) 
                                <E T="03">Vital signs:</E>
                            </P>
                            <P>(i) The patient's diastolic blood pressure, systolic blood pressure, body height, body weight, heart rate, respiratory rate, body temperature, pulse oximetry, and inhaled oxygen concentration must be exchanged in numerical values only; and</P>
                            <P>(ii) In accordance with the standard specified in § 170.207(c)(3) and with the associated applicable unit of measure for the vital sign measurement in the standard specified in § 170.207(m)(1).</P>
                            <P>
                                (iii) 
                                <E T="03">Optional:</E>
                                 The patient's BMI percentile per age and sex for youth 2-20 years of age, weight for age per length and sex for children less than 3 years of age, and head occipital-frontal circumference for children less than 3 years of age must be recorded in numerical values only in accordance with the standard specified in § 170.207(c)(3) and with the associated applicable unit of measure for the vital sign measurement in the standard specified in § 170.207(m)(1). For BMI percentile per age and sex for youth 2-20 years of age and weight for age per length and sex for children less than 3 years of age, the reference range/scale or growth curve should be included as appropriate.
                            </P>
                            <P>
                                (14) 
                                <E T="03">Procedures:</E>
                            </P>
                            <P>(i) At a minimum, the version of the standard specified in § 170.207(a)(4) or § 170.207(b)(2); or</P>
                            <P>(ii) For technology primarily developed to record dental procedures, the standard specified in § 170.207(b)(3).</P>
                            <P>
                                (iii) 
                                <E T="03">Optional:</E>
                                 The standard specified in § 170.207(b)(4).
                            </P>
                            <P>(15) Care team member(s).</P>
                            <P>
                                (16) 
                                <E T="03">Immunizations:</E>
                                 In accordance with, at a minimum, the standards specified in § 170.207(e)(3) and (4).
                            </P>
                            <P>(17) Unique device identifier(s) for a patient's implantable device(s): In accordance with the “Product Instance” in the “Procedure Activity Procedure Section” of the standard specified in § 170.205(a)(4).</P>
                            <P>
                                (18) 
                                <E T="03">Assessment and plan of treatment:</E>
                            </P>
                            <P>(i) In accordance with the “Assessment and Plan Section (V2)” of the standard specified in § 170.205(a)(4); or</P>
                            <P>(ii) In accordance with the “Assessment Section (V2)” and “Plan of Treatment Section (V2)” of the standard specified in § 170.205(a)(4).</P>
                            <P>
                                (19) 
                                <E T="03">Goals:</E>
                                 In accordance with the “Goals Section” of the standard specified in § 170.205(a)(4).
                            </P>
                            <P>
                                (20) 
                                <E T="03">Health concerns:</E>
                                 In accordance with the “Health Concerns Section” of the standard specified in § 170.205(a)(4).
                            </P>
                            <STARS/>
                            <P>
                                <E T="03">Electronic health information</E>
                                 (EHI) is defined as it is in § 171.102.
                            </P>
                            <P>
                                <E T="03">Fee</E>
                                 is defined as it is in § 171.102 of this subchapter.
                            </P>
                            <STARS/>
                            <P>
                                <E T="03">Health information technology</E>
                                 means hardware, software, integrated technologies or related licenses, IP, 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>
                            <STARS/>
                            <P>
                                <E T="03">Interoperability</E>
                                 is, with respect to health information technology, such health information technology that—
                            </P>
                            <P>(1) Enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user;</P>
                            <P>(2) Allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law; and</P>
                            <P>(3) Does not constitute information blocking as defined in § 171.103 of this subchapter.</P>
                            <P>
                                <E T="03">Interoperability element</E>
                                 is defined as it is in § 171.102 of this subchapter.
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.200 </SECTNO>
                        <SUBJECT>[Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>4. Amend § 170.200 by removing the phrase “Complete EHRs and”.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.202</SECTNO>
                        <SUBJECT> [Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>5. Amend § 170.202 by removing and reserving paragraph (a)(1).</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.204</SECTNO>
                        <SUBJECT> [Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>6. Amend § 170.204 by removing and reserving paragraphs (b)(1) and (2) and removing paragraph (c).</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>7. Amend § 170.205 by:</AMDPAR>
                        <AMDPAR>a. Removing and reserving paragraphs (a)(1) and (2);</AMDPAR>
                        <AMDPAR>b. Adding paragraphs (a)(5) and (b)(1);</AMDPAR>
                        <AMDPAR>c. Removing and reserving paragraphs (d)(3), (e)(3), and (h)(1);</AMDPAR>
                        <AMDPAR>d. Adding paragraph (h)(3);</AMDPAR>
                        <AMDPAR>e. Removing and reserving paragraphs (i)(1) and (j); and</AMDPAR>
                        <AMDPAR>f. Adding paragraph (k)(3).</AMDPAR>
                        <P>The additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.205 </SECTNO>
                            <SUBJECT>Content exchange standards and implementation specifications for exchanging electronic health information.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>
                                (5) 
                                <E T="03">Standard.</E>
                                 HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 (incorporated by reference in § 170.299).
                            </P>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Standard.</E>
                                 National Council for Prescription Drug Programs (NCPDP): SCRIPT Standard Implementation Guide; Version 2017071 (incorporated by reference in § 170.299).
                            </P>
                            <STARS/>
                            <P>(h) * * *</P>
                            <P>
                                (3) 
                                <E T="03">Standard.</E>
                                 CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting; Implementation Guide for 2019 (incorporated by reference in § 170.299).
                            </P>
                            <STARS/>
                            <P>(k) * * *</P>
                            <P>
                                (3) 
                                <E T="03">Standard.</E>
                                 CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2019 (incorporated by reference in § 170.299).
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.207 </SECTNO>
                        <SUBJECT>[Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>8. Amend § 170.207 by removing and reserving paragraphs (d)(2), (e)(2), (g)(1), (h), and (j).</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.210</SECTNO>
                        <SUBJECT> [Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>9. Amend § 170.210:</AMDPAR>
                        <AMDPAR>a. By removing and reserving paragraphs (a)(1) and (c)(1);</AMDPAR>
                        <AMDPAR>b. In paragraph (e)(1)(i), by removing the words “7.2 through 7.4, 7.6, and 7.7” and adding in their place “7.1.1 through 7.1.3 and 7.1.6 through 7.1.9”; and</AMDPAR>
                        <AMDPAR>c. In paragraph (h), by removing the words “ASTM E2147-01 (Reapproved 2013)” and adding in their place “ASTM E2147-18”.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <PRTPAGE P="25941"/>
                        <AMDPAR>10. Add § 170.213 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.213 </SECTNO>
                            <SUBJECT>United States Core Data for Interoperability</SUBJECT>
                            <P>
                                <E T="03">Standard.</E>
                                 United States Core Data for Interoperability (USCDI), Version 1 (v1) (incorporated by reference in § 170.299).
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>11. Add § 170.215 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.215</SECTNO>
                            <SUBJECT> Application Programming Interface Standards.</SUBJECT>
                            <P>The Secretary adopts the following application programming interface (API) standards and associated implementation specifications:</P>
                            <P>
                                (a)(1) 
                                <E T="03">Standard.</E>
                                 HL7® Fast Healthcare Interoperability Resources (FHIR ®) Release 4.0.1 (incorporated by reference in §  170.299).
                            </P>
                            <P>
                                (2) 
                                <E T="03">Implementation specification.</E>
                                 HL7 FHIR US Core Implementation Guide STU 3.1.0. (incorporated by reference in §  170.299).
                            </P>
                            <P>
                                (3) 
                                <E T="03">Implementation specification.</E>
                                 HL7 SMART Application Launch Framework Implementation Guide Release 1.0.0, including mandatory support for the “SMART Core Capabilities” (incorporated by reference in § 170.299).
                            </P>
                            <P>
                                (4) 
                                <E T="03">Implementation specification.</E>
                                 FHIR Bulk Data Access (Flat FHIR) (v1.0.0: STU 1), including mandatory support for the “group-export” “OperationDefinition” (incorporated by reference in § 170.299).
                            </P>
                            <P>
                                (b) 
                                <E T="03">Standard.</E>
                                 OpenID Connect Core 1.0, incorporating errata set 1 (incorporated by reference in §  170.299). 
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>12. Amend § 170.299 by:</AMDPAR>
                        <AMDPAR>a. Revising paragraph (c)(1);</AMDPAR>
                        <AMDPAR>b. Removing and reserving paragraphs (c)(2) and (3) and (d)(2), (7), and (8);</AMDPAR>
                        <AMDPAR>c. Adding paragraphs (e)(4) and (5);</AMDPAR>
                        <AMDPAR>d. Removing and reserving paragraphs (f)(3), (6), (7), (10), and (11);</AMDPAR>
                        <AMDPAR>e. Adding paragraphs (f)(30) through (34);</AMDPAR>
                        <AMDPAR>f. Removing and reserving paragraphs (h)(1) and (j)(1);</AMDPAR>
                        <AMDPAR>g. Adding paragraph (k)(3);</AMDPAR>
                        <AMDPAR>h. Removing and reserving paragraph (l)(3);</AMDPAR>
                        <AMDPAR>i. Adding paragraph (m)(5);</AMDPAR>
                        <AMDPAR>j. Redesignating paragraphs (n) through (r) as paragraphs (o) through (s), respectively;</AMDPAR>
                        <AMDPAR>k. Adding new paragraph (n); and</AMDPAR>
                        <AMDPAR>l. Removing and reserving newly redesignated paragraphs (r)(4) and (5).</AMDPAR>
                        <P>The revision and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.299 </SECTNO>
                            <SUBJECT>Incorporation by reference.</SUBJECT>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>(1) ASTM E2147-18 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems, approved May 1, 2018, IBR approved for § 170.210(h).</P>
                            <STARS/>
                            <P>(e) * * *</P>
                            <P>(4) CMS Implementation Guide for Quality Reporting Document Architecture Category I Hospital Quality Reporting Implementation Guide for 2019; published May 4, 2018, IBR approved for § 170.205(h).</P>
                            <P>(5) CMS Implementation Guide for Quality Reporting Document Architecture Category III Eligible Clinicians and Eligible Professionals Programs Implementation Guide for 2019; published October 8, 2018, IBR approved for § 170.205(k).</P>
                            <P>(f) * * *</P>
                            <P>(30) HL7® CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2-US Realm, October 2019, IBR approved for § 170.205(a).</P>
                            <P>(31) HL7 FHIR® Bulk Data Access (Flat FHIR®) (v1.0.0: STU 1), August 22, 2019, IBR approved for § 170.215(a).</P>
                            <P>(32) HL7 FHIR SMART Application Launch Framework Implementation Guide Release 1.0.0, November 13, 2018, IBR approved for § 170.215(a).</P>
                            <P>(33) HL7 Fast Healthcare Interoperability Resources Specification (FHIR®) Release 4, Version 4.0.1: R4, October 30, 2019, including Technical Correction #1, November 1, 2019, IBR approved for § 170.215(a).</P>
                            <P>(34) HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.0, November 06, 2019, IBR approved for § 170.215(a).</P>
                            <STARS/>
                            <P>(k) * * *</P>
                            <P>(3) SCRIPT Standard, Implementation Guide, Version 2017071 (Approval Date for ANSI: July 28, 2017), IBR approved for § 170.205(b).</P>
                            <STARS/>
                            <P>(m) * * *</P>
                            <P>
                                (5) United States Core Data for Interoperability (USCDI), Version 1, February 2020, IBR approved for § 170.213; available at 
                                <E T="03">https://www.healthit.gov/USCDI</E>
                                .
                            </P>
                            <STARS/>
                            <P>
                                (n) OpenID Foundation, 2400 Camino Ramon, Suite 375, San Ramon, CA 94583, Telephone +1 925-275-6639, 
                                <E T="03">http://openid.net/</E>
                                .
                            </P>
                            <P>(1) OpenID Connect Core 1.0 Incorporating errata set 1, November 8, 2014, IBR approved for § 170.215(b).</P>
                            <P>(2) [Reserved]</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.300</SECTNO>
                        <SUBJECT> [Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>13. Amend § 170.300 in paragraphs (a) and (c) by removing the phrase “Complete EHRs and”.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.314</SECTNO>
                        <SUBJECT> [Removed and Reserved] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>14. Remove and reserve § 170.314.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>15. Amend § 170.315:</AMDPAR>
                        <AMDPAR>a. By removing and reserving paragraphs (a)(6) through (8);</AMDPAR>
                        <AMDPAR>
                            b. In paragraph (a)(9)(ii)(B)(
                            <E T="03">1</E>
                            )(
                            <E T="03">iii</E>
                            ) by removing “medication allergy” and adding in its place “allergy and intolerance”;
                        </AMDPAR>
                        <AMDPAR>
                            c. In paragraph (a)(9)(ii)(B)(
                            <E T="03">2</E>
                            ) by removing “medication allergies” and adding in its place “allergies and intolerance”;
                        </AMDPAR>
                        <AMDPAR>d. By removing and reserving paragraph (a)(11);</AMDPAR>
                        <AMDPAR>
                            e. In paragraphs (b)(1)(ii)(A) introductory text, (b)(1)(ii)(A)(
                            <E T="03">2</E>
                            ) and (
                            <E T="03">3</E>
                            ), (b)(1)(ii)(B), and (b)(1)(ii)(C) introductory text, by removing the reference “§ 170.205(a)(3) and § 170.205(a)(4)” and adding in its place the reference “§ 170.205(a)(3), (4), and (5)”;
                        </AMDPAR>
                        <AMDPAR>f. In paragraph (b)(1)(iii) introductory text, by removing the reference “§ 170.205(a)(4)” and adding in its place the reference “§ 170.205(a)(3), (4), and (5)”;</AMDPAR>
                        <AMDPAR>g. By revising paragraphs (b)(1)(iii)(A) and (b)(2) and (3);</AMDPAR>
                        <AMDPAR>h. By removing and reserving paragraphs (b)(4) and (5);</AMDPAR>
                        <AMDPAR>i. By revising paragraphs (b)(7) through (9);</AMDPAR>
                        <AMDPAR>j. By adding paragraph (b)(10);</AMDPAR>
                        <AMDPAR>k. By revising paragraph (c)(3);</AMDPAR>
                        <AMDPAR>l. By adding paragraphs (d)(12) and (13);</AMDPAR>
                        <AMDPAR>
                            m. By revising paragraphs (e)(1)(i)(A)(
                            <E T="03">1</E>
                            ) through (
                            <E T="03">5</E>
                            );
                        </AMDPAR>
                        <AMDPAR>
                            n. By adding paragraphs (e)(1)(i)(A)(
                            <E T="03">6</E>
                            ) and (
                            <E T="03">7</E>
                            )
                        </AMDPAR>
                        <AMDPAR>
                            o. In paragraph (e)(1)(i)(B)(
                            <E T="03">1</E>
                            )(
                            <E T="03">ii</E>
                            ) and (e)(1)(i)(B)(
                            <E T="03">2</E>
                            ) introductory text, by removing the reference “§ 170.205(a)(4)” and adding in its place the reference “§ 170.205(a)(4) and (5)”;
                        </AMDPAR>
                        <AMDPAR>p. By removing and reserving paragraph (e)(1)(ii)(B);</AMDPAR>
                        <AMDPAR>
                            q. By revising paragraphs (f)(5)(iii)(B)(
                            <E T="03">1</E>
                            ) through (
                            <E T="03">4</E>
                            ),
                        </AMDPAR>
                        <AMDPAR>
                            r. By adding paragraph (f)(5)(iii)(B)(
                            <E T="03">5</E>
                            );
                        </AMDPAR>
                        <AMDPAR>s. By revising paragraphs (g)(1) and (2), (g)(3)(i), and (g)(6)</AMDPAR>
                        <AMDPAR>
                            t. By removing paragraphs (g)(7)(ii)(A)(
                            <E T="03">3</E>
                            ) and (g)(8)(ii)(A)(
                            <E T="03">3</E>
                            );
                        </AMDPAR>
                        <AMDPAR>u. By revising paragraph (g)(9)(i)(A);</AMDPAR>
                        <AMDPAR>
                            v. By removing paragraph (g)(9)(ii)(A)(
                            <E T="03">3</E>
                            ); and
                        </AMDPAR>
                        <AMDPAR>w. By adding paragraph (g)(10).</AMDPAR>
                        <P>The revisions and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.315 2015</SECTNO>
                            <SUBJECT> Edition health IT certification criteria.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>
                                (1) * * *
                                <PRTPAGE P="25942"/>
                            </P>
                            <P>(iii) * * *</P>
                            <P>
                                (A)(
                                <E T="03">1</E>
                                ) The data classes expressed in the standard in § 170.213 and in accordance with § 170.205(a)(4), (5), and paragraphs (b)(1)(iii)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iii</E>
                                ) of this section, or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The Common Clinical Data Set in accordance with § 170.205(a)(4) and paragraph (b)(1)(iii)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iv</E>
                                ) of this section for the period until May 2, 2022, 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>
                                (2) 
                                <E T="03">Clinical information reconciliation and incorporation</E>
                                —(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 on and after May 2, 2022.
                            </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), 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 standard(s) on and after May 2, 2022:</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.
                            </P>
                            <P>
                                (iv) 
                                <E T="03">System verification.</E>
                                 Based on the data reconciled and incorporated, the technology must be able to create a file formatted according to the standard specified in § 170.205(a)(4) using the Continuity of Care Document template and the standard specified in § 170.205(a)(5) on and after May 2, 2022.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Electronic prescribing.</E>
                                 (i) For technology certified prior to May 2, 2022, subject to the real world testing provisions at § 170.405(b)(5),
                            </P>
                            <P>(A) Enable a user to perform the following prescription-related electronic transactions in accordance with, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Create new prescriptions (NEWRX).
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Change prescriptions (RXCHG, CHGRES).
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) Cancel prescriptions (CANRX, CANRES).
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) Refill prescriptions (REFREQ, REFRES).
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) Receive fill status notifications (RXFILL).
                            </P>
                            <P>
                                (
                                <E T="03">6</E>
                                ) Request and receive medication history information (RXHREQ, RXHRES).
                            </P>
                            <P>(B) For each transaction listed in paragraph (b)(3)(i)(A) of this section, the technology must be able to receive and transmit the reason for the prescription using the diagnosis elements in the DRU Segment.</P>
                            <P>
                                (C) 
                                <E T="03">Optional:</E>
                                 For each transaction listed in paragraph (b)(3)(i)(A) of this section, the technology must be able to receive and transmit the reason for prescription using the indication elements in the SIG Segment.
                            </P>
                            <P>
                                (D) 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>(E) 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>(ii) For technology certified subsequent to June 30, 2020:</P>
                            <P>(A) Enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Create 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>
                                ) Request and receive medication history (RxHistoryRequest, RxHistoryResponse).
                            </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>(B) Optionally, enable a user to perform the following prescription-related electronic transactions in accordance with the standard specified in § 170.205(b)(1) and, at a minimum, the version of the standard specified in § 170.207(d)(3) as follows:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) Create and respond to new prescriptions (NewRxRequest, NewRxResponseDenied).
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) Receive fill status notifications (RxFillIndicator).
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) Ask the Mailbox if there are any transactions (GetMessage).
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) Request to send an additional supply of medication (Resupply).
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) Communicate drug administration events (DrugAdministration).
                            </P>
                            <P>
                                (
                                <E T="03">6</E>
                                ) Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse, RxTransferConfirm).
                            </P>
                            <P>
                                (
                                <E T="03">7</E>
                                ) Recertify the continued administration of a medication order (Recertification).
                            </P>
                            <P>
                                (
                                <E T="03">8</E>
                                ) Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
                            </P>
                            <P>
                                (
                                <E T="03">9</E>
                                ) Electronic prior authorization transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse, PACancelRequest, and PACancelResponse).
                            </P>
                            <P>
                                (C) For the following prescription-related transactions, the technology must be able to receive and transmit the 
                                <PRTPAGE P="25943"/>
                                reason for prescription using the diagnosis elements: &lt;Diagnosis&gt; &lt;Primary&gt; or &lt;Secondary&gt;:
                            </P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) 
                                <E T="03">Required transactions:</E>
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Create 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>
                                (
                                <E T="03">vi</E>
                                ) Receive medication history (RxHistoryResponse).
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) 
                                <E T="03">Optional transactions:</E>
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) Request to send an additional supply of medication (Resupply)
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) Request and respond to transfer one or more prescriptions between pharmacies (RxTransferRequest, RxTransferResponse)
                            </P>
                            <P>
                                (
                                <E T="03">iii</E>
                                ) Complete Risk Evaluation and Mitigation Strategy (REMS) transactions (REMSInitiationRequest, REMSInitiationResponse, REMSRequest, and REMSResponse).
                            </P>
                            <P>
                                (
                                <E T="03">iv</E>
                                ) Electronic prior authorization (ePA) transactions (PAInitiationRequest, PAInitiationResponse, PARequest, PAResponse, PAAppealRequest, PAAppealResponse and PACancelRequest, PACancelResponse).
                            </P>
                            <P>
                                (D) 
                                <E T="03">Optional:</E>
                                 For each transaction listed in paragraph (b)(3)(ii)(C) of this section, the technology must be able to receive and transmit reason for prescription using the &lt;IndicationforUse&gt; element in the SIG segment.
                            </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>
                            <STARS/>
                            <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:
                            </P>
                            <P>(i) Document, section, and entry (data element) level; or</P>
                            <P>(ii) Document level for the period until May 2, 2022.</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:
                            </P>
                            <P>(A) Document, section, and entry (data element) level; or</P>
                            <P>(B) Document level for the period until May 2, 2022; 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)) on and after May 2, 2022.</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) 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>
                                (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>(c) * * *</P>
                            <P>
                                (3) 
                                <E T="03">Clinical quality measures—report.</E>
                                 Enable a user to electronically create a data file for transmission of clinical quality measurement data in accordance with the applicable implementation specifications specified by the CMS implementation guides for Quality Reporting Document Architecture (QRDA), category I, for inpatient measures in § 170.205(h)(3) and CMS implementation guide for QRDA, category III for ambulatory measures in § 170.205 (k)(3).
                            </P>
                            <STARS/>
                            <P>(d) * * *</P>
                            <P>
                                (12) 
                                <E T="03">Encrypt authentication credentials.</E>
                                 Health IT developers must make one of the following attestations and may provide the specified accompanying information, where applicable:
                            </P>
                            <P>(i) Yes—the Health IT Module encrypts stored authentication credentials in accordance with standards adopted in § 170.210(a)(2).</P>
                            <P>(ii) 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>
                                (13) 
                                <E T="03">Multi-factor authentication.</E>
                                 Health IT developers must make one of the following attestations and, as applicable, provide the specified accompanying information:
                            </P>
                            <P>(i) 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>(ii) 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 identify with the use of industry-recognized standards.</P>
                            <P>(e) * * *</P>
                            <P>(1) * * *</P>
                            <P>(i) * * *</P>
                            <P>(A) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The data classes expressed in the standards in § 170.213 (which should be in their English (
                                <E T="03">i.e.,</E>
                                 non-coded) representation if they associate with a vocabulary/code set), and in accordance with § 170.205(a)(4) and (a)(5), and paragraphs (e)(1)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iii</E>
                                ) of this section, or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The Common Clinical Data Set in accordance with § 170.205(a)(4) and paragraphs (e)(1)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iv</E>
                                ) of this section for the period until May 2, 2022.
                            </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 
                                <PRTPAGE P="25944"/>
                                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).
                            </P>
                            <P>
                                (
                                <E T="03">7</E>
                                ) Diagnostic image report(s).
                            </P>
                            <STARS/>
                            <P>(f) * * *</P>
                            <P>(5) * * *</P>
                            <P>(iii) * * *</P>
                            <P>(B) * * *</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The data classes expressed in the standards in § 170.213, and in accordance with § 170.205(a)(4) and (5), or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The Common Clinical Data Set in accordance with § 170.205(a)(4) for the period until May 2, 2022.
                            </P>
                            <P>
                                (
                                <E T="03">3</E>
                                ) 
                                <E T="03">Encounter diagnoses.</E>
                                 Formatted according to at least one of the following standards:
                            </P>
                            <P>
                                (
                                <E T="03">i</E>
                                ) The standard specified in § 170.207(i).
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) At a minimum, the version of the standard specified in § 170.207(a)(4).
                            </P>
                            <P>
                                (
                                <E T="03">4</E>
                                ) The provider's name, office contact information, and reason for visit.
                            </P>
                            <P>
                                (
                                <E T="03">5</E>
                                ) An identifier representing the row and version of the trigger table that triggered the case report.
                            </P>
                            <STARS/>
                            <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 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) * * *</P>
                            <P>(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), and (14), and (b)(2) and (3).</P>
                            <STARS/>
                            <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 standard in § 170.213, and in accordance with § 170.205(a)(4) and (5) and paragraphs (g)(6)(i)(C)(
                                <E T="03">1</E>
                                ) through (
                                <E T="03">3</E>
                                ) of this section; or
                            </P>
                            <P>
                                (B) The Common Clinical Data Set in accordance with § 170.205(a)(4) and paragraphs (g)(6)(i)(C)(
                                <E T="03">1</E>
                                ) through (
                                <E T="03">4</E>
                                ) of this section for the period until May 2, 2022.
                            </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 within the scope of the certificate sought.</P>
                            <P>
                                (iv) 
                                <E T="03">Vocabulary 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 the required vocabulary standards (and value sets) are properly implemented.
                            </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 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>
                            <STARS/>
                            <P>(9) * * *</P>
                            <P>(i) * * *</P>
                            <P>
                                (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 the standards in § 170.213 at one time and return such data (according to the specified standards, where applicable) in a summary record formatted in accordance with § 170.205(a)(4) and (5) following the CCD document template, and as specified in paragraphs (g)(9)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iii</E>
                                ) of this section, or
                                <PRTPAGE P="25945"/>
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The Common Clinical Data Set in accordance with paragraphs (g)(9)(i)(A)(
                                <E T="03">3</E>
                                )(
                                <E T="03">i</E>
                                ) through (
                                <E T="03">iv</E>
                                ) of this section for the period until May 2, 2022, 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 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>
                            <STARS/>
                            <P>
                                (10) 
                                <E T="03">Standardized API for patient and population services.</E>
                                 The following technical outcomes and conditions must be met through the demonstration of application programming interface technology.
                            </P>
                            <P>
                                (i) 
                                <E T="03">Data response.</E>
                                 (A) Respond to requests for a single patient's data according to the standard adopted in § 170.215(a)(1) and implementation specification adopted in § 170.215(a)(2), including the mandatory capabilities described in “US Core Server CapabilityStatement,” for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.
                            </P>
                            <P>(B) Respond to requests for multiple patients' data as a group according to the standard adopted in § 170.215(a)(1), and implementation specifications adopted in § 170.215(a)(2) and (4), for each of the data included in the standard adopted in § 170.213. All data elements indicated as “mandatory” and “must support” by the standards and implementation specifications must be supported.</P>
                            <P>
                                (ii) 
                                <E T="03">Supported search operations.</E>
                                 (A) Respond to search requests for a single patient's data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(2), specifically the mandatory capabilities described in “US Core Server CapabilityStatement.”
                            </P>
                            <P>(B) Respond to search requests for multiple patients' data consistent with the search criteria included in the implementation specification adopted in § 170.215(a)(4).</P>
                            <P>
                                (iii) 
                                <E T="03">Application registration.</E>
                                 Enable an application to register with the Health IT Module's “authorization server.”
                            </P>
                            <P>
                                (iv) 
                                <E T="03">Secure connection.</E>
                                 (A) Establish a secure and trusted connection with an application that requests data for patient and user scopes in accordance with the implementation specifications adopted in § 170.215(a)(2) and (3).
                            </P>
                            <P>(B) Establish a secure and trusted connection with an application that requests data for system scopes in accordance with the implementation specification adopted in § 170.215(a)(4).</P>
                            <P>
                                (v) 
                                <E T="03">Authentication and authorization</E>
                                —(A) 
                                <E T="03">Authentication and authorization for patient and user scopes</E>
                                —(
                                <E T="03">1</E>
                                ) 
                                <E T="03">First time connections</E>
                                —(
                                <E T="03">i</E>
                                ) Authentication and authorization must occur during the process of granting access to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) and standard adopted in § 170.215(b).
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) An application capable of storing a client secret must be issued a refresh token valid for a period of no less than three months.
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) 
                                <E T="03">Subsequent connections.</E>
                                 (
                                <E T="03">i</E>
                                ) Access must be granted to patient data in accordance with the implementation specification adopted in § 170.215(a)(3) without requiring re-authorization and re-authentication when a valid refresh token is supplied by the application.
                            </P>
                            <P>
                                (
                                <E T="03">ii</E>
                                ) An application capable of storing a client secret must be issued a new refresh token valid for a new period of no less than three months.
                            </P>
                            <P>
                                (B) 
                                <E T="03">Authentication and authorization for system scopes.</E>
                                 Authentication and authorization must occur during the process of granting an application access to patient data in accordance with the “SMART Backend Services: Authorization Guide” section of the implementation specification adopted in § 170.215(a)(4) and the application must be issued a valid access token.
                            </P>
                            <P>
                                (vi) 
                                <E T="03">Patient authorization revocation.</E>
                                 A Health IT Module's authorization server must be able to revoke an authorized application's access at a patient's direction.
                            </P>
                            <P>
                                (vii) 
                                <E T="03">Token introspection.</E>
                                 A Health IT Module's authorization server must be able to receive and validate tokens it has issued.
                            </P>
                            <P>
                                (viii) 
                                <E T="03">Documentation.</E>
                                 (A) The API(s) must include complete accompanying documentation that contains, at a minimum:
                            </P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) 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>
                                (
                                <E T="03">2</E>
                                ) 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>
                                (
                                <E T="03">3</E>
                                ) All applicable technical requirements and attributes necessary for an application to be registered with a Health IT Module's authorization server. 
                            </P>
                            <P>(B) The documentation used to meet paragraph (g)(10)(viii)(A) of this section must be available via a publicly accessible hyperlink without any preconditions or additional steps.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>16. Add subpart D to part 170 to read as follows:</AMDPAR>
                        <CONTENTS>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart D—Conditions and Maintenance of Certification Requirements for Health IT Developers</HD>
                                <SECHD>Sec.</SECHD>
                                <SECTNO>170.400</SECTNO>
                                <SUBJECT>Basis and scope.</SUBJECT>
                                <SECTNO>170.401</SECTNO>
                                <SUBJECT>Information blocking.</SUBJECT>
                                <SECTNO>170.402</SECTNO>
                                <SUBJECT>Assurances.</SUBJECT>
                                <SECTNO>170.403</SECTNO>
                                <SUBJECT>Communications.</SUBJECT>
                                <SECTNO>170.404</SECTNO>
                                <SUBJECT>Application programming interfaces.</SUBJECT>
                                <SECTNO>170.405</SECTNO>
                                <SUBJECT>Real world testing.</SUBJECT>
                                <SECTNO>170.406</SECTNO>
                                <SUBJECT>Attestations.</SUBJECT>
                            </SUBPART>
                        </CONTENTS>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart D—Conditions and Maintenance of Certification Requirements for Health IT Developers</HD>
                            <SECTION>
                                <SECTNO>§ 170.400</SECTNO>
                                <SUBJECT> Basis and scope.</SUBJECT>
                                <P>This subpart implements section 3001(c)(5)(D) of the Public Health Service Act by setting forth certain Conditions and Maintenance of Certification requirements for health IT developers participating in the ONC Health IT Certification Program.</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 170.401 </SECTNO>
                                <SUBJECT>Information blocking.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Condition of Certification requirement.</E>
                                     A health IT developer must not take any action that constitutes information blocking as defined in 42 U.S.C. 300jj-52 and § 171.103 on or after November 2, 2020.
                                </P>
                                <P>(b) [Reserved]</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 170.402 </SECTNO>
                                <SUBJECT>Assurances.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Condition of Certification requirement.</E>
                                     (1) A health IT developer must provide assurances satisfactory to the Secretary that the health IT developer will not take any action that constitutes information blocking as defined in 42 U.S.C. 300jj-52 and § 171.103 on and after November 2, 2020, unless for legitimate purposes as specified by the Secretary; or any other action that may inhibit the appropriate exchange, access, and use of electronic health information.
                                    <PRTPAGE P="25946"/>
                                </P>
                                <P>(2) A health IT developer must ensure that its health IT certified under the ONC Health IT Certification Program conforms to the full scope of the certification criteria.</P>
                                <P>(3) A health IT developer must not take any action that could interfere with a user's ability to access or use certified capabilities for any purpose within the full scope of the technology's certification.</P>
                                <P>(4) A health IT developer of a certified Health IT Module that is part of a heath IT product which electronically stores EHI must certify to the certification criterion in § 170.315(b)(10).</P>
                                <P>
                                    (b) 
                                    <E T="03">Maintenance of Certification requirements.</E>
                                     (1) A health IT developer must retain all records and information necessary to demonstrate initial and ongoing compliance with the requirements of the ONC Health IT Certification Program for:
                                </P>
                                <P>(i) A period of 10 years beginning from the date a developer's Health IT Module(s) is first certified under the Program; or</P>
                                <P>(ii) If for a shorter period of time, a period of 3 years from the effective date that removes all of the certification criteria to which the developer's health IT is certified from the Code of Federal Regulations.</P>
                                <P>(2)(i) Within 36 months of May 1, 2020, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).</P>
                                <P>(ii) On and after 36 months from May 1, 2020, a health IT developer that must comply with the requirements of paragraph (a)(4) of this section must provide all of its customers of certified health IT with the health IT certified to the certification criterion in § 170.315(b)(10).</P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 170.403 </SECTNO>
                                <SUBJECT>Communications.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Condition of Certification requirements.</E>
                                     (1) A health IT developer may not prohibit or restrict any communication regarding—
                                </P>
                                <P>(i) The usability of its health IT;</P>
                                <P>(ii) The interoperability of its health IT;</P>
                                <P>(iii) The security of its health IT;</P>
                                <P>(iv) Relevant information regarding users' experiences when using its health IT;</P>
                                <P>(v) The business practices of developers of health IT related to exchanging electronic health information; and</P>
                                <P>(vi) The manner in which a user of the health IT has used such technology.</P>
                                <P>(2) A health IT developer must not engage in any practice that prohibits or restricts a communication regarding the subject matters enumerated in paragraph (a)(1) of this section, unless the practice is specifically permitted by this paragraph and complies with all applicable requirements of this paragraph.</P>
                                <P>
                                    (i) 
                                    <E T="03">Unqualified protection for certain communications.</E>
                                     A health IT developer must not prohibit or restrict any person or entity from communicating any information whatsoever (including proprietary information, confidential information, and intellectual property) when the communication is about one or more of the subject matters enumerated in paragraph (a)(1) of this section and is made for any of the following purposes:
                                </P>
                                <P>(A) Making a disclosure required by law;</P>
                                <P>(B) Communicating information about adverse events, hazards, and other unsafe conditions to government agencies, health care accreditation organizations, and patient safety organizations;</P>
                                <P>(C) Communicating information about cybersecurity threats and incidents to government agencies;</P>
                                <P>(D) Communicating information about information blocking and other unlawful practices to government agencies; or</P>
                                <P>(E) Communicating information about a health IT developer's failure to comply with a Condition of Certification requirement, or with any other requirement of this part, to ONC or an ONC-ACB.</P>
                                <P>
                                    (ii) 
                                    <E T="03">Permitted prohibitions and restrictions.</E>
                                     For communications about one or more of the subject matters enumerated in paragraph (a)(1) of this section that is not entitled to unqualified protection under paragraph (a)(2)(i) of this section, a health IT developer may prohibit or restrict communications only as expressly permitted by paragraphs (a)(2)(ii)(A) through (E) of this section.
                                </P>
                                <P>
                                    (A) 
                                    <E T="03">Developer employees and contractors.</E>
                                     (
                                    <E T="03">1</E>
                                    ) A health IT developer may prohibit or restrict the communications of the developer's employees or contractors.
                                </P>
                                <P>
                                    (
                                    <E T="03">2</E>
                                    ) A self-developer must not prohibit or restrict communications of users of their health IT who are also employees or contractors.
                                </P>
                                <P>
                                    (B) 
                                    <E T="03">Non-user-facing aspects of health IT.</E>
                                     A health IT developer may prohibit or restrict communications that disclose information about non-user-facing aspects of the developer's health IT.
                                </P>
                                <P>
                                    (C) 
                                    <E T="03">Intellectual property.</E>
                                     A health IT developer may prohibit or restrict communications that involve the use or disclosure of intellectual property existing in the developer's health IT (including third-party intellectual property), provided that any prohibition or restriction imposed by a developer must be no broader than necessary to protect the developer's legitimate intellectual property interests and consistent with all other requirements of paragraph (a)(2)(ii) of this section. A restriction or prohibition is deemed broader than necessary and inconsistent with the requirements of paragraph (a)(2)(ii) of this section if it would restrict or preclude a public display of a portion of a work subject to copyright protection (without regard to whether the copyright is registered) that would reasonably constitute a “fair use” of that work.
                                </P>
                                <P>
                                    (D) 
                                    <E T="03">Screenshots and video.</E>
                                     A health IT developer may require persons who communicate screenshots or video to—
                                </P>
                                <P>
                                    (
                                    <E T="03">1</E>
                                    ) Not alter the screenshots or video, except to annotate the screenshots or video or resize the screenshots or video;
                                </P>
                                <P>
                                    (
                                    <E T="03">2</E>
                                    ) Limit the sharing of screenshots to the relevant number of screenshots needed to communicate about the health IT regarding one or more of the six subject areas in paragraph (a)(1) of this section; and
                                </P>
                                <P>
                                    (
                                    <E T="03">3</E>
                                    ) Limit the sharing of video to:
                                </P>
                                <P>
                                    (
                                    <E T="03">i</E>
                                    ) The relevant amount of video needed to communicate about the health IT regarding one or more of the six subject areas in paragraph (a)(1) of this section; and
                                </P>
                                <P>
                                    (
                                    <E T="03">ii</E>
                                    ) Only videos that address temporal matters that cannot be communicated through screenshots or other forms of communication.
                                </P>
                                <P>
                                    (E) 
                                    <E T="03">Pre-market testing and development.</E>
                                     A health IT developer may prohibit or restrict communications that disclose information or knowledge solely acquired in the course of participating in pre-market product development and testing activities carried out for the benefit of the developer or for the joint benefit of the developer and communicator. A developer must not, once the subject health IT is released or marketed for purposes other than product development and testing, and subject to the permitted prohibitions and restrictions described in paragraph (a)(2)(ii) of this section, prohibit or restrict communications about matters enumerated in paragraph (a)(1) of this section.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Maintenance of Certification requirements</E>
                                    —(1) 
                                    <E T="03">Notice.</E>
                                     Health IT developers must issue a written notice to all customers and those with which it has contracts or agreements containing provisions that contravene paragraph (a) of this section annually, beginning in calendar year 2020, until 
                                    <PRTPAGE P="25947"/>
                                    paragraph (b)(2)(ii) of this section is fulfilled, stating that any communication or contract provision that contravenes paragraph (a) of this section will not be enforced by the health IT developer.
                                </P>
                                <P>
                                    (2) 
                                    <E T="03">Contracts and agreements.</E>
                                     (i) A health IT developer must not establish, renew, or enforce any contract or agreement that contravenes paragraph (a) of this section.
                                </P>
                                <P>(ii) If a health IT developer has a contract or agreement in existence as of November 2, 2020, that contravenes paragraph (a) of this section, then the developer must amend the contract or agreement to remove or void the contractual provision that contravenes paragraph (a) of this section whenever the contract is next modified for other reasons or renewed.</P>
                                <P>
                                    (c) 
                                    <E T="03">Communication, defined.</E>
                                     “Communication” as used in this section means any communication, irrespective of the form or medium. The term includes visual communications, such as screenshots and video.
                                </P>
                            </SECTION>
                            <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).</P>
                                <P>
                                    (a) 
                                    <E T="03">Condition of certification requirements</E>
                                    —(1) 
                                    <E T="03">General.</E>
                                     A Certified API Developer must publish APIs and allow electronic 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, including providing access to all data elements of a patient's electronic health record to the extent permissible under applicable privacy laws. 
                                </P>
                                <P>
                                    (2) 
                                    <E T="03">Transparency conditions</E>
                                    —(i) 
                                    <E T="03">Complete business and technical documentation.</E>
                                     A Certified API Developer must publish complete business and technical documentation, including the documentation described in paragraph (a)(2)(ii) of this section, via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps.
                                </P>
                                <P>
                                    (ii) 
                                    <E T="03">Terms and conditions</E>
                                    —(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>
                                <P>
                                    (3) 
                                    <E T="03">Fees conditions</E>
                                    —(i) 
                                    <E T="03">General conditions</E>
                                    —(A) 
                                    <E T="03">All fees.</E>
                                     All fees related to certified API technology not otherwise permitted by this section are prohibited from being imposed by a Certified API Developer. The permitted fees in paragraphs (a)(3)(ii) and (iv) of this section may include fees that result in a reasonable profit margin in accordance with § 171.302.
                                </P>
                                <P>
                                    (B) 
                                    <E T="03">Permitted fees requirements.</E>
                                     For all permitted fees, a Certified API Developer must:
                                </P>
                                <P>
                                    (
                                    <E T="03">1</E>
                                    ) Ensure that such fees are based on objective and verifiable criteria that are uniformly applied to all similarly situated API Information Sources and API Users;
                                </P>
                                <P>
                                    (
                                    <E T="03">2</E>
                                    ) Ensure that such fees imposed on API Information Sources are reasonably related to the Certified API Developer's costs to supply certified API technology to, and if applicable, support certified API technology for, API Information Sources;
                                </P>
                                <P>
                                    (
                                    <E T="03">3</E>
                                    ) Ensure that such fees to supply and, if applicable, support certified API technology are reasonably allocated among all similarly situated API Information Sources; and
                                </P>
                                <P>
                                    (
                                    <E T="03">4</E>
                                    ) Ensure that such fees are not based on whether API Information Sources or API Users are competitors, potential competitors, or will be using the certified API technology in a way that facilitates competition with the Certified API Developer.
                                </P>
                                <P>
                                    (C) 
                                    <E T="03">Prohibited fees.</E>
                                     A Certified API Developer is prohibited from charging fees for the following:
                                </P>
                                <P>
                                    (
                                    <E T="03">1</E>
                                    ) Costs associated with intangible assets other than actual development or acquisition costs of such assets;
                                </P>
                                <P>
                                    (
                                    <E T="03">2</E>
                                    ) Opportunity costs unrelated to the access, exchange, or use of electronic health information; and
                                </P>
                                <P>
                                    (
                                    <E T="03">3</E>
                                    ) The permitted fees in this section cannot include any costs that led to the creation of intellectual property if the actor charged a royalty for that intellectual property pursuant to § 171.303 and that royalty included the development costs for the creation of the intellectual property.
                                </P>
                                <P>
                                    (D) 
                                    <E T="03">Record-keeping requirements.</E>
                                     A Certified API Developer must keep for inspection detailed records of any fees charged with respect to the certified API technology, the methodology(ies) used to calculate such fees, and the specific costs to which such fees are attributed.
                                </P>
                                <P>
                                    (ii) 
                                    <E T="03">Permitted fee—development, deployment, and upgrades.</E>
                                     A Certified API Developer is permitted to charge fees to an API Information Source to recover the costs reasonably incurred by the Certified API Developer to develop, deploy, and upgrade certified API technology.
                                </P>
                                <P>
                                    (iii) 
                                    <E T="03">Permitted fee—recovering API usage costs.</E>
                                     A Certified API Developer is permitted to charge fees to an API Information Source related to the use of certified API technology. The fees must be limited to the recovery of incremental costs reasonably incurred by the Certified API Developer when it hosts certified API technology on behalf of the API Information Source.
                                </P>
                                <P>
                                    (iv) 
                                    <E T="03">Permitted fee—value-added services.</E>
                                     A Certified API Developer is permitted to charge fees to an API User for value-added services related to certified API technology, so long as such services are not necessary to efficiently and effectively develop and deploy production-ready software that interacts with certified API technology.
                                </P>
                                <P>
                                    (4) 
                                    <E T="03">Openness and pro-competitive conditions; general condition.</E>
                                     A Certified API Developer must grant an API Information Source the independent ability to permit an API User to interact with the certified API technology deployed by the API Information Source.
                                </P>
                                <P>
                                    (
                                    <E T="03">i</E>
                                    ) 
                                    <E T="03">Non-discrimination.</E>
                                     (A) A Certified API Developer must provide certified API technology to an API Information Source on terms that are no less favorable than it provides to itself and its own customers, suppliers, partners, and other persons with whom it has a business relationship.
                                    <PRTPAGE P="25948"/>
                                </P>
                                <P>(B) The terms on which a Certified API Developer provides certified API technology must be based on objective and verifiable criteria that are uniformly applied to all substantially similar or similarly situated classes of persons and requests.</P>
                                <P>(C) A Certified API Developer must not offer different terms or services based on:</P>
                                <P>
                                    (
                                    <E T="03">1</E>
                                    ) Whether a competitive relationship exists or would be created;
                                </P>
                                <P>
                                    (
                                    <E T="03">2</E>
                                    ) The revenue or other value that another party may receive from using the API technology.
                                </P>
                                <P>
                                    (ii) 
                                    <E T="03">Rights to access and use certified API technology</E>
                                    —(A) 
                                    <E T="03">Rights that must be granted.</E>
                                     A Certified API Developer must have and, upon request, must grant to API Information Sources and API Users all rights that may be reasonably necessary to:
                                </P>
                                <P>
                                    (
                                    <E T="03">1</E>
                                    ) Access and use the Certified API Developer's certified API technology in a production environment;
                                </P>
                                <P>
                                    (
                                    <E T="03">2</E>
                                    ) Develop products and services that are designed to interact with the Certified API Developer's certified API technology; and
                                </P>
                                <P>
                                    (
                                    <E T="03">3</E>
                                    ) Market, offer, and distribute products and services associated with the Certified API Developer's certified API technology.
                                </P>
                                <P>
                                    (B) 
                                    <E T="03">Prohibited conduct.</E>
                                     A Certified API Developer is prohibited from conditioning the receipt of the rights described in paragraph (a)(4)(ii)(A) of this section on:
                                </P>
                                <P>
                                    (
                                    <E T="03">1</E>
                                    ) Receiving a fee, including but not limited to a license fee, royalty, or revenue-sharing arrangement;
                                </P>
                                <P>
                                    (
                                    <E T="03">2</E>
                                    ) Agreeing to not compete with the Certified API Developer in any product, service, or market;
                                </P>
                                <P>
                                    (
                                    <E T="03">3</E>
                                    ) Agreeing to deal exclusively with the Certified API Developer in any product, service, or market;
                                </P>
                                <P>
                                    (
                                    <E T="03">4</E>
                                    ) Obtaining additional licenses, products, or services that are not related to or can be unbundled from the certified API technology;
                                </P>
                                <P>
                                    (
                                    <E T="03">5</E>
                                    ) Licensing, granting, assigning, or transferring any intellectual property to the Certified API Developer;
                                </P>
                                <P>
                                    (
                                    <E T="03">6</E>
                                    ) Meeting any Certified API Developer-specific testing or certification requirements; and.
                                </P>
                                <P>
                                    (
                                    <E T="03">7</E>
                                    ) Providing the Certified API Developer or its technology with reciprocal access to application data.
                                </P>
                                <P>
                                    (iii) 
                                    <E T="03">Service and support obligations.</E>
                                     A Certified API Developer must provide all support and other services reasonably necessary to enable the effective development, deployment, and use of certified API technology by API Information Sources and API Users in production environments.
                                </P>
                                <P>
                                    (A) 
                                    <E T="03">Changes and updates to</E>
                                     certified 
                                    <E T="03">API technology.</E>
                                     A Certified API Developer must make reasonable efforts to maintain the compatibility of its certified API technology and to otherwise avoid disrupting the use of certified API technology in production environments.
                                </P>
                                <P>
                                    (B) 
                                    <E T="03">Changes to terms and conditions.</E>
                                     Except as exigent circumstances require, prior to making changes to its certified API technology or to the terms and conditions thereof, a Certified API Developer must provide notice and a reasonable opportunity for API Information Sources and API Users to update their applications to preserve compatibility with certified API technology and to comply with applicable terms and conditions.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Maintenance of certification requirements</E>
                                    —(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 the certification criterion adopted in § 170.315(g)(10):
                                </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 § 170.315(g)(10).
                                </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.
                                </P>
                                <P>
                                    (2) 
                                    <E T="03">Service base URL publication.</E>
                                     A Certified API Developer must publish the service base URLs for all Health IT Modules certified to § 170.315(g)(10) that can be used by patients to access their electronic health information. The Certified API Developer must publicly publish the service base URLs:
                                </P>
                                <P>(i) For all of its customers regardless of whether the Health IT Modules certified to § 170.315(g)(10) are centrally managed by the Certified API Developer or locally deployed by an API Information Source; and</P>
                                <P>(ii) In a machine-readable format at no charge.</P>
                                <P>
                                    (3) 
                                    <E T="03">Rollout of (g)(10)-certified APIs.</E>
                                     A Certified API Developer with certified API technology previously certified to the certification criterion in § 170.315(g)(8) must provide all API Information Sources with such certified API technology deployed with certified API technology certified to the certification criterion in § 170.315(g)(10) by no later than May 2, 2022.
                                </P>
                                <P>
                                    (4) 
                                    <E T="03">Compliance for existing certified API technology.</E>
                                     By no later than November 2, 2020, a Certified API Developer with Health IT Module(s) certified to the certification criteria in § 170.315(g)(7), (8), or (9) must comply with paragraph (a) of this section, including revisions to their existing business and technical API documentation and make such documentation available via a publicly accessible hyperlink that allows any person to directly access the information without any preconditions or additional steps.
                                </P>
                                <P>
                                    (c) 
                                    <E T="03">Definitions.</E>
                                     The following definitions apply to this section:
                                </P>
                                <P>
                                    <E T="03">API Information Source</E>
                                     means an organization that deploys certified API technology created by a “Certified API Developer;”
                                </P>
                                <P>
                                    <E T="03">API User</E>
                                     means a person or entity that creates or uses software applications that interact with the “certified API technology” developed by a “Certified API Developer” and deployed by an “API Information Source;”
                                </P>
                                <P>
                                    <E T="03">Certified API Developer</E>
                                     means a health IT developer that creates the “certified API technology” that is certified to any of the certification criteria adopted in § 170.315(g)(7) through (10); and
                                </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).
                                </P>
                            </SECTION>
                            <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 2015 Edition certification criteria in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h) must successfully test the real world use of those Health IT Module(s) for interoperability (as defined in 42 U.S.C.300jj(9) and § 170.102) in the type of setting in which such Health IT Module(s) would be/is marketed.
                                </P>
                                <P>
                                    (b) 
                                    <E T="03">Maintenance of Certification requirements</E>
                                    —(1) 
                                    <E T="03">Real world testing plan submission.</E>
                                     A health IT developer with Health IT Module(s) certified to any one or more of the criteria referenced in paragraph (a) of this section must submit to its ONC-ACB an annual real world testing plan addressing each of those certified Health IT Modules by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the plan on CHPL no later than December 15 of each calendar year.
                                </P>
                                <P>
                                    (i) The plan must be approved by a health IT developer authorized representative capable of binding the 
                                    <PRTPAGE P="25949"/>
                                    health IT developer for execution of the plan and include the representative's contact information.
                                </P>
                                <P>(ii) The plan must include all health IT certified to any one or more of the criteria referenced in paragraph (a) of this section as of August 31 of the year in which the plan is submitted, and address the real world testing to be conducted in the calendar year immediately following plan submission.</P>
                                <P>(iii) The plan must address the following for each of the certification criteria identified in paragraph (a) of this section that are included in each Health IT Module's scope of certification:</P>
                                <P>(A) The testing method(s)/methodology(ies) that will be used to demonstrate real world interoperability and conformance to the full scope of the certification criterion's requirements, including scenario- and use case-focused testing;</P>
                                <P>(B) The care setting(s) that will be tested for real world interoperability and an explanation for the health IT developer's choice of care setting(s) to test;</P>
                                <P>(C) For any standards and implementation specifications referenced by the criterion that the developer has chosen to certify to National Coordinator-approved newer versions pursuant to paragraph (b)(8) or (9) of this section, a description of how the developer will test and demonstrate conformance to all requirements of the criterion using all versions of the adopted standards to which each Health IT Module was certified as of August 31 of the year in which the real world testing plan is due.</P>
                                <P>(D) A schedule of key real world testing milestones;</P>
                                <P>(E) A description of the expected outcomes of real world testing;</P>
                                <P>(F) At least one measurement/metric associated with the real world testing; and</P>
                                <P>(G) A justification for the health IT developer's real world testing approach.</P>
                                <P>
                                    (2) 
                                    <E T="03">Real world testing results reporting.</E>
                                     (i) If in the course of conducting real world testing the developer discovers one or more non-conformities with the full scope of any certification criterion under the Program, the developer must report that non-conformity to the ONC-ACB within 30 days.
                                </P>
                                <P>(ii) For real world testing activities conducted during the immediately preceding calendar year, a health IT developer must submit to its ONC-ACB an annual real world testing results report addressing each of its certified Health IT Modules that include certification criteria referenced in paragraph (a) of this section by a date determined by the ONC-ACB that enables the ONC-ACB to publish a publicly available hyperlink to the results report on CHPL no later than March 15 of each calendar year. The real world testing results must report the following for each of the certification criteria identified in paragraph (a) of this section that are included in the Health IT Module's scope of certification:</P>
                                <P>(A) The method(s) that was used to demonstrate real world interoperability;</P>
                                <P>(B) The care setting(s) that was tested for real world interoperability;</P>
                                <P>(C) The voluntary updates to standards and implementation specifications that the National Coordinator has approved through the Standards Version Advancement Process;</P>
                                <P>(D) A list of the key milestones met during real world testing;</P>
                                <P>(E) The outcomes of real world testing including a description of any challenges encountered during real world testing; and</P>
                                <P>(F) At least one measurement/metric associated with the real world testing.</P>
                                <P>
                                    (3) 
                                    <E T="03">USCDI Updates for C-CDA.</E>
                                     A health IT developer with health IT certified to § 170.315(b)(1), (b)(2), (e)(1), (g)(6), (f)(5), and/or (g)(9) on May 1, 2020, must:
                                </P>
                                <P>(i) Update their certified health IT to be compliant with the revised versions of these criteria adopted in this final rule; and</P>
                                <P>(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(3)(i) of this section by May 2, 2022.</P>
                                <P>
                                    (4) 
                                    <E T="03">C-CDA Companion Guide Updates.</E>
                                     A health IT developer with health IT certified to § 170.315(b)(1), (b)(2), (b)(9), (e)(1), (g)(6), and/or (g)(9) prior to May 1, 2020, must:
                                </P>
                                <P>(i) Update their certified health IT to be compliant with the revised versions of the Program criteria in the 2015 Edition; and</P>
                                <P>(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(4)(i) of this section by May 2, 2022.</P>
                                <P>
                                    (5) 
                                    <E T="03">Electronic prescribing.</E>
                                     A health IT developer with health IT certified to § 170.315(b)(3) prior to November 2, 2020, must:
                                </P>
                                <P>(i) Update their certified health IT to be compliant with the revised versions of this criteria adopted in § 170.315(b)(3)(ii); and</P>
                                <P>(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(5)(i) of this section by May 2, 2022</P>
                                <P>
                                    (6) 
                                    <E T="03">Security tags.</E>
                                     A health IT developer with health IT certified to § 170.315(b)(7) and/or § 170.315(b)(8) prior to May 1, 2020, must:
                                </P>
                                <P>(i) Update their certified health IT to be compliant with the revised versions of the criteria adopted in § 170.315(b)(7) and/or the revised versions of the criteria adopted in § 170.315(b)(8); and</P>
                                <P>(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(6)(i) of this section by May 2, 2022.</P>
                                <P>
                                    (7) 
                                    <E T="03">ASTM updates.</E>
                                     A health IT developer with health IT certified to § 170.315(d)(2), (3), and/or (d)(10) prior to May 1, 2020, must:
                                </P>
                                <P>(i) Update their certified health IT to be compliant with § 170.210(e)(1) and the standard specified in § 170.210(h); and</P>
                                <P>(ii) Provide its customers of the previously certified health IT with certified health IT that meets paragraph (b)(7)(i) of this section by May 2, 2022.</P>
                                <P>
                                    (8) 
                                    <E T="03">Standards Version Advancement Process</E>
                                    —
                                    <E T="03">voluntary updates of certified health IT to newer versions of standards and implementation specifications.</E>
                                     A health IT developer subject to this paragraph (b) is permitted to update Health IT Module(s) certified to any one or more of the certification criteria referenced in paragraph (a) of this section to a newer version of any adopted standard or implementation specification included in the criterion, provided that newer version is approved by the National Coordinator for use in certifications issued under the ONC Health IT Certification Program. A developer that pursues such updates to its certified Health IT Module(s) must:
                                </P>
                                <P>(i) Provide advance notice to all affected customers and its ONC-ACB—</P>
                                <P>(A) Expressing its intent to update the certified Health IT Module(s) to the National Coordinator-approved advanced version of the standard implementation specification;</P>
                                <P>(B) The developer's expectations for how the update(s) will affect real world interoperability for the Health IT Module(s);</P>
                                <P>(C) Whether the developer intends to continue to support the certificate(s) for the existing certified Health IT Module(s) version(s) for some period of time and how long or if the existing certified Health IT Module(s) version(s) will be deprecated; and</P>
                                <P>(ii) Successfully demonstrate conformance with approved more recent versions of the standard(s) or implementation specification(s) included in each certification criterion under which the developer chooses to update its certified Health IT Module(s).</P>
                                <P>
                                    (iii) Maintain the updated certified Health IT Module(s) in full conformance 
                                    <PRTPAGE P="25950"/>
                                    with all applicable Program requirements.
                                </P>
                                <P>
                                    (9) 
                                    <E T="03">Standards Version Advancement Process—voluntary certification to newer versions of standards and implementation specifications.</E>
                                     A Health IT developer is permitted to seek certification for its Health IT Module(s) to any one or more of the certification criteria referenced in paragraph (a) of this section using a newer version of any adopted standard(s) or implementation specification(s) included in the criterion without first obtaining certification to the version of that adopted standard or implementation specification that is incorporated by reference in § 170.299, provided that the newer version is approved by the National Coordinator for use in certifications issued under the ONC Health IT Certification Program. Developers may, for each standard and implementation specification included in each criterion, choose on an itemized basis whether to seek certification to the version incorporated by reference in § 170.299, or to one or more newer version(s) approved by the National Coordinator for use in Health IT Module certifications issued pursuant to section 3001(c)(5) of the Public Health Service Act, or to both.
                                </P>
                            </SECTION>
                            <SECTION>
                                <SECTNO>§ 170.406 </SECTNO>
                                <SUBJECT>Attestations.</SUBJECT>
                                <P>
                                    (a) 
                                    <E T="03">Condition of Certification requirement.</E>
                                     A health IT developer, or its authorized representative that is capable of binding the health IT developer, must provide the Secretary an attestation of compliance with the following Conditions and Maintenance of Certification requirements:
                                </P>
                                <P>(1) Section 170.401;</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;</P>
                                <P>(3) Section 170.403;</P>
                                <P>(4) Section 170.404 if the health IT developer has a Health IT Module(s) certified to any of the certification criteria adopted in § 170.315(g)(7) through (10); and such health IT developer must also ensure that health IT allows for health information to be exchanged, accessed, and used, in the manner described in § 170.404; and</P>
                                <P>(5) Section 170.405 if a health IT developer has a Health IT Module(s) certified to any one or more 2015 Edition certification criteria in § 170.315(b), (c)(1) through (3), (e)(1), (f), (g)(7) through (10), and (h).</P>
                                <P>
                                    (b) 
                                    <E T="03">Maintenance of Certification requirement.</E>
                                     (1) A health IT developer, or its authorized representative that is capable of binding the health IT developer, must provide the attestation specified in paragraph (a) of this section semiannually for any Health IT Modules that have or have had an active certification at any time under the ONC Health IT Certification Program during the prior six months.
                                </P>
                                <P>(2) [Reserved].</P>
                            </SECTION>
                        </SUBPART>
                    </REGTEXT>
                    <SUBPART>
                        <HD SOURCE="HED">Subpart E—ONC Health IT Certification Program</HD>
                        <SECTION>
                            <SECTNO>§ 170.501 </SECTNO>
                            <SUBJECT> [Amended] </SUBJECT>
                        </SECTION>
                    </SUBPART>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>17. Amend § 170.501:</AMDPAR>
                        <AMDPAR>a. In paragraph (a), by removing the phrase “Complete EHRs,”;</AMDPAR>
                        <AMDPAR>b. In paragraph (b), by removing the phrase “Complete EHRs and”; and</AMDPAR>
                        <AMDPAR>c. By removing and reserving paragraph (c).</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.502 </SECTNO>
                        <SUBJECT>[Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>18. Amend § 170.502:</AMDPAR>
                        <AMDPAR>a. In the definition of “Deployment site”, by removing the phrase “Complete EHR,”;</AMDPAR>
                        <AMDPAR>b. In the definition of “Development site”, by removing the phrase “Complete EHR,”;</AMDPAR>
                        <AMDPAR>c. In the introductory text to the definition of “Gap certification”, by removing the phrase “Complete EHR or”;</AMDPAR>
                        <AMDPAR>d. By removing the definition of “ONC-Approved Accreditor or ONC-AA”;</AMDPAR>
                        <AMDPAR>e. In the definition of “ONC-Authorized Certification Body or ONC-ACB”, by removing the phrase “Complete EHRs,”; and</AMDPAR>
                        <AMDPAR>f. In the definition of “ONC-Authorized Testing Lab or ONC-ATL,” by removing the phrase “Complete EHRs and”.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§§ 170.503 and 170.504 </SECTNO>
                        <SUBJECT> [Removed and Reserved] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>19. Remove and reserve §§ 170.503 and 170.504.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>20. Revise § 170.505 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.505 </SECTNO>
                            <SUBJECT> Correspondence.</SUBJECT>
                            <P>(a) Correspondence and communication with ONC or the National Coordinator shall be conducted by email, unless otherwise necessary or specified.</P>
                            <P>(1) Consideration for providing notice beyond email, such as by regular, express, or certified mail, will be based on, but not limited to, whether: The party requests use of correspondence beyond email; the party has responded via email to our communications; we have sufficient information from the party to ensure appropriate delivery of any other method of notice; and the matter involves an alleged violation within ONC's purview under § 170.580 that indicates a serious violation under the ONC Health IT Certification Program with potential consequences of suspension, certification termination, or a certification ban.</P>
                            <P>(2) The official date of receipt of any email between ONC or the National Coordinator and an applicant for ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a party to any proceeding under this subpart is the date on which the email was sent.</P>
                            <P>(b) In circumstances where it is necessary for an applicant for ONC-ACB status, an applicant for ONC-ATL status, an ONC-ACB, an ONC-ATL, health IT developer, or a party to any proceeding under this subpart to correspond or communicate with ONC or the National Coordinator by regular, express, or certified mail, the official date of receipt for all parties will be the date of the delivery confirmation to the address on record.</P>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.510 </SECTNO>
                        <SUBJECT>[Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>21. Amend § 170.510 by removing paragraph (a) and redesignating paragraphs (b) and (c) as paragraphs (a) and (b).</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>22. Amend § 170.520 by revising paragraph (a)(3) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.520 </SECTNO>
                            <SUBJECT>Application.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>(3) Documentation that confirms that the applicant has been accredited to ISO/IEC 17065 (for availability, see § 170.599), with an appropriate scope, by any accreditation body that is a signatory to the Multilateral Recognition Arrangement (MLA) with the International Accreditation Forum (IAF).</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>23. Amend § 170.523:</AMDPAR>
                        <AMDPAR>a. By revising paragraph (a);</AMDPAR>
                        <AMDPAR>b. By adding subject headings to paragraphs (b), (c), (d) introductory text, and (e);</AMDPAR>
                        <AMDPAR>c. In paragraph (f) introductory text, by adding a subject heading and removing the phrase, “Complete EHRs,” and;</AMDPAR>
                        <AMDPAR>d. By removing and reserving paragraph (f)(2);</AMDPAR>
                        <AMDPAR>e. Revising paragraphs (g) and (h);</AMDPAR>
                        <AMDPAR>f. Adding subject headings to paragraphs (i) introductory text and (j) introductory text;</AMDPAR>
                        <AMDPAR>g. In paragraph (k) introductory text, by adding a subject heading and removing the phrase “Complete EHRs and”;</AMDPAR>
                        <AMDPAR>
                            h. In paragraph (k)(1), by removing the phrase “Complete EHR or”;
                            <PRTPAGE P="25951"/>
                        </AMDPAR>
                        <AMDPAR>i. By revising paragraphs (k)(1)(ii) and (iii);</AMDPAR>
                        <AMDPAR>j. By removing and reserving paragraphs (k)(1)(iv)(B) and (C) and (k)(2) and (3);</AMDPAR>
                        <AMDPAR>k. By revising paragraph (k)(4);</AMDPAR>
                        <AMDPAR>l. By adding a subject heading to paragraph (l);</AMDPAR>
                        <AMDPAR>m. By revising paragraph (m);</AMDPAR>
                        <AMDPAR>n. In paragraph (o), by adding a subject heading and removing the phrase “Complete EHR or”; and</AMDPAR>
                        <AMDPAR>o. By adding paragraphs (p) through (t).</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>
                                (a) 
                                <E T="03">Accreditation.</E>
                                 Maintain its accreditation in good standing to ISO/IEC 17065 (incorporated by reference in § 170.599).
                            </P>
                            <P>
                                (b) 
                                <E T="03">Mandatory training.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (c) 
                                <E T="03">Training program.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (d) 
                                <E T="03">Reporting.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (e) 
                                <E T="03">Onsite observation.</E>
                                 * * *
                            </P>
                            <P>
                                (f) 
                                <E T="03">Certified product listing.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (g) 
                                <E T="03">Records retention.</E>
                                 (1) Retain all records related to the certification of Complete EHRs and Health IT Modules to an edition of certification criteria beginning with the codification of an edition of certification criteria in the Code of Federal Regulations through a minimum of 3 years from the effective date that removes the applicable edition from the Code of Federal Regulations; and
                            </P>
                            <P>(2) Make the records available to HHS upon request during the retention period described in paragraph (g)(1) of this section;</P>
                            <P>
                                (h) 
                                <E T="03">Certification decision.</E>
                                 Only certify Health IT Modules that have been:
                            </P>
                            <P>(1) Tested, using test tools and test procedures approved by the National Coordinator, by an:</P>
                            <P>(i) ONC-ATL;</P>
                            <P>(ii) ONC-ATL, National Voluntary Laboratory Accreditation Program-accredited testing laboratory under the ONC Health IT Certification Program, and/or an ONC-ATCB for the purposes of performing gap certification; or</P>
                            <P>(2) Evaluated by it for compliance with a conformance method approved by the National Coordinator.</P>
                            <P>
                                (i) 
                                <E T="03">Surveillance.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (j) 
                                <E T="03">Refunds.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (k) 
                                <E T="03">Disclosures.</E>
                                 * * *
                            </P>
                            <P>(1) * * *</P>
                            <P>(ii) For a Health IT Module certified to the 2015 Edition health IT certification criteria, the information specified by paragraphs (f)(1)(i), (vi) through (viii), (xv), and (xvi) of this section as applicable for the specific Health IT Module.</P>
                            <P>(iii) In plain language, a detailed description of all known material information concerning additional types of costs or fees that a user may be required to pay to implement or use the Health IT Module's capabilities, whether to meet provisions of HHS programs requiring the use of certified health IT or to achieve any other use within the scope of the health IT's certification. The additional types of costs or fees required to be disclosed include but are not limited to costs or fees (whether fixed, recurring, transaction-based, or otherwise) imposed by a health IT developer (or any third party from whom the developer purchases, licenses, or obtains any technology, products, or services in connection with its certified health IT) to purchase, license, implement, maintain, upgrade, use, or otherwise enable and support the use of capabilities to which health IT is certified; or in connection with any data generated in the course of using any capability to which health IT is certified.</P>
                            <STARS/>
                            <P>(4) A certification issued to a Health IT Module based solely on the applicable certification criteria adopted by the ONC Health IT Certification Program must be separate and distinct from any other certification(s) based on other criteria or requirements.</P>
                            <P>
                                (l) 
                                <E T="03">Certification and Design Mark.</E>
                                 * * *
                            </P>
                            <P>
                                (m) 
                                <E T="03">Adaptations and updates.</E>
                                 On a quarterly basis each calendar year, obtain a record of:
                            </P>
                            <P>(1) All adaptations of certified Health IT Modules;</P>
                            <P>(2) All updates made to certified Health IT Modules affecting the capabilities in certification criteria to which the “safety-enhanced design” criteria apply;</P>
                            <P>(3) All uses cases for § 170.315(d)(13);</P>
                            <P>(4) All updates made to certified Health IT Modules in compliance with § 170.405(b)(3); and</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.</P>
                            <STARS/>
                            <P>
                                (o) 
                                <E T="03">Scope reduction.</E>
                                 * * *
                            </P>
                            <P>
                                (p) 
                                <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>
                                (q) 
                                <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>
                                (r) 
                                <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>
                                (s) 
                                <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>
                                (t) 
                                <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>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>24. Amend § 170.524:</AMDPAR>
                        <AMDPAR>a. By adding subject headings to paragraphs (a) through (c), (d) introductory text, and (e);</AMDPAR>
                        <AMDPAR>b. By revising paragraph (f);</AMDPAR>
                        <AMDPAR>c. By adding a subject heading to paragraph (g) and paragraph (h) introductory text; and</AMDPAR>
                        <AMDPAR>d. In paragraph (h)(3), by removing the phrase “Complete EHRs and/or”.</AMDPAR>
                        <P>The additions and revisions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.524</SECTNO>
                            <SUBJECT> Principles of proper conduct for ONC-ATLs.</SUBJECT>
                            <STARS/>
                            <PRTPAGE P="25952"/>
                            <P>
                                (a) 
                                <E T="03">Accreditation.</E>
                                 * * *
                            </P>
                            <P>
                                (b) 
                                <E T="03">Mandatory training.</E>
                                 * * *
                            </P>
                            <P>
                                (c) 
                                <E T="03">Training program.</E>
                                 * * *
                            </P>
                            <P>
                                (d) 
                                <E T="03">Reporting.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (e) 
                                <E T="03">Onsite observation.</E>
                                 * * *
                            </P>
                            <P>
                                (f) 
                                <E T="03">Records retention.</E>
                                 (1) Retain all records related to the testing of Complete EHRs and/or Health IT Modules to an edition of certification criteria beginning with the codification of an edition of certification criteria in the Code of Federal Regulations through a minimum of three years from the effective date that removes the applicable edition from the Code of Federal Regulations; and
                            </P>
                            <P>(2) Make the records available to HHS upon request during the retention period described in paragraph (f)(1) of this section;</P>
                            <P>
                                (g) 
                                <E T="03">Approved testing methods.</E>
                                 * * *
                            </P>
                            <P>
                                (h) 
                                <E T="03">Refunds.</E>
                                 * * *
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.545 </SECTNO>
                        <SUBJECT>[Removed and Reserved] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>25. Remove and reserve § 170.545.</AMDPAR>
                        <AMDPAR>26. Amend § 170.550 by:</AMDPAR>
                        <AMDPAR>a. Adding subject headings to paragraphs (a),(b), and (d), and adding paragraph (e);</AMDPAR>
                        <AMDPAR>b. Removing and reserving paragraph (f);</AMDPAR>
                        <AMDPAR>c. Adding a subject heading to paragraph (g) introductory text and adding paragraph (g)(5);</AMDPAR>
                        <AMDPAR>d. Revising paragraph (h); and</AMDPAR>
                        <AMDPAR>e. Adding paragraphs (l) and (m).</AMDPAR>
                        <P>The additions and revisions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.550 </SECTNO>
                            <SUBJECT>Health IT Module certification.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Certification scope.</E>
                                 * * *
                            </P>
                            <P>
                                (b) 
                                <E T="03">Health IT product scope options.</E>
                                 * * *
                            </P>
                            <STARS/>
                            <P>
                                (d) 
                                <E T="03">Upgrades and enhancements.</E>
                                 * * *
                            </P>
                            <P>
                                (e) 
                                <E T="03">Standards updates.</E>
                                 ONC-ACBs must provide an option for certification of Health IT Modules consistent with § 171.405(b)(7) or (8) to any one or more of the criteria referenced in § 170.405(a) based on newer versions of standards included in the criteria which have been approved by the National Coordinator for use in certification.
                            </P>
                            <STARS/>
                            <P>
                                (g) 
                                <E T="03">Health IT module dependent criteria.</E>
                                 * * *
                            </P>
                            <P>(5) Section 170.315(b)(10) when a health IT developer presents a Health IT Module for certification that can store electronic health information at the time of certification by the product, of which the Health IT Module is a part.</P>
                            <P>
                                (h) 
                                <E T="03">Privacy and security certification framework</E>
                                —(1) 
                                <E T="03">General rule.</E>
                                 When certifying a Health IT Module to the 2015 Edition health IT certification criteria, an ONC-ACB can only issue a certification to a Health IT Module if the privacy and security certification criteria in paragraphs (h)(3)(i) through (ix) of this section have also been met (and are included within the scope of the certification).
                            </P>
                            <P>
                                (2) 
                                <E T="03">Testing.</E>
                                 In order to be issued a certification, a Health IT Module would only need to be tested once to each applicable privacy and security criterion in paragraphs (h)(3)(i) through (ix) of this section so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification, except for the following:
                            </P>
                            <P>(i) A Health IT Module presented for certification to § 170.315(e)(1) must be separately tested to § 170.315(d)(9); and</P>
                            <P>(ii) A Health IT Module presented for certification to § 170.315(e)(2) must be separately tested to § 170.315(d)(9).</P>
                            <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), (d)(12), and (13).
                            </P>
                            <P>(ii) Section 170.315(a)(4), (9), (10), and (13) are also certified to the certification criteria specified in § 170.315(d)(1) through (3), and (d)(5) through (7), (d)(12), and (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) and (d)(5) through (8), (12), and (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), (B), (d)(2)(ii) through (v), (d)(3), (5), (12), and (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), (12), and (13);</P>
                            <P>(vi) Section 170.315(e)(2) and (3) 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), (5), (9), (12), and (13);</P>
                            <P>(vii) Section 170.315(f) is also certified to the certification criteria specified in § 170.315(d)(1) through (3), (7), (12), and (13);</P>
                            <P>(viii) Section 170.315(g)(7) through (10) is also certified to the certification criteria specified in § 170.315(d)(1), (9), (12), and (13); and (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), (d)(3), (12), and (13); and</P>
                            <STARS/>
                            <P>
                                (l) 
                                <E T="03">Conditions of certification attestations.</E>
                                 Ensure that the health IT developer of the Health IT Module has met its responsibilities under subpart D of this part.
                            </P>
                            <P>
                                (m) 
                                <E T="03">Time-limited certification and certification status for certain 2015 Edition certification criteria.</E>
                                 An ONC-ACB may only issue a certification to a Health IT Module and permit continued certified status for:
                            </P>
                            <P>(1) Section 170.315(a)(10) and (13) and § 170.315(e)(2) until January 1, 2022.</P>
                            <P>(2) Section 170.315(b)(6) until May 1, 2023.</P>
                            <P>(3) Section 170.315(g)(8) until May 2, 2022.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>27. Amend § 170.555:</AMDPAR>
                        <AMDPAR>a. In paragraph (a) by removing the words “Complete EHRs and/or”; and</AMDPAR>
                        <AMDPAR>b. By revising paragraph (b)(1).</AMDPAR>
                        <P>The revision reads as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.555 </SECTNO>
                            <SUBJECT>Certification to newer versions of certain standards.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(1) ONC-ACBs are not required to certify Health IT Module(s) according to newer versions of standards adopted and named in subpart B of this part, unless:</P>
                            <P>(i) The National Coordinator approves a newer version for use in certification and a health IT developer voluntarily elects to seek certification of its health IT in accordance with § 170.405(b)(9) or update its certified health IT to the newer version in accordance with § 170.405(b)(8); or</P>
                            <P>(ii) The new version is incorporated by reference in § 170.299.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>28. Amend § 170.556:</AMDPAR>
                        <AMDPAR>a. By removing the phrases “certified Complete EHR or” and “Complete EHR or”, wherever they occur;</AMDPAR>
                        <AMDPAR>b. By revising paragraph (a) introductory text and paragraph (c) introductory text;</AMDPAR>
                        <AMDPAR>c. By removing and reserving paragraph (c)(2);</AMDPAR>
                        <AMDPAR>d. In paragraph (c)(3), by removing the phrase “certified Complete EHRs”; and</AMDPAR>
                        <AMDPAR>e. By removing paragraphs (c)(5) and (6).</AMDPAR>
                        <P>The revisions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.556 </SECTNO>
                            <SUBJECT>In-the-field surveillance and maintenance of certification for Health IT.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">In-the-field surveillance.</E>
                                 Consistent with its accreditation under 170.523(a) to ISO/IEC 17065 and the requirements of this subpart, an ONC-
                                <PRTPAGE P="25953"/>
                                ACB must initiate surveillance “in the field” as necessary to assess whether a certified Health IT Module continues to conform to the requirements in subparts A, B, C and E of this part once the certified Health IT Module has been implemented and is in use in a production environment.
                            </P>
                            <STARS/>
                            <P>
                                (c) 
                                <E T="03">Randomized surveillance.</E>
                                 During each calendar year surveillance period, an ONC-ACB may conduct in-the-field surveillance for certain randomly selected Health IT Modules to which it has issued a certification.
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§§ 170.560, 170.565, and 170.570 </SECTNO>
                        <SUBJECT>[Amended] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>29. In the table below, for each section and paragraph indicated in the first two columns, remove the phrase indicated in the third column:</AMDPAR>
                        <GPOTABLE COLS="3" OPTS="L2,tp0,i1" CDEF="xs60,r50,xs100">
                            <TTITLE> </TTITLE>
                            <BOXHD>
                                <CHED H="1">Section</CHED>
                                <CHED H="1">Paragraphs</CHED>
                                <CHED H="1">Remove</CHED>
                            </BOXHD>
                            <ROW>
                                <ENT I="01">§ 170.560</ENT>
                                <ENT>(a)(2)</ENT>
                                <ENT>“Complete EHRs and/or”</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">§ 170.565</ENT>
                                <ENT>(d)(1)(ii) and (iii)</ENT>
                                <ENT>“Complete EHRs or”</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">§ 170.565</ENT>
                                <ENT>(h)(2)(iii)</ENT>
                                <ENT>“Complete EHRs and”</ENT>
                            </ROW>
                            <ROW>
                                <ENT I="01">§ 170.570</ENT>
                                <ENT>(a), (b)(2), (c) introductory text, and (c)(1) and (2)</ENT>
                                <ENT>“Complete EHRs and/or”</ENT>
                            </ROW>
                        </GPOTABLE>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 170.575 </SECTNO>
                        <SUBJECT>[Removed and Reserved] </SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>30. Remove and reserve § 170.575.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>31. Amend § 170.580:</AMDPAR>
                        <AMDPAR>a. By revising paragraph (a)(1) and the subject headings to paragraphs (a)(2)(i) and(ii);</AMDPAR>
                        <AMDPAR>b. By adding paragraph (a)(2)(iii);</AMDPAR>
                        <AMDPAR>c. By revising paragraphs (a)(3)(i), (iv), and (v);</AMDPAR>
                        <AMDPAR>d. By adding paragraph (a)(4);</AMDPAR>
                        <AMDPAR>e. By revising paragraphs (b)(1)(i) and (b)(1)(iii)(D), (b)(2)(i), and (b)(3)(i) and (ii);</AMDPAR>
                        <AMDPAR>f. By adding paragraphs (b)(3)(iii) and (iv);</AMDPAR>
                        <AMDPAR>g. By revising paragraph (c)(1);</AMDPAR>
                        <AMDPAR>h. In paragraphs (d)(1), (d)(2)(i)(C), and (d)(4), by removing the phrase “Complete EHR or”;</AMDPAR>
                        <AMDPAR>i. In paragraph (d)(5), by removing the phrase “Complete EHRs or”;</AMDPAR>
                        <AMDPAR>j. By revising paragraphs (e)(1) introductory text and (f)(1);</AMDPAR>
                        <AMDPAR>k. In paragraph (f)(2)(i)(C), by removing the phrase “Complete EHR or”; and</AMDPAR>
                        <AMDPAR>l. Revising paragraphs (g)(1) introductory text, (g)(1)(i), (g)(2), (g)(3)(i), (g)(4), (g)(5)(i), and (g)(6)(v).</AMDPAR>
                        <P>The revisions and additions read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.580</SECTNO>
                            <SUBJECT> ONC review of certified health IT or a health IT developer's actions.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Purpose.</E>
                                 ONC may directly review certified health IT or a health IT developer's actions or practices to determine whether either conform to the requirements of the ONC Health IT Certification Program.
                            </P>
                            <P>(2) * * *</P>
                            <P>
                                (i) 
                                <E T="03">Certified health IT causing or contributing to unsafe conditions.</E>
                                 * * *
                            </P>
                            <P>
                                (ii) 
                                <E T="03">Impediments to ONC-ACB oversight of certified health IT.</E>
                                 * * *
                            </P>
                            <P>
                                (iii) 
                                <E T="03">Noncompliance with a Condition and Maintenance of Certification requirement.</E>
                                 ONC may initiate direct review under this section if it has a reasonable belief that a health IT developer has not complied with a Condition or Maintenance of Certification requirement under subpart D of this part.
                            </P>
                            <P>(3) * * *</P>
                            <P>(i) ONC's review of certified health IT or a health IT developer's actions or practices is independent of, and may be in addition to, any surveillance of certified health IT conducted by an ONC-ACB.</P>
                            <STARS/>
                            <P>(iv) An ONC-ACB and ONC-ATL shall provide ONC with any available information that ONC deems relevant to its review of certified health IT or a health IT developer's actions or practices.</P>
                            <P>(v) ONC may end all or any part of its 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 ONC determines that doing so would serve the effective administration or oversight of the ONC Health IT Certification Program.</P>
                            <P>
                                (4) 
                                <E T="03">Coordination with the Office of Inspector General.</E>
                                 (i) ONC may coordinate its review of a claim of information blocking with the Office of Inspector General or defer to the Office of Inspector General to lead a review of a claim of information blocking.
                            </P>
                            <P>(ii) ONC may rely on Office of Inspector General findings to form the basis of a direct review action.</P>
                            <P>(b) * * *</P>
                            <P>(1) * * *</P>
                            <P>
                                (i) 
                                <E T="03">Circumstances that may trigger notice of potential non-conformity.</E>
                                 At any time during its review of certified health IT or a health IT developer's actions or practices under paragraph (a) of this section, ONC may send a notice of potential non-conformity if it has a reasonable belief that certified health IT or a health IT developer's actions or practices may not conform to the requirements of the ONC Health IT Certification Program.
                            </P>
                            <STARS/>
                            <P>(iii) * * *</P>
                            <P>(D) Issue a notice of proposed termination if the health IT is under review in accordance with paragraph (a)(2)(i) or (ii) of this section.</P>
                            <P>(2) * * *</P>
                            <P>
                                (i) 
                                <E T="03">Circumstances that may trigger notice of non-conformity.</E>
                                 At any time during its review of certified health IT or a health IT developer's actions or practices under paragraph (a) of this section, ONC may send a notice of non-conformity to the health IT developer if it determines that certified health IT or a health IT developer's actions or practices does not conform to the requirements of the ONC Health IT Certification Program.
                            </P>
                            <STARS/>
                            <P>
                                (
                                <E T="03">3</E>
                                ) * * *
                            </P>
                            <P>(i) All records related to the development, testing, certification, implementation, maintenance and use of its certified health IT;</P>
                            <P>(ii) Any complaint records related to the certified health IT;</P>
                            <P>(iii) All records related to the Condition(s) and Maintenance of Certification requirements, including marketing and distribution records, communications, and contracts; and</P>
                            <P>(iv) Any other relevant information.</P>
                            <P>(c) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Applicability.</E>
                                 If ONC 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>
                            <STARS/>
                            <P>(e) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Applicability.</E>
                                 Excluding situations of noncompliance with a Condition or Maintenance of Certification 
                                <PRTPAGE P="25954"/>
                                requirement under subpart D of this part, ONC may propose to terminate a certification issued to a Health IT Module if:
                            </P>
                            <STARS/>
                            <P>(f) * * *</P>
                            <P>
                                (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)(
                                <E T="03">3</E>
                                ) 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)(
                                <E T="03">3</E>
                                ) 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) ONC concludes that the non-conformity(ies) cannot be cured.</P>
                            <STARS/>
                            <P>(g) * * *</P>
                            <P>
                                (1) 
                                <E T="03">Basis for appeal.</E>
                                 A health IT developer may appeal an ONC determination to suspend or terminate a certification issued to a Health IT Module and/or an ONC determination to issue a certification ban under § 170.581(a)(2) if the health IT developer asserts:
                            </P>
                            <P>(i) ONC incorrectly applied 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>
                            <STARS/>
                            <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) * * *</P>
                            <P>(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>
                            <STARS/>
                            <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) * * *</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.</P>
                            <STARS/>
                            <P>(6) * * *</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, its determination to suspend or terminate the certification or issue a certification ban.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>32. Revise § 170.581 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 170.581</SECTNO>
                            <SUBJECT> Certification ban.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Circumstances that may trigger a certification ban.</E>
                                 The certification of any of a health IT developer's health IT is prohibited when:
                            </P>
                            <P>(1) The certification of one or more of the health IT developer's Health IT Modules is:</P>
                            <P>(i) Terminated by ONC under the ONC Health IT Certification Program;</P>
                            <P>(ii) Withdrawn from the ONC Health IT Certification Program by an ONC-ACB because the health IT developer requested it to be withdrawn (for reasons other than to comply with Program requirements) when the health IT developer's health IT was the subject of a potential non-conformity or non-conformity as determined by ONC;</P>
                            <P>(iii) Withdrawn by an ONC-ACB because of a non-conformity with any of the certification criteria adopted by the Secretary under subpart C of this part;</P>
                            <P>(iv) Withdrawn by an ONC-ACB because the health IT developer requested it to be withdrawn (for reasons other than to comply with Program requirements) when the health IT developer's health IT was the subject of surveillance for a certification criterion or criteria adopted by the Secretary under subpart C of this part, including notice of pending surveillance; or</P>
                            <P>(2) ONC determines a certification ban is appropriate per its review under § 170.580(a)(2)(iii).</P>
                            <P>
                                (b) 
                                <E T="03">Notice of certification ban.</E>
                                 When ONC 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>
                            <P>(1) An explanation of the certification ban;</P>
                            <P>(2) Information supporting the certification ban;</P>
                            <P>(3) Instructions for appealing the certification ban if banned in accordance with paragraph (a)(2) of this section; and</P>
                            <P>(4) Instructions for requesting reinstatement into the ONC Health IT Certification Program, which would lift the certification ban.</P>
                            <P>
                                (c) 
                                <E T="03">Effective date of certification ban.</E>
                                 (1) A certification ban will be effective immediately if banned under paragraph (a)(1) of this section.
                            </P>
                            <P>(2) For certification bans issued under paragraph (a)(2) of this section, the ban will be effective immediately after the following applicable occurrence:</P>
                            <P>
                                (i) The expiration of the 10-day period for filing a statement of intent to appeal in § 170.580(g)(3)(i) if the health IT 
                                <PRTPAGE P="25955"/>
                                developer does not file a statement of intent to appeal.
                            </P>
                            <P>(ii) The expiration of the 30-day period for filing an appeal in § 170.580(g)(3)(ii) if the health IT developer files a statement of intent to appeal, but does not file a timely appeal.</P>
                            <P>(iii) A final determination to issue a certification ban per § 170.580(g)(7) if a health IT developer files an appeal timely.</P>
                            <P>
                                (d) 
                                <E T="03">Reinstatement.</E>
                                 The certification of a health IT developer's health IT subject to the prohibition in paragraph (a) of this section may commence once the following conditions are met.
                            </P>
                            <P>(1) A health IT developer must request ONC's permission in writing to participate in the ONC Health IT Certification Program.</P>
                            <P>(2) The request must demonstrate that the customers affected by the certificate termination, certificate withdrawal, or noncompliance with a Condition or Maintenance of Certification requirement have been provided appropriate remediation.</P>
                            <P>(3) For noncompliance with a Condition or Maintenance of Certification requirement, the noncompliance must be resolved.</P>
                            <P>(4) ONC is satisfied with the health IT developer's demonstration under paragraph (d)(2) of this section that all affected customers have been provided with appropriate remediation and grants reinstatement into the ONC Health IT Certification Program.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="170">
                        <AMDPAR>33. Amend § 170.599 by:</AMDPAR>
                        <AMDPAR>a. Redesignating paragraph (b)(4) as paragraph (b)(5);</AMDPAR>
                        <AMDPAR>b. Adding new paragraph (b)(4); and</AMDPAR>
                        <AMDPAR>c. Revising newly redesignated paragraph (b)(5).</AMDPAR>
                        <P>The addition and revision read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 170.599</SECTNO>
                            <SUBJECT> Incorporation by Reference</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <P>(4) ISO/IEC 17025:2017(E)—General requirements for the competence of testing and calibration laboratories (Third Edition), 2017-11, “ISO/IEC 17025,” IBR approved for §§ 170.520(b), and 170.524(a).</P>
                            <P>(5) ISO/IEC 17065:2012(E)—Conformity assessment—Requirements for bodies certifying products, processes and services (First Edition), 2012, “ISO/IEC 17065,” IBR approved for §§ 170.503 and 170.523(a).</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="45" PART="171">
                        <AMDPAR>34. Add part 171 to read as follows:</AMDPAR>
                        <PART>
                            <HD SOURCE="HED">PART 171—INFORMATION BLOCKING</HD>
                            <CONTENTS>
                                <SUBPART>
                                    <HD SOURCE="HED">Subpart A—General Provisions</HD>
                                    <SECHD>Sec.</SECHD>
                                    <SECTNO>171.100</SECTNO>
                                    <SUBJECT>Statutory basis and purpose.</SUBJECT>
                                    <SECTNO>171.101</SECTNO>
                                    <SUBJECT>Applicability.</SUBJECT>
                                    <SECTNO>171.102</SECTNO>
                                    <SUBJECT>Definitions.</SUBJECT>
                                    <SECTNO>171.103</SECTNO>
                                    <SUBJECT>Information blocking.</SUBJECT>
                                </SUBPART>
                                <SUBPART>
                                    <HD SOURCE="HED">Subpart B—Exceptions That Involve Not Fulfilling Requests to Access, Exchange, or use Electronic Health Information</HD>
                                    <SECTNO>171.200</SECTNO>
                                    <SUBJECT>Availability and effect of exceptions.</SUBJECT>
                                    <SECTNO>171.201</SECTNO>
                                    <SUBJECT>Preventing harm exception—when will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to prevent harm not be considered information blocking?</SUBJECT>
                                    <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>
                                    <SECTNO>171.203</SECTNO>
                                    <SUBJECT>Security exception—when will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to protect the security of electronic health information not be considered information blocking?</SUBJECT>
                                    <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>
                                    <SECTNO>171.205</SECTNO>
                                    <SUBJECT>Health IT performance exception—when will an actor's practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of electronic health information not be considered information blocking?</SUBJECT>
                                </SUBPART>
                                <SUBPART>
                                    <HD SOURCE="HED">Subpart C—Exceptions That Involve Procedures for Fulfilling Requests to Access, Exchange, or use Electronic Health Information</HD>
                                    <SECTNO>171.300</SECTNO>
                                    <SUBJECT>Availability and effect of exceptions.</SUBJECT>
                                    <SECTNO>171.301</SECTNO>
                                    <SUBJECT>Content and manner exception—when will an actor's practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use electronic health information not be considered information blocking?</SUBJECT>
                                    <SECTNO>171.302</SECTNO>
                                    <SUBJECT>Fees exception—when will an actor's practice of charging fees for accessing, exchanging, or using electronic health information not be considered information blocking?</SUBJECT>
                                    <SECTNO>171.303</SECTNO>
                                    <SUBJECT>Licensing exception—when will an actor's practice to license interoperability elements in order for electronic health information to be accessed, exchanged, or used not be considered information blocking?</SUBJECT>
                                    <AUTH>
                                        <HD SOURCE="HED">Authority:</HD>
                                        <P>42 U.S.C. 300jj-52; 5 U.S.C. 552.</P>
                                    </AUTH>
                                </SUBPART>
                            </CONTENTS>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart A—General Provisions</HD>
                                <SECTION>
                                    <SECTNO>§ 171.100</SECTNO>
                                    <SUBJECT> Statutory basis and purpose.</SUBJECT>
                                    <P>
                                        (a) 
                                        <E T="03">Basis.</E>
                                         This part implements section 3022 of the Public Health Service Act, 42 U.S.C. 300jj-52.
                                    </P>
                                    <P>
                                        (b) 
                                        <E T="03">Purpose.</E>
                                         The purpose of this part is to establish exceptions for reasonable and necessary activities that do not constitute information blocking as defined by section 3022(a)(1) of the Public Health Service Act, 42 U.S.C. 300jj-52.
                                    </P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.101 </SECTNO>
                                    <SUBJECT>Applicability.</SUBJECT>
                                    <P>(a) This part applies to health care providers, health IT developers of certified health IT, health information exchanges, and health information networks, as those terms are defined in § 171.102.</P>
                                    <P>(b) Health care providers, health IT developers of certified health IT, health information exchanges, and health information networks must comply with this part on and after November 2, 2020.</P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.102 </SECTNO>
                                    <SUBJECT>Definitions.</SUBJECT>
                                    <P>For purposes of this part:</P>
                                    <P>
                                        <E T="03">Access</E>
                                         means the ability or means necessary to make electronic health information available for exchange or use.
                                    </P>
                                    <P>
                                        <E T="03">Actor</E>
                                         means a health care provider, health IT developer of certified health IT, health information network or health information exchange.
                                    </P>
                                    <P>
                                        <E T="03">API Information Source</E>
                                         is defined as it is in § 170.404(c).
                                    </P>
                                    <P>
                                        <E T="03">API User</E>
                                         is defined as it is in § 170.404(c).
                                    </P>
                                    <P>
                                        <E T="03">Certified API Developer</E>
                                         is defined as it is in § 170.404(c).
                                    </P>
                                    <P>
                                        <E T="03">Certified API technology</E>
                                         is defined as it is in § 170.404(c).
                                    </P>
                                    <P>
                                        <E T="03">Electronic health information (EHI)</E>
                                         means electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501, regardless of whether the group of records are used or maintained by or for a covered entity as defined in 45 CFR 160.103, but EHI shall not include:
                                    </P>
                                    <P>(1) Psychotherapy notes as defined in 45 CFR 164.501; or</P>
                                    <P>(2) Information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding.</P>
                                    <P>
                                        <E T="03">Exchange</E>
                                         means the ability for electronic health information to be transmitted between and among different technologies, systems, platforms, or networks.
                                    </P>
                                    <P>
                                        <E T="03">Fee</E>
                                         means any present or future obligation to pay money or provide any other thing of value.
                                    </P>
                                    <P>
                                        <E T="03">Health care provider</E>
                                         has the same meaning as “health care provider” in 42 U.S.C. 300jj.
                                    </P>
                                    <P>
                                        <E T="03">Health information network</E>
                                         or 
                                        <E T="03">health information exchange</E>
                                         means an individual or entity that determines, 
                                        <PRTPAGE P="25956"/>
                                        controls, or has the discretion to administer any requirement, policy, or agreement that permits, enables, or requires the use of any technology or services for access, exchange, or use of electronic health information:
                                    </P>
                                    <P>(1) Among more than two unaffiliated individuals or entities (other than the individual or entity to which this definition might apply) that are enabled to exchange with each other; and</P>
                                    <P>(2) That is for a treatment, payment, or health care operations purpose, as such terms are defined in 45 CFR 164.501 regardless of whether such individuals or entities are subject to the requirements of 45 CFR parts 160 and 164.</P>
                                    <P>
                                        <E T="03">Health IT developer of certified health IT</E>
                                         means an individual or entity, other than a health care provider that self-develops health IT for its own use, that develops or offers health information technology (as that term is defined in 42 U.S.C. 300jj(5)) and which has, at the time it engages in a practice that is the subject of an information blocking claim, one or more Health IT Modules certified under a program for the voluntary certification of health information technology that is kept or recognized by the National Coordinator pursuant to 42 U.S.C. 300jj-11(c)(5) (ONC Health IT Certification Program).
                                    </P>
                                    <P>
                                        <E T="03">Information blocking</E>
                                         is defined as it is in § 171.103.
                                    </P>
                                    <P>
                                        <E T="03">Interfere with</E>
                                         or 
                                        <E T="03">interference</E>
                                         means to prevent, materially discourage, or otherwise inhibit.
                                    </P>
                                    <P>
                                        <E T="03">Interoperability element</E>
                                         means hardware, software, integrated technologies or related licenses, technical information, privileges, rights, intellectual property, upgrades, or services that:
                                    </P>
                                    <P>(1) May be necessary to access, exchange, or use electronic health information; and</P>
                                    <P>(2) Is/Are controlled by the actor, which includes the ability to confer all rights and authorizations necessary to use the element to enable the access, exchange, or use of electronic health information.</P>
                                    <P>
                                        <E T="03">Permissible purpose</E>
                                         means a purpose for which a person is authorized, permitted, or required to access, exchange, or use electronic health information under applicable law.
                                    </P>
                                    <P>
                                        <E T="03">Person</E>
                                         is defined as it is in 45 CFR 160.103.
                                    </P>
                                    <P>
                                        <E T="03">Practice</E>
                                         means an act or omission by an actor.
                                    </P>
                                    <P>
                                        <E T="03">Use</E>
                                         means the ability for electronic health information, once accessed or exchanged, to be understood and acted upon.
                                    </P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.103 </SECTNO>
                                    <SUBJECT>Information blocking.</SUBJECT>
                                    <P>(a) Information blocking means a practice that—</P>
                                    <P>(1) Except as required by law or covered by an exception set forth in subpart B or subpart C of this part, is likely to interfere with access, exchange, or use of electronic health information; and</P>
                                    <P>(2) If conducted by a health information technology developer, health information network or health information exchange, such developer, network or exchange knows, or should know, that such practice is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information; or</P>
                                    <P>(3) If conducted by a health care provider, such provider knows that such practice is unreasonable and is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information.</P>
                                    <P>(b) Until May 2, 2022, electronic health information for purposes of paragraph (a) of this section is limited to the electronic health information identified by the data elements represented in the USCDI standard adopted in § 170.213.</P>
                                </SECTION>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart B—Exceptions That Involve Not Fulfilling Requests To Access, Exchange, or Use Electronic Health Information</HD>
                                <SECTION>
                                    <SECTNO>§ 171.200</SECTNO>
                                    <SUBJECT> Availability and effect of exceptions.</SUBJECT>
                                    <P>A practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in this subpart B by meeting all applicable requirements and conditions of the exception at all relevant times.</P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.201</SECTNO>
                                    <SUBJECT> Preventing harm exception—when will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to prevent harm not be considered information blocking?</SUBJECT>
                                    <P>An actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to prevent harm will not be considered information blocking when the practice meets the conditions in paragraphs (a) and (b) of this section, satisfies at least one condition from each of paragraphs (c), (d), and (f) of this section, and also meets the condition in paragraph (e) of this section when applicable.</P>
                                    <P>
                                        (a) 
                                        <E T="03">Reasonable belief.</E>
                                         The actor engaging in the practice must hold a reasonable belief that the practice will substantially reduce a risk of harm to a patient or another natural person that would otherwise arise from the access, exchange, or use of electronic health information affected by the practice. For purposes of this section, “patient” means a natural person who is the subject of the electronic health information affected by the practice.
                                    </P>
                                    <P>
                                        (b) 
                                        <E T="03">Practice breadth.</E>
                                         The practice must be no broader than necessary to substantially reduce the risk of harm that the practice is implemented to reduce.
                                    </P>
                                    <P>
                                        (c) 
                                        <E T="03">Type of risk.</E>
                                         The risk of harm must:
                                    </P>
                                    <P>
                                        (1) Be determined on an individualized basis in the exercise of professional judgment by a licensed health care professional who has a current or prior clinician-patient relationship with the patient whose electronic health information is affected by the determination; 
                                        <E T="03">or</E>
                                    </P>
                                    <P>(2) Arise from data that is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason.</P>
                                    <P>
                                        (d) 
                                        <E T="03">Type of harm.</E>
                                         The type of harm must be one that could serve as grounds for a covered entity (as defined in § 160.103 of this title) to deny access (as the term “access” is used in part 164 of this title) to an individual's protected health information under:
                                    </P>
                                    <P>(1) Section 164.524(a)(3)(iii) of this title where the practice is likely to, or in fact does, interfere with access, exchange, or use (as these terms are defined in § 171.102) of the patient's electronic health information by their legal representative (including but not limited to personal representatives recognized pursuant to 45 CFR 164.502) and the practice is implemented pursuant to an individualized determination of risk of harm consistent with paragraph (c)(1) of this section;</P>
                                    <P>(2) Section 164.524(a)(3)(ii) of this title where the practice is likely to, or in fact does, interfere with the patient's or their legal representative's access to, use or exchange (as these terms are defined in § 171.102) of information that references another natural person and the practice is implemented pursuant to an individualized determination of risk of harm consistent with paragraph (c)(1) of this section;</P>
                                    <P>
                                        (3) Section 164.524(a)(3)(i) of this title where the practice is likely to, or in fact does, interfere with the patient's access, exchange, or use (as these terms are defined in § 171.102) of their own electronic health information, regardless of whether the risk of harm that the practice is implemented to substantially reduce is consistent with paragraph (c)(1) or (2) of this section; or
                                        <PRTPAGE P="25957"/>
                                    </P>
                                    <P>(4) Section 164.524(a)(3)(i) of this title where the practice is likely to, or in fact does, interfere with a legally permissible access, exchange, or use (as these terms are defined in § 171.102) of electronic health information not described in paragraph (d)(1), (2), or (3) of this section, and regardless of whether the risk of harm the practice is implemented to substantially reduce is consistent with paragraph (c)(1) or (2) of this section.</P>
                                    <P>
                                        (e) 
                                        <E T="03">Patient right to request review of individualized determination of risk of harm.</E>
                                         Where the risk of harm is consistent with paragraph (c)(1) of this section, the actor must implement the practice in a manner consistent with any rights the individual patient whose electronic health information is affected may have under § 164.524(a)(4) of this title, or any Federal, State, or tribal law, to have the determination reviewed and potentially reversed.
                                    </P>
                                    <P>
                                        (f) 
                                        <E T="03">Practice implemented based on an organizational policy or a determination specific to the facts and circumstances.</E>
                                         The practice must be consistent with an organizational policy that meets paragraph (f)(1) of this section or, in the absence of an organizational policy applicable to the practice or to its use in particular circumstances, the practice must be based on a determination that meets paragraph (f)(2) of this section.
                                    </P>
                                    <P>(1) An organizational policy must:</P>
                                    <P>(i) Be in writing;</P>
                                    <P>(ii) Be based on relevant clinical, technical, and other appropriate expertise;</P>
                                    <P>(iii) Be implemented in a consistent and non-discriminatory manner; and</P>
                                    <P>(iv) Conform each practice to the conditions in paragraphs (a) and (b) of this section, as well as the conditions in paragraphs (c) through (e) of this section that are applicable to the practice and its use.</P>
                                    <P>(2) A determination must:</P>
                                    <P>(i) Be based on facts and circumstances known or reasonably believed by the actor at the time the determination was made and while the practice remains in use; and</P>
                                    <P>(ii) Be based on expertise relevant to implementing the practice consistent with the conditions in paragraphs (a) and (b) of this section, as well as the conditions in paragraphs (c) through (e) of this section that are applicable to the practice and its use in particular circumstances.</P>
                                </SECTION>
                                <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>
                                    <P>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 will not be considered information blocking when the practice meets all of the requirements of at least one of the sub-exceptions in paragraphs (b) through (e) of this section.</P>
                                    <P>
                                        (a) 
                                        <E T="03">Definitions in this section.</E>
                                         (1) The term 
                                        <E T="03">HIPAA Privacy Rule</E>
                                         as used in this section means 45 CFR parts 160 and 164.
                                    </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)(1) or (2) 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)(1) or (2) 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)(1) or (2) of this section or the individual's estate under State or other law.</P>
                                    <P>
                                        (b) 
                                        <E T="03">Sub-exception—precondition not satisfied.</E>
                                         To qualify for the exception on the basis that State or Federal law requires one or more preconditions for providing access, exchange, or use of electronic health information that have not been satisfied, the following requirements must be met—
                                    </P>
                                    <P>(1) The actor's practice is tailored to the applicable precondition not satisfied, is implemented in a consistent and non-discriminatory manner, and either:</P>
                                    <P>(i) Conforms to the actor's organizational policies and procedures that:</P>
                                    <P>(A) Are in writing;</P>
                                    <P>(B) Specify the criteria to be used by the actor to determine when the precondition would be satisfied and, as applicable, the steps that the actor will take to satisfy the precondition; and</P>
                                    <P>(C) Are implemented by the actor, including by providing training on the policies and procedures; or</P>
                                    <P>(ii) Are documented by the actor, on a case-by-case basis, identifying the criteria used by the actor to determine when the precondition would be satisfied, any criteria that were not met, and the reason why the criteria were not met.</P>
                                    <P>(2) If the precondition relies on the provision of a consent or authorization from an individual and the actor has received a version of such a consent or authorization that does not satisfy all elements of the precondition required under applicable law, the actor must:</P>
                                    <P>(i) Use reasonable efforts within its control to provide the individual with a consent or authorization form that satisfies all required elements of the precondition or provide other reasonable assistance to the individual to satisfy all required elements of the precondition; and</P>
                                    <P>(ii) Not improperly encourage or induce the individual to withhold the consent or authorization.</P>
                                    <P>(3) For purposes of determining whether the actor's privacy policies and procedures and actions satisfy the requirements of paragraphs (b)(1)(i) and (b)(2) above when the actor's operations are subject to multiple laws which have inconsistent preconditions, they shall be deemed to satisfy the requirements of the paragraphs if the actor has adopted uniform privacy policies and procedures to address the more restrictive preconditions.</P>
                                    <P>
                                        (c) 
                                        <E T="03">Sub-exception—health IT developer of certified health IT not covered by HIPAA.</E>
                                         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, the actor's organizational privacy policies must have been disclosed to the individuals and entities that use the actor's product or service before they agreed to use them, and must implement the practice according to a process described in the organizational privacy policies. The actor's organizational privacy policies must:
                                    </P>
                                    <P>(1) Comply with State and Federal laws, as applicable;</P>
                                    <P>(2) Be tailored to the specific privacy risk or interest being addressed; and</P>
                                    <P>(3) Be implemented in a consistent and non-discriminatory manner.</P>
                                    <P>
                                        (d) 
                                        <E T="03">Sub-exception</E>
                                        —
                                        <E T="03">denial of an individual's request for their electronic health information consistent with 45 CFR 164.524(a)(1) and (2).</E>
                                         If an individual requests electronic health information under the right of access provision under 45 CFR 164.524(a)(1) from an actor that must comply with 45 CFR 164.524(a)(1), the actor's practice 
                                        <PRTPAGE P="25958"/>
                                        must be consistent with 45 CFR 164.524(a)(2).
                                    </P>
                                    <P>
                                        (e) 
                                        <E T="03">Sub-exception—respecting an individual's request not to share information.</E>
                                         Unless otherwise required by law, 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>
                                    <P>(1) The individual requests that the actor not provide such access, exchange, or use of electronic health information without any improper encouragement or inducement of the request by the actor;</P>
                                    <P>(2) The actor documents the request within a reasonable time period;</P>
                                    <P>(3) The actor's practice is implemented in a consistent and non-discriminatory manner; and</P>
                                    <P>(4) An actor may terminate an individual's request for a restriction to not provide such access, exchange, or use of the individual's electronic health information only if:</P>
                                    <P>(i) The individual agrees to the termination in writing or requests the termination in writing;</P>
                                    <P>(ii) The individual orally agrees to the termination and the oral agreement is documented by the actor; or</P>
                                    <P>(iii) The actor informs the individual that it is terminating its agreement to not provide such access, exchange, or use of the individual's electronic health information except that such termination is:</P>
                                    <P>(A) Not effective to the extent prohibited by applicable Federal or State law; and</P>
                                    <P>(B) Only applicable to electronic health information created or received after the actor has so informed the individual of the termination.</P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.203</SECTNO>
                                    <SUBJECT> Security exception—when will an actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to protect the security of electronic health information not be considered information blocking?</SUBJECT>
                                    <P>An actor's practice that is likely to interfere with the access, exchange, or use of electronic health information in order to protect the security of electronic health information will not be considered information blocking when the practice meets the conditions in paragraphs (a), (b), and (c) of this section, and in addition meets either the condition in paragraph (d) of this section or the condition in paragraph (e) of this section.</P>
                                    <P>(a) The practice must be directly related to safeguarding the confidentiality, integrity, and availability of electronic health information.</P>
                                    <P>(b) The practice must be tailored to the specific security risk being addressed.</P>
                                    <P>(c) The practice must be implemented in a consistent and non-discriminatory manner.</P>
                                    <P>(d) If the practice implements an organizational security policy, the policy must—</P>
                                    <P>(1) Be in writing;</P>
                                    <P>(2) Have been prepared on the basis of, and be directly responsive to, security risks identified and assessed by or on behalf of the actor;</P>
                                    <P>(3) Align with one or more applicable consensus-based standards or best practice guidance; and</P>
                                    <P>(4) Provide objective timeframes and other parameters for identifying, responding to, and addressing security incidents.</P>
                                    <P>(e) If the practice does not implement an organizational security policy, the actor must have made a determination in each case, based on the particularized facts and circumstances, that:</P>
                                    <P>(1) The practice is necessary to mitigate the security risk to electronic health information; and</P>
                                    <P>(2) There are no reasonable and appropriate alternatives to the practice that address the security risk that are less likely to interfere with, prevent, or materially discourage access, exchange or use of electronic health information.</P>
                                </SECTION>
                                <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>An actor's practice of not fulfilling a request to access, exchange, or use electronic health information due to the infeasibility of the request will not be considered information blocking when the practice meets one of the conditions in paragraph (a) of this section and meets the requirements in paragraph (b) of this section.</P>
                                    <P>
                                        (a) 
                                        <E T="03">Conditions</E>
                                        —(1) 
                                        <E T="03">Uncontrollable events.</E>
                                         The actor cannot fulfill the request for access, exchange, or use of electronic health information due to a natural or human-made disaster, public health emergency, public safety incident, war, terrorist attack, civil insurrection, strike or other labor unrest, telecommunication or internet service interruption, or act of military, civil or regulatory authority.
                                    </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) Cannot be made available due to an individual's preference or because the electronic health information cannot be made available by law; or</P>
                                    <P>(ii) May be withheld in accordance with § 171.201.</P>
                                    <P>
                                        (3) 
                                        <E T="03">Infeasible under the circumstances.</E>
                                         (i) The actor demonstrates, prior to responding to the request pursuant to paragraph (b) of this section, through a contemporaneous written record or other documentation its consistent and non-discriminatory consideration of the following factors that led to its determination that complying with the request would be infeasible under the circumstances:
                                    </P>
                                    <P>(A) The type of electronic health information and the purposes for which it may be needed;</P>
                                    <P>(B) The cost to the actor of complying with the request in the manner requested;</P>
                                    <P>(C) The financial and technical resources available to the actor;</P>
                                    <P>(D) Whether the actor's practice is non-discriminatory and the actor provides the same access, exchange, or use of electronic health information to its companies or to its customers, suppliers, partners, and other persons with whom it has a business relationship;</P>
                                    <P>(E) Whether the actor owns or has control over a predominant technology, platform, health information exchange, or health information network through which electronic health information is accessed or exchanged; and</P>
                                    <P>(F) Why the actor was unable to provide access, exchange, or use of electronic health information consistent with the exception in § 171.301.</P>
                                    <P>(ii) In determining whether the circumstances were infeasible under paragraph (a)(3)(i) of this section, it shall not be considered whether the manner requested would have:</P>
                                    <P>(A) Facilitated competition with the actor.</P>
                                    <P>(B) Prevented the actor from charging a fee or resulted in a reduced fee.</P>
                                    <P>
                                        (b) 
                                        <E T="03">Responding to requests.</E>
                                         If an actor does not fulfill a request for access, exchange, or use of electronic health information for any of the reasons provided in paragraph (a) of this section, the actor must, within ten business days of receipt of the request, provide to the requestor in writing the reason(s) why the request is infeasible.
                                    </P>
                                </SECTION>
                                <SECTION>
                                    <PRTPAGE P="25959"/>
                                    <SECTNO>§ 171.205 </SECTNO>
                                    <SUBJECT>Health IT performance exception—when will an actor's practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of electronic health information not be considered information blocking?</SUBJECT>
                                    <P>An actor's practice that is implemented to maintain or improve health IT performance and that is likely to interfere with the access, exchange, or use of electronic health information will not be considered information blocking when the practice meets a condition in paragraph (a), (b), (c), or (d) of this section, as applicable to the particular practice and the reason for its implementation.</P>
                                    <P>
                                        (a) 
                                        <E T="03">Maintenance and improvements to health IT.</E>
                                         When an actor implements a practice that makes health IT under that actor's control temporarily unavailable, or temporarily degrades the performance of health IT, in order to perform maintenance or improvements to the health IT, the actor's practice must be—
                                    </P>
                                    <P>(1) Implemented for a period of time no longer than necessary to complete the maintenance or improvements for which the health IT was made unavailable or the health IT's performance degraded;</P>
                                    <P>(2) Implemented in a consistent and non-discriminatory manner; and</P>
                                    <P>(3) If the unavailability or degradation is initiated by a health IT developer of certified health IT, health information exchange, or health information network:</P>
                                    <P>
                                        (i) 
                                        <E T="03">Planned.</E>
                                         Consistent with existing service level agreements between the individual or entity to whom the health IT developer of certified health IT, health information exchange, or health information network supplied the health IT; or
                                    </P>
                                    <P>
                                        (ii) 
                                        <E T="03">Unplanned.</E>
                                         Consistent with existing service level agreements between the individual or entity; or agreed to by the individual or entity to whom the health IT developer of certified health IT, health information exchange, or health information network supplied the health IT.
                                    </P>
                                    <P>
                                        (b) 
                                        <E T="03">Assured level of performance.</E>
                                         An actor may take action against a third-party application that is negatively impacting the health IT's performance, provided that the practice is—
                                    </P>
                                    <P>(1) For a period of time no longer than necessary to resolve any negative impacts;</P>
                                    <P>(2) Implemented in a consistent and non-discriminatory manner; and</P>
                                    <P>(3) Consistent with existing service level agreements, where applicable.</P>
                                    <P>
                                        (c) 
                                        <E T="03">Practices that prevent harm.</E>
                                         If the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a risk of harm to a patient or another person, the actor does not need to satisfy the requirements of this section, but must comply with all requirements of § 171.201 at all relevant times to qualify for an exception.
                                    </P>
                                    <P>
                                        (d) 
                                        <E T="03">Security-related practices.</E>
                                         If the unavailability of health IT for maintenance or improvements is initiated by an actor in response to a security risk to electronic health information, the actor does not need to satisfy the requirements of this section, but must comply with all requirements of § 171.203 at all relevant times to qualify for an exception.
                                    </P>
                                </SECTION>
                            </SUBPART>
                            <SUBPART>
                                <HD SOURCE="HED">Subpart C—Exceptions That Involve Procedures for Fulfilling Requests To Access, Exchange, or Use Electronic Health Information</HD>
                                <SECTION>
                                    <SECTNO>§ 171.300</SECTNO>
                                    <SUBJECT> Availability and effect of exceptions.</SUBJECT>
                                    <P>A practice shall not be treated as information blocking if the actor satisfies an exception to the information blocking provision as set forth in this subpart C by meeting all applicable requirements and conditions of the exception at all relevant times.</P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.301 </SECTNO>
                                    <SUBJECT>Content and manner exception—when will an actor's practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use electronic health information not be considered information blocking?</SUBJECT>
                                    <P>An actor's practice of limiting the content of its response to or the manner in which it fulfills a request to access, exchange, or use electronic health information will not be considered information blocking when the practice meets all of the following conditions.</P>
                                    <P>
                                        (a) 
                                        <E T="03">Content condition—electronic health information.</E>
                                         An actor must respond to a request to access, exchange, or use electronic health information with—
                                    </P>
                                    <P>
                                        (1) 
                                        <E T="03">USCDI.</E>
                                         For up to May 2, 2022, at a minimum, the electronic health information identified by the data elements represented in the USCDI standard adopted in § 170.213.
                                    </P>
                                    <P>
                                        (2) 
                                        <E T="03">All electronic health information.</E>
                                         On and after May 2, 2022, electronic health information as defined in § 171.102.
                                    </P>
                                    <P>
                                        (b) 
                                        <E T="03">Manner condition</E>
                                        —(1) 
                                        <E T="03">Manner requested.</E>
                                         (i) An actor must fulfill a request described in paragraph (a) of this section in any manner requested, unless the actor is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request.
                                    </P>
                                    <P>(ii) If an actor fulfills a request described in paragraph (a) of this section in any manner requested:</P>
                                    <P>(A) Any fees charged by the actor in relation to fulfilling the response are not required to satisfy the exception in § 171.302; and</P>
                                    <P>(B) Any license of interoperability elements granted by the actor in relation to fulfilling the request is not required to satisfy the exception in § 171.303.</P>
                                    <P>
                                        (2) 
                                        <E T="03">Alternative manner.</E>
                                         If an actor does not fulfill a request described in paragraph (a) of this section in any manner requested because it is technically unable to fulfill the request or cannot reach agreeable terms with the requestor to fulfill the request, the actor must fulfill the request in an alternative manner, as follows:
                                    </P>
                                    <P>(i) The actor must fulfill the request without unnecessary delay in the following order of priority, starting with paragraph (b)(2)(i)(A) of this section and only proceeding to the next consecutive paragraph if the actor is technically unable to fulfill the request in the manner identified in a paragraph.</P>
                                    <P>(A) Using technology certified to standard(s) adopted in part 170 that is specified by the requestor.</P>
                                    <P>(B) Using content and transport standards specified by the requestor and published by:</P>
                                    <P>
                                        (
                                        <E T="03">1</E>
                                        ) The Federal Government; or
                                    </P>
                                    <P>
                                        (
                                        <E T="03">2</E>
                                        ) A standards developing organization accredited by the American National Standards Institute.
                                    </P>
                                    <P>(C) Using an alternative machine-readable format, including the means to interpret the electronic health information, agreed upon with the requestor.</P>
                                    <P>(ii) Any fees charged by the actor in relation to fulfilling the request are required to satisfy the exception in § 171.302.</P>
                                    <P>(iii) Any license of interoperability elements granted by the actor in relation to fulfilling the request is required to satisfy the exception in § 171.303.</P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.302</SECTNO>
                                    <SUBJECT> Fees exception—when will an actor's practice of charging fees for accessing, exchanging, or using electronic health information not be considered information blocking?</SUBJECT>
                                    <P>
                                        An actor's practice of charging fees, including fees that result in a reasonable profit margin, for accessing, exchanging, or using electronic health information will not be considered information blocking when the practice meets the conditions in paragraph (a) of this section, does not include any of the excluded fees in paragraph (b) of this section, and, as applicable, meets the condition in paragraph (c) of this section.
                                        <PRTPAGE P="25960"/>
                                    </P>
                                    <P>
                                        (a) 
                                        <E T="03">Basis for fees condition.</E>
                                         (1) The fees an actor charges must be—
                                    </P>
                                    <P>(i) Based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons or entities and requests;</P>
                                    <P>(ii) Reasonably related to the actor's costs of providing the type of access, exchange, or use of electronic health information to, or at the request of, the person or entity to whom the fee is charged;</P>
                                    <P>(iii) Reasonably allocated among all similarly situated persons or entities to whom the technology or service is supplied, or for whom the technology is supported; and</P>
                                    <P>(iv) Based on costs not otherwise recovered for the same instance of service to a provider and third party.</P>
                                    <P>(2) The fees an actor charges must not be based on—</P>
                                    <P>(i) Whether the requestor or other person is a competitor, potential competitor, or will be using the electronic health information in a way that facilitates competition with the actor;</P>
                                    <P>(ii) Sales, profit, revenue, or other value that the requestor or other persons derive or may derive from the access, exchange, or use of the electronic health information;</P>
                                    <P>(iii) Costs the actor incurred due to the health IT being designed or implemented in a non-standard way, unless the requestor agreed to the fee associated with the non-standard design or implementation to access, exchange, or use the electronic health information;</P>
                                    <P>(iv) Costs associated with intangible assets other than the actual development or acquisition costs of such assets;</P>
                                    <P>(v) Opportunity costs unrelated to the access, exchange, or use of electronic health information; or</P>
                                    <P>(vi) Any costs that led to the creation of intellectual property, if the actor charged a royalty for that intellectual property pursuant to § 171.303 and that royalty included the development costs for the creation of the intellectual property.</P>
                                    <P>
                                        (b) 
                                        <E T="03">Excluded fees condition.</E>
                                         This exception does not apply to—
                                    </P>
                                    <P>(1) A fee prohibited by 45 CFR 164.524(c)(4);</P>
                                    <P>(2) A fee based in any part on the electronic access of an individual's EHI by the individual, their personal representative, or another person or entity designated by the individual;</P>
                                    <P>(3) A fee to perform an export of electronic health information via the capability of health IT certified to § 170.315(b)(10) of this subchapter for the purposes of switching health IT or to provide patients their electronic health information; and</P>
                                    <P>(4) A fee to export or convert data from an EHR technology that was not agreed to in writing at the time the technology was acquired.</P>
                                    <P>
                                        (c) 
                                        <E T="03">Compliance with the Conditions of Certification condition.</E>
                                         Notwithstanding any other provision of this exception, if the actor is a health IT developer subject to the Conditions of Certification in § 170.402(a)(4), § 170.404, or both of this subchapter, the actor must comply with all requirements of such conditions for all practices and at all relevant times.
                                    </P>
                                    <P>
                                        (d) 
                                        <E T="03">Definition of Electronic access.</E>
                                         The following definition applies to this section:
                                    </P>
                                    <P>
                                        <E T="03">Electronic access</E>
                                         means an internet-based method that makes electronic health information available at the time the electronic health information is requested and where no manual effort is required to fulfill the request.
                                    </P>
                                </SECTION>
                                <SECTION>
                                    <SECTNO>§ 171.303 </SECTNO>
                                    <SUBJECT>Licensing exception—when will an actor's practice to license interoperability elements in order for electronic health information to be accessed, exchanged, or used not be considered information blocking?</SUBJECT>
                                    <P>An actor's practice to license interoperability elements for electronic health information to be accessed, exchanged, or used will not be considered information blocking when the practice meets all of the following conditions.</P>
                                    <P>
                                        (a) 
                                        <E T="03">Negotiating a license conditions.</E>
                                         Upon receiving a request to license an interoperability element for the access, exchange, or use of electronic health information, the actor must—
                                    </P>
                                    <P>(1) Begin license negotiations with the requestor within 10 business days from receipt of the request; and</P>
                                    <P>(2) Negotiate a license with the requestor, subject to the licensing conditions in paragraph (b) of this section, within 30 business days from receipt of the request.</P>
                                    <P>
                                        (b) 
                                        <E T="03">Licensing conditions.</E>
                                         The license provided for the interoperability element(s) needed to access, exchange, or use electronic health information must meet the following conditions:
                                    </P>
                                    <P>
                                        (1) 
                                        <E T="03">Scope of rights.</E>
                                         The license must provide all rights necessary to:
                                    </P>
                                    <P>(i) Enable the access, exchange, or use of electronic health information; and</P>
                                    <P>(ii) Achieve the intended access, exchange, or use of electronic health information via the interoperability element(s).</P>
                                    <P>
                                        (2) 
                                        <E T="03">Reasonable royalty.</E>
                                         If the actor charges a royalty for the use of the interoperability elements described in paragraph (a) of this section, the royalty must be reasonable and comply with the following requirements:
                                    </P>
                                    <P>(i) The royalty must be non-discriminatory, consistent with paragraph (c)(3) of this section.</P>
                                    <P>(ii) The royalty must be based solely on the independent value of the actor's technology to the licensee's products, not on any strategic value stemming from the actor's control over essential means of accessing, exchanging, or using electronic health information.</P>
                                    <P>(iii) If the actor has licensed the interoperability element through a standards developing organization in accordance with such organization's policies regarding the licensing of standards-essential technologies on terms consistent with those in this exception, the actor may charge a royalty that is consistent with such policies.</P>
                                    <P>(iv) An actor may not charge a royalty for intellectual property if the actor recovered any development costs pursuant to § 171.302 that led to the creation of the intellectual property.</P>
                                    <P>
                                        (3) 
                                        <E T="03">Non-discriminatory terms.</E>
                                         The terms (including royalty terms) on which the actor licenses and otherwise provides the interoperability elements must be non-discriminatory and comply with the following requirements:
                                    </P>
                                    <P>(i) The terms must be based on objective and verifiable criteria that are uniformly applied for all similarly situated classes of persons and requests.</P>
                                    <P>(ii) The terms must not be based in any part on—</P>
                                    <P>(A) Whether the requestor or other person is a competitor, potential competitor, or will be using electronic health information obtained via the interoperability elements in a way that facilitates competition with the actor; or</P>
                                    <P>(B) The revenue or other value the requestor may derive from access, exchange, or use of electronic health information obtained via the interoperability elements.</P>
                                    <P>
                                        (4) 
                                        <E T="03">Collateral terms.</E>
                                         The actor must not require the licensee or its agents or contractors to do, or to agree to do, any of the following—
                                    </P>
                                    <P>(i) Not compete with the actor in any product, service, or market.</P>
                                    <P>(ii) Deal exclusively with the actor in any product, service, or market.</P>
                                    <P>(iii) Obtain additional licenses, products, or services that are not related to or can be unbundled from the requested interoperability elements.</P>
                                    <P>(iv) License, grant, assign, or transfer to the actor any intellectual property of the licensee.</P>
                                    <P>
                                        (v) Pay a fee of any kind whatsoever, except as described in paragraph (b)(2) of this section, unless the practice meets 
                                        <PRTPAGE P="25961"/>
                                        the requirements of the exception in § 171.302.
                                    </P>
                                    <P>
                                        (5) 
                                        <E T="03">Non-disclosure agreement.</E>
                                         The actor may require a reasonable non-disclosure agreement that is no broader than necessary to prevent unauthorized disclosure of the actor's trade secrets, provided—
                                    </P>
                                    <P>(i) The agreement states with particularity all information the actor claims as trade secrets; and</P>
                                    <P>(ii) Such information meets the definition of a trade secret under applicable law.</P>
                                    <P>
                                        (c) 
                                        <E T="03">Additional conditions relating to the provision of interoperability elements.</E>
                                         The actor must not engage in any practice that has any of the following purposes or effects.
                                    </P>
                                    <P>(1) Impeding the efficient use of the interoperability elements to access, exchange, or use electronic health information for any permissible purpose.</P>
                                    <P>(2) Impeding the efficient development, distribution, deployment, or use of an interoperable product or service for which there is actual or potential demand.</P>
                                    <P>(3) Degrading the performance or interoperability of the licensee's products or services, unless necessary to improve the actor's technology and after affording the licensee a reasonable opportunity to update its technology to maintain interoperability.</P>
                                </SECTION>
                            </SUBPART>
                        </PART>
                    </REGTEXT>
                    <SIG>
                        <NAME>Alex M. Azar II,</NAME>
                        <TITLE>Secretary, Department of Health and Human Services.</TITLE>
                    </SIG>
                </SUPLINF>
                <FRDOC>[FR Doc. 2020-07419 Filed 4-21-20; 4:15 pm]</FRDOC>
                <BILCOD>BILLING CODE 4150-45-P</BILCOD>
            </RULE>
        </RULES>
    </NEWPART>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Rules and Regulations</UNITNAME>
    <NEWPART>
        <PTITLE>
            <PRTPAGE P="25963"/>
            <PARTNO>Part IV</PARTNO>
            <AGENCY TYPE="P">Securities and Exchange Commission</AGENCY>
            <CFR>17 CFR Parts 200, 230, 232, et al.</CFR>
            <TITLE>Updated Disclosure Requirements and Summary Prospectus for Variable Annuity and Variable Life Insurance Contracts; Final Rule</TITLE>
        </PTITLE>
        <RULES>
            <RULE>
                <PREAMB>
                    <PRTPAGE P="25964"/>
                    <AGENCY TYPE="S">SECURITIES AND EXCHANGE COMMISSION</AGENCY>
                    <CFR>17 CFR Parts 200, 230, 232, 239, 240, 270, and 274</CFR>
                    <DEPDOC>[Release Nos. 33-10765; 34-88358; IC-33814; File No. S7-23-18]</DEPDOC>
                    <RIN>RIN 3235-AK60</RIN>
                    <SUBJECT>Updated Disclosure Requirements and Summary Prospectus for Variable Annuity and Variable Life Insurance Contracts</SUBJECT>
                    <AGY>
                        <HD SOURCE="HED">AGENCY:</HD>
                        <P>Securities and Exchange Commission.</P>
                    </AGY>
                    <ACT>
                        <HD SOURCE="HED">ACTION:</HD>
                        <P>Final rule.</P>
                    </ACT>
                    <SUM>
                        <HD SOURCE="HED">SUMMARY:</HD>
                        <P>The Securities and Exchange Commission is adopting rule and form amendments intended to help investors make informed investment decisions regarding variable annuity and variable life insurance contracts. The amendments modernize disclosures by using a layered disclosure approach designed to provide investors with key information relating to the contract's terms, benefits, and risks in a concise and more reader-friendly presentation, with access to more detailed information available online and electronically or in paper format on request. New rule 498A under the Securities Act of 1933 will permit a person to satisfy its prospectus delivery obligations under the Securities Act for a variable annuity or variable life insurance contract by sending or giving a summary prospectus to investors and making the statutory prospectus available online. The rule also will consider a person to have met its prospectus delivery obligations for any portfolio companies associated with a variable annuity or variable life insurance contract if the portfolio company prospectuses are posted online. To implement the new disclosure framework, we are also amending the registration forms for variable annuity and variable life insurance contracts to update and enhance the disclosures to investors in these contracts, and to implement the proposed summary prospectus framework, and adopting amendments to our rules that will require variable contracts to use the Inline eXtensible Business Reporting Language (“Inline XBRL”) format for the submission of certain required disclosures in the variable contract statutory prospectus. The Commission is also taking the position that if an issuer of a discontinued contract that is discontinued as of July 1, 2020 that provides alternative disclosures does not file post-effective amendments to update a variable contract registration statement and does not provide updated prospectuses to existing investors, this would not provide a basis for enforcement action so long as investors are provided with the alternative disclosures or modernized alternative disclosures described below. We are also adopting certain technical and conforming amendments to our rules and forms, including amendments to rules relating to variable life insurance contracts, and rescinding certain related rules and forms.</P>
                    </SUM>
                    <EFFDATE>
                        <HD SOURCE="HED">DATES:</HD>
                        <P>
                            <E T="03">Effective dates:</E>
                             This rule is effective July 1, 2020, except:
                        </P>
                        <P>• Amendatory instructions 12, 46, 48, and 50 to 17 CFR 230.498A, Form N-3 (referenced in 17 CFR 239.17a and 274.11b), Form N-4 (referenced in 17 CFR 239.17b and 274.11c), and Form N-6 (referenced in 17 CFR 239.17c and 274.11d), which are effective January 1, 2022; and</P>
                        <P>• Effective July 1, 2020, amendatory instructions 20, 22, and 24 to Form N-3 (referenced in 17 CFR 239.17a and 274.11b), Form N-4 (referenced in 17 CFR 239.17b and 274.11c), and Form N-6 (referenced in 17 CFR 239.17c and 274.11d), published June 22, 2018, at 83 FR 29158, with an effective date of January 1, 2022, are withdrawn.</P>
                        <P>
                            <E T="03">Compliance dates:</E>
                             See Section II.G.
                        </P>
                    </EFFDATE>
                    <FURINF>
                        <HD SOURCE="HED">FOR FURTHER INFORMATION CONTACT:</HD>
                        <P>Daniel K. Chang, Pamela K. Ellis, Bradley Gude, James Maclean, Amy Miller (Senior Counsels) or Michael C. Pawluk (Senior Special Counsel), Investment Company Regulation Office, at (202) 551-6792; or Harry Eisenstein or Michael Kosoff (Senior Special Counsels), Disclosure Review and Accounting Office, at (202) 551-6921, Division of Investment Management, Securities and Exchange Commission, 100 F Street NE, Washington, DC 20549-8549.</P>
                    </FURINF>
                </PREAMB>
                <SUPLINF>
                    <HD SOURCE="HED">SUPPLEMENTARY INFORMATION:</HD>
                    <P>The Securities and Exchange Commission (“Commission”) is adopting 17 CFR 230.498A (new rule 498A) under the Securities Act. The Commission is also adopting amendments to the following rules:</P>
                    <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s100,xs96">
                        <BOXHD>
                            <CHED H="1">Commission reference</CHED>
                            <CHED H="1">
                                CFR citation
                                <LI>(17 CFR)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Organization; Conduct and Ethics; And Information and Requests</ENT>
                            <ENT>§§ 200.1 through 200.800.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Section 800</ENT>
                            <ENT>§ 200.800.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">
                                Securities Act of 1933 (“Securities Act”): 
                                <SU>1</SU>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 159A</ENT>
                            <ENT>§ 230.159A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 431</ENT>
                            <ENT>§ 230.431.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 482</ENT>
                            <ENT>§ 230.482.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 485</ENT>
                            <ENT>§ 230.485.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 496</ENT>
                            <ENT>§ 230.496.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 497</ENT>
                            <ENT>§ 230.497.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 498</ENT>
                            <ENT>§ 230.498.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-14</ENT>
                            <ENT>§ 239.23.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">Regulation S-T</ENT>
                            <ENT>§§ 232.10 through 232.501.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 11</ENT>
                            <ENT>§ 232.11.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 405</ENT>
                            <ENT>§ 232.405.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">
                                Securities Exchange Act of 1934 (“Exchange Act”): 
                                <SU>2</SU>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 14a-16</ENT>
                            <ENT>§ 240.14a-16.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 14a-101</ENT>
                            <ENT>§ 240.14a-101.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">
                                Investment Company Act of 1940 (“Investment Company Act”): 
                                <SU>3</SU>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 0-1</ENT>
                            <ENT>§ 270.0-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 6c-7</ENT>
                            <ENT>§ 270.6c-7.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 6c-8</ENT>
                            <ENT>§ 270.6c-8.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 6e-2</ENT>
                            <ENT>§ 270.6e-2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 6e-3 (former rule 6e-3(T))</ENT>
                            <ENT>§ 270.6e-3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 8b-1</ENT>
                            <ENT>§ 270.8b-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 11a-2</ENT>
                            <ENT>§ 270.11a-2.</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="25965"/>
                            <ENT I="02">Rule 14a-2</ENT>
                            <ENT>§ 270.14a-2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 26a-1</ENT>
                            <ENT>§ 270.26a-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27i-1 (former rule 27c-1)</ENT>
                            <ENT>§ 270.27i-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">Securities Act and Investment Company Act:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-3</ENT>
                            <ENT>§§ 239.17a and 274.11b.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-4</ENT>
                            <ENT>§§ 239.17b and 274.11c.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-6</ENT>
                            <ENT>§§ 239.17c and 274.11d.</ENT>
                        </ROW>
                        <TNOTE>
                            <SU>1</SU>
                             15 U.S.C. 77a 
                            <E T="03">et seq.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>2</SU>
                             15 U.S.C. 78a 
                            <E T="03">et seq.</E>
                        </TNOTE>
                        <TNOTE>
                            <SU>3</SU>
                             15 U.S.C. 80a 
                            <E T="03">et seq.</E>
                        </TNOTE>
                    </GPOTABLE>
                    <P>Finally, the Commission is rescinding:</P>
                    <GPOTABLE COLS="2" OPTS="L2,i1" CDEF="s100,xs96">
                        <BOXHD>
                            <CHED H="1">Commission reference</CHED>
                            <CHED H="1">
                                CFR citation
                                <LI>(17 CFR)</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="22">Investment Company Act:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 26a-2</ENT>
                            <ENT>§ 270.26a-2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27a-1</ENT>
                            <ENT>§ 270.27a-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27a-2</ENT>
                            <ENT>§ 270.27a-2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27a-3</ENT>
                            <ENT>§ 270.27a-3.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27d-2</ENT>
                            <ENT>§ 270.27d-2.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27e-1</ENT>
                            <ENT>§ 270.27e-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27f-1</ENT>
                            <ENT>§ 270.27f-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27g-1</ENT>
                            <ENT>§ 270.27g-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Rule 27h-1</ENT>
                            <ENT>§ 270.27h-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-27E-1</ENT>
                            <ENT>§ 274.127e-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-27F-1</ENT>
                            <ENT>§ 274.127f-1.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-27I-1</ENT>
                            <ENT>§ 274.302.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-27I-2</ENT>
                            <ENT>§ 274.303.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22">Securities Act and Investment Company Act:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="02">Form N-1</ENT>
                            <ENT>§§ 239.15 and 274.11.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD1">TABLE OF CONTENTS</HD>
                    <EXTRACT>
                        <FP SOURCE="FP-2">I. Introduction</FP>
                        <FP SOURCE="FP1-2">A. Background</FP>
                        <FP SOURCE="FP1-2">B. Overview of Final Rule and Rule and Form Amendments</FP>
                        <FP SOURCE="FP-2">II. Discussion</FP>
                        <FP SOURCE="FP1-2">A. New Option to Use a Summary Prospectus for Variable Contracts</FP>
                        <P>1. Initial Summary Prospectus</P>
                        <P>2. Updating Summary Prospectus</P>
                        <P>3. Interim Amendments to Contract Statutory Prospectuses</P>
                        <P>4. Legal Effect of Use of Summary Prospectus for Variable Contracts</P>
                        <P>5. Online Accessibility of Contract Statutory Prospectus and Certain Other Documents Relating to the Contract</P>
                        <P>6. Other Requirements for Summary Prospectus and Other Contract Documents</P>
                        <P>7. Incorporation by Reference</P>
                        <P>8. Filing Requirements for the Summary Prospectus</P>
                        <P>9. Defined Terms in Final Rule</P>
                        <P>B. Optional Method To Satisfy Portfolio Company Prospectus Delivery Requirements</P>
                        <P>1. Current Delivery Practices for Portfolio Company Prospectuses</P>
                        <P>2. New Option To Satisfy Prospectus Delivery Requirements</P>
                        <P>C. Amendments to Registration Forms</P>
                        <P>1. General Instructions</P>
                        <P>2. Part A (Information Required in a Prospectus)</P>
                        <P>3. Part B (Information Required in a Statement of Additional Information)</P>
                        <P>4. Part C (Other Information)</P>
                        <P>5. Guidelines</P>
                        <P>D. Inline XBRL</P>
                        <P>E. Discontinued Variable Contracts</P>
                        <P>1. Background</P>
                        <P>2. Comments Received on Proposal</P>
                        <P>3. Commission Position on Existing Contracts Whose Issuers Provide Alternative Disclosures to Investors</P>
                        <P>4. Commission Declines To Adopt Going-Forward Relief</P>
                        <P>F. Technical and Conforming Amendments to Other Aspects of the Regulatory Framework for Variable Contracts</P>
                        <P>G. Compliance Dates</P>
                        <FP SOURCE="FP-2">III. Other Matters</FP>
                        <FP SOURCE="FP-2">IV. Economic Analysis</FP>
                        <P>A. Introduction</P>
                        <P>B. Economic Baseline</P>
                        <P>1. Overview of Variable Products Market</P>
                        <P>2. Statutory and Regulatory Disclosure Requirements</P>
                        <P>C. Benefits and Costs of the Rule and Form Amendments</P>
                        <P>1. Optional Summary Prospectus Regime</P>
                        <P>2. Treatment of Discontinued Variable Contracts</P>
                        <P>3. Changes to Forms N-3, N-4, and N-6</P>
                        <P>4. Inline XBRL</P>
                        <P>D. Effects on Efficiency, Competition, and Capital Formation</P>
                        <P>E. Reasonable Alternatives</P>
                        <P>1. Mandating Summary Prospectuses</P>
                        <P>2. Summary Prospectuses Delivered with Statutory Prospectuses</P>
                        <P>3. Contract-Specific Updating Summary Prospectuses</P>
                        <P>4. Do Not Provide Updating Summary Prospectuses</P>
                        <P>5. Inline XBRL</P>
                        <P>6. Alternatives to Form N-3, N-4, and N-6 Amendments</P>
                        <P>7. Requiring All Variable Contracts (Including Currently Discontinued Contracts) To Prepare Updated Registration Statements and Deliver Statutory or Summary Prospectuses</P>
                        <P>8. Alternatives to Commission's Position on Alternative Disclosure Contracts</P>
                        <FP SOURCE="FP-2">V. Paperwork Reduction Act</FP>
                        <P>A. Form N-3</P>
                        <P>B. Form N-4</P>
                        <P>C. Form N-6</P>
                        <P>D. Investment Company Interactive Data</P>
                        <P>E. Rule 498A</P>
                        <FP SOURCE="FP-2">VI. Regulatory Flexibility Act Certification</FP>
                        <P>VII. Statutory Authority</P>
                    </EXTRACT>
                    <HD SOURCE="HD1">I. Introduction</HD>
                    <P>
                        The Securities and Exchange Commission is adopting rule and form amendments that are intended to help investors make informed investment decisions regarding variable annuity 
                        <FTREF/>
                        <SU>4</SU>
                          
                        <PRTPAGE P="25966"/>
                        and variable life insurance contracts 
                        <SU>5</SU>
                        <FTREF/>
                         (together, “variable contracts” or “contracts”).
                        <SU>6</SU>
                        <FTREF/>
                         To improve the current disclosure framework and update the manner in which variable contract investors receive and review prospectuses and related information, we are adopting new rule 498A under the Securities Act that permits the use of a summary prospectus to satisfy statutory prospectus delivery obligations, along with other rule and form amendments intended to implement the summary prospectus framework. Investors will have access to the contract statutory prospectus and other information about the contract online (and could receive paper or electronic copies upon request), which will provide more-detailed information about the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>4</SU>
                             Variable annuities allow investors to receive periodic payments for either a definite period (
                            <E T="03">e.g.,</E>
                             20 years), or for an indefinite period (
                            <E T="03">e.g.,</E>
                             the life of the investor), and also provide a basic death benefit to protect the investor's beneficiaries. The 
                            <PRTPAGE/>
                            investor may allocate the cash value of the purchase payments to a range of investment options available under the contract, including in some cases, to a fixed account option that pays a fixed or minimum rate of interest. The investor's account value changes depending on the performance of the investment options the investor has selected.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>5</SU>
                             Variable life insurance contracts offer a death benefit to the investor that may be significantly larger than the amount of premiums paid, as well as the ability to accumulate cash value. Like variable annuities, a variable life insurance contract permits the investor to allocate their cash value to a variety of investment options. Because an investor will generally allocate the insurance premiums to the investment options, the investor is exposed to market risk and the cash value (and in some cases, the death benefit) will vary with the performance of these investments.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>6</SU>
                             The Commission proposed these rule and form amendments in October 2018. 
                            <E T="03">See</E>
                             Updating Disclosure Requirements and Summary Prospectus for Variable Annuity and Variable Life Insurance Contracts, Investment Company Release No. 33286 (Oct. 30, 2018) [83 FR 61730 (Nov. 30, 2018)] (“Proposing Release”).
                        </P>
                    </FTNT>
                    <P>Specifically, the approach under the new rule contemplates the use of two types of summary prospectuses: An “initial summary prospectus” to be provided to new investors, and an “updating summary prospectus” to be provided to existing investors. To help investors make an informed investment decision, each type of summary prospectus uses a layered disclosure approach designed to provide investors with key information relating to the contract's terms, benefits, and risks in a concise and more reader-friendly presentation, with website addresses or hyperlinks to more detailed information posted online and delivered electronically or in paper format on request.</P>
                    <P>To implement this new disclosure framework, we are also amending the registration forms for variable annuity and variable life insurance contracts to update and enhance the disclosures to investors in these contracts, and requiring variable contracts to use the Inline eXtensible Business Reporting Language (“Inline XBRL”) format for the submission of certain required disclosures in the variable contract statutory prospectus.</P>
                    <P>In proposing new rule 498A, the Commission discussed and solicited comment on approaches it was considering that could affect, and raise the possibility of future amendments to, certain parallel provisions of rule 498 and certain of our registration forms applicable to other types of registered investment companies. While we are not taking any such parallel actions in this document, Commission staff is currently considering the comments received and reviewing the disclosure regime for investment companies as to these and other potential amendments as part of a broader modernization initiative.</P>
                    <HD SOURCE="HD1">A. Background</HD>
                    <P>
                        To meet life insurance needs and retirement or other financial goals, investors may consider variable contracts as a way of combining insurance guarantees with the potential for long-term investment appreciation.
                        <SU>7</SU>
                        <FTREF/>
                         Variable contracts are generally more complex than other retail investment products, such as mutual funds, in a variety of ways:
                    </P>
                    <FTNT>
                        <P>
                            <SU>7</SU>
                             For an overview of variable annuities and variable life insurance contracts, 
                            <E T="03">see</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section I.A.
                        </P>
                        <P>
                             The average contract value for individual variable annuities is approximately $106,187. 
                            <E T="03">See</E>
                             Insured Retirement Institute, 
                            <E T="03">IRI Fact Book 2019</E>
                             (“IRI Fact Book”), at 167. Americans who own annuities have a median annual household income of $64,000 (80% have total annual household incomes below $100,000). Most individual annuity owners are retired. Although the average age of an annuity owner is 70, the average age at which owners purchased their first annuity is 51. 
                            <E T="03">See</E>
                             The Gallup Organization and Mathew Greenwald &amp; Associates for The Committee of Annuity Insurers, 
                            <E T="03">Survey of Owners of Individual Annuity Contracts</E>
                             (2013) (“Gallup Survey”), at 8-9. There is limited data available regarding variable life insurance contracts, but based upon the data that is available, the Commission believes that the demographics of investors for those products are likely comparable.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Structure.</E>
                         Variable contracts combine both investment and insurance features. Investors generally allocate their purchase payments to a range of investment options, and the investor's account value changes depending on the performance of the investment options selected. For most variable contracts, these investment options typically are mutual funds, which are separately registered and have their own prospectuses.
                        <SU>8</SU>
                        <FTREF/>
                         In addition, variable contracts frequently offer a menu of optional benefits that an investor may select to customize the contract to meet his or her individual needs.
                        <SU>9</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>8</SU>
                             For purposes of this release, we refer to these entities as “portfolio companies.”
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>9</SU>
                             Variable contracts commonly offer optional benefit features as riders to the contract with their own terms and conditions, and typically for a separate charge. Riders commonly provide enhanced death benefits, as well as “living benefits” that may be designed to provide protection against declines in account value, longevity risk, or other risks, or to cover financial losses that result from illness, incapacity, or injury. These optional riders have become increasingly popular with variable contract investors. 
                            <E T="03">See, e.g.,</E>
                             IRI Fact Book, 
                            <E T="03">supra</E>
                             note 7, at 70 (“Approximately $1.8 trillion of VA assets were held by insurance companies as of the end of the fourth quarter of 2018, with an estimated $800 billion in assets under a guaranteed income benefit.”); Gallup Survey, 
                            <E T="03">supra</E>
                             note 7, at 21 (stating that “[n]early eight in ten annuity owners (79%) who own a variable annuity report that their contract has a guaranteed lifetime withdrawal benefit.”).
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Fees and Expenses.</E>
                         Most variable contracts have two-level fee structures, where fees are assessed at both the contract level by the issuer (including mortality and expense risk charges,
                        <SU>10</SU>
                        <FTREF/>
                         administrative fees, and fees for optional benefits selected by the investor) and at the portfolio company level.
                        <SU>11</SU>
                        <FTREF/>
                         Transactional charges may also apply, some of which could be substantial, for example, in the case of withdrawals made from a contract prior to a specified number of years.
                        <SU>12</SU>
                        <FTREF/>
                         Variable life insurance contracts also impose an additional insurance charge to cover the cost of the death benefit.
                        <SU>13</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>10</SU>
                             The mortality and expense (“M&amp;E”) risk charge, which is based on an investor's account value, compensates the insurance company for offering certain contract features (
                            <E T="03">e.g.,</E>
                             death benefit or annuitization) and is sometimes used to pay some or all of the insurance company's costs to sell the contract (
                            <E T="03">e.g.,</E>
                             commissions). Typical M&amp;E charges are approximately 1.25% of account value per year for variable annuities, and 0.90% for variable life insurance. 
                            <E T="03">See</E>
                             Morningstar M&amp;E Risk definition, 
                            <E T="03">available at https://awgmain.morningstar.com/webhelp/glossary_definitions/va_vl/pol_M_E_Risk.html.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>11</SU>
                             Investors indirectly bear the operating fees and expenses of the portfolio companies they select as the underlying investments in their variable contracts.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>12</SU>
                             A contract may impose a “surrender charge” if, after purchase payments are made, an investor withdraws money from the contract during a stated period typically ranging from six to ten (or even more) years.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>13</SU>
                             These additional insurance charges are determined at the time the contract is written and vary based on the insured's personal characteristics, such as age and health. These charges are in addition to the M&amp;E risk charge discussed above. 
                            <E T="03">See supra</E>
                             note 10.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Taxes.</E>
                         Special tax rules apply to variable products, with both tax advantages and potential adverse tax impacts in certain circumstances.
                        <SU>14</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>14</SU>
                             For example, assets within a variable contract grow tax-deferred, and transfers between investment options under the contract are not taxable events. However, investors may face a 10% federal income tax penalty if money is withdrawn before the investor reaches 59
                            <FR>1/2</FR>
                             years old. For these and other reasons, a variable contract generally is sold as a long-term investment.
                        </P>
                    </FTNT>
                    <PRTPAGE P="25967"/>
                    <P>
                        Investors should understand the features, risks, and charges associated with any potential investment. Providing investors with key information is particularly important in the context of variable contracts, since their structure is typically more complex than other types of investment products. The operation of and terminology associated with these products can be difficult for investors to understand. Moreover, variable contract prospectuses are often quite lengthy (frequently more than one hundred pages), particularly in the case of products that include optional benefits. It is also common for insurers to describe different versions of the contract in one prospectus, some of which may no longer be available to new investors, leaving investors to wade through a lengthy document to find disclosures relevant to the particular contract that they purchased or are considering purchasing.
                        <SU>15</SU>
                        <FTREF/>
                         Because insurers issuing variable contracts typically bundle prospectuses for the underlying portfolio companies together with the variable contract prospectus, the disclosures that investors receive at the time of the initial purchase and on an annual basis thereafter can be voluminous.
                        <SU>16</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>15</SU>
                             For a discussion of the requirements for variable contract prospectus disclosure and delivery, 
                            <E T="03">see</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section I.B.1.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>16</SU>
                             For example, variable annuity contracts offer an average of 60 investment options, with some contracts offering more than 250 investment options. 
                            <E T="03">See</E>
                             IRI Fact Book, 
                            <E T="03">supra</E>
                             note 7, at 167. Furthermore, variable life insurance contracts offer an average of 65 investment options, with some contracts offering more than 300 investment options. These variable life figures are based on September 2019 data obtained from Morningstar Direct.
                        </P>
                    </FTNT>
                    <P>
                        We are concerned that the volume, format, and content of disclosures in the variable contract context may make it difficult for some investors to find and understand key information that they need to make an informed investment decision. Based on our experience with both layered disclosure (under the mutual fund summary prospectus) 
                        <SU>17</SU>
                        <FTREF/>
                         and integrated disclosure (enhanced over a decade ago with securities offering reform for corporate issuers),
                        <SU>18</SU>
                        <FTREF/>
                         our more than twenty years of experience with the use of the internet as a medium to provide information to investors,
                        <SU>19</SU>
                        <FTREF/>
                         and on our investor testing efforts, outreach, and other empirical research concerning investors' preferences, the Commission proposed a summary prospectus framework for variable contracts using summary and layered disclosure principles.
                        <SU>20</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>17</SU>
                             Enhanced Disclosure and New Prospectus Delivery Option for Registered Open-End Management Investment Companies, Investment Company Act Release No. 28584 (Jan. 13, 2009) [74 FR 4546 (Jan. 26, 2009)] (“2009 Summary Prospectus Adopting Release”) (permitting the use of a summary prospectus by registered open-end management investment companies).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>18</SU>
                             Securities Offering Reform, Securities Act Release No. 8591 (July 19, 2005) [70 FR 44722 (Aug. 3, 2005)] (“Securities Offering Reform”) at n.202 and accompanying text (allowing the use of free writing prospectuses to provide information to investors and stating that a free writing prospectus is a permitted prospectus for purposes of Section 10(b) of the Securities Act and, as such, can be used without violating Section 5(b)(1) of the Securities Act).
                        </P>
                        <P>
                            Additionally, Congress recently required the Commission to extend securities offering reform to closed-end funds (
                            <E T="03">see</E>
                             Section 509 of the Economic Growth, Recovery Relief, and Consumer Protection Act, Pub. L. 115-174, 132 Stat. 1296 (2018)), and to business development companies (
                            <E T="03">see</E>
                             Section 803 of the Small Business Credit Availability Act, Pub. L. 115-141, 132 Stat. 348 (2018)). The Commission proposed such rules in 2019. 
                            <E T="03">See</E>
                             Securities Offering Reform for Closed-End Investment Companies, Investment Company Act Release No. 33427 (Mar. 20, 2019) [84 FR 14448 (Apr. 10, 2019)] (“Closed-End Offering Reform Release”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>19</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Use of Electronic Media for Delivery Purposes, Investment Company Act Release No. 21399 (Oct. 6, 1995) [60 FR 53458 (Oct. 13, 1995)] (“1995 Release”) (providing Commission views on the use of electronic media to deliver information to investors, with a focus on electronic delivery of prospectuses, annual reports, and proxy solicitation materials); Use of Electronic Media by Broker-Dealers, Transfer Agents, and Investment Advisers for Delivery of Information; Additional Examples Under the Securities Act of 1933, Securities Exchange Act of 1934, and Investment Company Act of 1940, Investment Company Act Release No. 21945 (May 9, 1996) [61 FR 24644 (May 15, 1996)] (“1996 Release”) (providing Commission views on electronic delivery of required information by broker-dealers, transfer agents, and investment advisers); Use of Electronic Media, Investment Company Act Release No. 24426 (Apr. 28, 2000) [65 FR 25843 (May 4, 2000)] (“2000 Release”) (providing updated interpretive guidance on the use of electronic media to deliver documents on matters such as telephonic and global consent, issuer liability for website content, and legal principles that should be considered in conducting online offerings).
                        </P>
                        <P>
                            <E T="03">See also</E>
                             Securities Offering Reform, 
                            <E T="03">supra</E>
                             note 18 (adopting rule 172 under the Securities Act providing an “access equals delivery” framework under which issuers and intermediaries can satisfy their final prospectus delivery obligations); Shareholder Choice Regarding Proxy Materials, Investment Company Act Release No. 27911 (July 26, 2007) [72 FR 42222 (Aug. 1, 2007)] (“Shareholder Choice Regarding Proxy Materials”) (adopting rule amendments requiring issuers to post their proxy materials on a specified website and provide shareholders with a notice of internet availability of the materials); Optional Internet Availability of Investment Company Shareholder Reports, Investment Company Act Release No. 33115 (June 5, 2018) [83 FR 29158 (June 22, 2018)] (“Investment Company Shareholder Reports Release”) (adopting 17 CFR 270.30e-3 (new rule 30e-3 under the Investment Company Act) and related rule amendments that, subject to conditions, provide certain registered investment companies, including registrants on Forms N-3, N-4, and N-6, with an optional method to transmit shareholder reports by making such reports and other materials accessible at a website address specified in a notice to investors).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>20</SU>
                             For a discussion of the evolution of layered disclosure and the delivery of information to investors, including the Commission's and the staff's investor testing efforts, outreach, and other empirical research concerning investor preferences, 
                            <E T="03">see</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section I.B.2.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">B. Overview of Final Rule and Rule and Form Amendments</HD>
                    <P>
                        We are adopting a new disclosure framework that, among other things, permits the use of summary prospectuses for variable contracts, with additional information available to investors online. To help investors make an informed investment decision, the new framework uses a layered disclosure approach designed to provide investors with key information relating to the contract's terms, benefits, and risks in a concise and more reader-friendly presentation, with access to more detailed information available online, or delivered in paper or electronic format on request. We anticipate that the framework will improve investor understanding of variable contracts. The mutual fund industry has widely adopted the use of summary prospectuses, and we expect our proposed prospectus delivery approach similarly will be widely adopted by issuers of variable contracts.
                        <SU>21</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>21</SU>
                             We estimate that as of December 31, 2018, approximately 93% of mutual funds and ETFs use summary prospectuses. This estimate is based on EDGAR data for the number of mutual funds and ETFs that filed a summary prospectus in 2018 (10,808) and the Investment Company Institute's estimated number of mutual funds and ETFs as of December 31, 2018 (11,656). 
                            <E T="03">See</E>
                             Investment Company Institute, 2019 Investment Company Fact Book (2019), at 50, 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.ici.org/pdf/2019_factbook.pdf.</E>
                        </P>
                    </FTNT>
                    <P>
                        New rule 498A builds upon our experience creating a summary prospectus option for mutual funds in 2009, but with certain differences intended to reflect the nature of variable contracts.
                        <SU>22</SU>
                        <FTREF/>
                         Like the Commission's mutual fund summary prospectus rule, the summary prospectus under rule 498A is meant to highlight key information of variable contracts that we believe will help an investor make an informed investment decision.
                        <SU>23</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>22</SU>
                             However, the final rule departs from rule 498 in requiring two separate types of summary prospectuses. 
                            <E T="03">See infra</E>
                             Sections II.A.1 and II.A.2. We designed this framework to distinguish the information we believe new and existing investors need, and to highlight the contract features and risks that are particularly relevant to these two groups of investors, taking into account information that we understand these investors may receive through other channels (
                            <E T="03">e.g.,</E>
                             as a result of state insurance law, other regulatory requirements, and industry practice).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>23</SU>
                             The mutual fund summary prospectus rule is designed to provide investors with “streamlined and user friendly information that is key to an investment decision.” 
                            <E T="03">See</E>
                             Enhanced Disclosure and New Prospectus Delivery Option for Registered Open-End Management Investment Companies, 
                            <PRTPAGE/>
                            Investment Company Act Release No. 28064 (Nov. 21, 2007) [72 FR 67790 (Nov. 30, 2007)] (“2007 Summary Prospectus Proposing Release”), at Section I; 
                            <E T="03">see also</E>
                             Richard J. Wirth, 
                            <E T="03">What's Puzzling You . . . Is the Nature of Variable Annuity Prospectuses,</E>
                             34 Western New England Law Review 127 (2012) (“Informed decision-making demands that consumers have enough of an understanding of what's for sale and what trade-offs are being asked of them in order to make an informed decision about whether or not to buy a product.”).
                        </P>
                    </FTNT>
                    <PRTPAGE P="25968"/>
                    <P>Because variable contracts typically include a number of optional benefits and underlying investment options, a summary could not, by its nature, include all relevant aspects and details regarding each of these contract features. The variable contract summary prospectus is designed to be a succinct summary of the contract's key terms and benefits and most significant risks, making it easier to read and more understandable for investors. This summary prospectus will serve as the cornerstone of a layered disclosure framework that alerts investors to the availability of more detailed information in the statutory prospectus and in other locations, and will be tailored to the unique aspects of these products. As a result, investors will have ready access to key information in connection with an investment decision.</P>
                    <P>The main elements of the new disclosure framework include:</P>
                    <P>
                        • 
                        <E T="03">Option to use summary prospectus.</E>
                        <SU>24</SU>
                        <FTREF/>
                         New rule 498A permits the use of two distinct types of contract summary prospectuses: (1) Initial summary prospectuses covering variable contracts currently offered to new investors; and (2) updating summary prospectuses for existing investors. The initial summary prospectus will include certain key information about the contract's most salient features, benefits, and risks, presented in plain English in a standardized order. The updating summary prospectus will include a brief description of certain changes to the contract that occurred during the previous year, as well as a subset of the information required to be in the initial summary prospectus. Certain key information about the portfolio companies will be provided in both the initial summary prospectus and updating summary prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>24</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Availability of variable contract statutory prospectus and other materials.</E>
                        <SU>25</SU>
                        <FTREF/>
                         New rule 498A requires the variable contract statutory prospectus, as well as the contract's statement of additional information (“SAI”), to be publicly accessible, free of charge, at a website address specified on or hyperlinked in the cover of the summary prospectus. An investor who receives a contract summary prospectus may request the contract statutory prospectus and SAI to be sent in paper or electronically, at no cost to the investor.
                    </P>
                    <FTNT>
                        <P>
                            <SU>25</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.5.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Optional method to satisfy portfolio company prospectus delivery requirements.</E>
                        <SU>26</SU>
                        <FTREF/>
                         New rule 498A provides an optional method for satisfying portfolio company prospectus delivery obligations by making portfolio company summary and statutory prospectuses available online at the website address specified on or hyperlinked in the variable contract summary prospectus, with certain key information about the portfolio companies provided in the variable contract's summary prospectus.
                        <SU>27</SU>
                        <FTREF/>
                         Investors may request and receive those disclosures in paper or electronically at no cost. This new option for satisfying portfolio company prospectus delivery requirements is only available for portfolio companies available as investment options through variable contracts that use contract summary prospectuses.
                    </P>
                    <FTNT>
                        <P>
                            <SU>26</SU>
                             
                            <E T="03">See infra</E>
                             Section II.B.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>27</SU>
                             This option will not apply to Form N-3 registrants, which do not have underlying portfolio companies due to their single-tier investment company structure.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Form amendments.</E>
                        <SU>28</SU>
                        <FTREF/>
                         We are amending Forms N-3, N-4, and N-6—the registration forms for variable contracts—to update and enhance the disclosure regime for these investment products.
                        <SU>29</SU>
                        <FTREF/>
                         The amendments are intended to consolidate certain summary information in a condensed presentation, reflect industry developments (
                        <E T="03">e.g.,</E>
                         the prevalence of optional benefits in today's variable contracts), and otherwise improve disclosures provided to variable contract investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>28</SU>
                             
                            <E T="03">See infra</E>
                             Section II.C.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>29</SU>
                             The Commission first adopted the registration form for variable annuities over 30 years ago, and adopted the registration form for variable life insurance over 15 years ago. 
                            <E T="03">See</E>
                             Registration Forms for Insurance Company Separate Accounts that Offer Variable Annuity Contracts, Investment Company Act Release No. 14575 (June 14, 1985) [50 FR 26145 (June 25, 1985)] (“Forms N-3 and N-4 Adopting Release”); Registration Form for Insurance Company Separate Accounts Registered as Unit Investment Trusts That Offer Variable Life Insurance Policies, Investment Company Act Release No. 25522 (Apr. 12, 2002) [67 FR 19848 (Apr. 23, 2002)] (“Separate Accounts Offering Variable Life Release”).
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Inline XBRL.</E>
                        <SU>30</SU>
                        <FTREF/>
                         With respect to contracts currently offered to new investors, registrants will be required to use the Inline XBRL format for the submission of certain information. This requirement is intended to harness technology to provide a mechanism for allowing investors, Commission staff, data aggregators, financial analysts, and other data users to efficiently analyze and compare the available information about variable contracts, as required by their particular needs and circumstances.
                    </P>
                    <FTNT>
                        <P>
                            <SU>30</SU>
                             
                            <E T="03">See infra</E>
                             Section II.D.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Discontinued Variable Contracts.</E>
                        <SU>31</SU>
                        <FTREF/>
                         We are taking the position that if an issuer of a discontinued contract that is discontinued as of July 1, 2020 that provides alternative disclosures does not file post-effective amendments to update a variable contract registration statement and does not provide updated prospectuses to existing investors, this would not provide a basis for enforcement action so long as investors are provided with the alternative disclosures or modernized alternative disclosures described below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>31</SU>
                             
                            <E T="03">See infra</E>
                             Section II.E.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Other Amendments.</E>
                        <SU>32</SU>
                        <FTREF/>
                         We are adopting certain technical and conforming amendments to our rules to reflect the proposed new regime for variable contract summary prospectuses. We are also adopting certain technical amendments to rules relating to variable life insurance contracts, as well as rescinding certain rules and forms.
                    </P>
                    <FTNT>
                        <P>
                            <SU>32</SU>
                             
                            <E T="03">See infra</E>
                             Section II.F.
                        </P>
                    </FTNT>
                    <P>Table 1 summarizes the various requirements—under the current prospectus delivery regime, and under the new optional summary prospectus regime—for information to either be (1) delivered to all investors, (2) made available online, or (3) delivered to those investors who so request:</P>
                    <GPH SPAN="3" DEEP="344">
                        <PRTPAGE P="25969"/>
                        <GID>ER01MY20.000</GID>
                    </GPH>
                    <HD SOURCE="HD1">II. Discussion</HD>
                    <HD SOURCE="HD2">A. New Option To Use a Summary Prospectus for Variable Contracts</HD>
                    <P>We are adopting, substantially as proposed, new rule 498A, which provides a new option for a person to satisfy its prospectus delivery obligations for variable contracts under Section 5(b)(2) of the Securities Act by: (1) Sending or giving to new investors key information contained in a variable contract statutory prospectus in the form of an initial summary prospectus; (2) sending or giving to existing investors each year a brief description of certain changes to the contract, and a subset of the information in the initial summary prospectus, in the form of an updating summary prospectus; and (3) providing the statutory prospectus and other materials online. Under the new rule, a registrant (or the financial intermediary distributing the variable contract) relying on the rule must send the variable contract statutory prospectus and other materials to an investor in paper or electronic format upon request.</P>
                    <P>
                        Commenters broadly supported our proposed layered disclosure approach.
                        <SU>33</SU>
                        <FTREF/>
                         One commenter stated that “a layered disclosure approach, as set forth in proposed Rule 498A, will vastly improve investors' experiences with respect to purchasing and owning variable products.” 
                        <SU>34</SU>
                        <FTREF/>
                         Another commenter observed that “the parallel approaches proposed in the rule properly mirror the sensible, constructive approaches adopted in the mutual fund summary disclosure initiative,” and predicted that such approach “can be expected to work equally well in the context of variable contracts.” 
                        <SU>35</SU>
                        <FTREF/>
                         A third commenter, finding that the proposal “appropriately balances the goals of investor protection with a better investor experience,” endorsed the use of variable contract 
                        <PRTPAGE P="25970"/>
                        summary prospectuses “as the lynchpin of a new variable contract disclosure framework.” 
                        <SU>36</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>33</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Comment Letter of Brighthouse Financial (Feb. 15, 2019) (“Brighthouse Comment Letter”); Comment Letter of the American Council of Life Insurers (Feb. 15, 2019) (“ACLI Comment Letter”); Comment Letter of the Committee of Annuity Insurers (Feb. 14, 2019) (“CAI Comment Letter”); Comment Letter of the Investment Company Institute (Feb. 15, 2019) (“ICI Comment Letter”); Comment Letter of the Independent Directors Council (Feb. 15, 2019) (“IDC Comment Letter”); Comment Letter of the Center for Capital Markets Competitiveness (Feb. 15, 2019) (“CCMC Comment Letter”); Comment Letter of Pacific Life Insurance Company (Feb. 15, 2019) (“Pacific Life Comment Letter”); Comment Letter of Jackson National Life (Feb. 15, 2019) (“Jackson Comment Letter”); Comment Letter of Donnelly Financial Solutions (Mar. 12, 2019) (“Donnelly Financial Comment Letter I”); Comment Letter of Donnelly Financial Solutions (Oct. 24, 2019); Comment Letter of Capital Research and Management Company (Mar. 14, 2019) (“Capital Group Comment Letter”); Comment Letter of Transamerica (Mar. 15, 2019) (“Transamerica Comment Letter”); Comment Letter of Lincoln Financial Group (Feb. 13, 2019) (“Lincoln Comment Letter”); Comment Letter of the National Association of Insurance and Financial Advisors (Feb. 14, 2019) (“NAIFA Comment Letter”); Comment Letter of TIAA (Feb. 15, 2019) (“TIAA Comment Letter”); Comment Letter of Wells Fargo Advisors (Mar. 14, 2019) (“WFA Comment Letter”); Comment Letter of the Financial Services Institute (Mar. 15, 2019) (“FSI Comment Letter”); Comment Letter of the Association for Advanced Life Underwriting (Mar. 15, 2019) (“AALU Comment Letter”); Comment Letter of the Insured Retirement Institute (Mar. 15, 2019) (“IRI Comment Letter I”).
                        </P>
                        <P>
                             One commenter asked us to clarify that all insurance products where the value of the contract will vary depending on investment performance are included within the scope of this proposal. 
                            <E T="03">See</E>
                             Comment Letter of the AARP (Mar. 15, 2019) (“AARP Comment Letter”). Because the scope of our proposal was limited to variable contracts registered on Forms N-3, N-4, and N-6, it does not extend to indexed annuities that register securities on Forms S-1 and S-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>34</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>35</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>36</SU>
                             
                            <E T="03">See</E>
                             Brighthouse Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Some commenters expressed reservations about key aspects of the proposal. One commenter stated that the initial summary prospectus should provide the information needed to make an investment decision without having to refer to other documents,
                        <SU>37</SU>
                        <FTREF/>
                         essentially rejecting the layered disclosure framework. Three commenters were skeptical that certain aspects of the proposed initial summary prospectus would result in better investor comprehension of how a variable contract works, and recommended that we engage in investor testing to validate our assumptions.
                        <SU>38</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>37</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Mark Bowler (Feb. 11, 2019) (“M. Bowler Comment Letter”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>38</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of the Consumer Federation of America (Feb. 27, 2019) (“CFA Comment Letter”) (stating that the Commission should test the summary prospectuses to determine whether the proposed disclosure effectively conveys key information to investors before finalizing the rule); NAIFA Comment Letter; AARP Comment Letter. 
                            <E T="03">See also</E>
                             Comment Letter of Miles Brooks (Nov. 28, 2019) (asserting the Commission should not regulate a disclosure regime on variable contracts).
                        </P>
                    </FTNT>
                    <P>
                        After considering the comments received on the proposal, we are adopting rule 498A and the general summary prospectus framework substantially as proposed, with several modifications reflecting considerations raised by commenters. As discussed in the Proposing Release, our proposal built on our experience with both layered disclosure (under the mutual fund summary prospectus) and integrated disclosure (enhanced over a decade ago with securities offering reform for corporate issuers), as well as more than 20 years of experience with the use of the internet as a medium to provide information to investors.
                        <SU>39</SU>
                        <FTREF/>
                         We drew on our investor testing efforts in developing the proposed summary prospectus framework, and specifically solicited feedback from investors and other market participants on hypothetical initial and updating summary prospectuses, which we received in response to our “feedback form” and in numerous comment letters.
                        <SU>40</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>39</SU>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section I.B.2.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>40</SU>
                             
                            <E T="03">See supra</E>
                             note 33. The Proposing Release was accompanied by a “Feedback Flier” that solicited investor feedback about the primary components of the initial summary prospectus, which was also generally supported by respondents. 
                            <E T="03">See, e.g.,</E>
                             Comment Letter of Betsy Nedar (“Nedar Comment Letter”) (Nov. 6, 2018); J. Topolski Comment Letter (Nov. 16, 2018); Anonymous Comment Letter (Nov. 11, 2018) (“Anonymous Comment Letter I”); Anonymous Comment Letter (Dec. 26, 2018) (“Anonymous Comment Letter II”); Velazquez Comment Letter (Feb. 8, 2019); Comment Letter of Bernard Mihayo (Nov. 5, 2019); Yinan Ying Comment Letter (Dec. 10, 2019).
                        </P>
                    </FTNT>
                    <P>
                        We also received comments on whether the use of the summary prospectus should be mandatory instead of voluntary as proposed. One commenter stated that the use of the summary prospectus should be voluntary to give insurers the flexibility to tailor their disclosure practices to best fit their situations.
                        <SU>41</SU>
                        <FTREF/>
                         Two commenters supported mandatory compliance to ensure that variable contract investors receive summary disclosures to aid their investment decisions.
                        <SU>42</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>41</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>42</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter; Comment Letter of Better Markets (Feb. 14, 2019) (“Better Markets Comment Letter”).
                        </P>
                    </FTNT>
                    <P>
                        After considering such comments and evaluating our prior experience with the mutual fund summary prospectus, we continue to believe that reliance on rule 498A should be optional. This will give insurers the opportunity to gradually transition to the new summary prospectus regime while minimizing disruption to their current registration and business processes. Although approximately 93% of mutual funds currently use a summary prospectus, it took nearly eight years after the adoption of the mutual fund summary prospectus framework for the industry to reach that threshold.
                        <SU>43</SU>
                        <FTREF/>
                         We believe that insurers may similarly need a period of time to transition to the new regime given the diversity of variable contracts (and corresponding diversity of disclosure for variable contracts) and the fact that the variable contract summary prospectus regime will differ from the mutual fund summary prospectus framework in several key ways (
                        <E T="03">e.g.,</E>
                         the use of an initial and an updating summary prospectus, and the new layered disclosure approach to satisfying portfolio company prospectus delivery obligations).
                    </P>
                    <FTNT>
                        <P>
                            <SU>43</SU>
                             
                            <E T="03">See supra</E>
                             note 21.
                        </P>
                    </FTNT>
                    <P>
                        Some variable contracts offer few (or no) optional benefits and few investment options. Because these contracts have fairly straightforward disclosure documents, the advantages of the summary prospectus regime may be less compelling for these products, as compared to more complex variable products with numerous optional benefits and investment options (which tend to have longer and more complicated prospectuses). Registrants will likely assess the relative benefit of using a summary prospectus based on the types of products they offer and the length of their current prospectuses—as well as the benefit of more concise disclosure to investors—when evaluating whether to opt into the new layered disclosure regime.
                        <SU>44</SU>
                        <FTREF/>
                         An optional approach also preserves flexibility for registrants that may not wish to undertake the costs of the transition to a summary prospectus regime.
                    </P>
                    <FTNT>
                        <P>
                            <SU>44</SU>
                             
                            <E T="03">See infra</E>
                             Section IV.C.1.
                        </P>
                    </FTNT>
                    <P>
                        Given the almost universal adoption of the summary prospectus regime by mutual funds, and the anticipated cost-savings and other efficiencies available to insurers that rely on the rule, we do not at this time believe a mandatory approach is necessary to achieve the goals of the variable contract summary prospectus regime. We intend to review the voluntary use of the summary prospectus and to assess whether benefits to investors warrant a future mandate.
                        <SU>45</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>45</SU>
                             
                            <E T="03">See</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17, at 66-67.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">1. Initial Summary Prospectus</HD>
                    <HD SOURCE="HD3">a. Overview</HD>
                    <P>
                        The new rule requires a person relying on the rule to send or give an initial summary prospectus in connection with sales of variable contracts to new investors.
                        <SU>46</SU>
                        <FTREF/>
                         The initial summary prospectus uses a layered disclosure approach that provides investors with key information relating to the contract's terms, benefits, and risks in a concise and more reader-friendly presentation, with access to more detailed information available online and electronically or in paper format on request.
                        <SU>47</SU>
                        <FTREF/>
                         We designed the initial summary prospectus to simplify and consolidate lengthy and complex disclosures, and to highlight aspects of the contract that may not be emphasized 
                        <PRTPAGE P="25971"/>
                        in marketing materials and other disclosures.
                        <SU>48</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>46</SU>
                             Rule 498A(f)(1). For an initial purchase of a variable contract, the initial summary prospectus must be “sent or given no later than the time of the carrying or delivery of the contract security.” 
                            <E T="03">See infra</E>
                             Section II.A.4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>47</SU>
                             One commenter, citing academic research, stated that to the extent summary disclosure reduces information overload, it could, in turn, increase financial literacy. 
                            <E T="03">See</E>
                             ACLI Comment Letter. This comment letter, together with other similar comment letters discussing the costs and benefits of the proposed rulemaking, are discussed in greater detail in Section IV. 
                            <E T="03">See infra</E>
                             note 1038 and accompanying and following text.
                        </P>
                        <P>
                            We believe simplicity and clarity are of heightened importance in a prospectus in connection with an initial purchase decision for a variable contract because of the long-term nature and complexity of these products. We also note that, unlike other investment products, variable contract investors typically have a state-mandated “free look” opportunity to return the contract for a full refund of premiums or purchase payments within a limited number of days following contract issuance. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at nn.65 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>48</SU>
                             Another unique aspect of variable contract disclosure practices is the wide variety of information about the contract that we understand investors commonly receive throughout the lifecycle of the contract. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at nn.66-69 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Contracts That May Be Included in the Initial Summary Prospectus</HD>
                    <P>
                        As proposed, we are requiring the initial summary prospectus to only describe a single contract that the registrant currently offers for sale.
                        <SU>49</SU>
                        <FTREF/>
                         Also as proposed, an initial summary prospectus may describe more than one class of a currently offered contract.
                        <SU>50</SU>
                        <FTREF/>
                         For purposes of the rule, we are adopting, as proposed, a definition of “class” to be a class of a contract that varies principally with respect to distribution-related fees and expenses.
                        <SU>51</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>49</SU>
                             Rule 498A(b)(1).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>50</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>51</SU>
                             
                            <E T="03">See</E>
                             rule 498A(a).
                        </P>
                    </FTNT>
                    <P>
                        The Commission proposed these requirements for the initial summary prospectus because aggregating disclosures for multiple contracts, or currently offered and no-longer-offered features and options of a single contract, can hinder investors from distinguishing between contract features and options that apply to them and those that do not. Currently, and under our amendments to the registration forms, it is industry practice for registrants to describe multiple contracts in a single prospectus (or multiple versions of a particular contract in a prospectus), or include multiple prospectuses in a single registration statement.
                        <SU>52</SU>
                        <FTREF/>
                         We also understand that certain contract prospectuses include disclosure about contract features and options that the registrant may no longer offer to new investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>52</SU>
                             
                            <E T="03">See</E>
                             General Guidance to Variable Annuity, Variable Life, and Other Insurance Company Investment Contract Registrants, SEC Staff No-Action Letter (Nov. 3, 1995), at Section I.4 (discussing industry practice). As discussed below, we are amending the registration forms to permit insurers to include multiple contracts (or versions thereof) in a single statutory prospectus and multiple prospectuses in a single registration statement subject to certain restrictions. 
                            <E T="03">See infra</E>
                             text following note 598 (discussing the amended form instructions that provide a prospectus may describe multiple contracts that are “essentially identical,” while a registration statement may include multiple prospectuses if the contracts described in those prospectuses are “substantially similar”).
                        </P>
                    </FTNT>
                    <P>
                        We received mixed comments regarding this aspect of the proposal. One commenter supported limiting the initial summary prospectus to a single contract currently offered for sale, but to facilitate reader comprehension, urged us to further limit the initial summary prospectus to only one class of a currently offered contract.
                        <SU>53</SU>
                        <FTREF/>
                         In contrast, three commenters urged us to allow an initial summary prospectus to describe multiple variable contracts that differed in ways other than distribution-related fees and expenses.
                        <SU>54</SU>
                        <FTREF/>
                         Their suggested approach would permit an initial summary prospectus to describe all contracts currently offered for sale, regardless of how they differed, including with respect to fees and expenses beyond traditional distribution-related fees and expenses (
                        <E T="03">e.g.,</E>
                         administrative, insurance, and benefit charges), optional benefits, and other features. These commenters asserted that our proposal would require investors to review multiple initial summary prospectuses to choose between different variable contracts, and suggested that instead permitting multiple contracts to be described in a single document would make it easier for investors to choose between contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>53</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>54</SU>
                             
                            <E T="03">See</E>
                             Transamerica Comment Letter; ACLI Comment Letter; CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>We are adopting this aspect of the rule as proposed. The initial summary prospectus is designed to provide investors key information to facilitate an initial investment decision. If we were to expand its scope as suggested by commenters, it could result in initial summary prospectuses that disclose information about contracts and contract features and options not available to the prospective investor. We continue to believe that requiring an initial summary prospectus to describe only one contract will provide more effective disclosure by omitting information that is not relevant to an investor's investment decision.</P>
                    <P>
                        Commenters raised the concern that our approach could result in investors reviewing multiple initial summary prospectuses.
                        <SU>55</SU>
                        <FTREF/>
                         We believe, however, that an approach that results in multiple initial summary prospectuses—where each is tailored to present key information about a single contract—will more effectively facilitate an investment decision than a longer or more complex document that may overwhelm investors with information that is not relevant to the investment decision.
                        <SU>56</SU>
                        <FTREF/>
                         The summary prospectus regime is designed to reduce the volume and content of variable contract disclosures that may make it difficult for some investors to find and understand key information they need to make an investment decision. Describing multiple contracts in a single initial summary prospectus, as some commenters suggest, conflicts with this goal. Our approach also is consistent with requirements for mutual fund and exchange-traded fund (“ETF”) summary prospectuses, where summary prospectuses may only present key information as to a single fund.
                        <SU>57</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>55</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>56</SU>
                             
                            <E T="03">See, e.g.,</E>
                             AARP Comment Letter (“By permitting the disclosures to discuss more than one contract and, indeed, even more than one class per contract, the information becomes unorganized, unfocused, and difficult to understand.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>57</SU>
                             For example, a mutual fund may offer a suite of equity funds that share the same statutory prospectus, but must provide a separate summary prospectus for each fund that has different investment objectives, strategies and risks (
                            <E T="03">e.g.,</E>
                             large-cap, mid-cap, small-cap, emerging markets, etc.). This reduces complexity and minimizes the likelihood of overwhelming investors with too much information in a single document.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Preparation of the Initial Summary Prospectus</HD>
                    <P>
                        The chart at the end of this section outlines the information required to appear in an initial summary prospectus. Along with specifying required introductory disclosures on the outside front cover page or the beginning of the initial summary prospectus, the new rule references particular disclosure items from Forms N-3, N-4, and N-6 (as amended).
                        <SU>58</SU>
                        <FTREF/>
                         We are adopting, largely as proposed, a standardized presentation to require certain disclosure items that we believe will be most relevant to investors (such as the table that includes key information about the contract and the contract overview section), to appear at the beginning of the initial summary prospectus, followed by supplemental information. The required presentation could also facilitate comparison of different variable contracts.
                        <SU>59</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>58</SU>
                             The amendments to Forms N-3, N-4, and N-6 that facilitate the summary prospectus content requirements, as well as amend the content requirements for the statutory prospectus, are generally discussed in more detail in Section II.C below. However, in order to better explain the initial summary prospectus, we discuss new or amended items in the statutory prospectus, to the extent they will also appear in the initial summary prospectus, in this Section II.A.1.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>59</SU>
                             We understand that many investors purchase variable contracts through an intermediary and may not directly compare competing products. A standardized order may nonetheless be useful for investment professionals to compare the products they ultimately recommend to investors with other products, as well as investors considering whether to purchase a new annuity contract to replace an existing one. 
                            <E T="03">See infra</E>
                             note 194 and accompanying text. Having a more standardized document may ultimately promote greater comparability across products, registrants, and insurance institutions, which could lead to better investor understanding and increased competition.
                        </P>
                        <P>
                            As discussed below in Section II.D, we are also adopting, as proposed, the requirement to use Inline XBRL format for the submission of certain required 
                            <PRTPAGE/>
                            disclosures in the variable contract statutory prospectus with respect to contracts currently offered to new investors. The structured data format will allow investors, Commission staff, data aggregators, financial analysts, and other data users to more efficiently analyze and compare these products.
                        </P>
                    </FTNT>
                    <PRTPAGE P="25972"/>
                    <P>
                        Largely as proposed, we are requiring an initial summary prospectus to only contain the information specifically required, which must appear in the same order, and under the relevant corresponding headings, as the rule specifies.
                        <SU>60</SU>
                        <FTREF/>
                         While we did not receive any comments regarding the proposed order of the substantive contents of the initial summary prospectus, in a change from the proposal, and as discussed below, we are reversing the order of the first two sections,
                        <SU>61</SU>
                        <FTREF/>
                         and, for Forms N-3 and N-4 only, merging two sections together.
                        <SU>62</SU>
                        <FTREF/>
                         These changes are designed to facilitate investor readership and to streamline the document.
                    </P>
                    <FTNT>
                        <P>
                            <SU>60</SU>
                             Rule 498A(b)(5). While the Commission did not propose (and we are not adopting) page limits for the initial summary prospectus, these provisions are designed to require registrants to produce a document that will present key information in a concise and clear way.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>61</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.1.c.ii.(a) (relocating “Important Information You Should Consider About the Contract” before “Overview of the Variable Contract”); 
                            <E T="03">see also</E>
                             rule 498A(b)(5)(i) through (ii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>62</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.1.c.ii.(c) through (d) (merging the “Standard Death Benefit” into “Benefits Under the Contract”); 
                            <E T="03">see also</E>
                             rule 498A(b)(5)(iv).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Use of Illustrations and Examples</HD>
                    <P>
                        While not proposed, three commenters suggested that we permit the use of illustrations or examples in summary prospectuses.
                        <SU>63</SU>
                        <FTREF/>
                         Illustrations and examples are frequently presented in variable contract sales materials, and may be included in the statutory prospectus.
                        <SU>64</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>63</SU>
                             
                            <E T="03">See</E>
                             Lincoln Comment Letter; Comment Letter of Cardozo School of Law Securities Arbitration Clinic (Mar. 14, 2019) (“Cardozo Clinic Comment Letter”); Comment Letter of Benjamin G. Baldwin, Jr. (Feb. 13, 2019) (“Baldwin Comment Letter”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>64</SU>
                             General Instruction C.3.(g) to Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        We are persuaded that illustrations and examples could assist investors in more readily understanding potentially complex or lengthy narrative disclosures. Consequently, the final rule and forms permit the inclusion of illustrations or examples in a summary prospectus to the extent that they are responsive and limited to the particular statutory prospectus items required to be included in the summary prospectus.
                        <SU>65</SU>
                        <FTREF/>
                         However, such illustrations and examples generally should not, by their nature, quantity, or manner of presentation, obscure or impede understanding of the information that is required to be included in the summary prospectus.
                        <SU>66</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>65</SU>
                             As guidance, we generally do not believe that illustrations or examples regarding the operation of optional benefits should be included in the initial summary prospectus because the summary prospectus disclosure requirements regarding those benefits are generally limited to a tabular summary of those benefits. 
                            <E T="03">See</E>
                             rule 498A(b)(5)(iv) (providing initial summary prospectus disclosure requirements for “(Other) Benefits Available Under the Contract” by referencing the relevant item requirements from the particular registration statement forms). 
                            <E T="03">See also</E>
                             Item 11(a) of amended Form N-3; Item 10(a) of amended Form N-4; and Item 11(a) of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>66</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(b) to amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Terminology</HD>
                    <P>
                        Commenters broadly objected to the requirement to use only the headings and terms specified in the proposed rule (and forms).
                        <SU>67</SU>
                        <FTREF/>
                         One commenter stated because the industry uses a wide variety of terminology in contract prospectuses, marketing materials, and the contracts themselves, investors may be confused by receiving an initial summary prospectus that uses different terminology than related contract documents.
                        <SU>68</SU>
                        <FTREF/>
                         Several commenters identified specific terms they believed should not be required.
                        <SU>69</SU>
                        <FTREF/>
                         Another commenter asked that we permit registrants reasonable flexibility to use alternative terms that reflect the substance of the defined terms in the proposed rule, noting that readability should be the top priority.
                        <SU>70</SU>
                        <FTREF/>
                         Commenters also stated that providing flexibility in terminology would allow the industry to simplify the complex language commonly used in variable product disclosures,
                        <SU>71</SU>
                        <FTREF/>
                         facilitate product evolution and innovation,
                        <SU>72</SU>
                        <FTREF/>
                         and be consistent with current practice as permitted by the staff.
                        <SU>73</SU>
                        <FTREF/>
                         Instead of prescribing specific terminology, four commenters asked that we prescribe only the content of the disclosures, giving industry the flexibility to modify headings and terms to better convey certain aspects of a variable contract and make them easier to understand, as long as such terms are substantially similar in meaning to the terms used in the rule and forms and are clearly defined in the prospectuses in which they appear.
                        <SU>74</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>67</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Pacific Life Comment Letter; ACLI Comment Letter; Brighthouse Comment Letter; Jackson Comment Letter; CCMC Comment Letter; ACLI Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>68</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>69</SU>
                             Several commenters objected to the terms “death benefit,” “mortality and expense risk charges,” and “surrender charge.” 
                            <E T="03">See</E>
                             Comment Letter of Jackson National Life (Feb. 15, 2019) (“Jackson Comment Letter”); CCMC Comment Letter. Others did not want to use “contract” on the grounds that investors are used to “policy.” 
                            <E T="03">See</E>
                             Comment Letter of Ameritas Life Insurance Corp. (Mar. 12, 2019) (“Ameritas Comment Letter”); ACLI Comment Letter. One insurer objected to “living benefit rider” because “protected lifetime income benefit” resonates more with investors. 
                            <E T="03">See</E>
                             Lincoln Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>70</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>71</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Pacific Life Comment Letter; Brighthouse Comment Letter; Jackson Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>72</SU>
                             
                            <E T="03">See</E>
                             Brighthouse Comment Letter; Transamerica Comment Letter; ACLI Comment Letter; CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>73</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>74</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Pacific Life Comment Letter; Jackson Comment Letter; Brighthouse Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We recognize that variable contract and other issuers may use terminology in their disclosure documents other than that used in our rules and forms, and that in many instances, our rules and forms do not prescribe terminology.
                        <SU>75</SU>
                        <FTREF/>
                         After considering comments, we are modifying the proposed rule and form requirements to give insurers the flexibility to describe their variable contracts in a manner best suited to their products and business practices, while still requiring the use of certain standardized headings in initial summary prospectuses to allow investors to easily compare the features of different products.
                    </P>
                    <FTNT>
                        <P>
                            <SU>75</SU>
                             However, in certain instances our rules and forms do prescribe specific terminology. 
                            <E T="03">See, e.g.,</E>
                             Form CRS (generally requiring that investment advisers and broker-dealers use specific headings when responding to each item).
                        </P>
                    </FTNT>
                    <P>
                        The proposed amendments to the forms would have defined and used certain terminology. However, contrary to certain commenters' concerns, the forms, as proposed, would not have required that registrants use the specific terminology in the forms in preparing a registration statement, other than in certain legends. To respond to these commenters' concerns, we are adding a clarifying instruction to the forms that explicitly and broadly permits registrants to use alternate terminology in preparing registration statements pursuant to the forms' disclosure requirements, so long as the alternate terminology clearly conveys the meaning of, or provides comparable information as, the terms used in the forms.
                        <SU>76</SU>
                        <FTREF/>
                         Notwithstanding this instruction, we are adding an additional instruction, which was not included in the proposed amendments to the forms, that a registrant must prepare the Key Information Table using the headings and sub-headings specified by the form.
                        <SU>77</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>76</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(d)(ii) of Forms N-3, N-4, and N-6. 
                            <E T="03">See also infra</E>
                             note 598 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>77</SU>
                             
                            <E T="03">See</E>
                             General Instruction 1(a) to Item 2 of Forms N-3, N-4, and N-6. We discuss the Key Information Table below in Section II.A.1.c.ii.(a).
                        </P>
                    </FTNT>
                    <P>
                        Because the initial summary prospectus (and as discussed below, the 
                        <PRTPAGE P="25973"/>
                        updating summary prospectus) draw from disclosures in the statutory prospectus, insurers will similarly have flexibility in preparing those documents with one exception. With respect to the initial summary prospectus, we are generally requiring, as proposed, that the initial summary prospectus use the standardized headings required by the rule.
                        <SU>78</SU>
                        <FTREF/>
                         We believe that the use of standardized headings will provide a consistent framework to allow investors to more easily navigate through variable product summary prospectuses and also facilitate the ability of investors to compare information across different variable contract products.
                    </P>
                    <FTNT>
                        <P>
                            <SU>78</SU>
                             However, registrants are provided with limited flexibility as to certain bracketed terms. For example, information about buying a contract must be disclosed under the heading “Buying the [Contract].” Registrants could substitute “Policy” for the bracketed term “Contract.” 
                            <E T="03">See</E>
                             rule 498A(b)(5)(v).
                        </P>
                    </FTNT>
                    <P>
                        Commenters generally objected to the proposed use of “surrender charges” and “death benefits” in the initial summary prospectus headings.
                        <SU>79</SU>
                        <FTREF/>
                         Regarding “surrender charges,” we believe that the term “withdrawal” both sufficiently encompasses surrenders and other types of withdrawals and is a more intuitive term for investors, and have modified the heading regarding surrenders and withdrawals to no longer require the term “surrender.” 
                        <SU>80</SU>
                        <FTREF/>
                         We decline, however, to permit the use of alternate terms for “death benefits” in the case of initial summary prospectuses for variable life insurance, because we believe that “death benefits” is a more intuitive term than “legacy benefits” or other terms.
                        <SU>81</SU>
                        <FTREF/>
                         Additionally, the terms “mortality and expense risk charges” and “living benefit rider” do not appear in the standardized headings required by the rule, so insurers will have flexibility with respect to those terms.
                    </P>
                    <FTNT>
                        <P>
                            <SU>79</SU>
                             
                            <E T="03">See</E>
                             Jackson Comment Letter; CCMC Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>80</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(vii) (requiring the heading “Making Withdrawals: Accessing the Money in Your [Contract]” when disclosing the information required by Item 13(a) of Form N-3, Item 12(a) of Form N-4, or Item 12(a) of Form N-6).
                        </P>
                        <P>
                             Similarly, we are modifying the sub-heading in the Key Information Table regarding surrenders and withdrawals to eliminate the proposed use of the term “surrenders.” 
                            <E T="03">See</E>
                             Item 2 of Forms N-3, N-4, and N-6. We discuss the Key Information Table below in Section II.A.1.c.ii.(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>81</SU>
                             Although information about standard death benefits offered by variable life insurance contracts must be disclosed under the heading “Standard Death Benefits,” the disclosures provided under that heading could, for example, explain that “death benefits” are referred to as “legacy benefits” under the contract and could use the term “legacy benefits” in providing the disclosures required under that heading. 
                            <E T="03">See</E>
                             rule 498A(b)(5)(iii).
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="04" OPTS="L2,i1" CDEF="s50,12,12,12">
                        <TTITLE>Table 2—Outline of the Initial Summary Prospectus</TTITLE>
                        <BOXHD>
                            <CHED H="1">Heading in initial summary prospectus</CHED>
                            <CHED H="1">
                                Item of
                                <LI>amended</LI>
                                <LI>Form N-3</LI>
                            </CHED>
                            <CHED H="1">
                                Item of
                                <LI>amended</LI>
                                <LI>Form N-4</LI>
                            </CHED>
                            <CHED H="1">
                                Item of
                                <LI>amended</LI>
                                <LI>Form N-6</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="22">Cover Page:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Identifying Information</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="03">Legends</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="03">EDGAR Contract Identifier</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="03">Table of Contents (optional)</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="22">Content:</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Important Information You Should Consider About the [Contract]</ENT>
                            <ENT>2</ENT>
                            <ENT>2</ENT>
                            <ENT>2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Overview of the [Contract]</ENT>
                            <ENT>3</ENT>
                            <ENT>3</ENT>
                            <ENT>3</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Standard Death Benefits</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>10(a)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">[Other] Benefits Available Under the [Contract]</ENT>
                            <ENT>11(a)</ENT>
                            <ENT>10(a)</ENT>
                            <ENT>11(a)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Buying the [Contract]</ENT>
                            <ENT>12(a)</ENT>
                            <ENT>11(a)</ENT>
                            <ENT>9(a)-9(c)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">How Your [Contract] Can Lapse</ENT>
                            <ENT/>
                            <ENT/>
                            <ENT>14(a)-14(c)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Making Withdrawals: Accessing the Money in Your [Contract]</ENT>
                            <ENT>13(a)</ENT>
                            <ENT>12(a)</ENT>
                            <ENT>12(a)</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Additional Information About Fees</ENT>
                            <ENT>4</ENT>
                            <ENT>4</ENT>
                            <ENT>4</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="03">Appendix: [Investment Options/Portfolio Companies] Available Under the [Contract]</ENT>
                            <ENT>
                                <SU>82</SU>
                                 18 or 19
                            </ENT>
                            <ENT>17</ENT>
                            <ENT>18</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">
                        i. Cover Page and Table of Contents
                        <FTREF/>
                    </HD>
                    <FTNT>
                        <P>
                            <SU>82</SU>
                              Registrants on Form N-3 may omit the Appendix specified by Item 18 of amended Form N-3, and instead provide the more detailed disclosures about the investment options offered under the contract required by Item 19 of amended Form N-3. 
                            <E T="03">See infra</E>
                             note 788 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Identifying Information.</E>
                         We are adopting, largely as proposed, the requirement that the following information appear on the front cover page or the beginning of the initial summary prospectus:
                    </P>
                    <P>• The depositor's name;</P>
                    <P>• The name of the contract, and the class or classes if any, to which the initial summary prospectus relates;</P>
                    <P>• A statement identifying the initial summary prospectus as a “Summary Prospectus for New Investors”; and</P>
                    <P>
                        • The approximate date of the first use of the initial summary prospectus.
                        <SU>83</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>83</SU>
                             Rule 498A(b)(2)(i) through (iv).
                        </P>
                    </FTNT>
                    <P>
                        Several commenters suggested that instead of requiring the document to be identified as a “Summary Prospectus,” we should permit different titles, such as “Key Information Document” or “Summary Information.” 
                        <SU>84</SU>
                        <FTREF/>
                         A prospectus, however, is a legal term with specific legal implications. It is also a term that is understood in the marketplace. We believe it is important that investors understand that an initial summary prospectus is, in fact, a prospectus, and that it therefore contains important required regulatory disclosures. However, in a change from the proposal, the cover page will not be required to include the registrant's name. We agree with a commenter's suggestion that the registrant's name is of limited value to investors because it is largely a legal convention,
                        <SU>85</SU>
                        <FTREF/>
                         and believe investors are more likely to be interested in the names of the depositor (or insurer) and the variable contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>84</SU>
                             
                            <E T="03">See, e.g.,</E>
                             NAIFA Comment Letter; Comment Letter of VIP Working Group (Dec. 4, 2018) (“VIP Working Group Comment Letter”); Comment Letter of Jack Breacher (Jan. 27, 2019) (“Breacher Comment Letter”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>85</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter (stating that the separate account name “is jargon and an accounting fiction”). In addition, mutual funds are not required to include the registrant's name on the summary prospectus cover page. 
                        </P>
                        <P>
                            We are making a conforming change to the cover page requirements for the updating summary prospectus. 
                            <E T="03">See infra</E>
                             Section II.A.2.c.i.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Legends.</E>
                         We are requiring, largely as proposed, the cover page or beginning of the initial summary prospectus to include the following legends: 
                    </P>
                    <EXTRACT>
                        <P>
                            This Summary Prospectus summarizes key features of the [Contract]. Before you invest, you should also review the prospectus for the [Contract], which contains more information about the [Contract's] features, benefits, and risks. You can find this document and other information about the [Contract] online at 
                            <PRTPAGE P="25974"/>
                            [__]. You can also obtain this information at no cost by calling [__] or by sending an email request to [__].
                            <SU>86</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>86</SU>
                                 The legend is required to provide an internet address, other than the address of the Commission's electronic filing system, toll-free telephone number, and email address that investors can use to obtain the statutory prospectus and other materials, request other information about the variable contract, and make investor inquiries. Rule 498A(b)(2)(v)(B). 
                            </P>
                            <P>
                                The website address must be specific enough to lead investors to a direct link to the statutory prospectus and other required information, rather than to the home page or another part of the website. The website could host other relevant disclosure documents with prominent links to each required document. 
                                <E T="03">Id.</E>
                            </P>
                            <P>
                                The legend could indicate, if applicable, that the statutory prospectus and other information are available from a financial intermediary (such as a broker-dealer) through which the contract may be purchased or sold. 
                                <E T="03">Id.</E>
                            </P>
                            <P>
                                 For purposes of this requirement, documents available on the website address must be publicly accessible and free of charge. Rule 498A(h)(1); 
                                <E T="03">see also infra</E>
                                 Section II.A.5.
                            </P>
                        </FTNT>
                        <P>
                            You may cancel your [Contract] within 10 days of receiving it without paying fees or penalties. In some states, this cancellation period may be longer. Upon cancellation, you will receive either a full refund of the amount you paid with your application or your total contract value. You should review the prospectus, or consult with your investment professional, for additional information about the specific cancellation terms that apply.
                            <SU>87</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>87</SU>
                                 The paragraph of the legend regarding cancellation of the contract may be omitted if not applicable. If this paragraph is included in the legend, the paragraph must be presented in a manner reasonably calculated to draw investor attention to that paragraph. 
                                <E T="03">See infra</E>
                                 note 95.
                            </P>
                        </FTNT>
                        <P>
                            Additional general information about certain investment products, including [variable annuities/variable life insurance contracts], has been prepared by the Securities and Exchange Commission's staff and is available at 
                            <E T="03">Investor.gov.</E>
                            <SU>88</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>88</SU>
                                 Rule 498A(b)(2)(v). The Commission's Office of Investor Education and Advocacy maintains the website as an online resource to help investors make sound investment decisions and avoid fraud. The website includes investor bulletins, alerts, guidance and tools designed to assist investors, including those considering variable contracts, in obtaining additional information and resources on understanding and managing their investments. 
                                <E T="03">See, e.g.,</E>
                                 Updated Investor Bulletin: Variable Annuities (Oct. 30, 2018), 
                                <E T="03">available at https://www.investor.gov/additional-resources/news-alerts/alerts-bulletins/updated-investor-bulletin-variable-annuities</E>
                                ; Investor Bulletin: Variable Life Insurance (Oct. 30, 2018), 
                                <E T="03">available at https://www.investor.gov/additional-resources/news-alerts/alerts-bulletins/investor-bulletin-variable-life-insurance</E>
                                .
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        These legends are designed to provide identifying information about the variable contract to which the initial summary prospectus relates, as well as certain general information applicable to all variable contracts.
                        <SU>89</SU>
                        <FTREF/>
                         Pursuant to the requirements of new rule 30e-3,
                        <SU>90</SU>
                        <FTREF/>
                         the initial summary prospectus may include the legend designed to alert investors that beginning on a specified date, shareholder reports for Form N-3 variable annuities and for portfolio companies available under Form N-4 variable annuity and Form N-6 variable life insurance contracts will no longer be sent by mail (unless paper copies are specifically requested), and will instead be posted on a website, subject to notification by mail of their location and availability.
                        <SU>91</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>89</SU>
                             A registrant will be able to modify the legends so long as the modified statements contain comparable information. Rule 498A(b)(2)(v)(A).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>90</SU>
                             Rule 30e-3; 
                            <E T="03">see also</E>
                             Investment Company Shareholder Reports Release, 
                            <E T="03">supra note</E>
                             19. This rule became effective January 1, 2019.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>91</SU>
                             Rule 498A(b)(2)(v)(E) through (F); 
                            <E T="03">see also</E>
                             rule 498A(b)(2)(v)(B) (requiring, if applicable, cover page legend to include the website address required by rule 30e-3, if different from the website address provided for variable contract and related documents). The legends required by rule 30e-3 will be removed from variable contract registration forms on January 1, 2022.
                        </P>
                    </FTNT>
                    <P>
                        One commenter stated that the initial summary prospectus would be more approachable if the cover page had more white space with fewer legal disclaimers and suggested that we eliminate the legend urging investors to review the statutory prospectus before investing and describing how to obtain further information about the contract.
                        <SU>92</SU>
                        <FTREF/>
                         We are retaining the legend and have streamlined it in consideration of this comment, but are otherwise adopting the legend largely as proposed because we believe that it concisely informs investors that the statutory prospectus is available and how to obtain it. Providing investors information about the statutory prospectus and where to find it will facilitate the layered disclosure approach we are adopting in this document.
                    </P>
                    <FTNT>
                        <P>
                            <SU>92</SU>
                             
                            <E T="03">See</E>
                             WFA Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Another commenter stated that because the free look period is one of the most crucial rights available to variable contract purchasers, investors should receive a separate, one-page disclosure describing this unique, time-limited revocation right.
                        <SU>93</SU>
                        <FTREF/>
                         The commenter also suggested that we require insurers to draw more attention to free look disclosure by requiring it to be in a larger font size, bolded, and boxed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>93</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We are not requiring insurers to provide a stand-alone document describing the free look period, but rather are requiring, as proposed, that the legend on the cover page or beginning of the summary prospectus retain all disclosures of key information in one document. We also understand that state laws typically mandate free look disclosures in the variable contract application, investor education materials (
                        <E T="03">e.g.,</E>
                         the NAIC Buyer's Guide), and the variable contract itself, and investors therefore already receive multiple notices regarding this unique revocation right. We agree, however, that this is important information that should be highlighted to investors because it is unique to variable contracts and time limited. We are therefore revising the rule to require that insurers present the “free-look” legend in a manner reasonably calculated to draw an investor's attention.
                        <SU>94</SU>
                        <FTREF/>
                         In response to comments, the new rule also clarifies that this legend is required only if applicable.
                        <SU>95</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>94</SU>
                             Rule 498A(2)(v)(C).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>95</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(2)(v)(C); 
                            <E T="03">see also</E>
                             ACLI Comment Letter (stating that some types of group annuity contracts, such as those used to fund Section 403(b) retirement plans, are not required to have a free look provision under state law).
                        </P>
                    </FTNT>
                    <P>
                        Taking into account the comments urging that we streamline the legends where possible, we are relocating one legend and eliminating two others. Specifically, the Commission proposed that, if any information is incorporated by reference into the initial summary prospectus, the front cover page would include a legend with certain disclosures related to that information.
                        <SU>96</SU>
                        <FTREF/>
                         Incorporation by reference is a technical legal doctrine that may not be understandable to many investors. To reduce the length of the legends on the cover page of the initial summary prospectus, we are relocating this legend to the back cover page or last page of the initial summary prospectus.
                        <SU>97</SU>
                        <FTREF/>
                         However, we are not eliminating the legend because our rules on incorporation by reference require registrants to provide disclosure about what information is incorporated into a document.
                        <SU>98</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>96</SU>
                             Proposed rule 498A(b)(2)(vi)(C).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>97</SU>
                             Rule 498A(b)(3)(i).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>98</SU>
                             
                            <E T="03">See, e.g.,</E>
                             17 CFR 230.411(e) (rule 411(e) under the Securities Act); 17 CFR 270.0-4(e) (rule 0-4(e) under the Investment Company Act).
                        </P>
                    </FTNT>
                    <P>
                        We are also eliminating the proposed legend stating “You should read this Summary Prospectus carefully, particularly the section titled Important Information You Should Consider About the Contract.” We believe that legend is no longer necessary because the section referenced by that legend is now the first item in the initial summary prospectus.
                        <SU>99</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>99</SU>
                             
                            <E T="03">See</E>
                             text following note 121.
                        </P>
                    </FTNT>
                    <P>
                        One commenter suggested that we remove the proposed legend stating that the Securities and Exchange Commission has not approved or disapproved of the contract or passed upon the accuracy or adequacy of the disclosure in the summary prospectus and that any contrary representation is a criminal offense, on the basis that this 
                        <PRTPAGE P="25975"/>
                        legend was “legalese.” 
                        <SU>100</SU>
                        <FTREF/>
                         We agree that this legend may not communicate as effectively as the other legends and that removing it will streamline the cover page, potentially increasing the likelihood that investors will read the remaining legends. Removing the requirement to include that legend also treats variable contract summary prospectuses similarly to mutual fund summary prospectuses, which are permitted, but not required, to include that legend on their cover page.
                    </P>
                    <FTNT>
                        <P>
                            <SU>100</SU>
                             
                            <E T="03">See</E>
                             Breacher Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">EDGAR Contract Identifier.</E>
                         We are adopting, as proposed, the requirement to include the contract's EDGAR contract identifier on the bottom of the back cover page or last page of the initial summary prospectus in a type size smaller than that generally used in the prospectus (
                        <E T="03">e.g.,</E>
                         8-point modern type).
                        <SU>101</SU>
                        <FTREF/>
                         This requirement is intended to enable Commission staff and others to more easily link the initial summary prospectus with other filings associated with the contract. We received no comments regarding the EDGAR contract identifier.
                    </P>
                    <FTNT>
                        <P>
                            <SU>101</SU>
                             Rule 498A(b)(3)(ii); 
                            <E T="03">see also</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.87 (describing an EDGAR contract identifier).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Table of Contents.</E>
                         Likewise, we are adopting, as proposed, the rule provision permitting an initial summary prospectus to include a table of contents.
                        <SU>102</SU>
                        <FTREF/>
                         A table of contents must show the page number of the various sections or subdivisions of the summary prospectus, and immediately follow the cover page in any initial summary prospectus delivered electronically.
                        <SU>103</SU>
                        <FTREF/>
                         We received no comments on this aspect of the proposal.
                    </P>
                    <FTNT>
                        <P>
                            <SU>102</SU>
                             Rule 498A(b)(4).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>103</SU>
                             17 CFR 230.481(c) (Rule 481(c)).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. Content of the Initial Summary Prospectus</HD>
                    <P>
                        We are adopting, generally as proposed but with some modifications, specifications in the rule regarding the content and order required in an initial summary prospectus.
                        <SU>104</SU>
                        <FTREF/>
                         An initial summary prospectus must contain the information required by the rule, and only that information, in the order specified by the rule.
                        <SU>105</SU>
                        <FTREF/>
                         Adhering to these content requirements is one condition that an initial summary prospectus must satisfy in order to be deemed to be a prospectus that is permitted under Section 10(b) of the Securities Act and Section 24(g) of the Investment Company Act for the purposes of Section 5(b)(1) of the Securities Act.
                        <SU>106</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>104</SU>
                             Rule 498A(b)(5); 
                            <E T="03">see also</E>
                             Section II.A.1.c.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>105</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>106</SU>
                             Rule 498A(b); 
                            <E T="03">see also infra</E>
                             Section II.A.4.
                        </P>
                        <P>
                            Section 10(b) of the Securities Act authorizes the Commission to adopt rules deemed necessary or appropriate in the public interest or for the protection of investors that permit the use of an “omitting prospectus” for the purposes of Section 5(b)(1) that omits or summarizes information contained in the statutory prospectus. Section 24(g) of the Investment Company Act authorizes the Commission to permit the use of a prospectus under Section 10(b) of the Securities Act to include information the substance of which is not included in the statutory prospectus. 15 U.S.C. 77j(b); 15 U.S.C. 77e(b)(1); 15 U.S.C. 80a-24(g); 
                            <E T="03">see also</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17, at n.70.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Key Information Table</HD>
                    <P>
                        The initial summary prospectus will include a table (the “Key Information Table”) that will provide a brief description of key facts about the variable contract in a specific sequence and in a standardized presentation that is designed to be easy to read and navigate.
                        <SU>107</SU>
                        <FTREF/>
                         Specifically, it will include a summary of five topic areas: (1) Fees and expenses; (2) risks; (3) restrictions; (4) taxes; and (5) conflicts of interest. This is intended to highlight, in a consolidated location, important considerations related to these products, including certain unique aspects of the variable contract that might be unfamiliar to investors who have experience with mutual funds or other types of investment products.
                        <SU>108</SU>
                        <FTREF/>
                         We are adopting the Key Information Table substantially as proposed, with some modifications made in response to comments.
                    </P>
                    <FTNT>
                        <P>
                            <SU>107</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); Item 2 of Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>108</SU>
                             As discussed in the Proposing Release, we considered investor complaints received by the Commission's Office of Investor Education and Advocacy and the results of the 2012 Financial Literacy Study. 
                            <E T="03">See</E>
                             text accompanying note 1041 (regarding investor complaints). Office of Investor Education and Advocacy of the U.S. Securities and Exchange Commission, 
                            <E T="03">Study Regarding Financial Literacy Among Investors</E>
                             (Aug. 2012), 
                            <E T="03">available at https://www.sec.gov/news/studies/2012/917-financial-literacy-study-part1.pdf</E>
                             (“2012 Financial Literacy Study”). We also considered various regulatory and industry sources. 
                            <E T="03">See, e.g.,</E>
                             FINRA Rule 2330(b)(1)(A)(i) (variable annuity investors must be informed, “in general terms, of various features of deferred variable annuities, such as the potential surrender period and surrender charge; potential tax penalty if consumers sell or redeem deferred variable annuities before reaching the age of 59
                            <FR>1/2</FR>
                            ; mortality and expense fees; investment advisory fees; potential charges for and features of riders; the insurance and investment components of deferred variable annuities; and market risk”).
                        </P>
                    </FTNT>
                    <P>
                        Commenters were broadly supportive of the proposed Key Information Table,
                        <SU>109</SU>
                        <FTREF/>
                         which was identified by respondents to the Feedback Flier as the “most useful” section in the hypothetical initial summary prospectus that accompanied the Proposing Release. One commenter said the information in the Key Information Table was most relevant to investors, particularly if standardized to compare annuities,
                        <SU>110</SU>
                        <FTREF/>
                         while another noted approvingly that it broke the information down in a simplified way.
                        <SU>111</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>109</SU>
                             
                            <E T="03">See, e.g.,</E>
                             ACLI Comment Letter; CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>110</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Christopher Viscomi (Dec. 4, 2018).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>111</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Anthony Harrison (Dec. 7, 2018).
                        </P>
                    </FTNT>
                    <P>Given the positive response to the Key Information Table, in a change from the proposal, we are relocating it so it will be the first substantive section of the initial summary prospectus, followed by the Overview of the Contract instead of the second section following Overview of the Contract, as proposed. We believe that investors of different levels of financial sophistication may benefit from receiving this information early in the initial summary prospectus, as it was designed to provide a contextual baseline to help inform investors' understanding of disclosure about more detailed aspects of the variable contract that are described later on.</P>
                    <P>
                        The Key Information Table includes a number of prescribed disclosures and is designed to complement the “Overview” section, discussed below. As proposed, we are placing these two disclosure sections at the beginning of the initial summary prospectus because we believe they contain certain basic information that is critical for variable contract investors to read. We are also requiring, as proposed, that this information be provided in a standardized tabular presentation because we believe that, as compared to the narrative-type presentation of corresponding disclosures in the statutory prospectus, a summary tabular presentation will be easier to read and better convey the importance of the information to investors.
                        <SU>112</SU>
                        <FTREF/>
                         This 
                        <PRTPAGE P="25976"/>
                        presentation may also facilitate comparisons of certain disclosure topics among variable contract prospectuses.
                    </P>
                    <FTNT>
                        <P>
                            <SU>112</SU>
                             As discussed in the Proposing Release, we considered mutual fund disclosure research that supported the view that a tabular presentation would be an effective disclosure delivery method. 
                            <E T="03">See, e.g.,</E>
                             John Kozup, Elizabeth Howlett, &amp; Michael Pagano, 
                            <E T="03">The Effects of Summary Information on Consumer Perceptions of Mutual Fund Characteristics,</E>
                             The Journal of Consumer Affairs 42, 37-59 (2008) (concluding that summary information, particularly using graphical presentation, is an effective way to facilitate the processing of information for investors evaluating mutual funds).
                        </P>
                        <P>
                             Experts in disclosure effectiveness for consumer-facing communications also have encouraged the use of a “strong design grid” (such as the tabular presentation we propose) to clarify concepts to consumers and to organize disclosure elements. 
                            <E T="03">See, e.g.,</E>
                             Susan Kleimann, 
                            <E T="03">Making Disclosures Work for Consumers,</E>
                             Presentation to the SEC's Investor Advisory Committee (June 14, 2018), 
                            <PRTPAGE/>
                            <E T="03">available at https://www.sec.gov/spotlight/investor-advisory-committee-2012/iac061418-slides-by-susan-kleimann.pdf</E>
                             (“Kleimann Presentation”).
                        </P>
                    </FTNT>
                    <P>
                        We are requiring, as proposed, that a registrant provide the Key Information Table under the heading “Important Information You Should Consider About the [Contract].” We are not requiring the proposed legend that would have followed this heading, because we believe that legend is largely redundant with similar language on the cover page or beginning of the summary prospectus.
                        <SU>113</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>113</SU>
                             We proposed that the following legend would precede the Key Information Table: “An investment in the Contract is subject to fees, risks, and other important considerations, some of which are briefly summarized in the following table. You should review the prospectus for additional information about these topics.” 
                            <E T="03">See also</E>
                             text following 
                            <E T="03">supra</E>
                             note 85 (discussing the legend that appears on the cover page or beginning of the summary prospectus).
                        </P>
                    </FTNT>
                    <P>
                        As proposed, specified headings are required for each of the five topic areas included in the table, and under each heading will be two columns. The left column lists the required disclosure line-items for each of the five topic areas, and the right column provides a brief description for each corresponding line-item, according to the respective instructions for each proposed line-item. Registrants will also provide a cross-reference to the location in the statutory prospectus where further information can be found for each line-item.
                        <SU>114</SU>
                        <FTREF/>
                         One commenter expressed a preference for allowing registrants the discretion to use a one or two column format based on specific formatting and design preferences.
                        <SU>115</SU>
                        <FTREF/>
                         While we recognize there are many ways to effectively provide the required information, requiring all registrants to adhere to the same presentation standards facilitates comparability. The overall format of the Key Information Table is depicted below:
                    </P>
                    <FTNT>
                        <P>
                            <SU>114</SU>
                             
                            <E T="03">See infra</E>
                             text following note 201.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>115</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter (stating that “[t]he priority should emphasize readability and clarity of presentation, rather than stipulating the number of appropriate columns.”).
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="02" OPTS="L2,tp0,p1,8/9,i1" CDEF="s100,r100">
                        <TTITLE> </TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1"> </CHED>
                        </BOXHD>
                        <ROW EXPSTB="01" RUL="s">
                            <ENT I="21">
                                <E T="02">FEES AND EXPENSES</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00" RUL="s">
                            <ENT I="01">Charges for Early Withdrawals</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Transaction Charges</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Ongoing Fees and Expenses (annual charges)</ENT>
                        </ROW>
                        <ROW EXPSTB="01" RUL="s">
                            <ENT I="21">
                                <E T="02">RISKS</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00" RUL="s">
                            <ENT I="01">Risk of Loss</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Not a Short-Term Investment</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Risks Associated with Investment Options</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Insurance Company Risks</ENT>
                        </ROW>
                        <ROW EXPSTB="01" RUL="s">
                            <ENT I="21">
                                <E T="02">RESTRICTIONS</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00" RUL="s">
                            <ENT I="01">Investment Options</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Optional Benefits</ENT>
                        </ROW>
                        <ROW EXPSTB="01" RUL="s">
                            <ENT I="21">
                                <E T="02">TAXES</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00" RUL="s">
                            <ENT I="01">Tax Implications</ENT>
                        </ROW>
                        <ROW EXPSTB="01" RUL="s">
                            <ENT I="21">
                                <E T="02">CONFLICTS OF INTEREST</E>
                            </ENT>
                        </ROW>
                        <ROW EXPSTB="00" RUL="s">
                            <ENT I="01">Investment Professional Compensation</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Exchanges</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">(i) Fees and Expenses</HD>
                    <P>
                        Variable contracts typically have multiple layers of fees, expenses, and charges that can be confusing to investors. While the Fee Table currently required in variable contract prospectuses provides comprehensive fee and expense information,
                        <SU>116</SU>
                        <FTREF/>
                         that information is frequently presented over a span of two or more pages when a prospectus is printed on paper.
                        <SU>117</SU>
                        <FTREF/>
                         We believe that investors may benefit from a shorter, more tailored discussion in the Key Information Table that is intended to convey how an investor's elections under the contract (
                        <E T="03">e.g.,</E>
                         as to classes, optional benefits, portfolio companies, etc.) will impact the fees and expenses he or she will experience under his or her contract.
                        <SU>118</SU>
                        <FTREF/>
                         As discussed below, we are requiring, as proposed, that the initial summary prospectus also include the Fee Table from the statutory prospectus.
                        <SU>119</SU>
                        <FTREF/>
                         This framework will allow an investor to determine the level of fee information that best suits his or her informational needs.
                    </P>
                    <FTNT>
                        <P>
                            <SU>116</SU>
                             
                            <E T="03">See</E>
                             Item 3 of current Forms N-3, N-4, and N-6 (“Fee Table”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>117</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter (observing that the Fee Tables in some statutory prospectuses “[a]re quite long (pushing 7 pages) . . . [one] has a fee table with its own table of contents.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>118</SU>
                             Although the presentation of fees and expenses in the Key Information Table is shorter and more tailored relative to what is included in the Fee Table, many of the calculations and instructions in the Key Information Table directly reference parallel provisions in the Fee Table. This should increase efficiency and comparability between the disclosures, and also help ensure that updates and amendments to the calculations and instructions in the Fee Table are appropriately reflected in the Key Information Table.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>119</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.1.c.ii.(h).
                        </P>
                    </FTNT>
                    <P>
                        We received mixed comments regarding the proposed Key Information 
                        <PRTPAGE P="25977"/>
                        fee tables. One commenter approved of the summary fee tables, stating “they are well‐conceived.” 
                        <SU>120</SU>
                        <FTREF/>
                         Two commenters opposed presenting fee information in the Key Information Table (and certain other sections of the initial summary prospectus) as repetitive and potentially confusing to investors, and instead recommended that all fee and expense information be disclosed in a single location in the initial summary prospectus (
                        <E T="03">i.e.,</E>
                         the full Fee Table, described in the section titled “Additional Information About Fees.”).
                        <SU>121</SU>
                        <FTREF/>
                         One commenter stated that numerical fee information should not be in the Key Information Table because the investor would not have sufficient context to understand specific dollar figures or percentages at that point of the document, and that a narrative explanation of the types of fees and expenses associated with the investment, accompanied by a cross-reference to the Fee Table, would be most useful to investors.
                        <SU>122</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>120</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter. In addition, almost all of the respondents to our Feedback Flier agreed that the examples reflecting how much an investor would pay for a variable annuity, including upfront fees and future costs were clear.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>121</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Lincoln Comment Letter; 
                            <E T="03">see also</E>
                             CFA Comment Letter (expressing skepticism that most investors would be able to pull together disparate information about the contract features and fees that is scattered throughout the initial summary prospectus to make an informed choice).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>122</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>While we acknowledge that some fee information presented in the Key Information Table may be duplicative of information in the Fee Table, we believe that this is consistent with our general layered disclosure approach. Investors can receive preliminary fee-related information in the Key Information Table, and more detailed information in the Fee Table later in the document. Moreover, we are not persuaded, as one commenter suggests, that providing only a narrative description of the charges, without corresponding numerical costs, would as effectively communicate to new investors the costs associated with a variable product as a presentation that includes numeric information. Accordingly, we are adopting, as proposed, the requirement to include specific dollar figures and percentages in the Key Information Table.</P>
                    <P>
                        <E T="03">Charges for Early Withdrawals.</E>
                         It is important that investors understand that if they make a withdrawal in the first several years following an investment in their contract, they may pay a significant charge that will reduce the value of their investment. We believe, however, that investors frequently do not understand, or may be surprised by, surrender charges associated with early withdrawals.
                        <SU>123</SU>
                        <FTREF/>
                         For that reason, the Commission proposed that the Key Information Table require information intended to alert investors about the potential impact of surrender charges imposed on early withdrawals.
                    </P>
                    <FTNT>
                        <P>
                            <SU>123</SU>
                             The Commission's Office of Investor Education and Advocacy frequently receives investor inquiries about variable contract surrender charges, suggesting that many investors may be confused about how surrender charges work.
                        </P>
                    </FTNT>
                    <P>
                        Comments were mixed on this issue. Two commenters urged us to de-emphasize the surrender charges in the summary prospectus, suggesting that their prominence overemphasizes the risk they present.
                        <SU>124</SU>
                        <FTREF/>
                         However, another commenter stressed the need for prominent disclosure of surrender charges, stating that older investors might not understand that long surrender periods may limit their ability to access money in their account.
                        <SU>125</SU>
                        <FTREF/>
                         Other commenters requested more flexibility in the terminology used for this heading, and objected to the use of the term “surrender charges.” 
                        <SU>126</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>124</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; NAIFA Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>125</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>126</SU>
                             
                            <E T="03">See supra</E>
                             note 79.
                        </P>
                    </FTNT>
                    <P>
                        Given the consequences of misunderstanding the impact of a surrender charge for early withdrawals, we are requiring, largely as proposed, the first line-item in the table, “Charges for Early Withdrawals,” to state that if the investor withdraws money from the contract within [x] years following his or her last premium payment, he or she will be assessed a surrender charge. This statement will include the maximum surrender charge, and the maximum number of years that a surrender charge may be assessed since the last payment was made under the contract.
                        <SU>127</SU>
                        <FTREF/>
                         In response to commenters' concerns regarding the term “surrender charges,” we believe that the term “withdrawal” both sufficiently encompasses surrenders and other types of withdrawals and is a more intuitive term for investors, and have modified the heading accordingly.
                    </P>
                    <FTNT>
                        <P>
                            <SU>127</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(a) to Item 2 of Forms N-3, N-4, and N-6. The maximum surrender charge must be expressed as a percentage of the purchase payment or premium or the amount surrendered, whichever is applicable.
                        </P>
                    </FTNT>
                    <P>
                        In addition, we are requiring, as proposed, an example of the maximum surrender charge an investor could pay (in dollars) under the contract assuming a $100,000 investment (
                        <E T="03">e.g.,</E>
                         “[i]f you make an early withdrawal, you could pay a surrender charge of up to $9,000 on a $100,000 investment.”).
                        <SU>128</SU>
                        <FTREF/>
                         The Commission proposed to use $100,000 as the basis for the surrender charge example because the value of the average variable annuity contract exceeds $100,000.
                        <SU>129</SU>
                        <FTREF/>
                         For purposes of the Key Information Table, we believe that providing a dollar figure may better communicate to investors the impact of surrender charges than a surrender charge schedule that shows the applicable surrender charge per year as a percentage, as reflected elsewhere in the document.
                        <SU>130</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>128</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>129</SU>
                             S
                            <E T="03">ee also</E>
                             IRI Fact Book, 
                            <E T="03">supra</E>
                             note 7.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>130</SU>
                             Registrants will continue to disclose the surrender fee as a percentage in the “Transaction Expenses” section of the Fee Table. 
                            <E T="03">See</E>
                             Item 4 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter objected to a surrender charge example in the Key Information Table based on an assumed investment of $100,000,
                        <SU>131</SU>
                        <FTREF/>
                         while several others generally opposed using $100,000 as the basis for any fee examples in the initial summary prospectus, preferring the current $10,000 assumed investment level.
                        <SU>132</SU>
                        <FTREF/>
                         As we noted in the Proposing Release, $100,000 more closely approximates the current average value of a variable annuity, and therefore we continue to believe that figure is more likely to result in cost projections that align with actual investor expectations and experience.
                        <SU>133</SU>
                        <FTREF/>
                         For this reason, and as discussed in more detail below, we are requiring $100,000 as the baseline investment assumption for all fee examples in a variable contract prospectus, including the Key Information Table's surrender charge example.
                        <SU>134</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>131</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter (“The assumed $100,000 average for variable contracts overstates the impact of surrender charges for contracts that are below that average.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>132</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Lincoln Comment Letter; Transamerica Comment Letter; ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>133</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.9.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>134</SU>
                             
                            <E T="03">See infra</E>
                             Section II.C.2.d.iv; 
                            <E T="03">see also</E>
                             Item 4 of amended Forms N-3, N-4, and N-6 (requiring registrants to reflect the consequence of any surrender fee in the “Example” to the Fee Table, which, based on a $100,000 assumed investment, shows in dollar figures how much an investor would pay if the contract were surrendered after 1 year, 3 years, 5 years, and 10 years).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Transaction Charges.</E>
                         As proposed, the second line-item in the “Fees and Expenses” section of the table, “Transaction Charges,” requires a statement explaining that in addition to surrender charges, the investor may also be charged for other transactions, accompanied by a brief description of the types of such charges (
                        <E T="03">e.g.,</E>
                         front-end loads, charges for transferring cash value between investment options, 
                        <PRTPAGE P="25978"/>
                        charges for wire transfers, etc.).
                        <SU>135</SU>
                        <FTREF/>
                         This requirement is designed to provide a simple narrative description to alert investors that surrender charges are not the only transaction charges they could pay. We received no comments regarding this line-item.
                    </P>
                    <FTNT>
                        <P>
                            <SU>135</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(b) to Item 2 of Forms N-3, N-4, and N-6. Although surrender charges are a type of transaction charge, we are requiring surrender charges be separately disclosed in the Key Information Table to highlight to investors the significant costs associated with early withdrawals.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Ongoing Fees and Expenses.</E>
                         We are adopting, largely as proposed, the third line-item in the “Fees and Expenses” section of the Key Information Table, “Ongoing Fees and Expenses (annual expenses),” which is designed to alert investors that they also will bear recurring fees on an annual basis.
                        <SU>136</SU>
                        <FTREF/>
                         In Forms N-3 and N-4, the disclosure in this line-item will begin with the legend: “The table below describes the fees and expenses that you may pay 
                        <E T="03">each year,</E>
                         depending on the options you choose.” 
                        <SU>137</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>136</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c) to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>137</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(i)(A) to Item 2 of amended Forms N-3and N-4.
                        </P>
                    </FTNT>
                    <P>
                        Largely as proposed, Form N-4 registrants will disclose, in a tabular presentation in the order specified, the minimum and maximum annual fees for: (1) Base contract expenses;
                        <SU>138</SU>
                        <FTREF/>
                         (2) investment options (
                        <E T="03">e.g.,</E>
                         portfolio company fees and expenses); 
                        <SU>139</SU>
                        <FTREF/>
                         and (3) optional benefits available for an additional charge (for a single optional benefit, if elected).
                        <SU>140</SU>
                        <FTREF/>
                         Since Form N-3 registrants have a single-tier structure and consolidate fees and expenses for investment options into base contract expenses, they will disclose the same information as Form N-4 registrants, except fees for base contract expenses and investment options will be consolidated into a single entry labeled “annual contract expenses.” 
                        <SU>141</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>138</SU>
                             The Commission did not propose to require and we are not adopting minimum and maximum annual fees for base contract expenses for Form N-6 registrants because life insurance charges are based on underwriting and can vary significantly from one insured person to another depending on various demographic characteristics. This could lead to significant variations between these amounts, which may be confusing to investors.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>139</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(i)(D) to Item 2 of amended Form N-4. Registrants will use the gross expense ratio disclosed in the Fee Table of a portfolio company's current prospectus, which is the same basis for calculating portfolio company expense ratios as Items 4 (Fee Table) and 17 (Portfolio Companies Available Under the Contract) of Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>140</SU>
                             The disclosure will also require, in a parenthetical or footnote to the table or each caption, an explanation of the basis for each percentage (
                            <E T="03">e.g.,</E>
                             as a percentage of separate account value or benefit base, or percentage of net asset value). 
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(i)(C) to Item 3 of amended Form N-4 (percentage of net asset value). 
                        </P>
                        <P>In a change from the proposal, we are revising the line-item heading for optional benefits available for an additional charge to clarify that the minimum and maximum fees disclosed for that line-item relate to a single optional benefit, if elected.</P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>141</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(i)(B) to Item 2 of amended Form N-3. In a conforming change, we are revising the instructions to this item to clarify that optional benefits charges should not be included in the calculation of annual contract expenses, because optional benefits charges are separately displayed in a line-item titled “optional benefits available for an additional charge (if elected).” 
                            <E T="03">See</E>
                             Instruction 2(c)(i)(D) to Item 2 of amended Form N-3.
                        </P>
                    </FTNT>
                    <P>
                        The minimum annual fee column will show the lowest fee for each annual fee category (
                        <E T="03">i.e.,</E>
                         the least expensive contract class, the lowest annual portfolio company expense or management fee, and the single least expensive optional benefit that is available for an additional charge).
                        <SU>142</SU>
                        <FTREF/>
                         The maximum annual fee column will show the highest fees for these categories (and will reflect the single most expensive optional benefit). Additionally, a legend preceding the minimum and maximum annual fee table will refer investors to their contract specifications page for information about the specific fees they would pay each year based on the options elected.
                        <SU>143</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>142</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(i) to Item 2 of amended Form N-3; Instruction 2(c)(i) to Item 2 of amended Form N-4. In a conforming change, we are revising this instruction in amended Form N-3 to mirror the parallel instruction in amended Form N-4 in order to identify the specific categories for which lowest and highest fees should be shown, as opposed to simply stating that the lowest and highest contract fees should be shown.
                        </P>
                        <P>
                            Because the table showing minimum and maximum annual fees is intended to inform investors about the types and ranges of fees associated with a variable contract, we are excluding certain assumptions from the calculations. For example, although some registrants do not charge extra for certain optional benefits (
                            <E T="03">e.g.,</E>
                             portfolio rebalancing and dollar-cost averaging), we believe investors should be alerted to the costs associated with optional benefits that are available for an additional charge. 
                            <E T="03">See</E>
                             Instruction 2(c)(i)(B) to Item 2 of amended FormN-3 (stating that disclosures should be provided for optional benefits available for an additional charge); Instruction 2(c)(i)(B) to Item 2 of amended FormN-4 (same). Accordingly, the disclosure should reflect the minimum cost associated with an optional benefit that has a fee. If the registrant offers any optional benefits for an additional charge, the minimum fee should not be zero. For example, if the registrant offers three optional benefits, with additional charges of 0%, 0.50%, and 1.50%, then the minimum and maximum annual fees reflected in the table would be 0.50% and 1.50%.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>143</SU>
                             Instruction 2(c)(i)(A) to Item 2 of amended Forms N-3 and N-4. Many states require a contract specifications page that contains information about the purchase payments, fees, annuitization date and other information specific to an investor's variable annuity contract. 
                            <E T="03">See, e.g.,</E>
                             the Insurance Compact's Individual Deferred Variable Annuity Contract Standards, 
                            <E T="03">available at https://www.insurancecompact.org/rulemaking_records/080911_stds_annuity_individual_deferred_variable.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <P>
                        This presentation will consolidate the more detailed information in the Fee Table, in an effort to minimize the need for investors to perform complex calculations to understand the fees they will pay.
                        <SU>144</SU>
                        <FTREF/>
                         For example, like the “Ongoing Fees and Expenses” line-item in the Key Information Table, the Fee Table will also include information about the contract's base contract fee, portfolio company fees and expenses, and optional benefits.
                        <SU>145</SU>
                        <FTREF/>
                         However, the Fee Table will include a separate response for each contract class.
                        <SU>146</SU>
                        <FTREF/>
                         In order to condense this information, the parallel disclosure in the Key Information Table will be presented as fee ranges.
                    </P>
                    <FTNT>
                        <P>
                            <SU>144</SU>
                             This reflects the principle, which experts in disclosure effectiveness for consumer-facing communications have encouraged, of “eliminat[ing] most complex calculations” for consumers. 
                            <E T="03">See</E>
                             Kleimann Presentation, 
                            <E T="03">supra</E>
                             note 112.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>145</SU>
                             
                            <E T="03">See</E>
                             Item 4 of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>146</SU>
                             
                            <E T="03">See</E>
                             Instruction 7 to Item 4 of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <P>
                        As described in the Proposing Release, we also designed an example in Forms N-3 and N-4 to provide a high-level cost illustration that will give an investor a tool to understand the basic cost framework of the contract. To emphasize that an investor's choices have a significant impact on the costs associated with his or her investment, we are requiring a two-column tabular presentation in the order specified reflecting the lowest and highest annual cost estimates for the variable contract.
                        <SU>147</SU>
                        <FTREF/>
                         The following legend will precede this table: “Because your contract is customizable, the choices you make affect how much you will pay. To help you understand the cost of owning your contract, the following table shows the lowest and highest cost you could pay 
                        <E T="03">each year.</E>
                         This estimate assumes that you do not take withdrawals from the contract, which could add surrender charges that substantially increase costs.” 
                        <SU>148</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>147</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(ii) to Item 3 of Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>148</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(ii)(A) to Item 3 of Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, the lowest and highest annual dollar costs in this table are based on certain prescribed assumptions (
                        <E T="03">i.e.,</E>
                         a $100,000 investment) with no additional contributions, transfers, or withdrawals, no sales charges, and a 5% annual return over a hypothetical 10-year period.
                        <SU>149</SU>
                        <FTREF/>
                         The lowest annual cost 
                        <PRTPAGE P="25979"/>
                        estimate is based on the least expensive combination of contract classes and portfolio company charges or management fees, and excludes optional benefits. The highest annual cost estimate reflects the most expensive combination of contract classes, portfolio company charges or management fees, and optional benefits.
                        <SU>150</SU>
                        <FTREF/>
                         Excluding optional benefits from the lowest annual cost estimate, and including them in the highest annual cost estimate, is intended to illustrate the cost impact of adding optional benefits to a contract.
                        <SU>151</SU>
                        <FTREF/>
                         With this information, the investor will be able to roughly estimate further costs,
                        <SU>152</SU>
                        <FTREF/>
                         and may be able to obtain additional information about costs in the statutory prospectus if needed.
                        <SU>153</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>149</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(ii)(C)(a) to Item 3 of Forms N-3 and N-4. 
                        </P>
                        <P>
                             The prescribed assumptions largely mirror the Fee Table, with the exception of the sales load, which is not reflected because we are seeking to 
                            <PRTPAGE/>
                            highlight the contract's ongoing expenses. Because registrants may charge different fees in different years (which may have the effect of making fees appear small under certain circumstances), we are basing the cost estimate on the average cost of a contract over a 10-year period to level-set the calculation. 
                            <E T="03">See</E>
                             Instruction 2(c)(ii)(C)(a) to Item 3 of Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>150</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(ii)(C)(a) to Item 2 of amended Forms N-3 and N-4. In a conforming change, we are revising this instruction in amended Form N-3 to mirror the parallel instruction in amended Form N-4 in order to identify the specific categories for which lowest and highest fees should be shown, as opposed to simply stating that the lowest and highest contract fees should be shown. Instruction 2(c)(ii)(C)(e) to Item 3 of amended Forms N-3 and N-4 direct that, unless otherwise stated, the least and most expensive combination of annual contract expenses and optional benefits available for an additional charge should be based on the disclosures provided in the Example in Item 4 (Fee Table), and that if a different combination of these items would result in different maximum or minimum fees in different years, the registrant must use the least or most expensive combination of these items each year.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>151</SU>
                             While the example in the Fee Table would include a similar cost estimate, it would reflect the most expensive combination of annual portfolio company expenses and optional benefits available for each contract class available under the contract. The Fee Table example also includes estimated costs for 1-, 3-, 5- and 10-year periods (not just for one year), and reflects different scenarios based on whether the contract is surrendered or annuitized. 
                            <E T="03">See</E>
                             Item 4 of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>152</SU>
                             For example, since he or she would know the range of costs to be paid over one year, he or she could estimate the costs to be paid over five years.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>153</SU>
                             We also encourage registrants to use design features (
                            <E T="03">e.g.,</E>
                             multiple colors or shading patterns) that visually distinguish minimum and maximum fees, and lowest and highest annual cost estimates.
                        </P>
                    </FTNT>
                    <P>
                        Despite advocating for the removal of numerical fee information in other sections of the Key Information Table, one commenter stated that “[a]n investor would benefit from the proposed annual cost estimates, which are easy for an investor to understand and would not be repeated elsewhere in the [Initial Summary Prospectus]” and supported including the cost estimates in this Key Information Table fee table.
                        <SU>154</SU>
                        <FTREF/>
                         We received two comments reiterating concerns with the $100,000 assumed investment amount,
                        <SU>155</SU>
                        <FTREF/>
                         but as previously discussed, we are requiring this amount for all examples in variable contract summary and statutory prospectuses because $100,000 more closely approximates the current average value of a variable annuity, and therefore we continue to believe that figure is more likely to result in cost projections that align with actual investor expectations and experience.
                        <SU>156</SU>
                        <FTREF/>
                         We received no other comments on the cost estimate in the Key Information Table, and are adopting it as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>154</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>155</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>156</SU>
                             
                            <E T="03">See supra</E>
                             note 133 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        For Form N-6, the Commission proposed a variation of the “Ongoing Fees and Expenses” section of the Key Information Table that was proposed for Forms N-3 and N-4. Because the costs associated with variable life insurance contracts are largely based on the personal characteristics of the insured (
                        <E T="03">e.g.,</E>
                         age, sex, health history), the Commission did not propose to require specific numeric information about the fees covering the cost of insurance and optional benefits,
                        <SU>157</SU>
                        <FTREF/>
                         but instead proposed to require this section of the Key Information Table to include: (1) A brief statement that investment in a variable life insurance contract is subject to certain ongoing fees and expenses that are set based on characteristics of the insured; and (2) the minimum and maximum annual fees for the investment options in a tabular presentation.
                        <SU>158</SU>
                        <FTREF/>
                         One commenter who addressed this aspect of the proposal supported our approach,
                        <SU>159</SU>
                        <FTREF/>
                         and we are adopting this requirement as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>157</SU>
                             In addition, maximum expenses for a variable life insurance contract could potentially exceed 100% of contract value based on the underwriting of the variable life insurance contract, which could potentially confuse investors.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>158</SU>
                             Instruction 2(c) to proposed Item 3 of FormN-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>159</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Fund Facilitation Fees.</E>
                         Two commenters asked how fund facilitation fees would be presented for purposes of the “Ongoing Fees and Expenses” section of the Key Information Table.
                        <SU>160</SU>
                        <FTREF/>
                         Currently, although our registration forms do not specifically reference fund facilitation fees, insurers that charge the fees disclose them in the prospectus. In our staff's experience, however, such practices vary.
                        <SU>161</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>160</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; Comment Letter of Lisa LeRoy (Nov. 9, 2018). We understand that some contracts registered on Forms N-4 and N-6 charge a fee, often referred to as “fund facilitation fees,” to make portfolio companies available as investment options under the contract. This fee varies solely on the basis of the portfolio company selected, and offsets the lack of distribution fees provided by certain low or no-cost portfolio companies, or provides revenue sharing from portfolio companies that wish to be included in the investment options under the variable contract. Because registrants on Form N-3 have a single tier structure and do not offer third-party portfolio companies as investment options, registrants on Form N-3 do not charge fund facilitation fees.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>161</SU>
                             As reflected by recent registration statement filings, insurers reflect fund facilitation fees in a number of ways, including as a separate account expense, as optional expenses, or under their own expense heading. Insurers typically include fund facilitation fees when calculating the Example to the Fee Table (some provide explanation in the footnotes) and the accumulation unit value tables. Insurers may also describe fund facilitation fees in the general description of the contract.
                        </P>
                    </FTNT>
                    <P>
                        To ensure that registrants disclose these fees in a consistent manner, in a change from the proposal, the final rules and forms include provisions in the registration forms covering such fees. First, consistent with our understanding of these fees, the forms define “platform charge” as any fee charged by the registrant to make a portfolio company available as an investment option under the contract, and that varies solely on the basis of the portfolio company selected.
                        <SU>162</SU>
                        <FTREF/>
                         To allow investors to see the lowest and highest charges associated with the range of available portfolio company options, we are modifying the proposed instructions to the Key Information Table to require the minimum (or maximum, if applicable) portfolio company expense ratio reflected in the table to include any platform fee charges to invest in that option.
                        <SU>163</SU>
                        <FTREF/>
                         The final rule and forms also require certain additional disclosures regarding platform charges in the Fee Table and in the portfolio company/investment option Appendix as described below.
                        <SU>164</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>162</SU>
                             
                            <E T="03">See</E>
                             General Instruction A of amended Forms N-4 and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>163</SU>
                             
                            <E T="03">See</E>
                             rule new 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 2(c)(i)(E) to Item 2 of amended FormN-4; Instruction 2(c)(i)(E) to Item 2 of amended Form N-6. Because we understand that Form N-3 registrants do not charge fund facilitation fees, we are not including this instruction in Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>164</SU>
                             
                            <E T="03">See, e.g., infra</E>
                             notes 300 (discussing platform charges in the context of the portfolio company/investment option Appendix) and 661 (discussing platform charges in the context of the Fee Table).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(ii) Risks</HD>
                    <P>
                        As proposed, the Key Information Table includes a condensed discussion of contract risks. Current risk disclosures in variable contract statutory prospectuses typically span multiple pages. While this level of disclosure may be appropriate for a statutory prospectus, we believe that a more-concise overview presentation of contract risks is better suited for the Key 
                        <PRTPAGE P="25980"/>
                        Information Table in light of the goals of the summary prospectus. Like the summary of fee and expense information that will appear in the Key Information Table, these risk summaries are intended to provide a concise overview, with additional information available for an investor who desires or requires additional details.
                    </P>
                    <P>
                        Specifically, the table will include four line-items under the heading “Risks,” each of which includes disclosure about a risk that we believe investors should be alerted to: (1) Risk of loss; (2) risks that could occur if an investor believes a variable annuity is a short-term investment; (3) risks associated with the contract's investment options; and (4) insurance company risks.
                        <SU>165</SU>
                        <FTREF/>
                         Each of these line-items will include succinct descriptions of the respective risk.
                    </P>
                    <FTNT>
                        <P>
                            <SU>165</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 3 to Item 3 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        The first line-item is intended to convey that although variable contracts have elements of insurance, unlike most traditional forms of insurance, these products are subject to the risk of loss.
                        <SU>166</SU>
                        <FTREF/>
                         This could help prevent any misunderstanding if, for example, an investor confused a variable annuity contract and a fixed annuity contract and did not understand that the contract value in a variable annuity could decline.
                    </P>
                    <FTNT>
                        <P>
                            <SU>166</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 3(a) to Item 3 of amended Forms N-3, N-4, andN-6 (“State that an investor can lose money by investing in the Contract.”).
                        </P>
                    </FTNT>
                    <P>
                        One commenter thought the “risk of loss” disclosure might be confusing because variable contracts should be held for the long term and that it would be more appropriate to state that the contract may be subject to market fluctuations or risks.
                        <SU>167</SU>
                        <FTREF/>
                         Another commenter stated that the disclosure should include the fact that high fees increase the risk of loss.
                        <SU>168</SU>
                        <FTREF/>
                         While risk of loss manifests in many different ways, we believe the proposed language serves its intended purpose of putting investors on notice that they can lose money by investing in the contract, and therefore we are adopting the requirement as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>167</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>168</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        The second line-item is intended to emphasize to investors that variable contracts are generally long-term investments and not appropriate for an investor who needs ready access to cash, particularly in view of the impact of surrender charges and/or tax penalties for early withdrawals.
                        <SU>169</SU>
                        <FTREF/>
                         The third line-item is intended to focus on the general risk of poor investment performance (as opposed to the details of the specific risks associated with each of the particular investment options available under the contract).
                        <SU>170</SU>
                        <FTREF/>
                         We received no comments on these line-items and are adopting them largely as proposed, although we have added a reference related to general or “fixed account” investment options to clarify for investors who might not understand that fixed account investment options have their own unique risks (such as credit risk).
                    </P>
                    <FTNT>
                        <P>
                            <SU>169</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 3(b) to Item 2 of amended Forms N-3, N-4, andN-6 (“State that a Contract is not a short-term investment and is not appropriate for an investor who needs ready access to cash, accompanied by a brief explanation.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>170</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 3(c) to Item 2 of amended Forms N-3, N-4, andN-6 (
                            <E T="03">e.g.,</E>
                             from Form N-4, “State that an investment in the Contract is subject to the risk of poor investment performance and can vary depending on the performance of the investment options available under the Contract (
                            <E T="03">e.g.,</E>
                             Portfolio Companies), that each investment option (including any fixed account investment option) will have its own unique risks, and that the investor should review these investment options before making an investment decision.”).
                        </P>
                        <P>Because most variable annuity contracts typically offer fifty or more portfolio companies to which investors can allocate their purchase payments, we are not requiring that the Key Information Table include risk information specific to each portfolio company, as to do so would undermine the goal of brevity for this disclosure item.</P>
                    </FTNT>
                    <P>
                        The fourth line-item is meant to alert investors that any obligations, guarantees, or benefits under the contract that may be subject to the claims-paying ability of the insurance company (as opposed to the separate account, which is insulated from the claims of the insurance company's creditors) will depend on the financial solvency of the insurance company. One commenter noted that this line-item is especially important because variable annuity products bear liquidity and single entity credit risk of the insurance company.
                        <SU>171</SU>
                        <FTREF/>
                         We agree and are adopting this line-item largely as proposed, but have added a reference to obligations related to general or “fixed account” investment options to clarify this point for investors who might not understand that any fixed account investment options may still be subject to the insurer's solvency and claims-paying ability.
                        <SU>172</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>171</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Chris Tobe (Nov. 1, 2018).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>172</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 3(d) to Item 2 of Forms N-3, N-4, and N-6 (
                            <E T="03">e.g.,</E>
                             from Form N-4, “State that an investment in the Contract is subject to the risks related to the Depositor, including the extent to which any obligations (including under any fixed account investment options), guarantees, or benefits are subject to the claims-paying ability of the Depositor.”).
                        </P>
                    </FTNT>
                    <P>
                        As part of these disclosures, the registrant is required to state that additional information about the insurance company, including, if applicable, its financial strength ratings, may be obtained upon request, and indicate how such requests can be made (
                        <E T="03">e.g.,</E>
                         via toll-free telephone number).
                        <SU>173</SU>
                        <FTREF/>
                         In lieu of providing the portion of this statement regarding the availability of the insurance company's financial strength ratings, a registrant could include the insurance company's financial strength rating(s).
                        <SU>174</SU>
                        <FTREF/>
                         One commenter suggested requiring a brief description of the insurer that includes the identification of the entity that is responsible for the insurance obligations under the contract.
                        <SU>175</SU>
                        <FTREF/>
                         Although that and other related information can be helpful to investors, and is required to be disclosed in variable contract statutory prospectuses, we do not believe that this line-item in the Key Information Table is the appropriate location for such disclosures.
                        <SU>176</SU>
                        <FTREF/>
                         As discussed above, the risks section of the Key Information Table is intended to provide succinct descriptions of certain key risks, as opposed to providing general factual information that is redundant with disclosures provided elsewhere in the prospectus and the registration statement.
                    </P>
                    <FTNT>
                        <P>
                            <SU>173</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 3(d) to Item 2 of amended Forms N-3, N-4, and N-6 (
                            <E T="03">e.g.,</E>
                             from Form N-4, “Further state that more information about the Depositor, including if applicable its financial strength ratings, is available upon request, and indicate how such requests can be made (
                            <E T="03">e.g.,</E>
                             via toll-free telephone number)”). 
                            <E T="03">See also</E>
                             Item 1(b)(1) of amended Form N-3, amended Form N-4, and amended Form N-6 (requiring the back cover page of the statutory prospectus to include a toll-free (or collect) telephone number for investor inquiries); rule 498A(b)(2)(v)(B) (requiring the front cover page of the initial summary prospectus to include a toll-free telephone number and email address for investor inquiries).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>174</SU>
                             
                            <E T="03">See</E>
                             Instruction to Instruction 3(d) to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>175</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>176</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 6 of amended Form N-4 (“General Description of Registrant, Depositor, and Portfolio Companies”); Item 26(g) of amended Form N-4 (“Reinsurance Contracts”).
                        </P>
                    </FTNT>
                    <P>
                        A fifth line-item, which will only appear in the “Risks” section for variable life insurance contracts, is meant to focus on contract lapse, which is a key risk for variable life insurance investors (but not relevant to variable annuity contracts).
                        <SU>177</SU>
                        <FTREF/>
                         For example, a variable life insurance contract may 
                        <PRTPAGE P="25981"/>
                        lapse when sufficient premium payments are not made by the investor. Since inadvertent contract lapse could negate the insurance benefit of the variable life insurance contract, we believe this risk should be included in the Key Information Table. We received no comments on this line-item and are adopting it as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>177</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 3(e) to Item 32 of amended Form N-6 (“Briefly state (1) the circumstances under which the Contract may lapse (
                            <E T="03">e.g.,</E>
                             insufficient premium payments, poor investment performance, withdrawals, unpaid loans or loan interest), (2) whether there is a cost associated with reinstating a lapsed Contract, and (3) that death benefits will not be paid if the Contract has lapsed.”).
                        </P>
                    </FTNT>
                    <P>
                        Some commenters identified other risks relevant to certain subsets of investors and contracts and suggested those risks be added to the Key Information Table.
                        <SU>178</SU>
                        <FTREF/>
                         We decline to revise the Key Information Table to include those additional risks because the required disclosures in the Key Information Table are intended to identify key risks that are common to all variable insurance contracts, and we do not believe that any of the suggested additional risks are necessarily common across all variable insurance contracts. As discussed further below, we are also adopting, as proposed, a new requirement in Forms N-3 and N-4 that, like the current parallel requirement in Form N-6, requires the registrant to summarize the principal risks of purchasing a contract in a consolidated risk section within the statutory prospectus.
                        <SU>179</SU>
                        <FTREF/>
                         Registrants have the flexibility to discuss any principal risks when responding to this requirement, including principal risks relevant to specific subsets of investors and contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>178</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Jill Lydos (Jan. 2, 2019) (stating that other important risks are not included in the initial summary prospectus, such as the risk of divorce affecting insurance benefits in a joint contract and the risk that, for an investor in a qualified contract with a withdrawal benefit, the withdrawal amount may not be sufficient to cover the required minimum distributions); 
                            <E T="03">see also</E>
                             Breacher Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>179</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 1(c) to Item 2; Item 5 of amended Forms N-3, N-4, and N-6. While we understand that variable annuity statutory prospectuses today commonly discuss contract risks (although Form N-3 and Form N-4 do not currently require them to do so), this discussion can be dispersed throughout the prospectus.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(iii) Restrictions</HD>
                    <P>
                        As proposed, the Key Information Table requires registrants to briefly disclose those features of a variable contract that commonly include restrictions or limitations, namely the investment options and optional benefits that the contract offers. We designed this section of the table to include separate line-items for each of these topics under the heading “Restrictions.” 
                        <SU>180</SU>
                        <FTREF/>
                         For example, many variable annuity contracts have optional benefits that restrict the percentage of assets that investors can allocate to certain investment options, such as more volatile categories of equity funds, in order to facilitate the insurance company's ability to reserve for the guarantees under the benefit.
                    </P>
                    <FTNT>
                        <P>
                            <SU>180</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 4 to Item 2 of amended Forms N-3, N-4, and N-6. We recognize that there may be overlap between the line-items for “Investments” and “Optional Benefits,” since many optional benefits limit the investments available to investors.
                        </P>
                    </FTNT>
                    <P>
                        The “Investments” line-item requires registrants to disclose whether there are any restrictions that may limit the investments that an investor may choose and/or limitations on the transfer of contract value among portfolio companies, and if applicable, that the insurer reserves the right to remove or substitute portfolio companies as investment options.
                        <SU>181</SU>
                        <FTREF/>
                         The “Optional Benefits” line-item requires registrants to disclose whether there are any restrictions or limitations relating to optional benefits, as well as whether the registrant may modify or terminate an optional benefit.
                        <SU>182</SU>
                        <FTREF/>
                         We included these line-items in the Key Information Table to put investors on notice of restrictions and limitations associated with different options that are available under the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>181</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 4(a) to Item 2 of amended Forms N-3, N-4, and N-6 (“State whether there are any restrictions that may limit the investments that an investor may choose, and/or whether there are any limitations on the transfer of Contract value among Portfolio Companies. If applicable, state that the insurer reserves the right to remove or substitute Portfolio Companies as investment options.”).
                        </P>
                        <P>
                            As a conforming change, we are changing the name of this line-item from “Investment Options” as proposed in Forms N-4 and N-6 to “Investments” to match the name of this line-item in amended Form N-3. 
                            <E T="03">See</E>
                             Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>182</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 4(b) to Item 2 of amended Forms N-3, N-4, and N-6 (“State whether there are any restrictions or limitations relating to optional benefits, and/or whether an optional benefit may be modified or terminated by the Registrant. If applicable, state that withdrawals that exceed limits specified by the terms of an optional benefit may affect the availability of the benefits by reducing the benefit by an amount greater than the value withdrawn, and/or could terminate the benefit.”). In a change from the proposal, registrants must state that this restriction or limitation may be triggered when withdrawals exceed limits specified by the terms of an optional benefit, which we believe will help investors better understand the circumstances under which this may occur.
                        </P>
                    </FTNT>
                    <P>
                        One commenter recommended placing greater emphasis on the investment restrictions associated with portfolio company options by renaming this section of the Key Investment Table “Investment Restrictions,” which would focus solely on benefit-related investment restrictions and the impact of not complying with such investment restrictions (including contract termination), and requiring all disclosure regarding restrictions or limitations related to optional benefits to be described in other sections of the initial summary prospectus.
                        <SU>183</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>183</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We are adopting the Restrictions line-items in the Key Information Table as proposed. As explained in the Proposing Release, we chose not to require a description of the specific restrictions and limitations associated with each of the available investment options and optional benefits because doing so would likely add significant length to the table, and such information will be provided in other parts of the initial summary prospectus, as well as the statutory prospectus.
                        <SU>184</SU>
                        <FTREF/>
                         Requiring a short description of these restrictions or limitations in the Key Information Table will alert investors of their existence. Investors looking for detailed descriptions of each such restriction or limitation may then review the “[Other]” Benefits Available Under the Contract” section. Finally, we decline to place greater emphasis on investment related restrictions in the Restrictions line-item, such as by renaming it “Investment Restrictions,” as this section is intended to cover all types of limitations or restrictions, including any non-investment related limitations or restrictions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>184</SU>
                             
                            <E T="03">See, e.g.,</E>
                             rule 498A(b)(5)(iv), Item 12(a) of amended Form N-3, and Item 11(a) of amended Forms N-4 and N-6 (all referencing the requirement that the table summarizing certain benefits available under the contract, which would appear in both the initial summary prospectus and the statutory prospectus, will be required to include a brief description of restrictions/limitations associated with each benefit); 
                            <E T="03">see also</E>
                             rule 498A(b)(5)(ix), Item 19 of amended Form N-3, and Item 18 of amended Forms N-4 and N-6 (all referencing the requirement that, if the availability of one or more portfolio company varies by benefit offered under the contract, the Appendix that would appear in the initial summary prospectus, updating summary prospectus, and statutory prospectus will be required to include a separate table indicating which portfolio companies are available under each of the benefits offered under the contract).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(iv) Taxes</HD>
                    <P>
                        Because variable contracts are subject to different tax rules than other investment products, with both tax advantages and potential tax impacts in certain circumstances, we are requiring that the Key Information Table include tax-related disclosures. The “Tax Implications” line-item of the table, which will appear under the heading “Taxes,” requires a statement that investors should consult with a tax professional to determine the tax implications of an investment in, and payments received under, the variable 
                        <PRTPAGE P="25982"/>
                        contract.
                        <SU>185</SU>
                        <FTREF/>
                         A registrant must also state that there is no additional tax benefit to the investor if the contract is purchased through a tax-qualified plan or individual retirement account (IRA), and that withdrawals will be subject to ordinary income tax and may be subject to tax penalties.
                        <SU>186</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>185</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 5 to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>186</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        One commenter stated that the tax consequences of purchasing a variable contract should be explained, and provided a list of six examples to include in the Key Information Table.
                        <SU>187</SU>
                        <FTREF/>
                         Another recommended adding disclosure regarding required minimum distributions for group contracts.
                        <SU>188</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>187</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter (recommending disclosure that, among other things, purchasing an annuity in an IRA in order to defer income is unnecessary since the IRA already is tax-deferred; funding an annuity with tax-deferred dollars gives the investor no additional tax benefits; and funding an annuity with after-tax money provides that all future gains are tax-deferred, but any gains are taxed at a higher ordinary income tax rate than capital gains rates).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>188</SU>
                             
                            <E T="03">See</E>
                             Breacher Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        As discussed in the Proposing Release, the tax disclosure in the Key Information Table is meant to alert investors to tax implications of their investment in a location using a presentation we believe investors are most likely to see and understand. While we agree that additional tax information could provide context for investors, it would also add length to what is intended to be a brief and targeted description in a summary document. Moreover, similar to the other line-items in the Key Information Table, additional detail about the tax implications of an investment in a variable contract will also be available in the statutory prospectus.
                        <SU>189</SU>
                        <FTREF/>
                         Finally, the tax disclosure is meant to include tax considerations that are generally applicable across all variable contracts, rather than a discussion of all tax considerations that may be relevant to a particular contract or investor. For these reasons we decline to add to the list of tax disclosures in the Key Information Table, and are adopting this requirement as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>189</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 15 of amended Form N-3, Item 14 of amended Form N-4, and Item 15 of amended Form and N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(v) Conflicts of Interest</HD>
                    <P>
                        As proposed, the Key Information Table must include, if applicable,
                        <SU>190</SU>
                        <FTREF/>
                         line-items regarding conflicts of interest that may arise in the context of variable contracts, specifically with regards to investment professional compensation and exchanges. The “Investment Professional Compensation” line-item requires registrants to disclose, if applicable, that an investment professional may be paid for selling the contract to investors.
                        <SU>191</SU>
                        <FTREF/>
                         A registrant must describe the basis upon which such compensation is typically paid (
                        <E T="03">e.g.,</E>
                         commissions, revenue sharing, compensation from affiliates and third parties). A registrant providing the required disclosure also must state that investment professionals may have a financial incentive to offer or recommend the contract over another investment for which the investment professional is not compensated (or compensated less). This requirement reflects analogous disclosure that appears in mutual fund summary prospectuses 
                        <SU>192</SU>
                        <FTREF/>
                         and is designed to address similar concerns—namely to alert investors to the existence of compensation arrangements for investment professionals and the potential conflicts of interest arising from these arrangements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>190</SU>
                             A registrant may omit these line-items if neither the registrant nor any of its related companies pay financial intermediaries for the sale of the contract or related services. 
                            <E T="03">See</E>
                             Instruction to Instruction 6 to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>191</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 6(a) to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>192</SU>
                             
                            <E T="03">See</E>
                             Item 8 of Form N-1A (requiring disclosure alerting investors who purchase a fund through a broker-dealer or other financial intermediary (such as a bank) that the fund and its related companies may pay the intermediary for the sale of fund shares and related services, and such payments may create a conflict of interest by influencing the broker-dealer or other intermediary and your salesperson to recommend the fund over another investment).
                        </P>
                    </FTNT>
                    <P>
                        The “Exchanges” line-item requires the registrant to state, if applicable, that some investment professionals may have a financial incentive to offer a new contract in place of the one owned by the investor.
                        <SU>193</SU>
                        <FTREF/>
                         A registrant must further state that investors should only exchange their contract if they determine, after comparing the features, fees, and risks of both contracts, that it is preferable for them to purchase the new contract rather than continue to own the existing contract. When a contract owner purchases a new annuity contract to replace an existing one, the new contract is referred to as a replacement contract.
                        <SU>194</SU>
                        <FTREF/>
                         We understand that a significant proportion of variable contract sales stem from exchanges, and these disclosures are intended to alert investors to potential conflicts of interest that may arise in that context.
                    </P>
                    <FTNT>
                        <P>
                            <SU>193</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 6(b) to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>194</SU>
                             Replacement contracts usually occur in connection with a tax-free exchange of non-qualified contracts under section 1035 of the Internal Revenue Code, or because of a rollover or direct transfer of a qualified plan contract (
                            <E T="03">e.g.,</E>
                             an individual retirement annuity) from one life insurance company to another. 
                            <E T="03">See</E>
                             26 U.S.C. 1035; 
                            <E T="03">see also</E>
                             26 CFR 1.1035-1.
                        </P>
                    </FTNT>
                    <P>
                        Several commenters sought to expand the scope of the conflicts of interest disclosure,
                        <SU>195</SU>
                        <FTREF/>
                         while others asked us to narrow it.
                        <SU>196</SU>
                        <FTREF/>
                         We are adopting this line-item as proposed. As noted above, the variable contract summary prospectus conflict of interest disclosures were modeled on the parallel requirement for mutual fund summary prospectuses. Based on our experience with the mutual fund summary prospectus regime we believe the required disclosure strikes the right balance of alerting investors to certain conflicts in a summary document, while accommodating additional detail that may be described in the statutory prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>195</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (asking that insurers be permitted to disclose other specific conflicts of interest that may be applicable to their products or services); Cardozo Clinic Comment Letter (recommending that conflicts of interest be removed from the Key Information Table and included in a separate section immediately following Key Information Table); AARP Comment Letter (recommending a requirement to disclose whether the person selling the variable contract is acting in the best interest of the investor.).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>196</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter (stating that because investment professional fees are not traditionally part of the contract, disclosure of those types of fees should not be required).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(vi) General Instructions</HD>
                    <P>
                        In addition to the proposed instructions specific to each line-item in the Key Information Table, we are adopting a set of general instructions to the table. As proposed, to streamline the disclosure and encourage registrants to use plain-English, investor-friendly principles when drafting the disclosures, the general instructions require registrants to disclose the required information in the tabular presentation reflected in the form, in the order specified.
                        <SU>197</SU>
                        <FTREF/>
                         However, registrants are permitted to exclude any disclosures that are not applicable or modify any of the statements required to appear in the table so long as the modified statement contains comparable information.
                        <SU>198</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>197</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 1(a) to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>198</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(a) to Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        In a change from the proposal, notwithstanding this instruction and a General Instruction permitting the use of alternate terminology under certain conditions, the title, headings, and sub-headings for this tabular presentation may not be modified or substituted with alternate terminology unless otherwise provided.
                        <SU>199</SU>
                        <FTREF/>
                         We believe having a standardized title, headings, and sub-
                        <PRTPAGE P="25983"/>
                        headings for the Key Information Table facilitates the ability of investors to easily compare key information and features for different variable contracts. Several commenters acknowledged the importance of an investor's ability to compare variable contracts across different insurance companies,
                        <SU>200</SU>
                        <FTREF/>
                         and we believe the use of standardized terms in this manner within the Key Information Table could facilitate comparability.
                    </P>
                    <FTNT>
                        <P>
                            <SU>199</SU>
                             
                            <E T="03">Id. See also</E>
                             General Instruction C.3.(d)(ii) to amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>200</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Jackson Comment Letter; Pacific Life Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        The general instructions require registrants to provide cross-references or links in electronic versions of the summary prospectus to the location in the statutory prospectus where the subject matter required by the line-item is described in greater detail.
                        <SU>201</SU>
                        <FTREF/>
                         As explained in the Proposing Release, we believe that providing cross-references and links (or similar technological access) will help investors who seek additional information quickly find more detailed information that may be important to them.
                        <SU>202</SU>
                        <FTREF/>
                         The cross-reference or link need not necessarily be a page number or page range; 
                        <SU>203</SU>
                        <FTREF/>
                         instead, a registrant could cross-reference or link to a particular section or sub-section, or heading or sub-heading, in the statutory prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>201</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             General Instruction 1(b) to Item 2 of amended Forms N-3, N-4, and N-6. The instruction specifies that the cross-reference should be adjacent to the relevant disclosure, either within the table row, or presented in an additional table column.
                        </P>
                        <P>
                             We also separately proposed that any cross-reference that is included in an electronic version of a summary prospectus must be an active hyperlink. 
                            <E T="03">See</E>
                             proposed rule 498A(i)(4). As discussed below, we are not adopting this requirement. 
                            <E T="03">See also infra</E>
                             Section II.A.6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>202</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at nn.162 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>203</SU>
                             We recognize that there may be operational challenges in syncing page numbers, especially between lengthy documents. 
                            <E T="03">See</E>
                             CAI Comment Letter (stating that page numbers are often in flux until the last moments prior to finalization).
                        </P>
                    </FTNT>
                    <P>
                        In response to comments,
                        <SU>204</SU>
                        <FTREF/>
                         we are modifying this general instruction in the context of the Key Information Table to allow registrants to provide another means of facilitating access through equivalent methods or technologies that lead directly to the relevant cross-referenced information.
                        <SU>205</SU>
                        <FTREF/>
                         In the context of the Key Information Table, this gives registrants the flexibility to provide a continuously visible sidebar in the summary prospectus that includes hyperlinks to sections in the statutory prospectus, as an alternative to providing a separate link for each line-item in the Key Information Table that links directly to the section in the statutory prospectus where the subject matter of that line-item is discussed in additional detail. Registrants who choose this option generally should provide a cross-reference for each line-item in the Key Information Table that directly corresponds to the appropriate heading in the sidebar (because otherwise an investor may find it difficult to determine which of the headings in the sidebar will provide more detailed information regarding that line-item).
                    </P>
                    <FTNT>
                        <P>
                            <SU>204</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (stating that proposed rule 498A(h)(1)(iii), which was modeled on parallel provisions in rule 498(e)(2)(iii) and applies to the summary prospectus as a whole, provides greater flexibility than the proposed form instruction, which would require direct links between the Key Information Table and the statutory prospectus with no alternative means); ACLI Comment Letter (recommending that the proposed requirement for additional embedded links be removed, and parallel the practices currently required in mutual fund summary disclosure).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>205</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(4) (“[A]ny website address or cross-reference that is included in an electronic version of the Summary Prospectus must include an active hyperlink or provide another means of facilitating access through equivalent methods or technologies that lead directly to the relevant website address or cross-referenced information.”); Instruction 1(b) to Item 2 of amended Forms N-3, N-4, and N-6 (“Cross-references in electronic versions of the Summary Prospectus and/or Statutory Prospectus should link directly to the location in the Statutory Prospectus where the subject matter is discussed in greater detail, or should provide a means of facilitating access to that information through equivalent methods or technologies.”).
                        </P>
                    </FTNT>
                    <P>
                        Finally, in keeping with our goal of providing a brief tabular presentation of key facts that can be easily digested by investors, the instructions provide that all disclosures in the Key Information Table should be short and succinct, consistent with the limitations of a tabular presentation.
                        <SU>206</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>206</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(i); 
                            <E T="03">see also</E>
                             Instruction 1(c) to Item 3 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Overview of the Contract</HD>
                    <P>
                        We are adopting, largely as proposed, the requirement that an initial summary prospectus include a section describing certain basic and introductory information about the contract and its benefits, under the heading “Overview of the [Variable Annuity/Life Insurance] Contract.” 
                        <SU>207</SU>
                        <FTREF/>
                         We are making only one substantive modification from the proposal related to this section. As proposed, this section would have appeared as the first substantive section of the initial summary prospectus, but as discussed above, this section will follow the Key Information Table under the final rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>207</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Item 3 of amended Forms N-3, N-4, and N-6; 
                            <E T="03">infra</E>
                             Section II.C.2.c.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Purpose of Contract.</E>
                         As proposed, the requirement to briefly describe the purpose(s) of the contract in general terms 
                        <SU>208</SU>
                        <FTREF/>
                         is intended to provide the reader with information on what financial objectives that contract could help the investor achieve, as well as the profile of an investor for whom the contract may be appropriate (
                        <E T="03">e.g.,</E>
                         by discussing a representative investor's time horizon, liquidity needs, and financial goals). This requirement could be satisfied, for example, by stating that the contract is meant to help the investor accumulate assets through an investment portfolio, to provide or supplement the investor's retirement income, or to provide death benefits and/or other benefits, and that the contract may not be appropriate for an investor that intends to access his or her invested funds within a short-term timeframe.
                        <SU>209</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>208</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Item 3(a) of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>209</SU>
                             One commenter recommended that to provide greater context for investors, this section should provide comparative information, stating “for example, if the purpose of the contract is `to provide or supplement the investor's retirement income,' the purpose should also state that other types of investments or products can achieve the same result.” 
                            <E T="03">See</E>
                             AARP Comment Letter. We decline to require this type of disclosure because it would not provide enough contextual information about the other products to permit comparison, and we do not require this type of disclosure for any other investment product.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Phases of Contract (for Variable Annuity Contracts).</E>
                         As proposed, the requirement to include a brief description of the accumulation (savings) phase and annuity (income) phases of the contract 
                        <SU>210</SU>
                        <FTREF/>
                         is meant to provide basic information about how the variable annuity contract functions, which in turn will help highlight how the contract differs from other types of investment products. It also is designed to address common areas of confusion among variable annuity investors. For example, it highlights the effect of annuitization on the ability to make withdrawals and the continuation of contract benefits.
                        <SU>211</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>210</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Item 3(b) of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>211</SU>
                             
                            <E T="03">See</E>
                             Cardozo Clinic Comment Letter (describing retail investors that failed to understand consequences of annuitizing, the adverse impact of withdrawals on optional benefits, and the fact that certain benefits can only be elected during the accumulation phase).
                        </P>
                    </FTNT>
                    <P>
                        This discussion requires a brief overview of the investment options available under the contract (that is, portfolio companies and any general or fixed account option).
                        <SU>212</SU>
                        <FTREF/>
                         The registrant 
                        <PRTPAGE P="25984"/>
                        also must prominently disclose that additional information on the portfolio companies is provided in an Appendix to the summary prospectus (or elsewhere in the case of registrants on Form N-3 that chose to omit the Appendix from the initial summary prospectus in favor of more detailed information about investment options as required by Item 19 of amended Form N-3), and provide a cross-reference to the Appendix.
                        <SU>213</SU>
                        <FTREF/>
                         Finally, the registrant must state, if applicable, that if an investor annuitizes, he or she will receive a stream of income payments, but he or she will be unable to make withdrawals, and death benefits and living benefits will terminate.
                        <SU>214</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>212</SU>
                             However, a detailed explanation of the separate account, sub-accounts, portfolio companies, and any “fixed account” (general account) investment options is not required. 
                            <E T="03">See</E>
                             Instruction 2 to Item 2(b)(1) of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>213</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instruction 1 to Item 3(b)(1) of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>214</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Item 3(b)(2) of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Premiums (for Variable Life Insurance Contracts).</E>
                         For the same reasons discussed in the Proposing Release, instead of requiring a description of the phases of the contract as with variable annuities, Form N-6 requires the “Overview” section to briefly describe the payment of premiums under the variable life insurance contract. This description of premiums must include: (1) Whether premiums may vary in timing and amount (
                        <E T="03">e.g.,</E>
                         flexible premiums); (2) whether restrictions may be imposed on premium payments (
                        <E T="03">e.g.,</E>
                         by age of insured, or by amount); (3) how premiums may be allocated (this discussion should include a brief overview of the investment options available under the contract, as well as any general (fixed) account options); and (4) a statement that payment of insufficient premiums may result in a lapse of the contract.
                        <SU>215</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>215</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Item 3(b) of amended Form N-6. The instructions will require the registrant to disclose that additional information on the portfolio companies is provided in an Appendix to the summary prospectus, and provide a cross-reference to the Appendix. In addition, the instructions note that a detailed explanation of the separate account, sub-accounts, portfolio companies, and any “fixed account” (general account) investment options is not required. 
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Instructions to Item 3(b)(3) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>Unlike variable annuities, variable life insurance generally requires the investor to make continuing premium payments in order to avoid a lapse of the contract. We therefore believe the “Overview” section should prominently explain the role of premium payments in the contract, and highlight for investors a key risk that non-payment (or insufficient payment) of premiums could result in contract lapse.</P>
                    <P>
                        <E T="03">Contract Features.</E>
                         Finally, this section will include a summary of the contract's primary features, including annuity benefits, death benefits, withdrawal options, loan provisions, and any available optional benefits.
                        <SU>216</SU>
                        <FTREF/>
                         If applicable, the registrant must state that the investor will incur an additional fee for selecting a particular benefit. Because registrants will discuss many of these subjects in other sections of the initial summary prospectus in greater detail (and will discuss each of these subjects in more detail in the contract statutory prospectus), this paragraph is intended to be summary in nature.
                    </P>
                    <FTNT>
                        <P>
                            <SU>216</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ii); 
                            <E T="03">see also</E>
                             Item 3(c) of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter suggested that the proposed list of overview topics was reasonable, but requested flexibility to allow registrants to prepare appropriate disclosures based on their products, markets, and customers.
                        <SU>217</SU>
                        <FTREF/>
                         A second commenter suggested that the contract's primary features and options should be listed in order of importance.
                        <SU>218</SU>
                        <FTREF/>
                         Because we believe the item requirements for the “Overview” section focuses on the most important features and options of a contract, while also giving registrants sufficient flexibility to tailor the disclosures in the manner best designed to briefly explain each product's features, we are adopting the substantive requirements for this section as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>217</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>218</SU>
                             
                            <E T="03">See</E>
                             Breacher Comment Letter.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Standard Death Benefits</HD>
                    <P>
                        We are modifying our proposed approach to death benefit disclosures in the initial summary prospectus. To highlight standard death benefit limitations and the possibility of its termination, the Commission proposed to require a section briefly describing the contract's standard death benefit,
                        <SU>219</SU>
                        <FTREF/>
                         immediately followed by a separate section describing any optional death benefits, as well as standard and optional living benefits.
                    </P>
                    <FTNT>
                        <P>
                            <SU>219</SU>
                             
                            <E T="03">See</E>
                             proposed rule 498A(b)(5)(iii); 
                            <E T="03">see also</E>
                             proposed Item 11(a) of Form N-3; proposed Item 10(a) of Form N-4; proposed Item 10(a) of Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        We received several comments suggesting that we eliminate the standard death benefit as a standalone section of the initial summary prospectus for variable annuities because, as one commenter explained, “investors typically don't purchase variable annuities for their death benefits, which don't generally require an additional fee.” 
                        <SU>220</SU>
                        <FTREF/>
                         Instead, commenters recommended that for variable annuities standard death benefits should be discussed in conjunction with the “Other Benefits Available Under the Contract.” 
                        <SU>221</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>220</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Comment Letter of Yassi Abdullah (Dec. 31, 2019) (“the standard death benefit isn't such a big deal under my contract.”); Comment Letter of Kristin Bowler (Feb. 11, 2019) (stating that the standard death benefit is “not that important.”). The respondents to our Feedback Flier collectively identified the standard death benefit as the “least useful” section of the hypothetical initial summary prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>221</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>After considering these comments, in a change from the proposal, we are not requiring variable annuity registrants to include a separate section of the initial summary prospectus briefly describing the standard death benefit. Registrants will instead provide standard death benefit information with all other standard and optional benefits, as discussed below.</P>
                    <P>
                        One commenter stated that “the concept of a `standard' death benefit generally does not apply to [variable life insurance] contracts.” The commenter noted that instead, variable life insurance contracts generally offer a choice of two or three death benefit options, none of which is standard.
                        <SU>222</SU>
                        <FTREF/>
                         This commenter recommended retaining a standalone section of the initial summary prospectus to describe variable life insurance contract death benefits, but suggested eliminating “Standard” from the heading, to be simply re-titled “Death Benefits.” This commenter also stated that the initial summary prospectus should summarize death benefit information rather than requiring almost all the information about death benefits in the variable life insurance contract's statutory prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>222</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (stating that “these death benefits generally are: (a) Face amount (the “level” death benefit); (b) face amount plus cash or contract value (the “increasing” death benefit); and in some cases, (c) return of (net) premium.”)
                        </P>
                    </FTNT>
                    <P>
                        In response to these comments, we are revising the rule to clarify that “standard death benefits” exclude optional or supplemental death benefits available for a separate charge.
                        <SU>223</SU>
                        <FTREF/>
                         To the extent that variable life insurance contracts present investors with a choice among several death benefit options whose costs are already reflected in the base contract, we believe that those options should be disclosed as part of the “standard death benefit” disclosures. To the extent that death benefits are available for a separate charge, those benefits should be presented as part of the section “Other Benefits Available Under the Contract.” 
                        <SU>224</SU>
                        <FTREF/>
                         We are retaining the heading “Standard Death Benefits” in the initial summary prospectus to 
                        <PRTPAGE P="25985"/>
                        distinguish the standard variable life insurance contract death benefits from any optional death benefits.
                    </P>
                    <FTNT>
                        <P>
                            <SU>223</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(iii); Item 10(a) of amended Form N-6; s
                            <E T="03">ee also infra</E>
                             Section II.C.2.k.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>224</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(iv); Item 11(a) of amended Form N-6; 
                            <E T="03">see also infra</E>
                             Section II.C.2.l.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, the rule requires disclosure of the forms the benefit may take and the form of benefit that will be provided if a particular form has not been selected, which should address the issue raised by the commenter regarding the various death benefit options that are generally offered by variable life insurance contracts. We are adopting the rule, as proposed, to require an initial summary prospectus for variable life insurance contracts to include certain key information regarding those standard death benefits.
                        <SU>225</SU>
                        <FTREF/>
                         Among other things, the initial summary prospectus requires, for each standard death benefit, when the insurance coverage is effective, when the death benefit is calculated and payable, how the death benefit is calculated, who has the right to choose the form of benefit and the procedure for choosing the form of benefit, the forms the benefit may take, and whether there is a minimum death benefit guarantee associated with the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>225</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(iii); Item 10(a) of amended Form N-6; 
                            <E T="03">see also infra</E>
                             Section II.C.2.k.
                        </P>
                    </FTNT>
                    <P>Finally, as proposed, under the registration form amendments, variable life insurance registrants will include in the statutory prospectus more detailed disclosures relating to standard death benefits, including how an investor may change the face amount of the death benefit, and how contract values and death benefits are affected by the investment performance of the portfolio companies, expenses, and deduction of charges. This additional information may help an investor who wants to understand the mechanics of how standard death benefits operate later in the contract lifecycle. However, we are not requiring that additional information to be included in the initial summary prospectus because we believe it would not be as critical to a basic initial understanding of the benefits, including any risks and limitations.</P>
                    <HD SOURCE="HD3">[Other] Benefits Available Under the Contract</HD>
                    <P>
                        We are requiring, largely as proposed, registrants to summarize standard and optional benefits available to the investor under the contract. We understand that insurers commonly consider these types of benefits to be primary features of variable contracts.
                        <SU>226</SU>
                        <FTREF/>
                         Because these benefits are also often key differentiators between competing products, we are requiring, largely as proposed, specific disclosures in both the statutory prospectus and the initial summary prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>226</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.17 and accompanying text (regarding the prevalence of optional benefits).
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, variable annuity contracts will not have a standalone section for standard death benefits, so we are retitling the heading for this section “Benefits Available Under the Contract” and requiring this summary table to include information about any standard and optional annuity or other living benefits, as well as any standard and optional death benefits that the variable annuity contract offers.
                        <SU>227</SU>
                        <FTREF/>
                         Since variable life insurance contracts will disclose standard death benefits in a separate section of the prospectus, in this section they will disclose non-standard death benefits (
                        <E T="03">i.e.,</E>
                         optional or supplemental death benefits available for a separate charge) as well as living contract benefits (such as income benefits, disability riders, long-term care insurance) under the heading “Other Benefits Available Under the Contract.” 
                        <SU>228</SU>
                        <FTREF/>
                         For purposes of this discussion, we refer to this table in the variable annuity and variable life insurance contract registration forms as the Benefits Table.
                    </P>
                    <FTNT>
                        <P>
                            <SU>227</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(iv); 
                            <E T="03">see also</E>
                             Item 11(a) of amended Form N-3; Item 10(a) of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>228</SU>
                             
                            <E T="03">See</E>
                             Item 11(a) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        Because benefit terms can be complex, we are requiring the information to be provided in a uniform tabular presentation to make these important disclosures easier for investors to read, understand, and compare. Largely as proposed, the Benefits Table requires the name of each benefit, its purpose, whether the benefit is standard or optional, and a brief description of limitations or restrictions.
                        <SU>229</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>229</SU>
                             For example, the description of limitations or restrictions could include statements like “benefit limits investment options available” or “withdrawals could terminate benefit.” 
                            <E T="03">See</E>
                             Instruction 6 to Item 11(a) of amended Form N-3; Instruction 6 to Item 10(a) of amended Form N-4; Instruction 6 to Item 11(a) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        In a change from the proposal, we are requiring the Benefits Table in Forms N-3 and N-4 to disclose the maximum fees (as a stated percentage of contract value, benefit base, etc.) associated with each benefit listed in the table(s), and revising the table heading to state “Maximum Fee.” 
                        <SU>230</SU>
                        <FTREF/>
                         Our proposal would have required disclosure of “associated fees,” but several commenters asked for clarification regarding whether registrants should disclose the maximum or current fees associated with the benefits, and whether fees could change over time.
                        <SU>231</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>230</SU>
                             
                            <E T="03">See</E>
                             Instruction 5 to Item 11(a) of amended Form N-3; Instruction 5 to Item 10(a) of amended Form N-4; Instruction 5 to Item 11(a) of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>231</SU>
                             
                            <E T="03">See</E>
                             [Feedback Flier] Comment Letters (seeking clarification regarding whether the “Fee” in the “Other Benefits Under the Contract” table was the current or maximum fee); 
                            <E T="03">see</E>
                             also VIP Working Group Comment Letter; Nedar Comment Letter; LeRoy Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Variable contracts typically include provisions that allow insurers to increase the fees associated with benefits up to a maximum charge, which can be significantly higher than the current fee. To help investors understand how much fees can be raised over time, we are revising the proposed instructions to the Benefits Table to clarify that registrants must disclose the maximum charge that investors could pay for each benefit.
                        <SU>232</SU>
                        <FTREF/>
                         Also in a change from the proposal, the final instructions to this table in Forms N-3 and N-4 will permit registrants to disclose the current charge in a separate column, if the disclosure of the current charge is no more prominent than, and does not obscure or impede understanding of, the disclosure of the maximum charge.
                        <SU>233</SU>
                        <FTREF/>
                         Collectively, this parallels the presentation of these charges in the Fee Table included in Forms N-3 and N-4.
                        <SU>234</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>232</SU>
                             For example, the table could disclose “up to 1.5%” or provide similar disclosure. 
                            <E T="03">See</E>
                             Instruction 5 to Item 11 of Form N-3; Instruction 5 to Item 10 of Form N-4. Where an insurer reserves the right to charge a fee, the table must include the maximum amount that may be charged, even if the insurer does not currently charge the fee.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>233</SU>
                             
                            <E T="03">See</E>
                             Instruction 6 to Item 11 of Form N-3; Instruction 6 to Item 10 of Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>234</SU>
                             
                            <E T="03">See</E>
                             Instruction 5 to Item 4 of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <P>
                        For variable life products registered on Form N-6, where fees are based in part on the personal characteristics of the insured, we recognize that a maximum fee applicable to an insured in the highest possible mortality risk category (
                        <E T="03">e.g.,</E>
                         an elderly smoker) may not be relevant to a typical investor. For these reasons, this item in Form N-6 does not require disclosure of maximum fees, but instead requires a statement explaining that the Fee Table contains information about the fees for each benefit.
                        <SU>235</SU>
                        <FTREF/>
                         We are adopting this requirement as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>235</SU>
                             As discussed above, the Fee Table includes the minimum fee, maximum fee, and fee for a representative investor for each benefit. 
                            <E T="03">See supra</E>
                             note 652 and accompanying text. This information should help provide better context for investors to understand the fees for the other benefits available under the contract.
                        </P>
                    </FTNT>
                    <P>
                        Under the form amendments, a registrant must include in the statutory prospectus the Benefits Table, as well as additional disclosures in narrative form relating to benefits, such as further descriptions of each benefit, whether it is standard or optional, descriptions of 
                        <PRTPAGE P="25986"/>
                        the benefits' limitations, restrictions and risks, and one or more examples illustrating the operation of each benefit.
                        <SU>236</SU>
                        <FTREF/>
                         We believe that requiring the initial summary prospectus to include only the Benefits Table and not the additional narrative disclosures is appropriate for the scope of the initial summary prospectus.
                        <SU>237</SU>
                        <FTREF/>
                         Consistent with the layered disclosure approach, investors who want more information about benefits may refer to the more extensive narrative disclosures in the contract statutory prospectus. Because the initial summary prospectus is intended for new investors and limited to features that are currently offered, benefits that are no longer available should not be included in the Benefits Table in the summary prospectus, but should be described in the statutory prospectus.
                        <SU>238</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>236</SU>
                             
                            <E T="03">See</E>
                             Items 11(b) and (c) of amended Form N-3 and instruction to same; Items 10(b) and (c) of amended Form N-4 and instruction to same; Items 11(b) and (c) of amended Form N-6 and instruction to same.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>237</SU>
                             Registrants may, but are not required to, provide in the initial summary prospectus cross-references or links to these additional narrative disclosures in the contract statutory prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>238</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (requesting that the Commission clarify that benefits (including versions and iterations of a single benefit) that are owned by existing contract owners but no longer for sale should not appear in an initial summary prospectus.”).
                        </P>
                    </FTNT>
                    <P>
                        We are also adopting, as proposed, instructions that allow registrants offering multiple benefits of the same type (
                        <E T="03">e.g.,</E>
                         death benefit, accumulation benefit, withdrawal benefit, long-term care benefit, etc.) to use multiple tables to provide the required information, if doing so might better permit comparisons of those benefits.
                        <SU>239</SU>
                        <FTREF/>
                         Registrants may also include appropriate titles, headings, or other information that might promote clarity and facilitate understanding of the table(s).
                        <SU>240</SU>
                        <FTREF/>
                         For example, if certain benefits are only available to certain investors, or are mutually exclusive, the table could include headings to identify which benefits are affected and to whom they are available. These instructions are designed to accommodate the variety of benefits currently offered or that might be offered in the future, and provide registrants flexibility in presenting this information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>239</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(b) to new Item 11(a) of amended Form N-3; Instruction 1(b) to amended Item 10(a) of amended Form N-4; Instruction 1(b) to Item 11(a) of amended Form N-6. Registrants that choose to use a single table should consider whether grouping together multiple benefits of the same type, with appropriate headings, might similarly permit better comparisons of those benefits.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>240</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(c) to new Item 11(a) of amended Form N-3; Instruction 1(c) to new Item 10(a) of amended Form N-4; Instruction 1(c) to Item 11(a) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter suggested that a one-page description of each rider may be more appropriate than the proposed Benefits Table.
                        <SU>241</SU>
                        <FTREF/>
                         In reacting to the Benefits Table contained in the hypothetical initial summary prospectus, some commenters also asked for more information, including how much a benefit pays, the likelihood that a benefit will pay out, and how much can be withdrawn annually.
                        <SU>242</SU>
                        <FTREF/>
                         While we recognize that the information in the Benefits Table only provides a brief description of the benefits, we believe that because variable contract features are typically complex, even a short description of each benefit available under the contract could significantly expand the length of what is designed to be a short and concise document. Because we believe retail investors are more likely to read a shorter document that briefly tells them about benefits available under the contract, and since more information will be available in the full contract prospectus,
                        <SU>243</SU>
                        <FTREF/>
                         we are not requiring the Benefits Table in the initial summary prospectus to include more information about those benefits.
                    </P>
                    <FTNT>
                        <P>
                            <SU>241</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>242</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Jake Sleder (Nov. 5, 2018) (“Sleder Comment Letter”); Breacher Comment Letter; M. Bowler Comment Letter; Nedar Comment Letter; Anonymous Comment Letter (Dec. 28, 2018) (“Anonymous Comment Letter III”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>243</SU>
                             
                            <E T="03">See infra</E>
                             Section II.C.2.l.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Buying the Contract (for Variable Annuity Contracts) and Premiums (for Variable Life Insurance Contracts)</HD>
                    <P>
                        We are adopting, largely as proposed, the requirement that the initial summary prospectus include a brief description of the procedures for purchasing the variable contract (and premiums, in the case of variable life insurance contracts), under the heading “Buying the Contract” for variable annuity contracts, and “Premiums” for variable life insurance contracts.
                        <SU>244</SU>
                        <FTREF/>
                         We believe this information should be included in the initial summary prospectus so investors have a clear understanding of how they can purchase the variable contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>244</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(v); 
                            <E T="03">see also</E>
                             Item 12(a) of amended Form N-3; Item 11(a) of amended Form N-4; Item 9(a) through (c) of amended Form N-6. With the exception of renumbering certain provisions, we made no other changes to this item as presented in current Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <P>
                        For variable annuity contracts, this will include a concise explanation of the minimum initial and subsequent purchase payments required, any limitations on the amount of purchase payments (such as when the selection of certain optional benefits may limit additional purchase payments), as well as a statement of when such payments are credited.
                        <SU>245</SU>
                        <FTREF/>
                         For variable life insurance contracts, this will include a description of the purchase procedures, premium amount, and premium due dates.
                        <SU>246</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>245</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(v); 
                            <E T="03">see also</E>
                             Item 12(a) of amended Form N-3; Item 11(a) of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>246</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(v); 
                            <E T="03">see also</E>
                             Item 9(a) through (c) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter noted that as proposed, the initial summary prospectus for variable life insurance contracts would include virtually all of the information required to be in the Premiums section of the variable life insurance statutory prospectus, and asked that we instead permit a brief summary of the specified premium information.
                        <SU>247</SU>
                        <FTREF/>
                         In response to the commenter's suggestion, we are revising the rule to require an initial summary prospectus for variable life insurance contracts to include only certain key information regarding premiums.
                        <SU>248</SU>
                        <FTREF/>
                         Among other things, the initial summary prospectus requires registrants on Form N-6 to describe the provisions of the contract that relate to premiums and the procedures for purchasing a contract, the factors that determine the amount of any required premiums, and the provisions of the contract that relate to premium due dates and the operation of any grace period.
                    </P>
                    <FTNT>
                        <P>
                            <SU>247</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; 
                            <E T="03">see also</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.181.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>248</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(v); 
                            <E T="03">see also</E>
                             Item 9(a) through (c) of amended Form N-6; 
                            <E T="03">see infra</E>
                             Section II.C.2.m.
                        </P>
                    </FTNT>
                    <P>
                        We believe this information should be included in the initial summary prospectus so investors have a clear understanding of how they can purchase the variable contract, but we are persuaded by the commenter that a more concise summary that is limited to key information regarding premiums is more likely to be useful to investors and is appropriate for the initial summary prospectus. We also note that, as proposed, additional information on purchases and premiums will appear in the statutory prospectus. For example, the statutory prospectus will also include information on the manner in which purchase or premium payments are credited, and the identity of each principal underwriter.
                        <SU>249</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>249</SU>
                             
                            <E T="03">See</E>
                             Item 12 of amended Form N-3; Item 11 of amended Form N-4; Item 9 of amended Form N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Contract Lapse (for Variable Life Insurance Contracts)</HD>
                    <P>
                        We are adopting, largely as proposed, the requirement that the initial 
                        <PRTPAGE P="25987"/>
                        summary prospectus for a variable life insurance contract include certain information about the possibility of contract lapse, under the heading “How Your Contract Can Lapse.” 
                        <SU>250</SU>
                        <FTREF/>
                         Specifically, the initial summary prospectus must briefly describe when and under what circumstances a variable life insurance contract will lapse, any lapse options, the effect of the lapse and under what circumstances such a contract may be reinstated. Because inadvertent contract lapse could negate the insurance benefit of a policy to an investor, possibly at significant cost,
                        <SU>251</SU>
                        <FTREF/>
                         understanding the risk of contract lapse is important when deciding whether to invest in a variable life insurance contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>250</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(vi); 
                            <E T="03">see also</E>
                             Item 14(a) of amended Form N-6 (requiring a brief summary of the disclosures required by paragraphs (b) through (e) of amended Item 14); 
                            <E T="03">see infra</E>
                             Section II.C.2.p.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>251</SU>
                             For example, costs could occur in the form of premium payments that the investor previously paid into the policy, and which the investor cannot retrieve following contract lapse.
                        </P>
                    </FTNT>
                    <P>
                        The Commission proposed that the initial summary prospectus would include the same information on contract lapse that would appear in the contract statutory prospectus. One commenter suggested that, consistent with a layered disclosure approach, the initial summary prospectus should only include a brief summary of the lapse and reinstatement information required in the full statutory prospectus.
                        <SU>252</SU>
                        <FTREF/>
                         In response to comments and consistent with our layered disclosure approach, we are revising the rule to require an initial summary prospectus for variable life insurance contracts to include only certain key information regarding contract lapse.
                        <SU>253</SU>
                        <FTREF/>
                         We were persuaded by the commenter that a more concise summary that is limited to key information regarding premiums is more likely to be useful to investors and is appropriate for the initial summary prospectus. Among other things, the initial summary prospectus requires registrants on Form N-6 to state when and under what circumstances a contract can lapse, the effect of lapse, and under what circumstances a contract may be reinstated.
                    </P>
                    <FTNT>
                        <P>
                            <SU>252</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>253</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(vi); 
                            <E T="03">see also</E>
                             Item 14(a) through (c) of amended Form N-6; 
                            <E T="03">see infra</E>
                             Section II.C.2.p.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Surrenders or Withdrawals</HD>
                    <P>
                        Largely as proposed, the initial summary prospectus must include certain information about contract surrenders or withdrawals, under the heading “Making Withdrawals: Accessing the Money in Your Contract.” 
                        <SU>254</SU>
                        <FTREF/>
                         This will include a brief summary on how to surrender (or partially surrender or make withdrawals from) a variable contract, including any limits on the ability to surrender, how withdrawal and surrender proceeds are calculated, and when they are payable.
                    </P>
                    <FTNT>
                        <P>
                            <SU>254</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(vii); 
                            <E T="03">see also</E>
                             Item 13(a) of amended Form N-3; Item 12(a) of amended Form N-4; Item 12(a) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        Several commenters observed that investors would also benefit from a description of the negative consequences of partial withdrawals on death and living benefits.
                        <SU>255</SU>
                        <FTREF/>
                         We agree that such information would be useful for investors, and have revised the relevant form requirements to additionally require the initial summary prospectus to briefly describe the potential impact of such surrenders or withdrawals.
                        <SU>256</SU>
                        <FTREF/>
                         Given that variable contracts are long-term investments that may entail high surrender fees, it is important to clearly explain the withdrawal and surrender terms to new variable contract investors, including the consequences of withdrawals on death and living benefits. To clarify the scope of paragraph (a), and to simplify this item in general, we are also removing references to “partial surrender” and “partial withdrawal” (which both have the same meaning as “withdrawal”) so that this item will only refer to “surrender” and “withdrawal,” which we believe are more plain English.
                        <SU>257</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>255</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Transamerica Comment Letter; AARP Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>256</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(vii); 
                            <E T="03">see also</E>
                             Item 13(a) of amended Form N-3; Item 12(a) of amended Form N-4; Item 12(a) of amended Form N-6; 
                            <E T="03">see also infra</E>
                             Section II.C.2.n.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>257</SU>
                             For example, as proposed, references to “surrender” appeared in paragraph (a) while references to “partial surrender” appeared in paragraphs (a) through (d). As amended, references to “surrender” appear in paragraphs (a) through (d) while all references to “partial surrender” are removed from this item. Among other things, this change clarifies that only the most important information about surrenders is required to be included in the summary prospectus pursuant to paragraph (a), while other information about surrenders should be disclosed in the statutory prospectus. This is consistent with the layered disclosure approach embodied in the summary prospectus and helps to ensure that the information in the summary prospectus regarding surrenders is not simply a full recitation of the same information contained in the statutory prospectus.
                        </P>
                    </FTNT>
                    <P>
                        Additional information on surrenders and withdrawals will appear in the statutory prospectus. For example, the statutory prospectus must include more detailed information on surrenders and withdrawals, sub-account allocation, involuntary redemptions, and revocation rights (free look period).
                        <SU>258</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>258</SU>
                             
                            <E T="03">See</E>
                             Item 13(b) through (d) of amended Form N-3; Item 12(b) through (d) of amended Form N-4; Item 12(b) through (d) of amended Form N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Additional Information About Fees</HD>
                    <P>
                        As proposed, the initial summary prospectus must include the Fee Table (including, for variable annuity contracts, the expense example), that will appear in the statutory prospectus, under the heading “Additional Information About Fees.” 
                        <SU>259</SU>
                        <FTREF/>
                         The Fee Table provides detailed information on the fees and expenses investors will pay when buying, owning, and surrendering the contract, as well as those paid each year during the time the investor owns the contract.
                        <SU>260</SU>
                        <FTREF/>
                         We are also adopting, largely as proposed, certain amendments to the Fee Table for each type of variable contract, as discussed below in Section II.C.2.d.
                    </P>
                    <FTNT>
                        <P>
                            <SU>259</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(viii); 
                            <E T="03">see also</E>
                             Item 4 of amended Forms N-3, N-4, and N-6.
                        </P>
                        <P>
                             The initial summary prospectus fee information will be the same as the Fee Table included in the contract statutory prospectus, modified as necessary to describe only a single contract that the registrant currently offers for sale. 
                            <E T="03">See infra</E>
                             Section II.A.1.b.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>260</SU>
                             In addition, the Fee Table details the minimum and maximum total operating expenses the portfolio companies charge annually, as well as an example intended to help the investor compare the cost of investing in different variable contracts.
                        </P>
                    </FTNT>
                    <P>
                        We are requiring the Fee Table in both the statutory prospectus and the initial summary prospectus because investor understanding of variable contract fees is particularly important given these products' layered fee structure and typically higher costs relative to other investment products. The Fee Table is intended to complement and build upon the high-level summary of contract fees and expenses in the Key Information Table by providing additional detail for those investors who may wish to review more comprehensive fee and expense information.
                        <SU>261</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>261</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.1.c.ii.(a).
                        </P>
                    </FTNT>
                    <P>We understand that some registrants currently prepare supplements to the contract prospectus that detail and modify certain fees and rates under the variable contract applicable to new investors (“rate sheets”). Current fees, withdrawal rates, and crediting rates associated with various contract benefits (for new sales) can change so frequently as to make filing of post-effective amendments to the registration statement with each change impractical. Instead, updated disclosure of current levels of these fees and rates is accomplished by filing a rate sheet as a supplement under rule 497 under the Securities Act. Because a rate sheet is no different than a change to any other term in the prospectus, the rate sheet approach permits the filing of a 497 filing instead of a rule 485(a) filing to implement that material change.</P>
                    <P>
                        Several commenters sought clarification regarding when a change to 
                        <PRTPAGE P="25988"/>
                        the contract would require the filing of a rate sheet supplement for an initial summary prospectus, and about the corresponding delivery obligations for rate sheet supplements.
                        <SU>262</SU>
                        <FTREF/>
                         As we noted in the proposal, we do not believe that the summary prospectus framework will affect the current practice of using rate sheets. When a rate (relating to fees, withdrawal rates, crediting rates, etc.) disclosed in any prospectus (initial, updating, or statutory) changes, the prospectus must be updated with the new rate and the update filed with the Commission, and the revised disclosures must be provided to investors affected by the rate change.
                        <SU>263</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>262</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; VIP Working Group Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>263</SU>
                             For example, if the rate sheet is updating information in a summary prospectus or the statutory prospectus, the document should describe how the rate sheet process works, and the rate sheet supplement should be affixed to the front of the document. In addition, the rate sheet supplement should be available on the website where current prospectuses and certain other documents must be posted online under rule 498A(h). As a best practice, all current rates should be separately posted on the website.
                        </P>
                    </FTNT>
                    <P>
                        Two commenters suggested that instead of filing rate sheets, insurers should provide current rates to investors as marketing materials at the point of sale.
                        <SU>264</SU>
                        <FTREF/>
                         Because a variable contract's fees and rates are material information, we do not believe relegating this information to marketing materials is sufficient, and are not making the suggested change.
                    </P>
                    <FTNT>
                        <P>
                            <SU>264</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Appendix: Portfolio Companies/Investment Options Available Under the Contract</HD>
                    <P>
                        We are requiring, largely as proposed, an initial summary prospectus to include an appendix, under the heading “Appendix: Portfolio Companies/Investment Options Available Under the Contract,” that provides summary information in a tabular form about the portfolio companies or investment options offered under the contract.
                        <SU>265</SU>
                        <FTREF/>
                         Commenters generally supported our proposal to include this Appendix in the initial summary prospectus.
                        <SU>266</SU>
                        <FTREF/>
                         While no commenters opposed the Appendix, we did receive a number of recommendations to modify certain aspects of the Appendix, some of which we are incorporating into the final version. In addition, we are making certain other changes discussed below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>265</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ix); 
                            <E T="03">see also</E>
                             Item 18 of amended Form N-3; Item 17 of amended Form N-4; Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>266</SU>
                             
                            <E T="03">See, e.g.,</E>
                             ICI Comment Letter; AARP Comment Letter (commending the “proposal for a summary disclosure for the underlying portfolio companies. We submit that a concise disclosure is needed.”); Capital Group Comment Letter; ACLI Comment Letter; Comment Letter of American International Group (Mar. 15, 2019) (“AIG Comment Letter”). In addition, the respondents to our Feedback Flier collectively identified the Appendix as the second “most useful” section of the hypothetical initial summary prospectus (after the Key Information Table).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Format/Scope.</E>
                         Because the investment experience of a variable contract investor will largely depend on his or her selection of portfolio companies (or investment options in the case of a variable annuity registered on Form N-3), we believe it is important for investors to receive an overview of the portfolio companies and investment options available under the contract in a uniform tabular presentation that promotes comparison, and are requiring, as proposed, the format specified in the introductory sentence of the relevant form item.
                        <SU>267</SU>
                        <FTREF/>
                         The Commission also proposed an instruction that registrants only include portfolio companies that are currently offered under the contract, and we are adopting this instruction with a modification, as described below.
                        <SU>268</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>267</SU>
                             
                            <E T="03">See</E>
                             Item 17 of amended Form N-4; Item 18 of amended Form N-6. In the context of participant-directed individual account plans under the Employee Retirement Income Security Act of 1974 (which, similar to variable contracts, are long-term, tax-advantaged investment vehicles whereby the investor may direct his or her investment among investment alternatives), a similar disclosure requirement applies. 
                            <E T="03">See</E>
                             29 CFR 2550.404a-5(d).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>268</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(b) to proposed Item 19 of Form N-3; Instruction 1(a) to proposed Item 18 of Form N-4; Instruction 1(a) to proposed Item 18 of Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter asked us to clarify whether the “currently offered” standard includes portfolio company options in which current, but not new, investors are permitted to invest (“soft closed” fund options).
                        <SU>269</SU>
                        <FTREF/>
                         This commenter suggested that an instruction be added to the Appendix specifying that soft closed fund options should not be included in the Appendix appearing in an initial summary prospectus, but should be included in the Appendix appearing in an updating summary prospectus and in a Statutory Prospectus, with an explanation (in a footnote or otherwise) of the limited availability of the options.
                    </P>
                    <FTNT>
                        <P>
                            <SU>269</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (explaining that “the Portfolio Company associated with a soft closed fund option may or may not be issuing new shares. Instead, when a Portfolio Company option is soft closed, the insurer limits the ability of some or all contract owners to invest in the subaccount corresponding to that Portfolio Company.”).
                        </P>
                    </FTNT>
                    <P>
                        We are modifying the form instruction to state that the Appendix must only include portfolio companies that are investment options under the contract (not just those that are “currently offered,” as proposed), and clarifying that registrants must indicate if investments in any of the portfolio companies offered under the contract are subject to a restriction (because of a “soft” or “hard” close).
                        <SU>270</SU>
                        <FTREF/>
                         This change is designed to require summary and statutory prospectuses to include all of the portfolio companies available under the contract in the Appendix, not just those that are currently offered. However, because the initial summary prospectus may describe only a single contract currently offered for sale,
                        <SU>271</SU>
                        <FTREF/>
                         the Appendix will only list the portfolio companies that are investment options under that particular contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>270</SU>
                             S
                            <E T="03">ee</E>
                             Instruction 1(a) to Item 18 of amended Form N-3, Item 17 of amended Form N-4, and Item 18 of amended Form N-6; 
                            <E T="03">see infra</E>
                             Section II.C.2.t.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>271</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(1).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Contents.</E>
                         The Commission proposed that the Appendix include separate columns for each portfolio company's type (
                        <E T="03">e.g.,</E>
                         money market fund, bond fund, balanced fund, etc.) or investment objective; the name of the portfolio company and its adviser or subadviser (as applicable); the portfolio company's expense ratio (expenses/average assets and, in the case of Form N-3, explicitly excluding optional benefit expenses); and its average annual total returns over the past 1-year, 5-year, and 10-year periods (in the case of Form N-3, explicitly excluding optional benefit expenses).
                        <SU>272</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>272</SU>
                             
                            <E T="03">See</E>
                             Instructions 2-4, 7 to Item 18 of amended Form N-3; Instructions 2-4, 7 to Item 17 of amended Form N-4; Instructions 2-4, 7 to Item 18 of amended Form N-6. 
                        </P>
                        <P> For purposes of this discussion, we use the term “portfolio company” throughout, even though the Appendix for Form N-3 registrants will use the term “investment option.”</P>
                    </FTNT>
                    <HD SOURCE="HD3">Type or Investment Objective</HD>
                    <P>
                        Regarding the proposed requirement that the Appendix include the portfolio company's type or investment objective, one commenter recommended that we require only the investment type (or primary asset class), which is similar to 401(k) fee disclosures, and not the investment objective.
                        <SU>273</SU>
                        <FTREF/>
                         Another commenter, which conducted its own online survey of variable annuity investors regarding certain aspects of the proposed Appendix, stated that its testing indicates that “if either `Investment Objective' information or `Investment Type' (
                        <E T="03">i.e.,</E>
                         one of these data fields, but not both) were to be included in the Appendix, “Investment Objective” would be more useful to investors.” 
                        <SU>274</SU>
                        <FTREF/>
                         In light of these varying 
                        <PRTPAGE P="25989"/>
                        comments, we continue to believe that it is appropriate to permit registrants the flexibility to choose the approach they believe most clearly and effectively communicates a portfolio company's investment category to retail investors, and are adopting this aspect of the Appendix as proposed.
                        <SU>275</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>273</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>274</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Broadridge Financial Solutions, Inc. (Mar. 15, 2019) (“Broadridge Comment Letter”) (reporting that based on a 4-day online survey of 120 individuals that self-identified as current variable annuity investors and were 
                            <PRTPAGE/>
                            asked to review a modified version of the proposed Appendix that replaced information on “investment type” with “investment objective, “nearly 90% said “Investment Objective” was more helpful than “Investment Type.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>275</SU>
                             
                            <E T="03">See</E>
                             Instruction 2 to Item 18 of amended Form N-3, Instruction 2 to Item 17 of Form N-4, and Instruction 2 to Item 18 of Form N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Name of Portfolio Company and Its Adviser or Subadviser</HD>
                    <P>
                        In response to our proposal to include a column with the name of each portfolio company and its adviser or subadviser, one commenter stated that that the Appendix should only identify sub-advisers “whose actions are likely to impact the fund significantly,” and an instruction should limit the requirement to sub-advisers that are responsible for a significant portion of a portfolio company's net assets, consistent with the approach for mutual funds.
                        <SU>276</SU>
                        <FTREF/>
                         We agree, and have modified the relevant instruction to mirror the approach in Form N-1A for consistency between the forms.
                        <SU>277</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>276</SU>
                             
                            <E T="03">See</E>
                             ICI Comment Letter (citing Instruction 2 to Item 5(b) of Form N-1A).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>277</SU>
                             
                            <E T="03">See</E>
                             Instruction 3 to Item 18 of amended Form N-3, Instruction 3 to Item 17 of Form N-4, and Instruction 3 to Item 18 of Form N-6; 
                            <E T="03">see also</E>
                             Instruction 2 to Item 5(a) of Form N-1A.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Portfolio Company Expenses and Performance</HD>
                    <P>
                        A number of commenters opposed our proposal to require the Appendix to include each portfolio company's expense ratio and/or performance information.
                        <SU>278</SU>
                        <FTREF/>
                         One commenter stated that insurers should not be responsible for disclosing specific data that is in each portfolio company's prospectus, and would be available at the website specified in the legend for the summary prospectus.
                        <SU>279</SU>
                        <FTREF/>
                         Several recommended eliminating this requirement, and replacing it with a legend or cross-reference stating where and how up-to-date portfolio company data can be obtained (
                        <E T="03">e.g.,</E>
                         on portfolio company and insurance company websites).
                        <SU>280</SU>
                        <FTREF/>
                         Two commenters suggested that electronic versions of the summary prospectus should be required to include direct links to the portfolio company summaries in the Appendix.
                        <SU>281</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>278</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (opposing fee and performance information); Brighthouse Comment Letter (opposing fee and performance information); Transamerica Comment Letter (opposing fee and performance information); Lincoln Comment Letter (opposing performance information); Ameritas Comment Letter (opposing performance information).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>279</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>280</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Lincoln Comment Letter; Brighthouse Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>281</SU>
                             
                            <E T="03">See</E>
                             AIG Comment Letter; CFA Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Commenters also opposed this requirement asserting that gathering the information for each portfolio company offered under a contract would be administratively burdensome (and in some cases, potentially infeasible given filing-related timing constraints).
                        <SU>282</SU>
                        <FTREF/>
                         They explained that insurers must rely on the portfolio companies to transmit their current expense ratios to them in time to meet the variable contracts' registration statement filing (and printing and mailing) deadlines. They noted that because portfolio companies often do not finalize their expense information until shortly before they file their annual registration statement updates, there is a very narrow window of time for insurers to collect, verify, and incorporate current portfolio company expense ratios into the variable contract prospectuses, which, like portfolio company prospectuses, must be filed by May 1.
                        <SU>283</SU>
                        <FTREF/>
                         Several commenters suggested there would also be operational and timing challenges associated with obtaining portfolio company performance data.
                        <SU>284</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>282</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Lincoln Comment Letter; Ameritas Comment Letter; Brighthouse Comment Letter; ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>283</SU>
                             
                            <E T="03">See</E>
                             Lincoln Comment Letter; Ameritas Comment Letter; Brighthouse Comment Letter; CAI Comment Letter; ACLI Comment Letter; AIG Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>284</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter; Brighthouse Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Commenters also expressed concern about being dependent on the cooperation of third-parties (particularly unaffiliated portfolio companies) to obtain the required portfolio company data in time to include the information in their variable contract initial summary (and other) prospectuses.
                        <SU>285</SU>
                        <FTREF/>
                         One commenter recalled that Form N-4 previously required expense ratios for each portfolio company in the Fee Table, stating “that requirement was later eliminated, and in this respect, the proposed requirement represents a step backwards.” 
                        <SU>286</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>285</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; ACLI Comment Letter (asking us to encourage portfolio companies to share the required information with them in a timely manner); Lincoln Comment Letter; Ameritas Comment Letter; Brighthouse Comment Letter; AIG Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>286</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (citing Disclosure of Costs and Expenses by Insurance Company Separate Accounts Registered as Unit Investments Trusts, Investment Company Act Release No. 25802 (Nov. 13, 2002) [67 FR 69973 (Nov. 19, 2002)] (“2002 Adopting Release”)).
                        </P>
                    </FTNT>
                    <P>
                        Two commenters also opposed including portfolio company performance in the Appendix on the grounds that performance would be quickly become outdated, whereas more current and frequently updated performance data is generally available online.
                        <SU>287</SU>
                        <FTREF/>
                         They expressed concern that having to disclose portfolio company performance, in addition to the expense ratios, would further exacerbate the timing and operational challenges associated with disclosing this information in the Appendix.
                    </P>
                    <FTNT>
                        <P>
                            <SU>287</SU>
                             
                            <E T="03">See</E>
                             Brighthouse Comment Letter; CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We recognize these timing and coordination concerns, and that these challenges increase for variable contracts that offer contracts with a large number of portfolio companies. Regarding portfolio expense information, however, insurers currently must obtain current expense ratios for each portfolio company to ensure the accuracy of the range of lowest and highest portfolio company expenses in the Fee Table—a requirement that we leave undisturbed in this document. In addition, the fact that some insurers provide expense information for each portfolio company shows that it is currently feasible to obtain and disclose this information,
                        <SU>288</SU>
                        <FTREF/>
                         and may soon be easier with the aid of new technology solutions.
                        <SU>289</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>288</SU>
                             
                            <E T="03">See</E>
                             Brighthouse Comment Letter (stating that “[it] has continued to include fund-by-fund expense ratios (but not performance data) in our prospectuses even after such requirement was eliminated from Form N-4 (which requires only the highest and lowest fund expense ratios to be disclosed).”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>289</SU>
                             As discussed below, we recently required mutual funds to use Inline XBRL to tag their risk/return summaries, which may make it easier for insurers to “scrape” the data they need to populate their variable contract Appendixes. 
                            <E T="03">See infra</E>
                             Section II.D. 
                            <E T="03">See also infra</E>
                             note 892.
                        </P>
                    </FTNT>
                    <P>
                        We acknowledge, as one commenter noted, that Form N-4 previously required expense ratios for each portfolio company in the Fee Table. However, as explained in the 2002 Adopting Release, the Commission removed the requirement in an effort to streamline the Fee Table, which had grown lengthy and complex, and instead required Form N-4 registrants to disclose a range showing the lowest and highest expenses for portfolio companies available under the contract.
                        <SU>290</SU>
                        <FTREF/>
                         We are now once again requiring disclosure of portfolio company expense information—but in the Appendix, as opposed to the Fee Table. As discussed below we believe that it is appropriate to require this disclosure, particularly in light of the 
                        <PRTPAGE P="25990"/>
                        portfolio company prospectus delivery option we are adopting.
                    </P>
                    <FTNT>
                        <P>
                            <SU>290</SU>
                             
                            <E T="03">See</E>
                             2002 Adopting Release, 
                            <E T="03">supra</E>
                             note 286.
                        </P>
                    </FTNT>
                    <P>
                        Regarding the concern that obtaining portfolio company performance data may also present operational and timing challenges for insurers, we note that a portfolio company's performance information must be included in its annual report that is typically filed and publicly available by early March,
                        <SU>291</SU>
                        <FTREF/>
                         which should provide sufficient time for a registrant to obtain such information before the variable contracts' registration statement annual update must be filed. As is the case with the portfolio company expense information, the portfolio company performance information is also part of the risk/return summary that will be tagged using the Inline XBRL format.
                    </P>
                    <FTNT>
                        <P>
                            <SU>291</SU>
                             
                            <E T="03">See</E>
                             17 CFR 270.30e-1 (rule 30e-1 under the Investment Company Act). All insurance product portfolio companies have a December 31 fiscal year-end, and must transmit their annual reports to shareholders within 60 days after that date. Form N-CSR, which must be filed no later than 10 days after the transmission of the annual report, must contain a copy of the annual report to shareholders, which is made publicly available on EDGAR.
                        </P>
                    </FTNT>
                    <P>
                        We are also concerned that eliminating portfolio company fee and performance data from the Appendix, as commenters suggest, will not benefit investors. We believe it is important for investors to receive an overview of the portfolio companies and investment options available under the contract in a uniform tabular presentation that promotes comparison, and designed the Appendix with that in mind. A portfolio company's expense ratio and performance provide key information that, if eliminated from the Appendix, would significantly reduce its usefulness to investors. We do not believe an Appendix that provides a legend or cross-reference stating where a portfolio company's prospectus may be found allows investors to as efficiently and effectively compare investment options as one that includes expense and performance information. Moreover, once an investor has purchased a variable contract, information about portfolio companies is the most important information he or she needs when considering how to invest new premiums and whether to reallocate current contract values to different investment options.
                        <SU>292</SU>
                        <FTREF/>
                         In a layered disclosure regime, including portfolio company expense and performance information in the updating summary prospectus is the type of key information that we believe should be provided to investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>292</SU>
                             
                            <E T="03">See</E>
                             Appendix A of the Memorandum from the Division of Investment Management regarding a May 29, 2019 Meeting with Representatives of the Committee of Annuity Insurers (materials provided by Committee of Annuity Insurers participants state that “the ongoing information most relevant to existing contract owners relates to their investment options”).
                        </P>
                    </FTNT>
                    <P>
                        In addition, the Appendix is designed to help facilitate the new optional portfolio company delivery option. Investors in contracts registered on Forms N-4 and N-6 currently receive portfolio company prospectuses at or shortly after the point of sale, as well as each portfolio company's updated prospectus each year. As discussed below, under rule 498A, portfolio company prospectus delivery obligations may be satisfied if the portfolio company summary and statutory prospectuses are posted at the website address specified on the variable contract summary prospectus.
                        <SU>293</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>293</SU>
                             
                            <E T="03">See infra</E>
                             Section II.B.
                        </P>
                    </FTNT>
                    <P>The Appendix is designed to complement the portfolio company prospectuses in a layered disclosure approach to provide the investor with an ability to choose the amount and type of information he or she prefers to review. For investors that do not choose to review portfolio company prospectuses posted at the specified website, the Appendix may contain all the information they receive about their investment options. If we were to eliminate fee and performance information from the Appendix, as some commenters suggest, a new investor (who would have previously received the prospectuses) would have the burden of locating, obtaining, and reviewing the prospectus for each portfolio company available under the contract to discern the very information we are proposing to require insurers to include in the Appendix. We believe that instead of shifting more responsibility to the investor, registrants should supply the portfolio company fee and performance information in the Appendix. Accordingly, we are requiring, largely as proposed, the Appendix to include portfolio company expense and performance information, with certain modifications as discussed below.</P>
                    <P>
                        Several commenters asked that, consistent with parallel requirements for open-end funds set forth in Form N-1A, we permit insurers to disclose, in addition to the gross expense ratio, a portfolio company's net expense ratio, and require those that choose to do so to include a footnote explaining the effect of waivers on portfolio company expenses.
                        <SU>294</SU>
                        <FTREF/>
                         One commenter, in viewing the Appendix in the hypothetical initial summary prospectus, asked whether the expense ratio was gross or net, and if the expense ratio was derived from the portfolio company prospectus, which would reflect the current fee, or its annual report, which would reflect the previous year's expense ratio.
                        <SU>295</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>294</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; ICI Comment Letter; Brighthouse Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>295</SU>
                             
                            <E T="03">See</E>
                             Breacher Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        After considering these comments, in a change from the proposal, we are requiring registrants to disclose under the column heading “Current Expenses,” the expense ratio currently charged by each portfolio company offered under the contract.
                        <SU>296</SU>
                        <FTREF/>
                         We believe that current expenses provide more pertinent information to investors than gross expenses in the case of portfolio companies operating pursuant to an expense reimbursement or fee waiver arrangement.
                        <SU>297</SU>
                        <FTREF/>
                         To alert investors that the costs for some portfolio companies could increase, we are requiring registrants, in a change from the proposal, to identify each portfolio company subject to an expense reimbursement or fee waiver arrangement, and provide a footnote stating that annual expenses reflect temporary fee reductions.
                        <SU>298</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>296</SU>
                             
                            <E T="03">See</E>
                             Instruction 4 to Item 18 of amended Form N-3; Instruction 4 to Item 17 of amended Form N-4; Instruction 4 to Item 18 of Form N-6. The expense ratio we proposed would not have reflected any waivers and reimbursements that reduce the portfolio company's rate or return. “Current Expenses,” as adopted, reflects these waivers and reimbursements.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>297</SU>
                             For portfolio companies that are not operating under expense reimbursement or fee waiver arrangements, current expenses will be the same as gross expenses.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>298</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        We are also modifying the Appendix requirements to account for fund facilitation fees, or “platform charges” as they may more commonly be understood by investors.
                        <SU>299</SU>
                        <FTREF/>
                         We believe that all the charges associated with choosing a particular portfolio company should be presented in the Appendix, not just those charged at the portfolio company level. If a registrant charges a platform charge for any portfolio company, the Appendix must include a separate column that discloses the current platform charge associated with any portfolio company offered under the contract, along with a separate column that sums the portfolio company's current expenses plus any platform 
                        <PRTPAGE P="25991"/>
                        charge.
                        <SU>300</SU>
                        <FTREF/>
                         In addition, the column that discloses each portfolio company that has a platform charge must include a footnote indicating the highest level to which any relevant platform charge may be increased.
                        <SU>301</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>299</SU>
                             
                            <E T="03">See generally supra</E>
                             note 160 and accompanying and following text (discussing fund facilitation fees and comments received regarding those fees).
                        </P>
                        <P>
                            Fund facilitation fees, or platform charges, were not explicitly addressed in the proposal, but one commenter questioned how insurers should treat them. 
                            <E T="03">See</E>
                             VIP Working Group Comment Letter. We believe it is appropriate to incorporate them into the forms and provide instructions on their treatment as part of the Appendix requirements.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>300</SU>
                             
                            <E T="03">See</E>
                             Instructions 5 and 6 to Item 17 of amended Form N-4; Instructions 5 and 6 to Item 18 of amended N-6. Form N-3 registrants do not have platform charges because they have a one tier structure, as discussed above. 
                            <E T="03">See supra</E>
                             note 160.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>301</SU>
                             
                            <E T="03">See</E>
                             General Instruction 5 to Item 17 of amended Form N-4; General Instruction 5 Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        To help investors identify the most relevant disclosures among the various combinations of portfolio company expenses and platform charges, the column displaying the sum of the portfolio company's current expenses plus platform charges must be presented in a manner reasonably calculated to draw investor attention to that column.
                        <SU>302</SU>
                        <FTREF/>
                         In addition, the legend preceding the table in the Appendix must also state that the current expenses and performance columns displayed in the table do not reflect the other fees and expenses that the contract may charge, such as platform charges.
                        <SU>303</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>302</SU>
                             Platform charges were not explicitly addressed in the proposal. 
                            <E T="03">See supra</E>
                             note 299.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>303</SU>
                             
                            <E T="03">See supra</E>
                             notes 300-301 (discussing the requirement to include a column displaying platform charges separately from current expenses, as well as a column displaying platform charges plus current expenses); 
                            <E T="03">infra</E>
                             note 327.
                        </P>
                    </FTNT>
                    <P>
                        One commenter recommended that we remove the proposed Annual Contract Expenses column from the Investment Option Appendix for Form N-3 registrants because it duplicates information in the Fee Table.
                        <SU>304</SU>
                        <FTREF/>
                         We believe some duplication is warranted to ensure that investors have key data, including expense information, about the available investment options located in one place. In addition, because the updating summary prospectus does not include a Fee Table, providing expense information in the Appendix ensures that current investors also receive the information. For these reasons, we are not making the requested change.
                    </P>
                    <FTNT>
                        <P>
                            <SU>304</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        In a change from the proposal, we are revising the disclosure requirements for registrants on Form N-3 to clarify that if the registrant is a multiple class fund, the registrant only needs to disclose expenses and performance for one class.
                        <SU>305</SU>
                        <FTREF/>
                         Investors who wish to obtain more information about portfolio company expenses for other classes can consult the information presented in the Fee Table.
                        <SU>306</SU>
                        <FTREF/>
                         The Appendix is intended to facilitate the ability of investors to compare the portfolio companies available under the contract, and therefore changes that would equally affect the expenses and performance of all portfolio companies, such as changes due to class, would not be helpful in facilitating the ability of investors to select a particular portfolio company. This issue is not relevant for registrants on Forms N-4 and N-6 because those are two-tiered products with separate expenses at the contract level and the portfolio company level (
                        <E T="03">e.g.,</E>
                         changes in expenses due to class will not be reflected in the expenses of portfolio company).
                    </P>
                    <FTNT>
                        <P>
                            <SU>305</SU>
                             
                            <E T="03">See</E>
                             Instructions 4-5 to Item 18 of amended Form N-3. Additionally, Instructions 4-5 cross-reference instructions in Form N-3 regarding calculation of expenses and performance as opposed to instructions in Form N-1A, as proposed. However, because those instructions in Form N-3 mirror the parallel instructions in Form N-1A, this change in cross-references does not affect the substantive disclosure requirements for the Appendix in Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>306</SU>
                             
                            <E T="03">See</E>
                             Instruction 7 to Item 4 of amended Form N-3 (providing that for a contract with more than one class, the registrant must provide a separate response for each class); 
                            <E T="03">see generally supra</E>
                             Section II.A.1.c.ii.(h) (discussing the Fee Table).
                        </P>
                    </FTNT>
                    <P>
                        Some commenters had specific suggestions or concerns regarding the performance information. One commenter recommended permitting variable contracts to include a statement telling investors where and how they could obtain more current portfolio company performance information.
                        <SU>307</SU>
                        <FTREF/>
                         We agree that this information is useful for investors and consistent with our layered disclosure approach, and are modifying the form instructions to permit such information to be included in the legend immediately preceding the table in the Appendix.
                        <SU>308</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>307</SU>
                             
                            <E T="03">See</E>
                             ICI Comment Letter; 
                            <E T="03">see also supra</E>
                             note 287 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>308</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(e) to Item 17 of amended Form N-4; Instruction 1(e) to Item 18 of amended Form N-6; 
                            <E T="03">see also</E>
                             Item 4(b)(2) of Form N-1A (parallel instruction); 
                            <E T="03">see infra</E>
                             note 324.
                        </P>
                    </FTNT>
                    <P>
                        Three commenters stated that portfolio company performance data could be misleading or confusing because it would not reflect recurring separate account or contract charges, and it could conflict with the variable contract performance information contained in other materials that do include these charges.
                        <SU>309</SU>
                        <FTREF/>
                         To address these concerns, we are modifying the item requirements to clarify what is (and is not) included in the performance and expense information in the Appendix.
                        <SU>310</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>309</SU>
                             
                            <E T="03">See</E>
                             Lincoln Comment Letter; Brighthouse Comment Letter; Ameritas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>310</SU>
                             
                            <E T="03">See</E>
                             Item 18 of amended Form N-3, Item 17 of amended Form N-4, and Item 18 of amended Form N-6. 
                            <E T="03">See infra</E>
                             note 327 and following text.
                        </P>
                    </FTNT>
                    <P>
                        Two commenters asked that the performance information be permitted to include returns for the life of the fund if in existence for more than 10 years, to align with mutual fund disclosure requirements.
                        <SU>311</SU>
                        <FTREF/>
                         Because we believe that presenting performance over 1, 5, and 10 year periods makes it easier for investors to compare fund performance, and because as part of the layered disclosure framework returns for the life of the fund are in a portfolio company's summary prospectus, which will be available online or upon request, we are not making this suggested change.
                    </P>
                    <FTNT>
                        <P>
                            <SU>311</SU>
                             
                            <E T="03">See</E>
                             ICI Comment Letter; Capital Group Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Several commenters asked for the Appendix to convey information about the risks associated with investment options.
                        <SU>312</SU>
                        <FTREF/>
                         To make the Appendix more approachable for investors, we designed it to be concise, including only certain information about the available portfolio companies. Because variable contracts commonly offer hundreds of portfolio companies, and each portfolio company may have many risks, requiring risk information could quickly expand the length of the Appendix, which would make it less useful for investors and therefore we are not adopting this suggestion.
                    </P>
                    <FTNT>
                        <P>
                            <SU>312</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of Barry Iris (Jan. 17, 2019); Anonymous Comment Letter II (suggesting that the Appendix include a measure of relative risks for each fund, 
                            <E T="03">i.e.,</E>
                             low, medium, high).
                        </P>
                    </FTNT>
                    <P>
                        The Commission proposed that if the availability of one or more portfolio companies varies by benefit offered under the contract, registrants would be required to include another table that showed which portfolio companies were available under each of those benefits.
                        <SU>313</SU>
                        <FTREF/>
                         One commenter strongly opposed this second tabular presentation, stating it would be difficult, and in some cases infeasible, for insurers to distill the numerous possible variations in investment restrictions, clearly and concisely, into the simple table suggested by the proposed forms and the hypothetical initial summary prospectus.
                        <SU>314</SU>
                        <FTREF/>
                         This commenter also stated that the proposed disclosure about benefit-related investment restrictions in “Other Benefits Available under the Contract” provides investors with a clear understanding that not all portfolio companies or investment options may be available for investment, with additional information about such restrictions in the statutory prospectus. Another commenter stated that the investment option table could be lengthy, especially since the restrictions change over time (even for the same 
                        <PRTPAGE P="25992"/>
                        contract benefit), and recommended removing this disclosure requirement if the insurer imposes guardrails that prevent an investor from violating these investment restrictions.
                        <SU>315</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>313</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(c) to proposed Item 19 of Form N-3; Instruction 1(c) to proposed Item 18 of Form N-4; Instruction 1(c) to proposed Item 18 of Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>314</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>315</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We are requiring the Appendix in the initial summary prospectus (as well as the updating summary and statutory prospectuses) to indicate which portfolio companies are subject to benefit-related investment restrictions.
                        <SU>316</SU>
                        <FTREF/>
                         We recognize that providing a reader-friendly tabular depiction of the investment limitations associated with certain variable contracts may be challenging for certain insurers, particularly those that offer multiple optional benefits, or benefits that have complicated investment restrictions. However, we believe the initial summary prospectus should alert investors which portfolio companies are (or are not) available for investment depending on the optional benefit they choose, as that information could affect their investment decisions. The initial summary prospectus will be limited to a single contract currently available for sale, which by its nature will limit the number of variations, and thus complexity, of the benefit-related investment restrictions insurers will be required to disclose to new purchasers.
                        <SU>317</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>316</SU>
                             Instruction 1(f)(2) to Item 17 of amended Form N-4; Instruction 1(f)(2) to Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>317</SU>
                             We understand that many insurers currently use sales materials to illustrate the benefits-related investment restrictions to potential purchasers in a manner that is similar to our proposed approach.
                        </P>
                    </FTNT>
                    <P>
                        In contrast, we believe it may be more difficult to succinctly condense all the investment-related restrictions associated with multiple optional benefits for multiple contracts over a period of years in an updating summary prospectus, which, as discussed below, may describe multiple contracts.
                        <SU>318</SU>
                        <FTREF/>
                         However, because a current investor's optional benefits may be voided if he or she inadvertently fails to comply with certain investment limitations, we believe the updating summary prospectus should, at a minimum, alert investors that restrictions apply.
                    </P>
                    <FTNT>
                        <P>
                            <SU>318</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.2.b.
                        </P>
                    </FTNT>
                    <P>
                        Accordingly, and in response to comments,
                        <SU>319</SU>
                        <FTREF/>
                         we are revising the instruction to provide greater flexibility to registrants in depicting such information to investors.
                        <SU>320</SU>
                        <FTREF/>
                         In addition, we are requiring additional disclosure in the legend preceding the Appendix alerting investors that, depending on the optional benefits they choose, they may not be able to invest in certain portfolio companies.
                        <SU>321</SU>
                        <FTREF/>
                         This approach is designed to minimize the Appendix's length and complexity, while addressing investor protection concerns. Accordingly, this flexibility may encourage issuers to develop more concise and effective ways to present the information to investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>319</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (seeking clarification that the language in the proposed instruction permitting “any other presentation that might promote clarity and facilitate understanding” would allow multiple tables, narrative explanations, annotations, and other approaches or combinations).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>320</SU>
                             Instruction 1(f)(2) to Item 17 of amended Form N-4; Instruction 1(f)(2) to Item 18 of amended Form N-6. The proposed instructions would have required a separate table indicating these investment-related restrictions without this added flexibility.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>321</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(f)(1) to Item 17 of amended Form N-4; Instruction 1(f)(1) to Item 18 of amended Form N-6. 
                            <E T="03">See infra</E>
                             note 324.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Legends.</E>
                         We are requiring, largely as proposed, certain legends to precede the table in the Appendix. We are modifying certain aspects of the proposed legends to provide a more straightforward presentation, as suggested by several commenters, as well as to highlight investor attention to potential investment limitations, as discussed above.
                        <SU>322</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>322</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter; CAI Comment Letter; ICI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        The first paragraph of the legend must state, as proposed: “The following is a list of [Investment Options/Portfolio Companies] available under the Contract.” 
                        <SU>323</SU>
                        <FTREF/>
                         In a change from the proposal, for registrants on Forms N-4 and N-6 for which the availability of portfolio company options varies by benefit offered under the contract, the legend will also state, “[d]epending on the optional benefits you choose under the Contract, you may not be able to invest in certain Portfolio Companies.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>323</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ix); Item 18 of amended Form N-3; Item 17 of Form N-4; Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, the legend will provide an internet address to a landing page, toll-free telephone number, and email address that investors could use to obtain portfolio company statutory and summary prospectuses.
                        <SU>324</SU>
                        <FTREF/>
                         For registrants on Form N-3, the legend will direct investors to the cover page of the initial summary prospectus to request the statutory prospectus for the registrant containing more information about the investment options.
                        <SU>325</SU>
                        <FTREF/>
                         The legend also could indicate, if applicable, that prospectuses and other information are available from a financial intermediary (such as an insurance agent or broker-dealer) distributing the contract.
                        <SU>326</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>324</SU>
                             For registrants on Forms N-4 and N-6, the legend will read as follows:
                        </P>
                        <P>“The following is a list of Portfolio Companies available under the Contract. More information about the Portfolio Companies is available in the prospectuses for the Portfolio Companies, which may be amended from time to time and can be found online at [__]. You can request this information at no cost by calling [__] or by sending an email request to [__].”</P>
                        <P>
                            Registrants that offer portfolio companies that are subject to benefits-related investment restrictions must add the statement, “Depending on the optional benefits you choose, you may not be able to invest in certain Portfolio Companies.” 
                            <E T="03">See</E>
                             Instruction 1(f)(1) to Item 17 of amended Form N-4 and Instruction 1(f)(1) to Item 18 of amended Form N-6.
                        </P>
                        <P>
                            Registrants that are not relying upon rule 498A(j) with respect to the portfolio companies that are offered under the contract may, but are not required to, provide the next-to-last sentence of the first paragraph of the introductory legend to the table regarding online availability of the prospectuses. 
                            <E T="03">See</E>
                             Instruction 1(d) to Item 17 of amended Form N-4 and Instruction 1(d) to Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>325</SU>
                             For registrants on Form N-3, the legend will read as follows:
                        </P>
                        <P>“The following is a list of Investment Options available under the Contract. More information about the Investment Options is available in the Statutory Prospectus for the Contract, which can be requested at no cost by following the instructions on [the front cover page or beginning of the Summary Prospectus].”</P>
                        <P>
                            <E T="03">See</E>
                             rule 498A(b)(5)(ix); Item 18 of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>326</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ix); Instruction 1(c) to Item 17 of amended Form N-4; Instruction 1(c) to Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>We had proposed the second paragraph of the legend to state:</P>
                    <EXTRACT>
                        <P>The performance information below reflects fees and expenses of the [Portfolio Companies], but does not reflect the other fees and expenses that your contract may charge. Performance would be lower if these charges were included. Each [Portfolio Company's] past performance is not necessarily an indication of future performance.</P>
                    </EXTRACT>
                    <P>We are requiring, with some modifications from the proposal, the second paragraph of the legend for variable contracts registered on Forms N-4 and N-6 to state as follows:</P>
                    <EXTRACT>
                        <P>
                            The expense and performance information below reflects fees and expenses of the Portfolio Companies, but does not reflect the other fees and expenses that your Contract may charge [, such as platform charges].
                            <SU>327</SU>
                            <FTREF/>
                             Expenses would be higher and performance would be lower if these charges were included. Each Portfolio Company's past performance is not necessarily an indication of future performance.
                            <SU>328</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>327</SU>
                                 
                                <E T="03">See</E>
                                 General Instruction 5 to Item 17 of amended Form N-4; General Instruction 5 to Item 18 of Form N-6. This additional phrase is only required for registrants that charge platform fees.
                            </P>
                        </FTNT>
                        <FTNT>
                            <P>
                                <SU>328</SU>
                                 
                                <E T="03">See</E>
                                 Item 17 of amended Form N-4; Item 18 of amended Form N-6.
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        These revisions are intended to streamline the legends in response to commenters' concerns, to clarify which charges are, and are not, included in the 
                        <PRTPAGE P="25993"/>
                        performance calculation, and to tell investors where they can find current performance information.
                    </P>
                    <P>
                        In contrast, because insurance charges are already reflected in the expenses and performance of the investment options for contracts registered on Form N-3, the second paragraph of the legend for variable annuities registered on Form N-3 will state, largely as proposed: 
                        <SU>329</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>329</SU>
                             The proposed legend did not include “current expenses.”
                        </P>
                    </FTNT>
                    <EXTRACT>
                        <P>
                            The current expenses and performance information below reflects contract fees and expenses that are paid by each investor. Each Investment Option's past performance is not necessarily an indication of future performance.
                            <SU>330</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>330</SU>
                                 
                                <E T="03">See</E>
                                 Item 18 of amended Form N-3.
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        <E T="03">Form N-3.</E>
                         For variable contracts registered on Form N-3, registrants may omit the required Appendix and instead provide more detailed disclosures for the investment options offered under the contract required by Item 19 of amended Form N-3.
                        <SU>331</SU>
                        <FTREF/>
                         Item 19 requires narrative disclosure for each investment option regarding its investment objectives and principal investment strategies, and principal risks of investing in the investment option, and a bar chart and table showing the performance of the investment option modeled after the risk/return bar chart and table that Form N-1A currently requires.
                        <SU>332</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>331</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ix); Item 19 of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>332</SU>
                             
                            <E T="03">See</E>
                             text following note 797 (discussing Item 19 of amended Form N-3); 
                            <E T="03">see also</E>
                             Item 4(b)(2) of Form N-1A.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Updating Summary Prospectus</HD>
                    <HD SOURCE="HD3">a. Overview</HD>
                    <P>
                        Today, variable contract investors are typically sent a copy of the updated current contract statutory prospectus each year.
                        <SU>333</SU>
                        <FTREF/>
                         New rule 498A permits a person to satisfy contract prospectus delivery obligations with respect to existing investors by sending or giving an updating summary prospectus in lieu of the statutory prospectus.
                        <SU>334</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>333</SU>
                             Investors generally must be provided with a prospectus when they make additional purchase payments or reallocate variable contract value. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at nn.27-29 and accompanying text. As proposed, an updating summary prospectus that complies with rule 498A will be deemed to be a prospectus that is permitted under Section 10(b) of the Securities Act and Section 24(g) of the Investment Company Act for the purposes of Section 5(b)(1) of the Securities Act.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>334</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c).
                        </P>
                    </FTNT>
                    <P>
                        The comments we received relating to the updating summary prospectus were generally supportive.
                        <SU>335</SU>
                        <FTREF/>
                         Although commenters did not raise broad objections to this aspect of our proposal, they raised concerns with and/or requested clarification on specific issues, as discussed in more detail below. We are adopting the proposed updating summary prospectus framework substantially as proposed, with some modifications in response to issues raised by commenters.
                    </P>
                    <FTNT>
                        <P>
                            <SU>335</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter; Lincoln Comment Letter; ACLI Comment Letter. Many commenters elected to provide detailed comments on the initial summary prospectus, stating that their comments also applied to the updating summary prospectus. 
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter; AARP Comment Letter.
                        </P>
                    </FTNT>
                    <P>As discussed in the Proposing Release, we are not requiring that registrants send a current initial summary prospectus to investors each year, due in part to the cost to maintain and update separate initial summary prospectuses for currently offered variable contracts and those no longer offered to new investors. Additionally, we believe that existing investors would benefit more from a brief summary of the changes to the contract reflected in the statutory prospectus than from the disclosures in the initial summary prospectus, which is designed for someone making an initial investment decision.</P>
                    <P>We have therefore designed the updating summary prospectus to provide a brief description of any important changes with respect to the contract that occurred within the prior year, which will allow investors to better focus their attention on new or updated information relating to the contract. Additionally, as proposed, the updating summary prospectus will include certain of the information required in the initial summary prospectus that we consider most relevant to investors when considering additional investment decisions.</P>
                    <P>
                        Finally, as proposed, a registrant may only use an updating summary prospectus if it uses an initial summary prospectus for each currently offered contract described under the contract statutory prospectus to which the updating summary prospectus relates.
                        <SU>336</SU>
                        <FTREF/>
                         We believe that making the use of the updating summary prospectus contingent on use of the initial summary prospectus for each currently offered contract will encourage registrants to utilize the summary prospectus framework and provide a more consistent disclosure experience to investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>336</SU>
                             Rule 498A(c)(1).
                        </P>
                    </FTNT>
                    <P>
                        Several commenters sought clarification regarding whether insurers could use an updating summary prospectus even if the insurer did not provide an initial summary prospectus to existing investors that previously received a full statutory prospectus.
                        <SU>337</SU>
                        <FTREF/>
                         Under new rule 498A, an insurer could use an updating summary prospectus even if the insurer did not provide an initial summary prospectus to an existing investor that previously received a full statutory prospectus. The rule only requires an insurer to use an initial summary prospectus for each currently offered contract described in the statutory prospectus if the insurer wishes to use an updating summary prospectus.
                        <SU>338</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>337</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter; CAI Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>338</SU>
                             Thus, if each contract in a registration statement is no longer offered to new investors (and therefore the insurer would no longer have a need to use an initial summary prospectus), an insurer may continue to use an updating summary prospectus.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Contracts That May Be Included in the Updating Summary Prospectus</HD>
                    <P>
                        As proposed, the new rule permits the updating summary prospectus to describe one or more contracts covered in the statutory prospectus to which the updating summary prospectus relates.
                        <SU>339</SU>
                        <FTREF/>
                         This scope is different than that of the initial summary prospectus, which may only cover a single contract that the registrant currently offers for sale.
                        <SU>340</SU>
                        <FTREF/>
                         Similar to the initial summary prospectus, however, the new rule also permits an updating summary prospectus to describe more than one class of a contract.
                        <SU>341</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>339</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(2). If there are multiple statutory prospectuses in a registration statement, a separate updating summary prospectus would be required for each such statutory prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>340</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.1.b.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>341</SU>
                             Rule 498A(c)(2); 
                            <E T="03">see also supra</E>
                             Section II.A.1.b (an initial summary prospectus also can describe more than one class of a currently offered contract).
                        </P>
                    </FTNT>
                    <P>
                        Given the limited subset of information provided in the updating summary prospectus, we believe permitting registrants to combine multiple contracts will not cause investor confusion in the same way that combining disclosure about multiple contracts in the initial summary prospectus might.
                        <SU>342</SU>
                        <FTREF/>
                         Furthermore, we understand that there are generally not a significant number of changes that occur to an individual contract year-over-year, and many of those changes (such as changes to the available portfolio companies or the addition of new optional benefits) typically apply across multiple contracts described in the same prospectus. We therefore believe the section describing contract 
                        <PRTPAGE P="25994"/>
                        changes, even if changes to multiple contracts are included, will not be overly lengthy, and will not prevent investors from reading or understanding the applicable disclosures.
                        <SU>343</SU>
                        <FTREF/>
                         Finally, combining multiple contracts could make the updating summary prospectus significantly more efficient for registrants to produce and distribute.
                    </P>
                    <FTNT>
                        <P>
                            <SU>342</SU>
                             
                            <E T="03">See infra</E>
                             text following note 598 (discussing new General Instruction C.3.(e)(i) to Forms N-3, N-4, and N-6 regarding the permitted inclusion of multiple contracts in a single prospectus).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>343</SU>
                             A registrant must indicate in this section, to the extent appropriate, whether certain described contract changes are only applicable to certain contracts in the statutory prospectus. 
                            <E T="03">See</E>
                             rule 498A(c)(6)(i)(B).
                        </P>
                    </FTNT>
                    <P>
                        Commenters widely agreed with the proposed approach, and supported the optionality to allow the updating summary prospectus to include multiple contracts under the statutory prospectus to which the summary prospectus relates.
                        <SU>344</SU>
                        <FTREF/>
                         Accordingly, we are adopting this approach as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>344</SU>
                             
                            <E T="03">See, e.g.,</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Preparation of the Updating Summary Prospectus</HD>
                    <P>
                        The following chart outlines the information required in an updating summary prospectus under new rule 498A. As proposed, along with specifying required cover page disclosures, the rule references particular disclosure items from Forms N-3, N-4, and N-6. The required information must appear in the same order, and under the relevant corresponding headings, as specified by the rule.
                        <SU>345</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>345</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6).
                        </P>
                    </FTNT>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s50,12,12,12">
                        <TTITLE>Table 3—Outline of the Updating Summary Prospectus</TTITLE>
                        <BOXHD>
                            <CHED H="1">Heading in updating summary prospectus</CHED>
                            <CHED H="1">
                                Item of
                                <LI>amended</LI>
                                <LI>Form N-3</LI>
                            </CHED>
                            <CHED H="1">
                                Item of
                                <LI>amended</LI>
                                <LI>Form N-4</LI>
                            </CHED>
                            <CHED H="1">
                                Item of
                                <LI>amended</LI>
                                <LI>Form N-6</LI>
                            </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="22">Cover Page:</ENT>
                            <ENT I="03">Identifying Information</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT I="03">Legends</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT I="03">EDGAR Contract Identifier</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT I="03">Table of Contents (optional)</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="22">Content:</ENT>
                            <ENT I="03">Updated Information About Your [Contract]</ENT>
                            <ENT/>
                            <ENT/>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT I="03">Important Information You Should Consider About the [Contract]</ENT>
                            <ENT>2</ENT>
                            <ENT>2</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT I="03">
                                Appendix: [Investment Options/Portfolio Companies] Available Under the [Contract]
                                <SU>346</SU>
                                 18 or 19
                            </ENT>
                            <ENT>17</ENT>
                            <ENT>18</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">
                        i. Cover Page and Table of Contents
                        <FTREF/>
                    </HD>
                    <FTNT>
                        <P>
                            <SU>346</SU>
                             Registrants on Form N-3 may omit the Appendix specified by Item 18 of amended Form N-3, and instead provide the more detailed disclosures about the investment options offered under the contract required by Item 19 of amended Form N-3. 
                            <E T="03">See infra</E>
                             note 788 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Identifying Information.</E>
                         As proposed, the following information will be required to appear on the front cover page or at the beginning of the updating summary prospectus:
                    </P>
                    <P>• The depositor's name;</P>
                    <P>• The name of the contract(s), and the class or classes, if any, to which the updating summary prospectus relates;</P>
                    <P>• A statement identifying the document as an “Updating Summary Prospectus”; and</P>
                    <P>
                        • The approximate date of the first use of the updating summary prospectus.
                        <SU>347</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>347</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(3)(i) through (iv). We are not requiring the cover page of the updating summary prospectus to include the registrant's name. 
                            <E T="03">See supra</E>
                             Section II.A.1.c.i.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Legend.</E>
                         The cover page or beginning of the updating summary prospectus is required to include the following legend:
                    </P>
                    <EXTRACT>
                        <P>
                            The prospectus for the [Contract] contains more information about the [Contract], including its features, benefits, and risks. You can find the current prospectus and other information about the [Contract] online at [__]. You can also obtain this information at no cost by calling [__] or by sending an email request to [__].
                            <SU>348</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>348</SU>
                                 
                                <E T="03">See supra</E>
                                 note 86 (discussing requirements of the registrant's internet address and contact information).
                            </P>
                        </FTNT>
                        <P>
                            Additional general information about certain investment products, including [variable annuities/variable life insurance contracts], has been prepared by the Securities and Exchange Commission's staff and is available at 
                            <E T="03">Investor.gov</E>
                            .
                            <SU>349</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>349</SU>
                                 
                                <E T="03">See</E>
                                 rule 498A(c)(3)(v).
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>
                        Like the cover page or beginning of the initial summary prospectus, the cover page or beginning of the updating summary prospectus will be required to include identifying information about the variable contract, as well as a legend including certain general information that will be applicable to all variable contracts. The portions of the legend that describe how to obtain further information about the contract, as well as the 
                        <E T="03">Investor.gov</E>
                         website, are identical to the parallel portions of the legend that will appear on the cover page or beginning of the initial summary prospectus.
                        <SU>350</SU>
                        <FTREF/>
                         As with the initial summary prospectus, a registrant could modify this required legend so long as the modified legend includes comparable information.
                        <SU>351</SU>
                        <FTREF/>
                         Likewise, the updating summary prospectus will also include a legend informing investors about the optional internet availability of shareholder reports, if applicable, pursuant to the requirements of rule 30e-3.
                        <SU>352</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>350</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(2)(v); 
                            <E T="03">see also supra</E>
                             note 86. The legend in the updating summary prospectus will note that “an updated prospectus” is available online, whereas the initial summary prospectus will note that it summarizes key features of the contract.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>351</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(3)(v); 
                            <E T="03">see also</E>
                             rule 498A(b)(2)(v)(A).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>352</SU>
                             
                            <E T="03">See infra</E>
                             note 623.
                        </P>
                    </FTNT>
                    <P>
                        Similar to the initial summary prospectus, if a registrant incorporates any information by reference into the updating summary prospectus, the rule requires the registrant to include in the legend certain information about the document(s) from which the information was incorporated.
                        <SU>353</SU>
                        <FTREF/>
                         The free look period legend that will appear on the cover page or beginning of the initial summary prospectus is not appropriate in the context of the updating summary prospectus, because the free look period is not applicable to additional investments after the initial purchase.
                    </P>
                    <FTNT>
                        <P>
                            <SU>353</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.7.
                        </P>
                    </FTNT>
                    <PRTPAGE P="25995"/>
                    <P>
                        In response to requests from commenters urging that we streamline the legends where possible, the legend on the cover page or beginning of the updating summary prospectus also reflects certain streamlining changes that mirror revisions made to the parallel legend in the initial summary prospectus.
                        <SU>354</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>354</SU>
                             
                            <E T="03">See</E>
                             text following note 95.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">EDGAR Contract Identifier.</E>
                         As proposed, we are also requiring that the EDGAR contract identifier for each contract covered by the updating summary prospectus be included on the bottom of the back cover page or last page of the updating summary prospectus in a type size smaller than that generally used in the prospectus (
                        <E T="03">e.g.,</E>
                         8-point modern type).
                        <SU>355</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>355</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(4)(ii). As in the case of the initial summary prospectus, this requirement is designed to allow Commission staff and others to more easily link the updating summary prospectus with other filings associated with the contract.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Table of Contents.</E>
                         As proposed, the new rule permits an updating summary prospectus, like the initial summary prospectus, to include a table of contents.
                        <SU>356</SU>
                        <FTREF/>
                         A table of contents must show the page number of the various sections or subdivisions of the prospectus and must immediately follow the cover page in any prospectus delivered electronically.
                        <SU>357</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>356</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(5).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>357</SU>
                             Rule 481(c).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. Content of the Updating Summary Prospectus</HD>
                    <P>
                        New rule 498A specifies the content and order required in an updating summary prospectus.
                        <SU>358</SU>
                        <FTREF/>
                         Similar to the initial summary prospectus and the summary prospectus for mutual funds, adhering to these content requirements is one condition that an updating summary prospectus must satisfy in order to be deemed to be a prospectus that is permitted under Section 10(b) of the Securities Act and Section 24(g) of the Investment Company Act for the purposes of Section 5(b)(1) of the Securities Act.
                        <SU>359</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>358</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>359</SU>
                             
                            <E T="03">See supra</E>
                             note 106.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">(a) Description of Changes to the Contract</HD>
                    <P>
                        The updating summary prospectus is required to include a concise description of certain changes to the contract made after the date of the most recent updating summary prospectus or statutory prospectus that was sent or given to investors.
                        <SU>360</SU>
                        <FTREF/>
                         As proposed, these changes include those that relate to (1) the availability of portfolio companies (or investment options under a variable annuity registered on Form N-3) under the contract,
                        <SU>361</SU>
                        <FTREF/>
                         (2) the Fee Table,
                        <SU>362</SU>
                        <FTREF/>
                         (3) the standard death benefit (for variable life insurance contracts),
                        <SU>363</SU>
                        <FTREF/>
                         and (4) the benefits available under the contract.
                        <SU>364</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>360</SU>
                             
                            <E T="03">See</E>
                             17 CFR 230.423 (rule 423 under the Securities Act) (regarding the date of the prospectus).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>361</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i). A change that has affected availability of portfolio companies (or investment options) includes changes in the portfolio companies (or investment options) offered under the contract or available in connection with any optional benefit. 
                            <E T="03">See also</E>
                             Item 18 of amended Form N-3; Item 17 of amended Form N-4; Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>362</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 4 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>363</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 10 of amended Form N-6. 
                            <E T="03">See supra</E>
                             Section II.A.1.c.ii.(c).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>364</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 11 of amended Forms N-3 and N-6; Item 10 of amended Form N-4.
                        </P>
                    </FTNT>
                    <P>
                        In a change from the proposal, we are also requiring the updating summary prospectus to include a concise description of changes to other items that are included in an initial summary prospectus. Specifically, we are requiring a discussion of changes that relate to the Key Information Table,
                        <SU>365</SU>
                        <FTREF/>
                         the overview of the contract,
                        <SU>366</SU>
                        <FTREF/>
                         purchases and contract value (premiums for variable life insurance contracts),
                        <SU>367</SU>
                        <FTREF/>
                         surrenders and withdrawals,
                        <SU>368</SU>
                        <FTREF/>
                         and lapse (for variable life insurance contracts).
                        <SU>369</SU>
                        <FTREF/>
                         Although we would not expect these additional items to change very frequently (for example, many relate to terms that are set by the contract or reflect Commission or state insurance regulatory requirements), given their importance, we believe that investors should be notified of any changes with respect to these items.
                    </P>
                    <FTNT>
                        <P>
                            <SU>365</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 2 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>366</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 3 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>367</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 12 of amended Form N-3; Item 11 of amended Form N-4; Item 9 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>368</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 13 of amended Form N-3; Item 12 of amended Forms N-4 and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>369</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i); 
                            <E T="03">see also</E>
                             Item 14 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        The updating summary prospectus also could include a concise description of any other changes to the contract that the registrant wishes to disclose, provided they occurred within the same time period.
                        <SU>370</SU>
                        <FTREF/>
                         We believe that permitting—but not requiring—a concise description of any additional changes will provide flexibility to registrants to highlight for investors any additional changes.
                    </P>
                    <FTNT>
                        <P>
                            <SU>370</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(ii). Any additional information included should not, by its nature, quantity, or manner of presentation, obscure or impede understanding of the information that the rule requires.
                        </P>
                    </FTNT>
                    <P>
                        These contract changes will be described under the heading “Updated Information About Your [Contract].” 
                        <SU>371</SU>
                        <FTREF/>
                         This legend will be required to follow the heading:
                    </P>
                    <FTNT>
                        <P>
                            <SU>371</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i).
                        </P>
                    </FTNT>
                    <EXTRACT>
                        <P>
                            The information in this Updating Summary Prospectus is a summary of certain [Contract] features that have changed since the [Updating Summary Prospectus] dated [date]. This may not reflect all of the changes that have occurred since you entered into your [Contract].
                            <SU>372</SU>
                            <FTREF/>
                        </P>
                        <FTNT>
                            <P>
                                <SU>372</SU>
                                 
                                <E T="03">See</E>
                                 rule 498A(c)(6)(i)(A).
                            </P>
                        </FTNT>
                    </EXTRACT>
                    <P>We designed this disclosure requirement in light of the fact that disclosures in a contract statutory prospectus do not change frequently, and we believe providing investors with notice and a brief description of any changes that do occur may be more informative than repeating all the disclosures each year. We believe that notice of these changes is particularly helpful, given that currently investors must determine which, if any, disclosures relevant to their particular contract have changed each year they receive the contract statutory prospectus. After receiving notice and a brief description of certain changes, an investor who then wishes to obtain more information on specific changes can consult the contract statutory prospectus to review related disclosures in more detail. We believe that highlighting certain key changes with respect to the contract in the updating summary prospectus will provide important information to investors that they can use in considering whether to continue making additional purchase payments or reallocate contract value.</P>
                    <P>
                        The requirement to disclose contract-related changes to investors is particularly relevant for variable contracts, since the length of statutory prospectus disclosure may hinder investors in identifying important year-over-year changes to contract features. One commenter noted that “because investors currently obtain disclosure about contract changes in a piecemeal fashion through different sequential updating disclosure, it may be helpful and constructive for investors to have a list in one place about contract changes in the updating prospectus.” 
                        <SU>373</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>373</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        In providing a concise description of a contract-related change in the updating summary prospectus, registrants must provide enough detail to allow investors to understand the 
                        <PRTPAGE P="25996"/>
                        change and how it will affect them.
                        <SU>374</SU>
                        <FTREF/>
                         For example, this could include stating that an optional benefit fee has changed from 1.5% to 1.7%, rather than stating that the fee has changed or increased, or specifically identifying each optional benefit that has changed (with a brief explanation of how), rather than generically stating that certain optional benefits are new or no longer available. As another example, if a portfolio company is no longer available under the contract to new investors although current investors may continue to make investments, this change should be disclosed in the discussion of changes to the contract, even though in the Appendix the portfolio company will have a footnote (or similar indication) alerting investors that investments in the portfolio company are restricted to current investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>374</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(i)(B).
                        </P>
                    </FTNT>
                    <P>
                        In the proposal, we had stated that “if a portfolio company's expense ratio has changed, a registrant generally should describe this in the body of the updating summary prospectus even though expense ratio information would also appear in the required appendix to the updating summary prospectus, in order to highlight this change to investors.” 
                        <SU>375</SU>
                        <FTREF/>
                         Commenters asked whether the updating summary prospectus should, in the discussion of changes to the contract, disclose changes to the expense ratio of the portfolio companies.
                        <SU>376</SU>
                        <FTREF/>
                         Because the Appendix will present updated portfolio company information as to portfolio company expenses (as well as performance), we do not expect changes to portfolio company expenses to be disclosed in the discussion of changes to the contract section, even in cases where the “Annual Portfolio Company Expenses” table in the Fee Table is changed to reflect a new range.
                    </P>
                    <FTNT>
                        <P>
                            <SU>375</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.236 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>376</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (seeking clarification because the proposal indicates that a change in expense ratio should be disclosed, “which would lead to voluminous, technical, and lengthy disclosure that would obscure information and reduce the effectiveness of the updating summary prospectus.”); ACLI Comment Letter (stating that providing details about changes to underlying fund expenses would be burdensome, and recommending that the disclosure state that underlying fund expenses can be expected to change and investors should consult the Appendix discussing them in greater detail). We agree that the proposing release contained an example that may have led to this misimpression, and have replaced this with another example.
                        </P>
                    </FTNT>
                    <P>
                        One commenter stated that the updating summary prospectus should be able to include changes that have occurred outside of the limited time period specified in proposed rule 498A.
                        <SU>377</SU>
                        <FTREF/>
                         Because we are seeking to limit the amount of information in the updating summary prospectus to key information in order make it more approachable for investors, we decline to expand its scope to include information beyond the specified period. This commenter also stated that since the delivery of the last updating summary or statutory prospectus, insurers may have delivered supplements to those documents. As a result, highlighting and repeating those disclosures in the updating summary prospectus could be confusing. This commenter recommended we permit insurers to omit information that has been disclosed in a prior updating summary prospectus or statutory prospectus supplements delivered to investors (and if insurers include it, they should be able to clarify that the information was previously communicated).
                        <SU>378</SU>
                        <FTREF/>
                         We do not share the commenter's concern that investors will become confused and in fact believe that permitting such omission could result in piecemeal disclosures that are less useful to investors, and are therefore not making the suggested change.
                        <SU>379</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>377</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>378</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>379</SU>
                             
                            <E T="03">See supra</E>
                             note 373.
                        </P>
                    </FTNT>
                    <P>
                        Another commenter suggested that we not require the delivery of an updating summary prospectus in the case of additional investments in a variable contract, as they will receive an updating summary prospectus annually, as well as prospectus supplements throughout the year, as necessary, for certain changes to the contract and/or portfolio company information.
                        <SU>380</SU>
                        <FTREF/>
                         We agree with the commenter's interpretation and note that the Commission did not propose, and we are not adopting, a requirement to deliver an updating summary prospectus each time an investor makes an additional investment.
                        <SU>381</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>380</SU>
                             
                            <E T="03">See</E>
                             Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>381</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.3 for further discussion on the delivery of amendments to contract prospectuses.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Key Information</HD>
                    <P>
                        As proposed, the updating summary prospectus must include the same Key Information Table that appears in the initial summary prospectus.
                        <SU>382</SU>
                        <FTREF/>
                         As discussed above, this table streamlines certain important concepts about the variable contract in a presentation that is designed to be easy to read and navigate.
                        <SU>383</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>382</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(iii). This disclosure will be the same information required by Item 2 of Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>383</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.1.c.ii.
                            <E T="03">(a).</E>
                        </P>
                    </FTNT>
                    <P>Because investors may make additional investments in the variable contract, we are requiring this disclosure in the updating summary prospectus to remind them of the contract's fees and expenses, risks, restrictions, tax implications, and investment professional compensation. Furthermore, we believe that an investor who continues to make investments in the variable contract (or to reallocate contract value)—not just an initial investor in the contract—should receive the benefit of this disclosure in a presentation that is intended to improve readability and readership.</P>
                    <P>Besides the brief description of contract-related changes and portfolio company/investment option Appendix discussed below, an updating summary prospectus will include only this Key Information Table as summary disclosure about the contract's key information, and will not also include the additional disclosure that the initial summary prospectus will include (for example, additional information about standard and optional contract benefits, or the contract Fee Table). We believe this is appropriate in the context of an updating summary prospectus for several reasons.</P>
                    <P>First, unless the investor invested prior to the registrant relying on rule 498A, the investor already will have received the initial summary prospectus (and have had access to the statutory prospectus), which includes this extra detail. Additionally, the updating summary prospectus draws on layered disclosure concepts, where the investor can access the more detailed statutory prospectus electronically (or in paper format on request) to complement the disclosure included in the updating summary prospectus.</P>
                    <P>
                        An updating summary prospectus that describes multiple contracts could contain a separate Key Information Table for each contract, or use a different presentation approach that consistently discloses the required information for each contract in the required order.
                        <SU>384</SU>
                        <FTREF/>
                         For example, if the only Key Information Table disclosure that will vary by contract is the fee information, a prospectus that describes multiple contracts could include a single Key Information Table that discloses separate fee information in the 
                        <PRTPAGE P="25997"/>
                        “Fees and Expenses” line-items for each contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>384</SU>
                             See ACLI Comment Letter (supporting this flexibility as “allowing an approach that makes the most sense for each company.”).
                        </P>
                    </FTNT>
                    <P>
                        One commenter opposed including the line-item for investment professional compensation in the Key Information Table, stating that once a contract has been purchased, information about investment professional compensation is not sufficiently relevant to be required in the table.
                        <SU>385</SU>
                        <FTREF/>
                         Because investment professionals may present investors with other opportunities to invest in variable contracts, or encourage them to terminate an existing contract and then purchase or exchange into a new one, we believe it is important to remind investors about potential conflicts of interest, and are retaining the requirement, as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>385</SU>
                             
                            <E T="03">Id.</E>
                             (stating that Regulation Best Interest and Form CRS may resolve questions about appropriate disclosure concerning investment professional compensation).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Appendix: Portfolio Companies/Investment Options Available Under the Contract</HD>
                    <P>
                        Finally, as proposed, the updating summary prospectus must include the Appendix, which provides summary information about the portfolio companies offered under the contract.
                        <SU>386</SU>
                        <FTREF/>
                         This Appendix requirement is identical to the requirement for the Appendix in the initial summary prospectus.
                        <SU>387</SU>
                        <FTREF/>
                         Like the requirement for the initial summary prospectus Appendix, Form N-3 registrants could omit the Appendix and instead provide the more detailed disclosures about the investment options offered under the contract that will be required by Item 19 of Form N-3.
                        <SU>388</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>386</SU>
                             Rule 498A(c)(6)(iv). This information on portfolio companies or investment options is the same information required by Item 17 of amended Form N-4 and Item 18 of amended Forms N-3 and N-6.
                        </P>
                        <P>
                             We received and considered several comments on the Appendix, which are discussed in Section II.A.1.ii.
                            <E T="03">(i). See, e.g., supra</E>
                             note 266.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>387</SU>
                             Paralleling a similar requirement for the initial summary prospectus, if the Appendix includes the information required by Item 18 of amended Form N-3, the Appendix must also include the following introductory legend: “The following is a list of [Investment Options] currently available under the [Contract], which is subject to change as discussed in the [Statutory Prospectus for the Contract]. More information about the [Investment Options] is available in [the Contract Statutory Prospectus], which can be requested at no cost by following the instructions on [the front cover page or beginning of the Summary Prospectus].” 
                            <E T="03">See</E>
                             Item 18 of amended Form N-3; rule 498A(c)(6)(iv).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>388</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(6)(iv); 
                            <E T="03">see also</E>
                             text following note 796 (discussing Item 19 of amended Form N-3).
                        </P>
                    </FTNT>
                    <P>
                        Because the selection of portfolio companies or investment options will directly affect the performance, and often the available optional benefits, of the contract, we believe that it is necessary to provide basic information about the portfolio companies to ongoing investors in variable contracts. This disclosure is intended to remind investors of one of the most important decisions they face during the life cycle of a contract—that is, whether and where to allocate additional purchase payments and reallocate contract value among the portfolio companies or investment options available to them.
                        <SU>389</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>389</SU>
                             As discussed above, we are requiring the Appendix in the initial and updating summary prospectuses to indicate which portfolio companies are subject to benefit-related investment restrictions. 
                            <E T="03">See supra</E>
                             note 316 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. Interim Amendments to Contract Statutory Prospectuses</HD>
                    <P>
                        One commenter asked for clarity regarding when contract prospectuses and summary prospectuses must be updated, and when information related to those updates must be delivered to investors.
                        <SU>390</SU>
                        <FTREF/>
                         We believe that the use of initial and updating summary prospectuses to satisfy prospectus delivery requirements generally should mirror today's summary prospectus delivery practices for mutual funds. To the extent there are amendments to the statutory prospectus that occur between annual updates (
                        <E T="03">i.e.,</E>
                         on an off-cycle basis) and an investor who received a summary prospectus makes a subsequent contribution to, or reallocates contract value within, their contract:
                    </P>
                    <FTNT>
                        <P>
                            <SU>390</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        • If the amendment affects information contained in the current summary prospectus (including any of the four categories of changes that will be disclosed as part of the “Updated Information About Your [Contract]” section of an updating summary prospectus), we believe that the summary prospectus would be amended (
                        <E T="03">e.g.,</E>
                         by sticker or supplement) and the amendment provided to investors as necessary to meet any requirements to deliver a current statutory prospectus for the contract; 
                        <SU>391</SU>
                        <FTREF/>
                         and
                    </P>
                    <FTNT>
                        <P>
                            <SU>391</SU>
                             Section 5(b)(2) of the Securities Act.
                        </P>
                    </FTNT>
                    <P>• If the amendment does not affect information contained in the current summary prospectus, we do not believe that the summary prospectus would be amended and therefore, no amendment would need to be provided to investors.</P>
                    <HD SOURCE="HD3">4. Legal Effect of Use of Summary Prospectus for Variable Contracts</HD>
                    <P>
                        Section 5(b)(2) of the Securities Act makes it unlawful to carry or cause to be carried a security for purposes of sale or for delivery after sale “unless accompanied or preceded” by a statutory prospectus.
                        <SU>392</SU>
                        <FTREF/>
                         As proposed, new rule 498A provides that, for variable contract securities in an offering registered on Forms N-3, N-4, or N-6, the use of a summary prospectus could satisfy this Section 5(b)(2) obligation under certain conditions, described below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>392</SU>
                             15 U.S.C. 77e(b)(2) (stating that it shall be unlawful for any person to carry or cause to be carried through the mails or in interstate commerce any such security for the purpose of sale or for delivery after sale, unless accompanied or preceded by a prospectus that meets the requirements of Securities Act Section 10(a)); 
                            <E T="03">see also</E>
                             Proposing Release 
                            <E T="03">supra</E>
                             note 6 at nn.27 (noting that the term “statutory prospectus” means a prospectus that meets the requirements of Section 10(a) of the Securities Act).
                        </P>
                        <P> Because the requirements of Section 5(b)(2) of the Securities Act are applicable to “any person,” its obligations are applicable to financial intermediaries through whom variable contracts are sold, as well as variable contract issuers.</P>
                    </FTNT>
                    <P>
                        First, a person relying on new rule 498A will be required to send or give a summary prospectus to an investor no later than the time of the “carrying or delivery” of the contract security.
                        <SU>393</SU>
                        <FTREF/>
                         This summary prospectus will be an initial summary prospectus in the case of an initial purchase of a variable contract, or an updating summary prospectus in the case of additional investments in a variable contract previously purchased.
                        <SU>394</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>393</SU>
                             
                            <E T="03">See supra</E>
                             note 392 (discussing the prohibition against carrying or delivering a security without otherwise accompanying it or preceding it with a statutory prospectus).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>394</SU>
                             
                            <E T="03">See</E>
                             rule 498A(f)(1); 
                            <E T="03">see also supra</E>
                             note 333 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        Second, the summary prospectus generally may not be bound together with any other materials, except portfolio company summary and statutory prospectuses may be bound together with the contract summary prospectus,
                        <SU>395</SU>
                        <FTREF/>
                         subject to certain conditions.
                        <SU>396</SU>
                        <FTREF/>
                         Third, the summary prospectus must meet the rule's content requirements for an initial summary prospectus or updating summary prospectus (as appropriate).
                        <SU>397</SU>
                        <FTREF/>
                         Finally, the initial summary prospectus, updating summary prospectus, contract statutory prospectus, and contract SAI must be publicly accessible, free of 
                        <PRTPAGE P="25998"/>
                        charge, on a website in the manner that the rule specifies.
                        <SU>398</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>395</SU>
                             
                            <E T="03">See</E>
                             rule 498A(f)(2).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>396</SU>
                             
                            <E T="03">See</E>
                             rule 498A(f)(2)(i) and (ii). These materials may be bound together so long as: (1) All of the underlying portfolio companies whose prospectuses are bundled together are available to the investor to whom they are sent or given; and (2) a table of contents identifying each portfolio company summary and/or statutory prospectus that is bound together (and the page number on which each document is found), is included at the beginning or immediately following a cover page of the bound materials.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>397</SU>
                             
                            <E T="03">See</E>
                             rule 498A(f)(3).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>398</SU>
                             
                            <E T="03">See</E>
                             rule 498A(f)(4) (in addition, a Form N-3 registrant will also be required to post its most recent annual and semi-annual reports to shareholders to the website); 
                            <E T="03">see also infra</E>
                             Section II.A.5.
                        </P>
                    </FTNT>
                    <P>
                        Failure to comply with any of these requirements will prevent a person from relying upon the rule 498A to meet its Section 5(b)(2) prospectus delivery obligations. Absent satisfaction of the Section 5(b)(2) obligation by other available means, a Section 5(b)(2) violation will result.
                        <SU>399</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>399</SU>
                             As discussed below, the rule also includes additional requirements (such as the requirement to send a copy of the contract statutory prospectus upon request) whose violation would result in a violation of the rule, but not result in a violation of Section 5(b)(2). 
                            <E T="03">See infra</E>
                             note 490 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        New rule 498A also provides that a communication relating to an offering registered on Forms N-3, N-4, or N-6 that a person sends or gives after the effective date of a variable contract's registration statement (other than a prospectus that Section 10 of the Securities Act permits or requires) will not be deemed a prospectus under Section 2(a)(10) of the Securities Act 
                        <SU>400</SU>
                        <FTREF/>
                         if:
                    </P>
                    <FTNT>
                        <P>
                            <SU>400</SU>
                             Section 2(a)(10) of the Securities Act provides that certain communications accompanied or preceded by a statutory prospectus are not deemed to be “prospectuses” for purposes of the Securities Act. 
                            <E T="03">See</E>
                             Section 2(a)(10) of the Securities Act [15 U.S.C. 77b(a)(10)(a)] (providing that a communication sent or given after the effective date of the registration statement (other than a prospectus permitted under subsection (b) of Section 10) shall not be deemed a prospectus if it is proved that prior to or at the same time with the communication a written prospectus meeting the requirements for a statutory prospectus at the time of the communication was sent or given to the person to whom the communication was made).
                        </P>
                    </FTNT>
                    <P>(1) It is proved that prior to or at the same time with such communication a summary prospectus was sent or given to the person to whom the communication was made;</P>
                    <P>(2) The summary prospectus meets the same binding requirements that we discuss in the immediately preceding paragraph;</P>
                    <P>(3) The summary prospectus that was sent or given satisfies the requirements for the initial summary prospectus or the updating summary prospectus, as applicable; and</P>
                    <P>
                        (4) The initial summary prospectus, updating summary prospectus, contract statutory prospectus, and contract SAI are publicly accessible, free of charge, on a website in the manner that the rule specifies.
                        <SU>401</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>401</SU>
                             
                            <E T="03">See</E>
                             rule 498A(g).
                        </P>
                    </FTNT>
                    <P>
                        This provision of the final rule, which is modeled on a corresponding provision of rule 498,
                        <SU>402</SU>
                        <FTREF/>
                         extends similar treatment to communications accompanied or preceded by a summary prospectus if all the provision's conditions are met. These communications remain subject to the general antifraud provisions of the federal securities laws.
                        <SU>403</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>402</SU>
                             
                            <E T="03">See</E>
                             rule 498(d).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>403</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Section 17(a) of the Securities Act [15 U.S.C. 77q(a)]; Section 10(b) of the Exchange Act [15 U.S.C. 78j(b)]; Section 34(b) of the Investment Company Act [15 U.S.C. 80a-33(b)].
                        </P>
                    </FTNT>
                    <P>Because we believe that all investors should receive the benefit of the succinct, investor-friendly disclosure that is included in the variable contract summary prospectus, all of the disclosure items that appear in the summary prospectus also will be required to appear in the statutory prospectus. In that respect, all variable contract investors, regardless of whether the product they choose has a summary prospectus, will have the benefit of improved disclosures in the statutory prospectus.</P>
                    <P>
                        We received comments relating to the rule's conditions as to delivery of the summary prospectus. One commenter recommended that the summary prospectus should be delivered at the point of the investment recommendation,
                        <SU>404</SU>
                        <FTREF/>
                         while another believed that retail investors should receive the initial summary prospectus “the earlier of `the time of the `carrying or delivery' of the contract' or 10 days in advance of the effective date of the contract” to allow time to make an educated investment decision and rescind the contract before the end of the free-look period.
                        <SU>405</SU>
                        <FTREF/>
                         Because the proposed delivery requirement effectuates the requirements of a statutory provision, we are not modifying the timing of the prospectus delivery requirements, and are accordingly adopting this aspect of the rule as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>404</SU>
                             
                            <E T="03">See</E>
                             CFA Comment Letter (“For investors to make good use of disclosures, they need to receive the information early enough (
                            <E T="03">e.g.,</E>
                             point of recommendation) to incorporate it in their decision-making process. Disclosure that arrives after a decision has already been made (
                            <E T="03">e.g.,</E>
                             point of sale) or worse, after a purchase has already been made, defeat the purpose of disclosure as a decision-making tool.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>405</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Although the Commission did not propose a change to the delivery format (paper versus electronic) of summary prospectuses, we received a number of comments on this topic.
                        <SU>406</SU>
                        <FTREF/>
                         One commenter asked that we allow insurers to deliver an electronic initial summary prospectus with links to the statutory prospectus at the point of sale.
                        <SU>407</SU>
                        <FTREF/>
                         A second commenter suggested that we allow insurers to satisfy prospectus delivery obligations by posting the prospectuses on the company's website, provided that paper copies are available upon request,
                        <SU>408</SU>
                        <FTREF/>
                         similar to the delivery requirements for the required online contract documents, discussed below.
                        <SU>409</SU>
                        <FTREF/>
                         A third commenter stated that any summary prospectus should be provided to investors digitally and in hard copy.
                        <SU>410</SU>
                        <FTREF/>
                         A fourth commenter urged us to require paper delivery as the default delivery of their prospectuses or summary prospectuses unless the retail investor has affirmatively chosen to receive these documents electronically.
                        <SU>411</SU>
                        <FTREF/>
                         Another commenter stated that it did not see a “need to modify the requirements to make clear that paper-based delivery is not the only permissible or desired delivery format.” 
                        <SU>412</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>406</SU>
                             Several commenters asked that we take steps to modernize the electronic delivery framework. 
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; CAI Comment Letter (requesting action with respect to the federal Electronic Signatures in Global and National Commerce Act of 2000 (“E-SIGN”), which, as described, includes provisions that impose significant burdens on how informed consent may be obtained); Broadridge Comment Letter (stating that if technologies like QR codes and offers to enroll in e-delivery were permitted (but not required) to be included in the new disclosure, the path to digital delivery could be smoother for the 85% of variable annuity investors who currently receive these documents in the mail). Because these issues go beyond the scope of this rulemaking, we do not address them here. However, recognizing the growth of different forms of electronic media and other technological developments, among other things, the Commission has stated that it plans to revisit its existing guidance regarding electronic delivery. 
                            <E T="03">See</E>
                             Form CRS Relationship Summary; Amendments to Form ADV, Investment Advisers Act Release No. 5247 (June 5, 2019) [84 FR 33492 (July 12, 2019)], at n.678.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>407</SU>
                             
                            <E T="03">See</E>
                             AIG Comment Letter. This approach is permitted under existing rules, subject to certain conditions. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.32.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>408</SU>
                             
                            <E T="03">See</E>
                             Lincoln Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>409</SU>
                             
                            <E T="03">See infra</E>
                             Section II.A.6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>410</SU>
                             
                            <E T="03">See</E>
                             Cardozo Clinic Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>411</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter; CFA Comment Letter (investors should continue to have the choice of how they prefer to receive disclosures—whether in paper or electronically).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>412</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        To maintain a consistent regime across all investment products, the summary prospectus framework we are adopting in this document will not change the Commission's current guidance regarding electronic delivery. As discussed in the Proposing Release, although paper is the default format for delivery of prospectuses and certain other required disclosures, the Commission has provided guidance noting that electronic delivery may be used to satisfy prospectus delivery requirements if: (1) The investor has notice of the availability of the information; (2) the use of the medium is not so burdensome that intended recipients cannot effectively access the 
                        <PRTPAGE P="25999"/>
                        information being provided; and (3) the issuer has evidence of delivery.
                        <SU>413</SU>
                        <FTREF/>
                         Issuers relying on this guidance have typically satisfied the “evidence of delivery” requirement by obtaining informed consent to electronic delivery.
                        <SU>414</SU>
                        <FTREF/>
                         We understand that investors that have elected electronic delivery of materials associated with their variable contract commonly receive an email that contains a link to the website where the materials are available.
                        <SU>415</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>413</SU>
                             
                            <E T="03">See</E>
                             1995 Release, 
                            <E T="03">supra</E>
                             note 19; 1996 Release, 
                            <E T="03">supra</E>
                             note 19; 2000 Release, 
                            <E T="03">supra</E>
                             note 19.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>414</SU>
                             
                            <E T="03">See</E>
                             Proposing Release 
                            <E T="03">supra</E>
                             note 6, at n.32 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>415</SU>
                             One commenter requested clarification regarding an issue related to electronic delivery obligations generally. 
                            <E T="03">See</E>
                             CFA Comment Letter. Because these comments go beyond the scope of this rulemaking, we do not address them here. 
                            <E T="03">See also supra</E>
                             note 406.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">5. Online Accessibility of Contract Statutory Prospectus and Certain Other Documents Relating to the Contract</HD>
                    <P>
                        Under the final rule, as proposed, investors who receive an initial or updating summary prospectus will have access to more detailed information about the variable contract, either by reviewing the information online, or by requesting the information to be sent in paper or electronically. These provisions parallel provisions in the rule governing the use of mutual fund summary prospectuses.
                        <SU>416</SU>
                        <FTREF/>
                         In our experience, layered disclosure for mutual funds has benefitted both investors and registrants, and we are adopting a similar framework for variable contracts. We believe that permitting variable contract investors to access the contract statutory prospectus in several ways (online and by physical or electronic delivery) maximizes the accessibility and usability of the information, as indicated by investors' preference for access to both online and paper resources.
                        <SU>417</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>416</SU>
                             
                            <E T="03">See</E>
                             rule 498(c)(4), (d)(4), (e), and (f).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>417</SU>
                             
                            <E T="03">See</E>
                             2012 Financial Literacy Study, 
                            <E T="03">supra</E>
                             note 108, at iv, xix.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">a. Required Online Contract Documents</HD>
                    <P>
                        As proposed, and under the final rule, a variable contract's current initial summary prospectus, updating summary prospectus, statutory prospectus, and SAI, and, in the case of a registrant on Form N-3, the registrant's most recent annual and semi-annual reports to shareholders under rule 30e-1 under the Investment Company Act (together, the “required online contract documents”), will be required to be available online.
                        <SU>418</SU>
                        <FTREF/>
                         This approach operationalizes the summary prospectus layered disclosure framework, with the summary prospectus provided in paper (or electronically) to investors, and additional information about the contract securities available online.
                    </P>
                    <FTNT>
                        <P>
                            <SU>418</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(1)(i) through (ii).
                        </P>
                    </FTNT>
                    <P>
                        The required online contract documents generally comprise the same set of documents that the mutual fund summary prospectus rules require to be posted online,
                        <SU>419</SU>
                        <FTREF/>
                         and provide additional important detail about the contract that investors can access, if they wish. The required online contract documents only reference the registrant's annual and semi-annual shareholder reports for Form N-3 registrants because Form N-4 and Form N-6 registrants do not have shareholder reports, but instead transmit the portfolio companies' annual and semi-annual shareholder reports to the investors in the contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>419</SU>
                             
                            <E T="03">See</E>
                             rule 498(e)(1).
                        </P>
                    </FTNT>
                    <P>
                        As with similar provisions in the mutual fund summary prospectus rule, these required online contract documents are required to be publicly accessible, free of charge, at the website address that the cover page of the summary prospectus specifies, on or before the time that the person relying on the rule provides the summary prospectus to investors.
                        <SU>420</SU>
                        <FTREF/>
                         Moreover, a current version of each of the required online contract documents must remain on that website for at least 90 days following either:
                    </P>
                    <FTNT>
                        <P>
                            <SU>420</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(1); 
                            <E T="03">see also</E>
                             rule 498(e)(1).
                        </P>
                    </FTNT>
                    <P>• The time of the “carrying or delivery” of the contract security if a person is relying on the rule to satisfy its Section 5(b)(2) prospectus delivery obligations; or</P>
                    <P>
                        • If a person is relying on the rule to send communications that will not be deemed to be prospectuses, the time that the person sends or gives the communication to investors.
                        <SU>421</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>421</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(1).
                        </P>
                    </FTNT>
                    <P>
                        This requirement is designed to provide continuous access to the information from the time the summary prospectus is sent or given until at least 90 days after the date of delivery of a security or communication in reliance on the rule. One commenter stated the proposed 90-day timeframe for the availability of online information was too short (unless there were an archive requirement, in which case it suggested the 90-day timeframe could make sense), and that a year would be more helpful to investors.
                        <SU>422</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>422</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        As a practical matter, because variable contracts (and their underlying portfolio companies) are generally continuously offered, a current contract prospectus and related documents would likely remain online for longer than 90 days. The 90 day period is also the timeframe required for the availability of online information under the mutual fund summary prospectus rule, and the Commission proposed that it be the same for variable contracts because of market participants' familiarity with this timeframe, and because there may be operational efficiencies for certain registrants in having the timeframe be the same under both summary prospectus frameworks. Moreover, we believe this timeframe appropriately balances the costs of maintaining information online with investors' interests in having the flexibility to access this online information after receiving the summary prospectus.
                        <SU>423</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>423</SU>
                             For example, an investor who has received the summary prospectus and would like to review more detail about a certain topic in the statutory prospectus would have at least 90 days to access the statutory prospectus that is available online.
                        </P>
                    </FTNT>
                    <P>
                        Two commenters recommended that we make the web-posting requirements more principles-based and less regimented.
                        <SU>424</SU>
                        <FTREF/>
                         The proposed requirements for the availability of online information were designed to mirror the requirements in the mutual fund summary prospectus rule because we believed that investors and the industry would benefit from the consistency between the two summary prospectus regimes. Moreover, we believe it would be more appropriate to undertake a holistic review of the website posting (and possibly other technology-based) requirements for all investment products, including funds and variable contracts as part of a future initiative. Therefore, we are adopting the website posting requirements as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>424</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; Anonymous Comment Letter III. One of these commenters suggested that we not be so prescriptive about the format of content, which appear to be paper-based, and instead permit the flexibility that would allow for a website with tabs for each section instead of a serial document. The final rule does not prohibit a website with tabs for each section.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Website Address at Which Required Online Contract Documents Are Available.</E>
                         Also as proposed, the website address must be specific enough to lead investors directly to the required online contract documents, although the website can be a central site with prominent links to each document.
                        <SU>425</SU>
                        <FTREF/>
                         Thus, while contract documents may be hosted at multiple locations, for purposes of compliance with the rule, a summary prospectus may only include a single website address where each of the required online contract documents 
                        <PRTPAGE P="26000"/>
                        may be accessed. This requirement is designed to ensure that the required online contract documents are collectively located at the same website address (or can be readily accessed from the same website address), as opposed to being scattered across various disconnected websites which could discourage investors from seeking those materials. As discussed below, if an insurer avails itself of the optional method of delivering portfolio company prospectuses, the portfolio company documents required to be made available online under that option must be accessible from the same website address used to access the required contract documents.
                        <SU>426</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>425</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(2)(v)(B).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>426</SU>
                             
                            <E T="03">See infra</E>
                             Section II.B.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Formatting Requirements for Required Online Contract Documents</HD>
                    <P>
                        The final rule, as proposed, requires that the online contract documents be presented in a manner that is human-readable and capable of being printed on paper in human-readable format.
                        <SU>427</SU>
                        <FTREF/>
                         We received no comments on this aspect of the proposal. This formatting requirement is a condition of reliance on the rule to satisfy a person's delivery obligations under Section 5(b)(2) of the Securities Act and the provision that a communication shall not be deemed a prospectus under Section 2(a)(1) of the Securities Act. The rule governing mutual fund summary prospectuses also requires this formatting approach.
                        <SU>428</SU>
                        <FTREF/>
                         The “human-readable” presentation requirement is designed to impose a minimum standard of usability comparable to that of a paper document, although the electronic version could include additional features (
                        <E T="03">e.g.,</E>
                         fee calculators or pop-up explanations) that might enhance its usability relative to the paper version.
                        <SU>429</SU>
                        <FTREF/>
                         Regarding usability, all portions of the document should be human-readable such that when an investor views the document electronically, the text is not cut off based on the screen size.
                    </P>
                    <FTNT>
                        <P>
                            <SU>427</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(2)(i).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>428</SU>
                             Rule 498(e)(2)(i).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>429</SU>
                             As in the parallel provisions of the rule governing mutual fund summary prospectuses, the “human-readable” condition is intended to make clear that posted information must be presented in human-readable text, rather than machine-readable software code, when accessed through an internet browser and that it must be printable in human-readable text. This condition does not impose any further requirements relating to user-friendliness of the presentation. 
                            <E T="03">See</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17, at 85; 
                            <E T="03">see also infra</E>
                             note 444 and accompanying and following text (discussing provisions that are meant to enhance investors' understanding of special terms when they view the summary prospectus online, as well as other technological tools associated with online disclosure (
                            <E T="03">e.g.,</E>
                             fee calculators or pop-up explanations) that present further opportunities to promote investor understanding).
                        </P>
                    </FTNT>
                    <P>
                        In addition, the final rule requires that the online materials be presented in a format, or formats, that are convenient for both reading online and printing on paper.
                        <SU>430</SU>
                        <FTREF/>
                         The failure to comply with these “convenient for reading and printing” formatting requirements will not, however, be a condition of reliance on the rule, because whether a particular format is convenient for reading online and printing depends on a number of factors and must be decided on a case-by-case basis.
                        <SU>431</SU>
                        <FTREF/>
                         In order to provide certainty to market participants, we are therefore not mandating that this requirement be a condition of reliance on the rule, and thus the failure to comply with this requirement will not negate a person's ability to rely on the rule in order to satisfy a person's delivery obligations under Section 5(b)(2) of the Securities Act.
                        <SU>432</SU>
                        <FTREF/>
                         Such a failure will, however, constitute a violation of Commission rules.
                    </P>
                    <FTNT>
                        <P>
                            <SU>430</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(3); 
                            <E T="03">see also</E>
                             rule 498(f)(3) (parallel provision in the rule governing the use of mutual fund summary prospectuses). This condition could be satisfied by, for example, providing one format that is convenient for reading online, and another format that is convenient for printing on paper.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>431</SU>
                             
                            <E T="03">See</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17, at nn.272 and 273 and accompanying text (relevant factors include the manner in which the online version renders charts, tables, and other graphics; the extent to which the online materials include search and other capabilities of the internet to enhance investors' access to information and include access to any software necessary to view the online version; and the time required to download the online materials).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>432</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(5); 
                            <E T="03">see also</E>
                             rule 498(f)(5) (parallel provision in the rule governing the use of mutual fund summary prospectuses).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Linking Within and Between Documents</HD>
                    <P>
                        As proposed, the final rule also includes requirements for linking within the electronic versions of the contract statutory prospectus and SAI that are available online, and also for linking between electronic versions of contract summary and statutory prospectuses that are available online.
                        <SU>433</SU>
                        <FTREF/>
                         These requirements, which are substantively identical to parallel provisions in the rule governing mutual fund summary prospectuses,
                        <SU>434</SU>
                        <FTREF/>
                         are designed to promote the usability of the information that appears in these documents.
                    </P>
                    <FTNT>
                        <P>
                            <SU>433</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(2)(ii) and (iii); 
                            <E T="03">see also</E>
                             rule 498A(
                            <E T="03">i</E>
                            )(4); General Instruction 1(b) to Item 2 of Forms N-3, N-4, and N-6; 
                            <E T="03">see supra</E>
                             note 201 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>434</SU>
                             
                            <E T="03">See</E>
                             rule 498(e)(2)(ii) and (iii). As discussed below, the parallel provisions of rule 498A also include similar linking requirements for the portfolio company documents that the rule requires to appear online if a person were to rely on the rule's new delivery option for portfolio company prospectuses.
                        </P>
                    </FTNT>
                    <P>
                        The first linking requirement will allow the reader to move directly between a table of contents of the contract statutory prospectus or SAI and the related sections of that document.
                        <SU>435</SU>
                        <FTREF/>
                         The second linking requirement will allow the reader to move back and forth between each section of the summary prospectus and any related section of the contract statutory prospectus and contract SAI that provides additional detail.
                        <SU>436</SU>
                        <FTREF/>
                         This back-and-forth movement could occur either directly from the summary prospectus to the relevant section of the statutory prospectus or SAI, or indirectly by linking from the summary prospectus to a table of contents for the statutory prospectus or SAI, and vice versa.
                        <SU>437</SU>
                        <FTREF/>
                         As discussed above, in response to commenters, we are modifying a separate aspect of the proposal that would have inadvertently negated the ability of registrants to use the indirect linking option.
                        <SU>438</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>435</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)
                            <E T="03">(</E>
                            2)(ii). The linked table of contents may be outside the document (
                            <E T="03">e.g.,</E>
                             in a separate section or panel of the screen), and need not be the table of contents that is contained within the document itself, as long as the linked table of contents for the statutory prospectus conforms to our rules' requirements for the table of contents that appears within the document). 
                            <E T="03">See</E>
                             rule 481(c) under the Securities Act.
                        </P>
                        <P> Mutual funds commonly implement this feature using a left navigation or “bookmark” design style. While such design styles continue to be popular (and we anticipate that some insurers relying on rule 498A might also employ this design style), the increased use of mobile devices and applications has led to the development of new and evolving design styles. Any navigation style must provide the functionality that is required by the rule.</P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>436</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(2)(iii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>437</SU>
                             
                            <E T="03">Id.</E>
                             Under the latter option, links either have to be available at both the beginning and end of the summary prospectus, or have to remain continuously visible to persons accessing the summary prospectus. This requirement is designed to promote the links' prominence and accessibility to investors.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>438</SU>
                             
                            <E T="03">See supra</E>
                             note 201 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Definitions of Special Terms, and Online Viewing of Special Terms</HD>
                    <P>
                        The summary prospectus content requirements reference information that is required to appear in the contract statutory prospectus, which in turn must be written using plain English principles.
                        <SU>439</SU>
                        <FTREF/>
                         Variable contract disclosure documents tend to include industry-specific language in order to describe the sometimes complex features of these products. We recognize, therefore, that it may be particularly challenging to accurately describe a variable contract without 
                        <PRTPAGE P="26001"/>
                        using certain terms that, while technically accurate, may be confusing or unfamiliar to retail investors. Accordingly, the final rule, as proposed, requires a summary prospectus to define any “special terms” elected by the registrant, using any presentation that clearly conveys their meaning to investors.
                        <SU>440</SU>
                        <FTREF/>
                         This requirement reflects the instructions in Forms N-3, N-4, and N-6 (as well as similar instructions in the current version of these forms to define “special terms” in a glossary or index).
                        <SU>441</SU>
                        <FTREF/>
                         The registrant will determine which terms constitute special terms. We generally believe that a special term is a term that is typically unfamiliar to a new contract investor and is important for the investor to understand key features of the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>439</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5), (6); General Instruction B.4(c) to amended Forms N-3, N-4 and N-6 (referencing 17 CFR 230.421 (rule 421(d) under the Securities Act)).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>440</SU>
                             
                            <E T="03">See</E>
                             rule 498A(e). For example, the summary prospectus could include a glossary or a list of definitions of special terms that appear throughout the document. Or, as another example, if a special term appears in only one section of the summary prospectus, the summary prospectus could include a definition for this term on the page, or in the section, where this term appears (for example, in a box to the side of the main text, or at the bottom of the page). Additionally, there are or may become available technological solutions for electronic versions of the summary prospectus. 
                            <E T="03">See infra</E>
                             note 444 and accompanying and following text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>441</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3(d) to Forms N-3, N-4, and N-6; 
                            <E T="03">see also</E>
                             Item 2 of current Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <P>
                        Two commenters responded favorably to the inclusion of a Special Terms section of the hypothetical initial summary prospectus, with one commenter stating its belief that “the `Special Terms' section . . . will be helpful to the reader as it defines terms with which they may not be familiar,” 
                        <SU>442</SU>
                        <FTREF/>
                         and another observing that “because the Special Terms are the first thing people see, they are likely to read them more diligently.” 
                        <SU>443</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>442</SU>
                             
                            <E T="03">See</E>
                             WFA Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>443</SU>
                             
                            <E T="03">See</E>
                             Cardozo Clinic Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        In order to leverage technology to help investors understand the variable contract, the final rule includes provisions that are meant to enhance investors' understanding of special terms when they view the summary prospectus online. Specifically, the rule requires that investors either be able to view the definition of each special term used in an online summary prospectus upon command,
                        <SU>444</SU>
                        <FTREF/>
                         or to move directly back and forth between each special term and the corresponding entry in any glossary or list of definitions that the summary prospectus includes.
                        <SU>445</SU>
                        <FTREF/>
                         This approach, which today is a common convention for many electronically available documents, is an example of how technology can enhance our layered approach to disclosure and help investors who access the document online grasp the complexities of variable contract features. Registrants may wish to consider whether other technological tools associated with their online disclosure (
                        <E T="03">e.g.,</E>
                         pop-up explanations) present further opportunities to promote investor understanding.
                    </P>
                    <FTNT>
                        <P>
                            <SU>444</SU>
                             For example, investors could view the definitions of special terms by moving or “hovering” the computer's pointer or mouse over the term, or selecting the term on a mobile device.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>445</SU>
                             Rule 498A(h)(2)(iv).
                        </P>
                    </FTNT>
                    <P>
                        Two commenters supported the proposed approach. One commenter “commend[ed] the Commission for its requirement that investors accessing the summary prospectus should be able to view the definition of special terms upon command,” and suggested that the requirement be expanded to all definitions to improve the readability of the document.
                        <SU>446</SU>
                        <FTREF/>
                         Another commenter stated that electronic versions of the prospectus should have definitions for defined terms that pop up when clicked.
                        <SU>447</SU>
                        <FTREF/>
                         Conversely, one commenter stated that requiring the definition of each special term used in an online summary prospectus to be viewed upon command, or to permit investors to move directly back and forth between each special term and the corresponding entry in any glossary in the summary prospectus, may be burdensome and excessive since an initial and updating summary prospectus has so many terms.
                        <SU>448</SU>
                        <FTREF/>
                         This commenter recommended instead that insurers be permitted to make a link to a summary prospectus's glossary continuously visible, thereby allowing an investor to move back-and-forth between the various sections of a summary prospectus and its glossary.
                    </P>
                    <FTNT>
                        <P>
                            <SU>446</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>447</SU>
                             
                            <E T="03">See</E>
                             Cardozo Clinic Comment Letter (“if the reader “clicks” on a defined term, the definition of the term should automatically be shown to the reader”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>448</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>We are adopting the requirement as proposed. We believe that registrants should provide investors with an easy and convenient means to understand the terms used to describe the investment product offered. Given the prevalence of different technological solutions that allow online documents to be viewed upon command, we are not persuaded that the burdens are as great as this commenter suggests. Moreover, we are concerned that for a registrant that chooses to make the table of contents for the statutory prospectus continuously available, the inclusion of a continuously available glossary would clutter an investor's visual field, potentially reduce the investor's focus, and detract attention away from the information in the summary documents.</P>
                    <P>
                        Commenters offered a variety of suggestions regarding technological tools that could enhance online disclosure to promote investor understanding. While several commenters agreed with the concept of an interactive fee calculator,
                        <SU>449</SU>
                        <FTREF/>
                         they recommended that the final rule not require this functionality because of concerns about the feasibility of developing this feature for such a highly customized investment product,
                        <SU>450</SU>
                        <FTREF/>
                         and raised questions about the relative benefits to investors.
                        <SU>451</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>449</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter; CAI Comment Letter; ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>450</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (stating that interactive fee calculators would be very difficult to design for even a single contract, given the potential complications associated with multiple classes/versions, fee structures, features, investment restrictions, and optional benefits, and administering interactive fee calculators for entire books of business could be virtually impossible for many insurers); ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>451</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter (stating that investors would receive the same fee information from the investment professional selling the variable contract, who could also explain the information, whereas use of an interactive calculator without the benefit of an explanation might serve to create investor confusion); Ameritas Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        One commenter suggested an interactive tool that could allow investors to vary the assumptions in a visual illustration to see the effect on policy value as the inputs are changed.
                        <SU>452</SU>
                        <FTREF/>
                         Another commenter stated that a modern app-based disclosure solution is the best technology option to provide investors with streamlined, user-friendly technology, and recommended that we add language to the final rule that specifically supports apps for delivery of content related to prospectus data for variable contracts.
                        <SU>453</SU>
                        <FTREF/>
                         The final rule does not preclude the use of apps as a disclosure delivery channel provided all conditions of the rule are met, and, as we note below, we decline to add any additional language supporting their use. A different commenter suggested that the Commission should develop an application or other web-based tool to enable investors to compare the key information contained in summary prospectuses of different issuers in a manner similar to the way websites today enable consumers looking to purchase a new car to compare key features of vehicles of different manufacturers.
                        <SU>454</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>452</SU>
                             
                            <E T="03">See</E>
                             Baldwin Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>453</SU>
                             
                            <E T="03">See</E>
                             Donnelley Financial Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>454</SU>
                             
                            <E T="03">See</E>
                             IRI Comment Letter I (“Rather than relying on investors or third parties to harness modern technology to give investors the ability to efficiently analyze and compare available information, the Commission, as the repository of all Summary 
                            <PRTPAGE/>
                            Prospectus data, should itself harness such technology.”).
                        </P>
                    </FTNT>
                    <PRTPAGE P="26002"/>
                    <P>
                        We appreciate all of these technological suggestions and are continuing to consider their usefulness in investor disclosures. As previously noted, however, because we believe it would be more efficient to undertake a holistic review of technology-based approaches for all investment products as part of a future initiative,
                        <SU>455</SU>
                        <FTREF/>
                         we are adopting the requirements to define, and provide online viewing of, Special Terms as proposed. We nonetheless encourage registrants and other industry participants to consider how technology can be used to improve the communication of information to investors, particularly as investors trend toward using applications and other technologies to access information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>455</SU>
                             
                            <E T="03">See supra</E>
                             note 424 and subsequent text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">e. Ability To Retain Documents</HD>
                    <P>
                        The final rule, as proposed, also requires that persons accessing the website that appears on the summary prospectus cover page be able to permanently retain, free of charge, an electronic version of each of the required online contract documents.
                        <SU>456</SU>
                        <FTREF/>
                         Like the online version of these documents, the retainable version of the documents must be in a format that: (1) Is human-readable and capable of being printed on paper in human-readable format; and (2) permits persons accessing the downloaded documents to move directly back and forth between each section heading in a table of contents of that document and the section of the document referenced in that section heading.
                        <SU>457</SU>
                        <FTREF/>
                         The permanently retained document does not have to be in a format that allows an investor to move back and forth between the summary prospectus and the statutory prospectus and SAI, because of possible technical difficulties associated with maintaining links between multiple downloaded documents.
                        <SU>458</SU>
                        <FTREF/>
                         These conditions are substantively identical to parallel provisions in the rule governing mutual fund summary prospectuses.
                        <SU>459</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>456</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>457</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(2)(i) through (ii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>458</SU>
                             One commenter said we should require that downloaded documents retain links that enable a user to move readily between related passages of multiple documents because without the links, the documents do not provide complete information to investors. 
                            <E T="03">See</E>
                             AARP Comment Letter. We do not agree that the lack of an active link diminishes the completeness of the information in the documents, and decline to make the suggested change.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>459</SU>
                             
                            <E T="03">See</E>
                             rule 498(e)(3).
                        </P>
                    </FTNT>
                    <P>
                        In addition, the rule mandates that the electronic versions of the documents that may be permanently retained must be in a format that is convenient for both reading online and printing on paper.
                        <SU>460</SU>
                        <FTREF/>
                         Like the “convenient for reading and printing” online formatting requirements,
                        <SU>461</SU>
                        <FTREF/>
                         the failure to comply with these formatting requirements for retained electronic documents is not a condition for reliance on the rule.
                        <SU>462</SU>
                        <FTREF/>
                         Since the convenience of these formatting requirements must be decided on a case-by-case basis, we believe this approach will help provide certainty to market participants who seek to rely on the rule to satisfy prospectus delivery obligations.
                        <SU>463</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>460</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(3).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>461</SU>
                             
                            <E T="03">See supra</E>
                             note 430 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>462</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(5).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>463</SU>
                             
                            <E T="03">See supra</E>
                             notes 431 and 432 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">f. Safe Harbor for Temporary Noncompliance</HD>
                    <P>
                        Compliance with the conditions in new rule 498A regarding the online availability of the required online contract documents (including the formatting and linking requirements for these documents, the requirements associated with the use of special terms in these documents, and the ability to retain these documents permanently) is generally required in order to rely on the rule to meet prospectus delivery obligations under Section 5(b)(2) of the Securities Act.
                        <SU>464</SU>
                        <FTREF/>
                         Failure to comply with any of these conditions could result in a violation of Section 5(b)(2) unless the contract statutory prospectus is delivered by means other than reliance on the rule.
                    </P>
                    <FTNT>
                        <P>
                            <SU>464</SU>
                             
                            <E T="03">See</E>
                             rule 498A(f)(4) (Section 5(b)(2) transfer of the contract security is satisfied if, among other things, the conditions in rule 498A(h) are satisfied).
                        </P>
                    </FTNT>
                    <P>
                        We recognize, however, that there may be times when, due to events beyond a person's control, the person may temporarily not be in compliance with the rule's conditions regarding the availability of the required online contract documents.
                        <SU>465</SU>
                        <FTREF/>
                         Commenters expressed support for the proposed safe harbor provision,
                        <SU>466</SU>
                        <FTREF/>
                         and the final rule, as proposed, contains a provision for temporary noncompliance, which is substantively identical to a parallel provision in the rule governing mutual fund summary prospectuses.
                        <SU>467</SU>
                        <FTREF/>
                         This provision provides that the conditions regarding the availability of the required online contract documents will be deemed to be met, even if the required online contract documents are temporarily unavailable, provided that the person has reasonable procedures in place to ensure that those materials are available in the required manner. A person relying on the rule to satisfy prospectus delivery obligations is required to take prompt action to ensure that those materials become available in the manner required as soon as practicable following the earlier of the time when the person knows, or reasonably should have known, that the documents were not available in the manner required.
                        <SU>468</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>465</SU>
                             Such events might, for example, include system outages or other technological issues, natural disasters, acts of terrorism, or pandemic illnesses.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>466</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter. 
                            <E T="03">See also</E>
                             Comment Letter of Martha Chemas (Mar. 8, 2019) (“Chemas Comment Letter”) (suggesting a safe harbor in the case of a denial of service attack or similar outage while the website was under attack).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>467</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(4); 
                            <E T="03">see also</E>
                             rule 498(e)(4).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>468</SU>
                             
                            <E T="03">Id.</E>
                             This safe harbor generally would not be available to a registrant that repeatedly fails to comply with the rule's website posting requirements or that is not in compliance with the requirements over a prolonged period. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at nn.285.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">6. Other Requirements for Summary Prospectus and Other Contract Documents</HD>
                    <HD SOURCE="HD3">a. Delivery Upon Request</HD>
                    <P>
                        Proposed rule 498A included certain requirements relating to the delivery of paper or electronic copies of required online contract documents upon request.
                        <SU>469</SU>
                        <FTREF/>
                         We are adopting these requirements as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>469</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(1).
                        </P>
                    </FTNT>
                    <P>Under the final rule, an investor who receives a contract summary prospectus and who would also like to review the contract's statutory prospectus, SAI, and, in the case of a variable contract registered on Form N-3, its most recent annual and semi-annual report to shareholders is able to choose whether to review these documents online or to receive that information directly, in paper or electronic format as requested by the investor. Accordingly, a registrant (or financial intermediary distributing the contract) is required to send a paper or electronic copy of the required online contract documents to any person requesting such a copy. The person must send requested paper documents at no cost to the requestor, by U.S. first class mail or other reasonably prompt means, within three business days after receiving the request.</P>
                    <P>
                        A registrant or intermediary is also required to send electronic copies of these documents upon request within three business days. The requirement to send an electronic copy of a document may be satisfied by sending a direct link to the online document; provided that a current version of the document is directly accessible through the link from the time that the email is sent through the date that is six months after the date that the email is sent and the email 
                        <PRTPAGE P="26003"/>
                        explains both how long the link will remain useable and that, if the recipient desires to retain a copy of the document, he or she should access and save the document. Collectively, these requirements are intended to ensure that an investor has prompt access to the required information in a format that he or she prefers.
                    </P>
                    <P>As proposed and under the final rule, investors who prefer paper copies of the statutory prospectus but do not have ready access to the internet (or the ability to print out the statutory prospectus that is made available online) will not be able to elect in advance to receive paper copies of all future statutory prospectuses unless a registrant chose to give investors that option. Assuming no such accommodation, investors will need to follow the summary prospectus legend's instruction on how to request paper copies of the statutory prospectus each time a new statutory prospectus is available. Those that do not take the additional step of requesting a paper copy of the statutory prospectus will not receive the statutory prospectus in their preferred format.</P>
                    <P>
                        Two commenters supported this framework.
                        <SU>470</SU>
                        <FTREF/>
                         One of those commenters stated that the ability to obtain a paper copy of the prospectus without charge through a toll-free number provides a functional and practical mechanism for investors to obtain a paper copy, and advised against mandating opt-in or opt-out practices concerning future delivery of paper prospectuses, which would impose unnecessary tracking responsibilities and costs that would greatly overshadow the marginal benefit to consumers.
                        <SU>471</SU>
                        <FTREF/>
                         In contrast, a separate commenter asserted that investors who want paper should be able to permanently elect to receive the full statutory prospectus and underlying fund documents.
                        <SU>472</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>470</SU>
                             
                            <E T="03">See, e.g.,</E>
                             NAIFA Comment Letter (“Any investor who wants to receive more detailed information should have access to more detailed, second-tier disclosures upon request and without cost. Firms should be required to provide hard-copy versions of these second-tier disclosures free of charge to any investor who requests a hard-copy disclosure document.”); ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>471</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter (predicting that, based on insurers' experiences under the current paper delivery regime, few variable contract purchasers are likely to request a paper copy after the initial purchase).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>472</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        While registrants may choose to give investors the option to permanently elect to receive the full statutory prospectus and underlying fund documents, we are not requiring registrants to provide that option. As discussed throughout this release, we believe the layered disclosure framework contemplated by the rule (
                        <E T="03">i.e.,</E>
                         sending or receiving the summary prospectus and making the statutory prospectus and underlying fund materials available online and upon request) will benefit the majority of investors and generally represents an improvement over the current disclosure regime.
                        <SU>473</SU>
                        <FTREF/>
                         Moreover, we believe that this approach appropriately balances the interests of the number of variable contract investors whom we believe would benefit from the convenience of online documents against the number of those whom we believe prefer paper. Although certain investors may prefer statutory prospectuses rather than summary prospectuses, we believe that such investors are likely willing to seek out detailed information to inform their investment decisions.
                        <SU>474</SU>
                        <FTREF/>
                         We believe that for these investors, the additional effort required to access the statutory prospectus online or request paper or electronic statutory prospectuses will be incrementally minimal.
                        <SU>475</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>473</SU>
                             
                            <E T="03">See generally infra</E>
                             Section IV.C.1.a.i.(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>474</SU>
                             
                            <E T="03">See generally infra</E>
                             Section IV.C.1.a.i.(b).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>475</SU>
                             
                            <E T="03">See id.</E>
                             (noting that investors may need to manually enter a hyperlink from a paper updating summary prospectus or open a link to a website containing the statutory prospectus in such circumstances).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Prominence Requirement</HD>
                    <P>
                        The final rule also requires that, generally like mutual funds, a contract summary prospectus must be given greater prominence than any materials that accompany the summary prospectus.
                        <SU>476</SU>
                        <FTREF/>
                         As discussed in the Proposing Release, this requirement is designed to prevent any accompanying sales or other materials from obscuring the contract summary prospectus, and to highlight for investors the concise presentation of the summary prospectus, and the salience of the information it includes.
                        <SU>477</SU>
                        <FTREF/>
                         We believe that the greater prominence requirement would be satisfied if the placement of the contract summary prospectus makes it more conspicuous than any accompanying materials.
                        <SU>478</SU>
                        <FTREF/>
                         The only commenter who addressed this aspect of the proposal offered mixed support.
                        <SU>479</SU>
                        <FTREF/>
                         We continue to believe the prominence requirement benefits investors and are adopting it as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>476</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(2); 
                            <E T="03">see also</E>
                             rule 498(f)(2).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>477</SU>
                             
                            <E T="03">See</E>
                             Prospectus Release, 
                            <E T="03">supra</E>
                             note 6, at nn.293-294 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>478</SU>
                             
                            <E T="03">Id.</E>
                             A summary prospectus on top of a group of papers that are provided together, or listed first if presented on a website together with other materials related to the contract, satisfies this requirement.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>479</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter (stating “We support the proposal's narrative that the summary prospectus should be the first among several documents listed electronically or delivered in a bundle. This approach has worked well in the mutual fund industry and can be expected to work equally well for variable contract disclosure,” while also stating “Imposing prominence requirements is unnecessary.”).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Hyperlinking of website Addresses in Electronic Versions of Summary Prospectus</HD>
                    <P>
                        Largely as proposed, we are also requiring any website address that is included in an electronic version of the summary prospectus (
                        <E T="03">i.e.,</E>
                         electronic versions sent to investors or available online) to be an active hyperlink.
                        <SU>480</SU>
                        <FTREF/>
                         This provision is intended to ensure that investors viewing electronic versions are able to easily access website addresses that are included in the summary prospectus.
                        <SU>481</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>480</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(4). In addition, a parallel requirement applies to statutory prospectuses. 
                            <E T="03">See</E>
                             General Instruction C.3.(i) to Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>481</SU>
                             A summary prospectus filed on EDGAR must not include a functioning link to an external location, as our rules prohibit hyperlinking to websites, locations, or other documents that are outside of the EDGAR system. 
                            <E T="03">See</E>
                             17 CFR 232.105 [rule 105 of Regulation S-T]. Because this is an existing EDGAR restriction, we do not believe it is necessary to add this provision to rule 498A. Thus, in a change from the proposal, rule 498A does not include this provision.
                        </P>
                    </FTNT>
                    <P>
                        One commenter stated that requiring active hyperlinks for website addresses referenced in electronic versions of the initial summary prospectus could be administratively burdensome because insurers would need to monitor to ensure the disclosed website locations were accurate and functioning.
                        <SU>482</SU>
                        <FTREF/>
                         The cover page of the initial summary prospectus must provide a website where investors can obtain the summary and statutory prospectuses (and certain other contract documents),
                        <SU>483</SU>
                        <FTREF/>
                         and the legend in the Appendix in the initial summary prospectus must include a website where investors can access the portfolio company prospectuses (and, if applicable, access updated performance information).
                        <SU>484</SU>
                        <FTREF/>
                         However, the rule and form requirements give registrants the 
                        <PRTPAGE P="26004"/>
                        flexibility to determine whether to provide the required information on the registrant's website, or a third party website. Because the availability of more detailed information is a key component to a layered disclosure approach, enabling access to that information is fundamental to the framework. We therefore believe it is reasonable, and not unduly burdensome, for a registrant to ensure that the website address it chooses to include in the electronic version of its summary prospectuses has an active link, and are adopting this aspect of the rule largely as proposed.
                        <SU>485</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>482</SU>
                             
                            <E T="03">See</E>
                             Ameritas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>483</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(2)(v)(B) (“The legend must provide a website address, other than the address of the Commission's electronic filing system . . . that investors can use to obtain the Statutory Prospectus and other materials . . . [t]he website address must be specific enough to lead investors directly to the Statutory Prospectus and other materials that are required to be accessible under paragraph (h)(1) of this section . . . [t]he website could be a central site with prominent links to each document.”); 
                            <E T="03">see also</E>
                             rule 498A(c)(3)(v) (parallel requirements); rule 498A(h)(1) (required online documents).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>484</SU>
                             
                            <E T="03">See</E>
                             General Instruction 1(d) to Item 18 of amended Form N-3; General Instructions 1(b) and (e) to Item 17 of Form N-4; General Instructions 1(b) and (e)(e) to Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>485</SU>
                             
                            <E T="03">See</E>
                             rule 498A(
                            <E T="03">i</E>
                            )(4).
                        </P>
                    </FTNT>
                    <P>
                        However, as discussed above, in response to comments we are modifying this requirement to allow registrants to provide another means of facilitating access through equivalent methods or technologies that lead directly to the relevant website address.
                        <SU>486</SU>
                        <FTREF/>
                         This change is intended to give registrants the flexibility to provide hyperlinks in a continually visible sidebar, or some equivalent means of facilitating access from the summary prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>486</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(4) (“[A]ny website address that is included in an electronic version of the Summary Prospectus must include an active hyperlink or provide another means of facilitating access through equivalent methods or technologies that lead directly to the relevant website address.”). 
                            <E T="03">See also supra</E>
                             note 205 and accompanying text.
                        </P>
                    </FTNT>
                      
                    <HD SOURCE="HD3">d. Hyperlinking of Cross-References in Electronic Versions of Summary Prospectus</HD>
                    <P>
                        Although we proposed that registrants provide hyperlinks for cross-references included in an electronic version of the summary prospectus,
                        <SU>487</SU>
                        <FTREF/>
                         we recognize that the summary prospectus could contain multiple cross-references to both internal disclosures as well as external documents, and implementing and maintaining active hyperlinks for those cross-references could be burdensome or in some cases infeasible (
                        <E T="03">e.g.,</E>
                         cross-references to individual external documents that are specific to each investor).
                        <SU>488</SU>
                        <FTREF/>
                         We also believe that hyperlinked cross-references may be largely unnecessary because rule 498A provides that the summary prospectus, statutory prospectus, and SAI must include links or otherwise permit persons accessing those documents to move directly back and forth between each section heading in a table of contents and the section of the document referenced in that topic heading, as well as between each section of the summary prospectus and any section of the statutory prospectus and SAI (or, alternately, have continuously visible links that allow persons accessing those documents to move directly back and forth between each section heading in a table of contents and the section of the document referenced in that topic heading).
                        <SU>489</SU>
                        <FTREF/>
                         Therefore, we are eliminating the proposed requirement, but we nonetheless encourage registrants to use hyperlinks and other tools to provide investors with means to more easily read and access information in electronic versions of documents relating to their contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>487</SU>
                             
                            <E T="03">Compare</E>
                             rule 498A(i)(4) as proposed (requiring hyperlinks for both website addresses and cross-references) 
                            <E T="03">with</E>
                             final rule 498A(i)(4) (requiring hyperlinks only for website addresses). 
                            <E T="03">See also</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, in the text accompanying notes 295 and 296 and General Instruction C.3.(
                            <E T="03">i</E>
                            ) to Forms N-3, N-4, and N-6 as proposed.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>488</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 4 of amended Forms N-3, N-4, and N-6 (cross-referencing the contract specifications page from each investor's contract).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>489</SU>
                             
                            <E T="03">See</E>
                             rule 498A(h)(2)(ii) and (iii).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">e. Failure To Comply With Other Requirements in Rule</HD>
                    <P>
                        Under the final rule, as proposed, the failure to comply with the “other requirements” in the new rule will not negate a person's ability to rely on the rule to satisfy a person's delivery obligations under Section 5(b)(2) of the Securities Act.
                        <SU>490</SU>
                        <FTREF/>
                         Commenters supported this approach, noting especially the potential for technological challenges to impact the ability of a person seeking to rely on the rule to comply with certain requirements.
                        <SU>491</SU>
                        <FTREF/>
                         One commenter also raised concerns regarding how compliance with certain requirements might be determined, and the potential subjectivity involved in that assessment.
                        <SU>492</SU>
                        <FTREF/>
                         We received no comments opposing or suggesting modifications to this aspect of the proposal and are adopting as proposed. Failure to comply with the “other requirements” in the rule will, however, constitute a violation of Commission rules.
                    </P>
                    <FTNT>
                        <P>
                            <SU>490</SU>
                             Rule 498A(i)(5). The final rule's requirements under paragraph (i)(3) that (1) the required online documents be presented in a format that is convenient for reading and printing, and (2) a person be able to retain electronic versions of these documents in a format that is convenient for reading and printing, also are not conditions to relying on the rule to satisfy prospectus delivery obligations. 
                            <E T="03">See supra</E>
                             notes 430 and 460 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>491</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter; Chemas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>492</SU>
                             
                            <E T="03">See</E>
                             Chemas Comment Letter (“How long could what is supposed to be an active hyperlink be a dead link before a registrant is deemed non-compliant with this proposed updated requirement?”); 
                            <E T="03">see also</E>
                             Proposing Release 
                            <E T="03">supra</E>
                             note 6, at n. 297 (similar comments regarding the “greater prominence” requirement in the proposed mutual fund summary prospectus rule). Consistent with the requirements of the safe harbor for electronic delivery in rule 498A(h), a registrant should update a dead hyperlink when it knows or reasonably should have known that the hyperlink is dead. 
                            <E T="03">See also supra</E>
                             notes 406 and 415.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">7. Incorporation by Reference</HD>
                    <HD SOURCE="HD3">a. Permissible Incorporation by Reference</HD>
                    <P>
                        The final rule, as proposed, permits a registrant to incorporate by reference into the summary prospectus information contained in the contract statutory prospectus and SAI, subject to certain conditions.
                        <SU>493</SU>
                        <FTREF/>
                         As discussed in the Proposing Release, we do not intend the variable contract summary prospectus to be a self-contained disclosure vehicle, but rather one element in a layered disclosure regime.
                        <SU>494</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>493</SU>
                             
                            <E T="03">See</E>
                             rule 498A(d)(2). We received no comments on this aspect of the proposal.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>494</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.300 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        Any information incorporated by reference must be separately made available to investors, either electronically or in paper. A Form N-3 registrant also could incorporate by reference into the summary prospectus information from its reports to shareholders that the registrant has incorporated by reference into its statutory prospectus.
                        <SU>495</SU>
                        <FTREF/>
                         Under the final rule, a registrant is not permitted to incorporate by reference into the summary prospectus information from any other source. Moreover, a registrant may not incorporate by reference any information that will be required to appear in the contents of the initial summary prospectus or the updating summary prospectus.
                        <SU>496</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>495</SU>
                             Rule 498A(d)(2) references rule 30e-1 under the Investment Company Act, which applies only to management companies (Form N-3 registrants). While rule 30e-2 under the Investment Company Act requires Form N-4 and Form N-6 registrants to transmit portfolio company annual and semi-annual shareholder reports to the investors in their trust accounts, these registrants do not incorporate by reference information from a portfolio company shareholder report into the contract prospectus. 
                            <E T="03">See</E>
                             CAI Comment Letter (stating that the underlying fund summary or statutory prospectus should not be incorporated by reference into the variable contract summary prospectus). Accordingly, the final rule does not reference rule 30e-2.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>496</SU>
                             
                            <E T="03">See</E>
                             rule 498A(d)(2)(ii); 
                            <E T="03">see also supra</E>
                             Sections II.A.1 (describing content requirements for the initial summary prospectus) and II.A.2 (describing content requirements for the updating summary prospectus).
                        </P>
                    </FTNT>
                    <P>
                        Information could be incorporated by reference into the summary prospectus only by reference to the specific document that contains the information, and not by reference to another document that incorporates the information by reference.
                        <SU>497</SU>
                        <FTREF/>
                         For example, if a contract statutory prospectus were to incorporate the 
                        <PRTPAGE P="26005"/>
                        contract SAI by reference, the summary prospectus could not incorporate information in the SAI simply by referencing the statutory prospectus but will be required to reference the SAI directly.
                        <SU>498</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>497</SU>
                             
                            <E T="03">See</E>
                             rule 498A(d)(2)(iii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>498</SU>
                             
                            <E T="03">Cf.</E>
                             rule 411(e) under the Securities Act (“[U]nless expressly permitted or required, disclosure must not be incorporated by reference from a second document if that second document incorporates information pertinent to such disclosure by reference to a third document.”). Rule 411 was recently amended as part of the 2019 FAST Act Modernization rulemaking adoption (which includes amendments to the Commission's rules on incorporation by reference). 
                            <E T="03">See</E>
                             FAST Act Modernization and Simplification of Regulation S-K, Securities Act Release No. 10618 (Mar. 20, 2019) [84 FR 12674 (Apr. 2, 2019)] (“FAST Act Adopting Release”). General Instruction D.1 to amended Forms N-3, N-4, and N-6 makes rule 411 applicable to incorporation by reference for a variable contract's statutory prospectus.
                        </P>
                    </FTNT>
                    <P>
                        Incorporation by reference is permissible only if the registrant satisfies the rule's conditions that prescribe the means by which the required online contract documents must be made available to investors.
                        <SU>499</SU>
                        <FTREF/>
                         In addition, if a registrant incorporates information by reference into a summary prospectus, the summary prospectus legend must specify the type of document (
                        <E T="03">e.g.,</E>
                         statutory prospectus) that contains the incorporated information and the date of the document.
                        <SU>500</SU>
                        <FTREF/>
                         If a registrant incorporates a part of a document by reference into the summary prospectus, the summary prospectus legend must clearly identify the part by page, paragraph, caption, or otherwise.
                        <SU>501</SU>
                        <FTREF/>
                         The legend must also explain that the incorporated information may be obtained, free of charge, in the same manner as the contract statutory prospectus.
                        <SU>502</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>499</SU>
                             
                            <E T="03">See</E>
                             rule 498A(d)(2)(i) (referencing rule 498A(h), among other paragraphs in the final rule); 
                            <E T="03">see also supra</E>
                             Section II.A.5.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>500</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(3)(i) and 498A(c)(4).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>501</SU>
                             
                            <E T="03">Id.</E>
                             This requirement mirrors the requirements of rule 498(b)(1)(v)(B), and is similar to the requirements of rule 411(e) under the Securities Act, which states that a document that incorporates information by reference must “include an express statement clearly describing the specific location of the information you are incorporating by reference. The statement must identify the document where the information was originally filed or submitted and the location of the information within that document.”
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>502</SU>
                             
                            <E T="03">Id.; see also supra</E>
                             discussion in Section II.A.5 and 6.
                        </P>
                    </FTNT>
                    <P>
                        The conditions on the availability of information that is incorporated by reference into the contract summary prospectus, and on identifying the information that is incorporated by reference, are intended to facilitate access to this information. Parallel conditions exist in the rule governing mutual fund summary prospectuses. Based on our experience, we believe that investors have found this approach to be useful. Therefore, the final rule includes similar conditions for incorporation by reference for variable contract summary prospectuses.
                        <SU>503</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>503</SU>
                             
                            <E T="03">See supra</E>
                             note 494 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        A registrant that fails to comply with any of the above conditions is not permitted to incorporate information by reference into its summary prospectus. A registrant that does comply with these conditions, however, including the conditions for providing the documents that include the incorporated information online, is also not required to send or give the incorporated information to investors together with the summary prospectus.
                        <SU>504</SU>
                        <FTREF/>
                         The contract summary prospectus, together with information incorporated therein by reference, would be subject to liability under Sections 12(a)(2) and 17(a)(2) of the Securities Act.
                    </P>
                    <FTNT>
                        <P>
                            <SU>504</SU>
                             Rule 498A(d)(1).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Effect of Incorporation by Reference</HD>
                    <P>
                        Title 17 CFR 230.159 (rule 159 under the Securities Act) provides that any information “conveyed” to a purchaser after the time of sale will not be taken into account, for purposes of determining whether a prospectus or oral statement included an untrue statement of material fact at the time of sale for purposes of Sections 12(a)(2) and 17(a)(2) of the Act.
                        <SU>505</SU>
                        <FTREF/>
                         As proposed, the final rule provides that, for purposes of rule 159, information is conveyed to a person not later than the time the person receives a summary prospectus, if that information is incorporated by reference into the summary prospectus in accordance with the rule's conditions.
                        <SU>506</SU>
                        <FTREF/>
                         This addresses the question of when information that is incorporated by reference into the contract summary prospectus is conveyed for purposes of liability under Sections 12(a)(2) and 17(a)(2) of the Securities Act.
                        <SU>507</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>505</SU>
                             
                            <E T="03">See</E>
                             rule 159 under the Securities Act.
                        </P>
                        <P> Under Section 12(a)(2) of the Securities Act, sellers have liability to purchasers for offers or sales by means of a prospectus or oral communication that includes an untrue statement of material fact or omits to state a material fact that makes the statements made, based on the circumstances under which they were made, not misleading. Section 17(a)(2) of the Securities Act is a general antifraud provision, which makes it unlawful for any person in the offer and sale of a security to obtain money or property by means of any untrue statement of a material fact or any omission to state a material fact necessary in order to make the statements made, in light of the circumstances under which they were made, not misleading.</P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>506</SU>
                             Rule 498A(d)(3).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>507</SU>
                             
                            <E T="03">See</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17, at nn.109 and 110 (discussing further considerations of liability under Sections 12(a)(2) and 17(a)(2) of the Securities Act, as well as reliance under Section 19(a) of the Securities Act). 
                            <E T="03">See also infra</E>
                             note 571 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">8. Filing Requirements for the Summary Prospectus</HD>
                    <HD SOURCE="HD3">a. Form of Summary Prospectus</HD>
                    <P>
                        Under the final rule and as proposed, registrants must file as an exhibit to the registration statement any form of any initial summary prospectus the registrant intends to use on or after the effective date of the registration statement. Registrants are only required to file the form of initial summary prospectus exhibit with an initial registration statement or with a pre-effective amendment or a post-effective amendment filed in accordance with paragraph (a) of rule 485 under the Securities Act. In a change from the proposal, however, registrants are not required to file any form of updating summary prospectus.
                        <SU>508</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>508</SU>
                             
                            <E T="03">See</E>
                             Item 32(r) of amended Form N-3; Item 26(o) of amended Form N-4; Item 29(r) of amended Form N-6. In modifying the proposed exhibit requirement, we revised the exhibit heading, replacing “Preliminary Summary Prospectuses” with “Form of Initial Summary Prospectus.”
                        </P>
                    </FTNT>
                    <P>
                        Commenters objected to filing a preliminary summary prospectus for each contract as unduly burdensome and time consuming for issuers to prepare and file and Commission staff to review, and instead recommended that insurers be permitted to file a “form of” or “template” summary prospectus under rule 485(a) for contracts that are substantially similar, or that the registrant asserts is meaningfully representative of similar contracts pursuant to rule 485(b)(1)(vii).
                        <SU>509</SU>
                        <FTREF/>
                         In support of this request, one commenter asserted that staff review of the “template” or representative summary prospectus would provide adequate protection for investors, while relieving burdens on issuers and Commission staff.
                        <SU>510</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>509</SU>
                             
                            <E T="03">See</E>
                             Lincoln Comment Letter; Brighthouse Comment Letter; Transamerica Comment Letter; ACLI Comment Letter. 
                            <E T="03">See also</E>
                             Section II.C.4.b.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>510</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter; 
                            <E T="03">see also</E>
                             CAI Comment Letter, Brighthouse Comment Letter (seeking clarification regarding whether and how template and selective review might apply to summary prospectuses).
                        </P>
                    </FTNT>
                    <P>
                        We believe that it is important that Commission staff have the opportunity to review a variable contract's summary prospectus for compliance with the rule and the relevant form requirements prior to its first use. The approach for variable contract summary prospectus differs from that of mutual fund summary prospectuses, where the Commission did not require such a filing because the content of that summary prospectus is essentially identical to the content of the summary section of the statutory prospectus, 
                        <PRTPAGE P="26006"/>
                        which is filed prior to its first use.
                        <SU>511</SU>
                        <FTREF/>
                         In contrast, while some variable contract summary prospectus disclosures will be identical to those in the statutory prospectus,
                        <SU>512</SU>
                        <FTREF/>
                         others will include only part of the information required in the statutory prospectus.
                        <SU>513</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>511</SU>
                             
                            <E T="03">See</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17, at n.73. The contents of a mutual fund summary prospectus consist of the information required or permitted by Items 2-8 of Form N-1A, which constitutes the summary section of the statutory prospectus. 
                            <E T="03">See</E>
                             rule 498(b)(2).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>512</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Items 2 and 3 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>513</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 10(a) of amended Form N-6; Items 11(a), 10(a), and 11(a) of Forms N-3; N-4, and N-6, respectively. (“Death Benefits” for amended Form N-6, and “[Other] Benefits Available Under the Contract” for amended Forms N-3, N-4, and N-6.). While only certain information in the statutory prospectus is required to be included in the summary prospectus, rule 498A permits the summary prospectus to incorporate by reference some or all of the information contained in the statutory prospectus or SAI. 
                            <E T="03">See supra</E>
                             Section II.A.7.
                        </P>
                    </FTNT>
                    <P>
                        For example, the final rule requires an initial summary prospectus only to describe the features and options of the contract that the registrant currently offers,
                        <SU>514</SU>
                        <FTREF/>
                         while the statutory prospectus (and updating summary prospectus) 
                        <SU>515</SU>
                        <FTREF/>
                         could include information regarding contracts that the registrant no longer sells to new investors. The initial and updating summary prospectuses will also present certain information in a different order than might appear in the contract statutory prospectus.
                        <SU>516</SU>
                        <FTREF/>
                         Furthermore, certain disclosure requirements differ depending on whether the summary prospectus is an initial summary prospectus or an updating summary prospectus. We do not believe that registrants would need to visually identify or otherwise segregate those portions of the statutory prospectus that are also summary prospectus disclosures, and we recognize that doing so could impede the effective presentation of information in a contract statutory prospectus to investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>514</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(1).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>515</SU>
                             
                            <E T="03">See</E>
                             rule 498A(c)(2) (updating summary prospectus).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>516</SU>
                             For example, in the initial summary prospectus, the Fee Table is located towards the end of the prospectus, with more summary type of fee information provided earlier in the summary prospectus as part of the Key Information Table. In contrast, the Fee Table in the statutory prospectus is closer to the front of the document, where it has been traditionally located.
                        </P>
                    </FTNT>
                    <P>For these reasons, we continue to believe it is important for the staff to review the form of initial summary prospectus. However, in response to commenter concerns, we note that nothing in the amended forms or the summary prospectus framework generally precludes the use of “form of” or “template” review pursuant to rule 485(b)(1)(vii). Thus, registrants are permitted to seek such staff review in appropriate circumstances.</P>
                    <P>
                        On the other hand, the updating summary prospectus will contain the Key Information Table and Appendix that will be in the statutory prospectus. Moreover, while the updating summary prospectus will also contain a brief summary of specified changes to the statutory prospectus (which we anticipate to typically be limited since variable contracts tend not to change their contract features very often), any material changes should be reflected in a post-effective amendment filing under rule 485(a), which will be marked to indicate such changes and subject to staff review.
                        <SU>517</SU>
                        <FTREF/>
                         Because the information contained in the updating summary prospectus will mirror information contained in the statutory prospectus, we do not believe the staff needs to separately review a form of updating summary prospectus prior to first use. Therefore, to relieve burdens on registrants, we are not requiring it as an exhibit to the registration statement.
                    </P>
                    <FTNT>
                        <P>
                            <SU>517</SU>
                             
                            <E T="03">See</E>
                             17 CFR 232.301 (rule 301 of Regulation S-T). Changes may also be indicated in blacklined versions the registration statement that registrants or their counsel commonly supply to the staff as courtesy copies.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Definitive Form of Summary Prospectus</HD>
                    <P>
                        In addition to requiring registrants to file a form of initial summary prospectus with the Commission prior to use, we are, as proposed, amending rule 497 under the Securities Act to require a registrant to file a definitive form of summary prospectus—whether an initial summary prospectus or an updating summary prospectus—after it is first used.
                        <SU>518</SU>
                        <FTREF/>
                         This will ensure that the Commission receives a copy of every summary prospectus in use.
                        <SU>519</SU>
                        <FTREF/>
                         This is consistent with the filing requirement for mutual fund summary prospectuses under rule 497.
                        <SU>520</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>518</SU>
                             Rule 497(k).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>519</SU>
                             A summary prospectus filed with the Commission will be publicly available; however, a registrant could not rely on this availability to satisfy the requirements to post the document online. 
                            <E T="03">See supra</E>
                             Section II.A.5.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>520</SU>
                             S
                            <E T="03">ee</E>
                             rule 497(k).
                        </P>
                    </FTNT>
                    <P>
                        To allow investors and staff to more easily locate an initial summary prospectus or updating summary prospectus when searching on EDGAR, one commenter asked that we consider whether initial and updating summary prospectuses should be filed under differentiating form type designations (though noting that separate filing designations could cause filing errors).
                        <SU>521</SU>
                        <FTREF/>
                         We agree and anticipate having different EDGAR submission types for initial and updating summary prospectus. Notice of EDGAR system readiness to accept summary prospectuses using differentiated filing types will be provided in a manner similar to notices of taxonomy updates and EDGAR Filer Manual updates. Until then, registrants may file definitive forms of summary prospectuses using submission type 497H2.
                    </P>
                    <FTNT>
                        <P>
                            <SU>521</SU>
                             
                            <E T="03">See</E>
                             IRI Comment Letter I; Comment Letter of the Insured Retirement Institute (Nov. 6, 2019) (“IRI Comment Letter II”).
                        </P>
                    </FTNT>
                    <P>
                        Another commenter asked us to amend rule 497 so insurers could customize and make prospectuses more interactive without having to file every variation on EDGAR.
                        <SU>522</SU>
                        <FTREF/>
                         While we support the goal of making prospectuses more interactive, as with statutory prospectuses, it is important for investor protection purposes that our staff is able to review every form of summary prospectus that is used.
                        <SU>523</SU>
                        <FTREF/>
                         Accordingly, we are not modifying rule 497 as this commenter suggests.
                    </P>
                    <FTNT>
                        <P>
                            <SU>522</SU>
                             
                            <E T="03">See</E>
                             Anonymous Comment Letter III.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>523</SU>
                             As noted above, however, we believe that only the initial summary prospectus needs to be filed prior to use. 
                            <E T="03">See supra</E>
                             text surrounding note 517.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Investor Protection and Liability Under Section 11 of the Securities Act</HD>
                    <P>
                        Section 10(b) of the Securities Act provides that a prospectus permitted under that section must, unless Commission rules provide otherwise, be filed as part of the registration statement but would not be deemed a part of the registration statement for purposes of Section 11 of the Securities Act.
                        <SU>524</SU>
                        <FTREF/>
                         Accordingly, as discussed in the proposal, a summary prospectus that is filed as part of the registration statement (
                        <E T="03">e.g.,</E>
                         as an exhibit or otherwise) would not be deemed a part of the registration statement for purposes of Section 11 of the Securities Act.
                        <SU>525</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>524</SU>
                             15 U.S.C. 77j(b) and 77k. Under Section 11 of the Securities Act [15 U.S.C. 77k], purchasers of an issuer's securities have private rights of action for untrue statements of material facts or omissions of material facts required to be included in the registration statement or necessary to make the statements in the registration statement not misleading. Congress provided a specific exception from liability under Section 11 for summary prospectuses under Section 10(b) of the Securities Act in order to encourage the use of summary prospectuses. L. Loss &amp; J. Seligman, Securities Regulation, section 2-b-5 (3d ed. 2006) (citing S. Rep. 1036, 83d Cong., 2d Sess. 17-18 (1954) and H.R. Rep. 1542, 83d Cong., 2d Sess. 26 (1954)).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>525</SU>
                             Section 10(b) of the Securities Act (“A prospectus permitted under this subsection shall, except to the extent the Commission by rules or regulations deems necessary or appropriate in the public interest or for the protection of investors otherwise provides, be filed as part of the registration statement but shall not be deemed a part of such registration statement for purposes of Section 11.”).
                        </P>
                    </FTNT>
                    <PRTPAGE P="26007"/>
                    <P>
                        Some commenters in connection with the mutual fund summary prospectus proposal expressed concerns that the mutual fund summary prospectus would not be subject to Section 11 liability, suggesting that this would result in a diminution of funds' liability under that section.
                        <SU>526</SU>
                        <FTREF/>
                         The Commission stated in response that while Section 11 prescribes that the mutual fund summary prospectus will not itself be deemed a part of the registration statement for purposes of Section 11, all of the information in the summary prospectus will be subject to liability under Section 11, either because the information is the same as information contained in the statutory prospectus or because the information is incorporated by reference from the registration statement.
                        <SU>527</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>526</SU>
                             
                            <E T="03">See</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17, at n.344 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>527</SU>
                             The Commission noted that: (1) The final rule required the information contained in a summary prospectus that is used to satisfy prospectus delivery obligations must be the same as the information contained in the summary section of the fund's statutory prospectus; and (2) information may be incorporated by reference into a summary prospectus only if it is contained in the fund's statutory prospectus, SAI, or has been incorporated into the statutory prospectus from the shareholder report. 
                            <E T="03">Id.</E>
                             at nn.111 and 112; 
                            <E T="03">see also</E>
                             rules 498(f)(4) and 498(b)(3).
                        </P>
                    </FTNT>
                    <P>
                        For similar reasons, it is our view that while a variable contract summary prospectus under the final rule will not itself be deemed a part of the registration statement for purposes of Section 11, the information in the summary prospectus will generally be subject to liability under Section 11. While rule 498A does not have a comparable provision to the one in rule 498 requiring that the information in the summary prospectus must be the same as in the statutory prospectus, we believe that the substance of the information itself would be the same, even though the language in both documents relating to the information may not be identical. For example, the language of the initial summary prospectus could differ from the language used in the statutory prospectus because rule 498A requires that the initial summary prospectus may only describe a single contract that the registrant currently offers for sale, whereas we understand that certain contract statutory prospectuses include disclosure about contract features and options that the registrant may no longer offer to new investors. Nevertheless, the substance of the information for any currently offered features and options will be the same.
                        <SU>528</SU>
                        <FTREF/>
                         In addition, rule 498A includes the same provisions regarding information permitted to be incorporated into the summary prospectus as those in rule 498.
                        <SU>529</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>528</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.1.b.
                        </P>
                        <P>
                            The updating summary prospectus could include information that does not appear in the related contract statutory prospectus if the updating summary prospectus discloses changes to the contract that the issuer has made after the most recent updating summary prospectus or statutory prospectus was sent or given to investors. 
                            <E T="03">See supra</E>
                             Section II.A.2.c.ii.(a); 
                            <E T="03">see also</E>
                             rule 498A(c)(6)(i) and (ii). This information that only appears in the updating summary prospectus therefore would not be deemed a part of the registration statement for purposes of Section 11 of the Securities Act.
                        </P>
                        <P>For example, if a particular fee has changed from x% to y%, while the disclosure of the current fee rate (y%) would appear in both the updating summary prospectus and the related statutory prospectus, the earlier fee rate (x%) and the fact that the fee was changed would likely not be disclosed in the statutory prospectus.</P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>529</SU>
                             
                            <E T="03">See</E>
                             rule 498A(d); 
                            <E T="03">see also</E>
                             rule 498(b)(3) (parallel provisions in the rule governing the use of mutual fund summary prospectuses).
                        </P>
                    </FTNT>
                    <P>
                        As discussed in the Proposing Release, the summary prospectus also would be subject to other liability and antifraud provisions of the federal securities laws.
                        <SU>530</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>530</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at nn.329-332 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">9. Defined Terms in Final Rule</HD>
                    <P>
                        We are adopting, substantially as proposed, a section of definitions for certain terms used throughout new rule 498A.
                        <SU>531</SU>
                        <FTREF/>
                         These definitions generally: (1) Identify specific prospectuses described in the proposed rule (
                        <E T="03">e.g.,</E>
                         “initial summary prospectus”); (2) mirror the existing definitions used in Forms N-3, N-4, and N-6 (
                        <E T="03">e.g.,</E>
                         “variable annuity contract” as used in Forms N-3 and N-4) or other rules (
                        <E T="03">e.g.,</E>
                         “statement of additional information” as used in rule 498); or (3) combine other defined terms in the rule (
                        <E T="03">e.g.,</E>
                         “summary prospectus”).
                        <SU>532</SU>
                        <FTREF/>
                         We received no comments regarding these terms.
                    </P>
                    <FTNT>
                        <P>
                            <SU>531</SU>
                             Rule 498A(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>532</SU>
                             Although proposed, we are not including in the final rule a definition for “prospectus supplement” because the term is not used elsewhere in the final rule. 
                            <E T="03">See</E>
                             proposed rule 498A(a)(8). This is the only change from the proposal regarding the rule's defined terms.
                        </P>
                    </FTNT>
                    <P>
                        In recognition that today a variable contract may offer classes with the same currently available features and options but different pricing structures, the Commission proposed to define “class” to mean a class of a contract that varies principally with respect to distribution-related fees and expenses.
                        <SU>533</SU>
                        <FTREF/>
                         While we received comments suggesting we broaden the definition of “class,” 
                        <SU>534</SU>
                        <FTREF/>
                         we are adopting the definition as proposed, which we believe has an appropriate scope.
                        <SU>535</SU>
                        <FTREF/>
                         We believe that investors value the ability to understand which fees apply to the products that they purchase, and defining “class” in relation to the fees charged ensures that investors will receive a level of granularity to the fees disclosed such that they should be better able to make an informed investment decision.
                        <SU>536</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>533</SU>
                             We understand that this is how the term is commonly used in industry practice. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at note 334.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>534</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (a variable contract can and “frequently does have “classes” that differ in ways other than distribution-related fees and expenses . . . [t]hus, the concepts of classes with respect to mutual funds and classes with respect to variable products do not necessarily correspond. Indeed, with respect to variable products, the term “class” is often used interchangeably with “versions”); 
                            <E T="03">see also</E>
                             ACLI Comment Letter (“While we do not suggest any specific additions or exclusions to the defined terms, we note that flexibility should be provided to permit a registrant's use of alternative terms used by the company in its contracts that reflect the substance of the defined terms in the proposal”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>535</SU>
                             
                            <E T="03">See also</E>
                             rule 498A(a) and 17 CFR 270.18f-3 (rule 18f-3) (permitting registered investment companies to issue multiple classes of voting stock); Part A (“Definitions”) of the General Instructions to Form N-1A (defining “class” as “a class of shares issued by a Multiple Class Fund that represents interests in the same portfolio of securities under rule 18f-3 [17 CFR 270.18f-3] or under an order exempting the Multiple Class Fund from Sections 18(f), 18(g), and 18(i) [15 U.S.C. 80a-18(f), 18(g), and 18(i)]”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>536</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 4 of Form N-4 (requiring separate responses for each Class regarding the Example in the Fee Table).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">B. Optional Method To Satisfy Portfolio Company Prospectus Delivery Requirements</HD>
                    <HD SOURCE="HD3">1. Current Delivery Practices for Portfolio Company Prospectuses</HD>
                    <P>
                        As discussed in greater detail in the Proposing Release, we understand that summary prospectuses, as opposed to statutory prospectuses, are typically delivered to investors for all the underlying portfolio companies offered under the contract.
                        <SU>537</SU>
                        <FTREF/>
                         As with contract prospectuses, portfolio company prospectuses may be delivered electronically pursuant to the Commission's guidance.
                    </P>
                    <FTNT>
                        <P>
                            <SU>537</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.B.1 (stating that, typically, prospectuses for all underlying portfolio companies are delivered to investors to avoid the administrative burden of tracking whether an investor has already received the current prospectus).
                        </P>
                    </FTNT>
                    <P>
                        Delivery of prospectuses for underlying portfolio companies is typically effected by the insurance company rather than the portfolio company. Based on a staff review of participation agreements between insurance companies and underlying portfolio companies, we understand that there is diversity in practice as to whether the insurance company or portfolio company bears the printing and mailing costs associated with portfolio company prospectus deliveries.
                        <PRTPAGE P="26008"/>
                    </P>
                    <HD SOURCE="HD3">2. New Option To Satisfy Prospectus Delivery Requirements</HD>
                    <HD SOURCE="HD3">a. Overview</HD>
                    <P>
                        As proposed, new rule 498A provides an optional method for satisfying portfolio company prospectus delivery obligations under section 5(b)(2) of the Securities Act by making portfolio company summary and statutory prospectuses available online, with certain key information about the portfolio companies provided in the contract's summary prospectus.
                        <SU>538</SU>
                        <FTREF/>
                         This new option is available to Form N-4 and Form N-6 registrants, but is not available to Form N-3 registrants because they do not have underlying portfolio companies.
                    </P>
                    <FTNT>
                        <P>
                            <SU>538</SU>
                             Rule 498A(j). In a conforming change, we have revised the language in rule 498A(j)(1) regarding prospectus delivery obligations to more closely track the language in Section 5(b)(2) of the Securities Act.
                        </P>
                    </FTNT>
                    <P>
                        This option allows satisfaction of prospectus delivery obligations with respect to a portfolio company, if: (1) An initial summary prospectus is used for each currently offered contract described under the related registration statement; 
                        <SU>539</SU>
                        <FTREF/>
                         (2) a summary prospectus is used for the portfolio company (only if the portfolio company is registered on Form N-1A); 
                        <SU>540</SU>
                        <FTREF/>
                         and (3) the portfolio company's current summary prospectus, statutory prospectus, SAI, and most recent shareholder reports are posted online under similar posting requirements for the variable contract's summary prospectuses and other documents.
                        <SU>541</SU>
                        <FTREF/>
                         In addition, the rule provides that any communication related to a portfolio company, other than a prospectus permitted or required under Section 10 of the Securities Act, would not be deemed a prospectus if the above conditions are satisfied.
                        <SU>542</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>539</SU>
                             Rule 498A(j)(1)(i).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>540</SU>
                             Rule 498A(j)(1)(ii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>541</SU>
                             Rule 498A(j)(1)(iii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>542</SU>
                             Rule 498A(j)(2).
                        </P>
                    </FTNT>
                    <P>
                        Many commenters agreed that the proposed delivery option for underlying portfolio company prospectuses would produce cost savings for funds and shareholders and directly align with shareholder preferences for accessing fund information online.
                        <SU>543</SU>
                        <FTREF/>
                         Commenters also stated that the proposed delivery option would meaningfully improve the experience of investors by allowing them to navigate funds' prospectus disclosures in a manner responsive to their needs and financial sophistication.
                        <SU>544</SU>
                        <FTREF/>
                         One commenter agreed with the optional nature of the proposed delivery option, stating that it would provide registrants time to build the process out for the delivery option.
                        <SU>545</SU>
                        <FTREF/>
                         This commenter further agreed that a communication relating to a portfolio company should not be deemed a prospectus if the conditions of rule 498A were satisfied.
                    </P>
                    <FTNT>
                        <P>
                            <SU>543</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter; Comment Letter of the Independent Directors Council (Feb. 15, 2019); WFA Comment Letter; Comment Letter of TIAA (Feb. 15, 2019).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>544</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter; Capital Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>545</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        However, one commenter opposed the proposed delivery option on the grounds that investors who choose to receive their disclosures in paper are unlikely to seek out portfolio company prospectuses.
                        <SU>546</SU>
                        <FTREF/>
                         The commenter noted, for example, that only a small percentage of variable annuity investors have chosen to receive disclosures electronically. Other commenters did not express either agreement or disagreement with the proposed delivery option, but requested clarity regarding the purpose and mechanics of this option.
                        <SU>547</SU>
                        <FTREF/>
                         As noted below, the purpose of this option is to help reduce the volume of documents investors receive that may prevent effective disclosure. Under the layered disclosure framework we are adopting in this document, summary information as to the portfolio companies will be provided in the Appendix and more fulsome information available to investors online or on request.
                    </P>
                    <FTNT>
                        <P>
                            <SU>546</SU>
                             
                            <E T="03">See</E>
                             CFA Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>547</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Anonymous Comment Letter III (questioning why the Commission had proposed the optional delivery method); VIP Working Group (asking whether a filing on Form N-14 could incorporate by reference a portfolio company prospectus that is delivered pursuant to the optional delivery method). 
                            <E T="03">See supra</E>
                             Section II.B.2.d (discussing the delivery of portfolio company prospectuses in connection with Form N-14).
                        </P>
                    </FTNT>
                    <P>
                        We are concerned that the volume of disclosure materials variable contract investors currently receive may discourage them from reading the materials or prevent them from fully understanding these products. While the new variable contract summary prospectus framework is intended to provide investors with key information relating to the contract's terms, benefits, and risks in a concise and more reader-friendly format, we are concerned that investors may not read or understand information if the variable contract summary prospectus is accompanied by hundreds of pages of underlying portfolio company prospectuses.
                        <SU>548</SU>
                        <FTREF/>
                         We also note that, to the extent that an investor wants additional information regarding a portfolio company beyond that provided in the Appendix and cannot or chooses not to view that information online, the final rule provides that an investor may always request paper or electronic copies of these documents be sent to them at no charge to them.
                        <SU>549</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>548</SU>
                             Variable annuity contracts offer an average of 60 portfolio companies as investment options. 
                            <E T="03">See supra</E>
                             note 16. While we intended mutual fund summary prospectuses to be three to four pages in length, rule 498 does not provide page length or similar restrictions and some summary prospectuses have been as long as 19 pages. 
                            <E T="03">See</E>
                             Request for Comment on Fund Retail Investor Experience and Disclosure, Investment Company Act Release No. 33113 (June 5, 2018) [83 FR 26891 (June 11, 2018)] (“Request for Comment on Fund Retail Investor Experience”), at n.27 and accompanying text. If we conservatively estimate that each portfolio company summary prospectus is four pages in length, an investor who purchases a variable contract that offers 60 portfolio companies would receive 240 pages of portfolio company disclosure materials, in addition to the contract prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>549</SU>
                             Rule 498A(j)(3) and (
                            <E T="03">i</E>
                            )(1).
                        </P>
                    </FTNT>
                    <P>
                        To address this issue, the new option for satisfying portfolio company prospectus delivery requirements provides investors with certain key summary information about underlying portfolio companies in an Appendix to the contract summary prospectus.
                        <SU>550</SU>
                        <FTREF/>
                         This information is formatted in a tabular presentation to facilitate the ability of investors to compare key information relating to those portfolio companies.
                        <SU>551</SU>
                        <FTREF/>
                         If an investor desires more detailed information about a particular portfolio company, prospectuses and other documents relating to the portfolio company will be available online and in paper or electronically upon request.
                    </P>
                    <FTNT>
                        <P>
                            <SU>550</SU>
                             A contract summary prospectus will include an Appendix that will provide for each portfolio company its name, type or investment objective, adviser and subadviser, expense information, and average annual returns for the past year, five years, and ten years. 
                            <E T="03">See supra</E>
                             discussion at Section II.A.1.c.ii.(i); 
                            <E T="03">see also infra</E>
                             Section II.C.2.t (discussing inclusion of this Appendix also in variable contracts' statutory prospectuses). Registrants on Form N-3, who will not be relying upon this optional method to satisfy portfolio company prospectus delivery obligations, will have the option of omitting the Appendix from the summary prospectus and instead providing more detailed disclosures for the investment options offered under the contract that will be required by new Item 19 of Form N-3. 
                            <E T="03">See supra</E>
                             note 331 and accompanying text.
                        </P>
                        <P>
                             In addition, each summary prospectus will also include a Key Information Table that will provide certain disclosures about portfolio company risks and investment restrictions. 
                            <E T="03">See supra</E>
                             discussion at Section II.A.1.c.ii.(a); 
                            <E T="03">see also infra</E>
                             Section II.C.2.b (discussing the Key Information Table in amended Forms N-3, N-4, and N-6).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>551</SU>
                             
                            <E T="03">See supra</E>
                             note 267.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Conditions</HD>
                    <P>
                        As a condition to relying on the new option, as proposed, we are requiring that the related variable contract use an initial summary prospectus for each 
                        <PRTPAGE P="26009"/>
                        currently offered contract described under the related registration statement.
                        <SU>552</SU>
                        <FTREF/>
                         One commenter stated that eliminating this condition would “provide enhanced readable consumer disclosure” by “reducing the totality of the [paper] documentation that consumers must confront” even when the registrant is not using a summary prospectus.
                        <SU>553</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>552</SU>
                             Rule 498A(j)(1)(i).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>553</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <P>We disagree. We continue to believe that this condition is an important part of the layered disclosure framework that we are establishing in this document. This requirement is designed to encourage registrants to utilize the summary prospectus framework and provide a more consistent disclosure experience to investors, and reinforces the parallel requirement by tying the use of an updating summary prospectus to the condition that an initial summary prospectus be used for each currently offered contract. Together, we expect that these requirements will provide significant incentives for registrants to embrace the new summary prospectus framework and will further the adoption of the new framework for the mutual benefit of investors and registrants. Therefore, we are requiring a variable contract to use an initial summary prospectus for each currently offered contract described under the related registration in order to rely upon the optional delivery method.</P>
                    <P>
                        As a second condition, as proposed, a portfolio company that is registered on Form N-1A must use a summary prospectus.
                        <SU>554</SU>
                        <FTREF/>
                         Several commenters suggested that registrants should be able to use the optional method for delivering portfolio company prospectuses in order to reduce costs and provide consistent disclosures of portfolio company information even when portfolio company summary prospectuses are not available.
                        <SU>555</SU>
                        <FTREF/>
                         Commenters also stated that not all portfolio companies currently use summary prospectuses, and concluded that the ability of insurers to rely on the optional delivery method rests at the mercy of those portfolio companies.
                        <SU>556</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>554</SU>
                             Rule 498A(j)(1)(ii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>555</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Transamerica Comment Letter; ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>556</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; ACLI Comment Letter. As discussed above, we estimate approximately 93% of mutual funds and ETFs use summary prospectuses. 
                            <E T="03">See supra</E>
                             note 21.
                        </P>
                    </FTNT>
                    <P>
                        Absent this requirement, we believe that portfolio companies may be disinclined to use summary prospectuses,
                        <SU>557</SU>
                        <FTREF/>
                         potentially resulting in investors having to obtain information as to a particular portfolio company by reviewing a lengthy statutory prospectus offering multiple funds. We anticipate that this condition could further increase the likelihood that portfolio companies will use summary prospectuses, which will provide investors with summary information about portfolio companies that we believe they are more likely to use and understand.
                    </P>
                    <FTNT>
                        <P>
                            <SU>557</SU>
                             Portfolio companies today are incentivized to use summary prospectuses because of the cost savings associated with printing and mailing summary prospectuses as opposed to lengthier statutory prospectuses.
                        </P>
                    </FTNT>
                    <P>
                        We also note that use of the delivery option is not contingent on every portfolio company offered as an investment option under the contract using a summary prospectus. Rather, the delivery option is available on a portfolio company by portfolio company basis so an insurer will only be ineligible to use the delivery option as to those portfolio companies that do not use a summary prospectus. Thus, an insurer could use the delivery option to satisfy delivery obligations as to those portfolio companies using summary prospectuses, and continue to mail statutory prospectuses for those portfolio companies that do not use summary prospectuses as under current practice. Regardless of the method used to satisfy prospectus delivery obligations as to a given portfolio company, all portfolio companies offered under a variable contract shall be included in the Appendix.
                        <SU>558</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>558</SU>
                             
                            <E T="03">See generally supra</E>
                             note 551.
                        </P>
                    </FTNT>
                    <P>Finally, as a third condition to rely on the delivery option, as proposed, the portfolio company's current summary and statutory prospectus, SAI, and most recent annual and semi-annual shareholder reports (together, the “required online portfolio company documents”) must be posted online under similar conditions for the posting of required online contract documents:</P>
                    <P>
                        • The required online portfolio company documents are publicly accessible, free of charge, at the website address specified on the cover page or beginning of the summary prospectuses for the variable contract, for the time period specified in rule 498A(h)(1); 
                        <SU>559</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>559</SU>
                             Rule 498A(j)(1)(iii).
                        </P>
                    </FTNT>
                    <P>
                        • The required online portfolio company documents are presented on the website in a format, or formats, that are human-readable and capable of being printed on paper in human-readable format,
                        <SU>560</SU>
                        <FTREF/>
                         and permit persons accessing the documents to move directly back and forth between each section heading in a table of contents and the corresponding section of the document; 
                        <SU>561</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>560</SU>
                             Rule 498A(h)(2)(i); rule 498A(j)(1)(iii). In addition, as proposed, the documents must be presented on the website in a format or formats that are convenient for reading online and printing on paper. Rule 498A(i)(3)(i); rule 498A(j)(1)(iii).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>561</SU>
                             Rule 498A(h)(2)(ii).
                        </P>
                    </FTNT>
                    <P>
                        • Persons accessing the required online portfolio company documents must be able to permanently retain, free of charge, an electronic version of such documents in a format, or formats, that is human-readable and permits persons accessing the materials to move directly back and forth between each section heading in a table of contents and the corresponding section of the document; 
                        <SU>562</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>562</SU>
                             Rule 498A(j)(1)(iii); rule 498A(h)(3). In addition, as proposed, persons must be able to permanently retain these documents in a format or formats that are convenient for reading online and printing on paper. Rule 498A(j)(1)(iii); rule 498A(i)(3)(ii).
                        </P>
                    </FTNT>
                    <P>
                        • Requested required online portfolio company documents must be sent in paper or electronically upon request within three business days after receiving a request; 
                        <SU>563</SU>
                        <FTREF/>
                         and
                    </P>
                    <FTNT>
                        <P>
                            <SU>563</SU>
                             Rule 498A(j)(1)(iii); rule 498A(i)(1).
                        </P>
                    </FTNT>
                    <P>
                        • The safe harbor specified in paragraph (h)(4) of the rule will be available if the required online portfolio company documents are temporarily unavailable at the specified website.
                        <SU>564</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>564</SU>
                             Rule 498A(j)(1)(iii); rule 498A(h)(4).
                        </P>
                    </FTNT>
                    <P>
                        Several commenters urged the Commission to permit flexibility regarding the website where required online portfolio company documents would be posted, and stated that insurers should be permitted to include website addresses or links to portfolio companies' existing website document libraries.
                        <SU>565</SU>
                        <FTREF/>
                         One commenter asserted that the costs of posting the required online portfolio company documents online in machine-readable format(s) would greatly outweigh the benefits.
                        <SU>566</SU>
                        <FTREF/>
                         As discussed above, many commenters also commented on the web-posting requirements for variable contract materials in the context of the variable contract summary prospectus, and suggested that those requirements (which are largely replicated in the context of portfolio company materials) should be made more principles-based and less regimented.
                        <SU>567</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>565</SU>
                             
                            <E T="03">See</E>
                             ICI Comment Letter; ACLI Comment Letter; CAI Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>566</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>567</SU>
                             
                            <E T="03">See, e.g.,</E>
                             VIP Working Group Comment Letter; Anonymous Comment Letter III; 
                            <E T="03">see also supra</E>
                             Section II.A.5.
                        </P>
                    </FTNT>
                    <P>
                        We believe that the “publicly accessible” provision of the rule as proposed already contemplated flexibility for issuers with respect to website posting requirements. Therefore, as proposed, the final rule 
                        <PRTPAGE P="26010"/>
                        permits flexibility regarding the website where the required online portfolio company documents are posted, so long as electronic versions of the required online portfolio company documents (or links to those documents) are posted at the same website where the required online contract documents for the variable contract prospectus (or links to those documents) are posted.
                        <SU>568</SU>
                        <FTREF/>
                         This requirement is designed to allow flexibility regarding the location where electronic versions of those materials are posted (and permits the website to be hosted, for example, by a financial intermediary or other entity than the insurer), while still ensuring that access to all materials relating to the contract is provided in a central location.
                    </P>
                    <FTNT>
                        <P>
                            <SU>568</SU>
                             
                            <E T="03">See</E>
                             rule 498A(j) (conditioning reliance upon the new portfolio company prospectus delivery option on satisfaction of the conditions in paragraphs (h)(1), (h)(2)(i) and (ii), and (h)(3) and (4)), (h)(1) (providing that the required online portfolio company documents must be posted online at the website address referenced in paragraph (h)(1), which refers to the website on the cover page or beginning of the summary prospectus where the required online contract documents are posted). As proposed, both sets of materials were required to be posted on the website specified on the cover page or beginning of the summary prospectus, but we revised rule 498A(j)(1)(iii) to clarify that the website address used for the required online portfolio company documents must be the same website used for the required online contract documents.
                        </P>
                    </FTNT>
                    <P>
                        Also as proposed, the website address must be specific enough to lead investors directly to the required online portfolio company documents, although the website can be a central site with prominent links to each document.
                        <SU>569</SU>
                        <FTREF/>
                         Thus, while portfolio company documents may be hosted at multiple locations, for purposes of compliance with the rule, a summary prospectus may only include a single website address where each of the required online portfolio company documents together with the required online contract documents may be accessed. This requirement is designed to ensure that the required online portfolio company documents are collectively located at the same website address (or can be readily accessed from the same website address) as the related variable contract materials, as opposed to being scattered across various disconnected websites which could discourage investors from seeking those materials.
                    </P>
                    <FTNT>
                        <P>
                            <SU>569</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(2)(v)(B).
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, the Commission is currently engaged in an overall review of the retail fund investor experience. The Commission and its staff will continue to consider further in the broader context of that overall review whether more global changes to the online disclosure framework should be made with regards to the other issues raised by commenters regarding making the web-posting requirements more principles-based and less regimented, as well as whether documents should be required to be posted online in machine-readable format.
                        <SU>570</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>570</SU>
                             
                            <E T="03">See</E>
                             Request for Comment on Fund Retail Investor Experience, 
                            <E T="03">supra</E>
                             note 548.
                        </P>
                    </FTNT>
                    <P>
                        Another commenter observed that proposed rule 498A did not clarify when information in a portfolio company's statutory prospectus is deemed to be conveyed to investors for purposes of rule 159 under the Securities Act.
                        <SU>571</SU>
                        <FTREF/>
                         Although the commenter's letter only addressed a portfolio company's statutory prospectus, we believe similar concerns would also apply to a portfolio company's Statement of Additional Information and shareholder reports. Accordingly, in a change from the proposal, the final rule provides that information contained in the required online portfolio company documents is conveyed for purposes of rule 159 when portfolio company prospectus delivery obligations under section 5(b)(2) of the Securities Act are satisfied pursuant to the optional portfolio company prospectus delivery method.
                        <SU>572</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>571</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter. 
                            <E T="03">See generally supra</E>
                             note 505 (discussing the significance of rule 159 in the context of liability under Sections 12(a)(2) and 17(a)(2) of the Securities Act).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>572</SU>
                             
                            <E T="03">See</E>
                             rule 498A(j)(1).
                        </P>
                    </FTNT>
                    <P>
                        Finally, in a change from the proposal,
                        <SU>573</SU>
                        <FTREF/>
                         we are correcting an oversight and adding language to the rule to clarify that failure to comply with the delivery upon request and “convenient for reading and printing” requirements with regards to the required online portfolio company documents will not negate the ability to rely on the portfolio company prospectus delivery method.
                        <SU>574</SU>
                        <FTREF/>
                         This failure would, however, constitute a violation of Commission rules.
                    </P>
                    <FTNT>
                        <P>
                            <SU>573</SU>
                             The proposal addressed this issue for the summary prospectus itself, but not with regards to portfolio company prospectuses. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at notes 264 and 298 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>574</SU>
                             
                            <E T="03">See</E>
                             rule 498A(j)(3).
                        </P>
                    </FTNT>
                    <P>
                        The proposal did not address this issue, but we believe that this provision is consistent with our stated intention to both address the problem of the high volume of disclosure materials variable contract investors receive,
                        <SU>575</SU>
                        <FTREF/>
                         and to build upon our experience regarding mutual fund summary prospectuses.
                        <SU>576</SU>
                        <FTREF/>
                         The new language, which parallels a similar provision in rule 498,
                        <SU>577</SU>
                        <FTREF/>
                         is intended to provide greater certainty to market participants who seek to rely on the rule, and conforms to similar language regarding the application of those same requirements to the ability of funds and financial intermediaries to rely on the rule to satisfy prospectus delivery obligations.
                        <SU>578</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>575</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.B.2.a.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>576</SU>
                             
                            <E T="03">Id.</E>
                             at note 46 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>577</SU>
                             Rule 498(f)(5).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>578</SU>
                             
                            <E T="03">See</E>
                             rule 498A(i)(5) (“Compliance with this paragraph (i) of this section is not a condition to the ability to rely on paragraph (f) or (g) of this section with respect to a Contract, and failure to comply with paragraph (i) does not negate the ability to rely on paragraph (f) or (g) of this section.”).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Interim Amendments to Portfolio Company Prospectuses</HD>
                    <P>
                        When a portfolio company supplements or otherwise amends its summary or statutory prospectus between annual updates, the amendment is typically filed with the Commission pursuant to rule 497 under the Securities Act.
                        <SU>579</SU>
                        <FTREF/>
                         In addition, we understand that the amendment is typically delivered to investors, either by special mailing or by including it with another mailing, such as with the account statement or confirmation.
                        <SU>580</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>579</SU>
                             Rule 497 under the Securities Act.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>580</SU>
                             For investors who received a summary prospectus for a portfolio company, we understand that amendments are typically delivered to investors only if the amendments relate to the summary prospectus and summary section portion of the statutory prospectus.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, the new option for satisfying portfolio company prospectus delivery requirements will require that current portfolio company summary prospectuses and statutory prospectuses are posted online. If a portfolio company amends its prospectus between annual updates, the updated prospectus (including any prospectus supplements) must be posted online. However, as proposed, we are not separately requiring delivery of portfolio company prospectus amendments to investors. Commenters generally supported this aspect of our proposal.
                        <SU>581</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>581</SU>
                             
                            <E T="03">See, e.g.,</E>
                             ACLI Comment Letter and CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        In addition, if an interim amendment to a portfolio company prospectus affects the information provided in the initial or updating summary prospectus (
                        <E T="03">e.g.,</E>
                         a change to the type/investment objective or current expenses of the portfolio company provided in the required Appendix to the contract summary prospectus), then investors will receive notice of the change through an amendment to the contract summary prospectus which will be delivered to investors. As proposed, the new rule will not, however, affect the requirements to deliver other materials specified under other rules or terms of exemptive orders, and in such cases, the 
                        <PRTPAGE P="26011"/>
                        materials specified under those rules or terms of exemptive orders must be delivered to investors.
                        <SU>582</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>582</SU>
                             
                            <E T="03">See, e.g.,</E>
                             17 CFR 270.35d-1 (rule 35d-1 under the Investment Company Act) (requiring a registered investment company with a name suggesting investment in certain investments or industries, or investment in countries or geographic regions, to adopt a policy to invest at least 80% of its net assets (plus the amount of any borrowings for investment purposes) in investments suggested by its name, and if not a fundamental policy, to provide investors with at least 60 days prior notice of any change in that investment policy).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Delivery of Portfolio Company Prospectuses in Connection With Form N-14 Proxy Statement/Prospectuses</HD>
                    <P>
                        Management investment companies and business development companies use Form N-14 to register certain transactions under the Securities Act. These include a merger in which a vote or consent of the security holders of the company being acquired is not required, an exchange offer for securities of the issuer or another person, a public reoffering or resale of any securities acquired in an offering registered on Form N-14, or any combination of such transactions.
                        <SU>583</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>583</SU>
                             
                            <E T="03">See</E>
                             General Instruction A to Form N-14.
                        </P>
                    </FTNT>
                    <P>
                        Among other things, Form N-14 requires the disclosure of certain information about the registrant and the company being acquired, such as fees, synopsis information of the information contained in their prospectuses, and risk factors.
                        <SU>584</SU>
                        <FTREF/>
                         If the transaction will not be submitted to security holders of the registrant for approval or consent, then some of the required information about the company being acquired may be incorporated by reference from that company's current prospectus without being sent to investors, on the grounds that investors in the company being acquired have already received the prospectus for their fund.
                        <SU>585</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>584</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Items 3, 5, and 6 of Form N-14.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>585</SU>
                             
                            <E T="03">See</E>
                             Item 6.(2)(ii) of Form N-14.
                        </P>
                    </FTNT>
                    <P>
                        While the Commission did not propose any changes to Form N-14 in the Proposing Release, one commenter asked whether a filing on Form N-14 could similarly incorporate by reference a portfolio company prospectus without delivering it if the investor had received a variable contract prospectus which offered the portfolio company as an underlying investment option.
                        <SU>586</SU>
                        <FTREF/>
                         We believe the same policy rationale behind the incorporation by reference provision in current Form N-14 should also apply here so long as prospectus delivery obligations for the portfolio company have been satisfied pursuant to the new portfolio company prospectus delivery option. Accordingly, we are now amending Form N-14 to provide that a portfolio company prospectus whose delivery obligations were satisfied via new rule 498A(j) may be incorporated by reference into a filing on Form N-14 without being sent to investors, so long as that portfolio company was listed in the variable contract summary prospectus Appendix at the time the disclosures required by Form N-14 were delivered to investors.
                        <SU>587</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>586</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>587</SU>
                             
                            <E T="03">See</E>
                             General Instruction G to amended Form N-14.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">C. Amendments to Registration Forms</HD>
                    <P>We are adopting amendments to Forms N-3, N-4, and N-6 to update and enhance the disclosures to investors in variable contracts, and to implement the summary prospectus framework. These amendments include new disclosure requirements to reflect the evolution of variable contract features, including, in particular, the prevalence of optional benefits that insurers offer under these contracts. In addition, we are adopting amendments to provide greater consistency among the registration forms for variable contracts. Form N-6, which was adopted in 2002 and is the newest variable contract form, served as a model for many of the revisions to Forms N-3 and N-4. Accordingly, we are adopting fewer changes to Form N-6 than the other forms.</P>
                    <P>Certain investors who are considering variable annuities may also be considering variable life insurance (and vice versa). We believe a consistent presentation could reduce investor confusion and promote investor understanding through common disclosure across types of variable products on elements that we consider useful in explaining variable contracts' features and risks. Also, we believe that more uniformity of disclosures across variable contract types may make it easier for investors to compare similar products. We also believe that increasing consistency of disclosure requirements among registration forms could increase efficiencies among sponsors of variable contracts that register on multiple of these registration form types, and other market participants.</P>
                    <P>
                        We are adopting amendments to the registration statement forms substantially as proposed with some modifications in response to comments on specific reporting items.
                        <SU>588</SU>
                        <FTREF/>
                         The comments that we received relating to our proposal to amend variable contract registration statements were generally supportive of our efforts to improve the information that is provided to shareholders and filed with the Commission.
                        <SU>589</SU>
                        <FTREF/>
                         Although commenters did not raise broad objections to our proposed amendments, commenters raised concerns with and/or requested clarification on various items, as discussed in more detail below. To the extent we received no comments on certain items, we are adopting them as proposed, as discussed further below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>588</SU>
                             In a change from the proposal, we are also making non-substantive amendments to the forms to standardize and conform the use of certain terminology and references to defined terms, such as changing references from “contractowner” to the more plain English term “investor.”
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>589</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter (“[T]he Committee applauds the Commission for dedicating considerable time and effort to revamp the variable product registration statement forms. . . .”); XBRL U.S. Comment Letter (“Making variable annuity data consistent, comparable from product to product, and easily accessible on a timely basis, will improve the investor's ability to evaluate these offerings, and is a task best handled through standardized reported data.”).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">1. General Instructions</HD>
                    <P>We are adopting amendments to the General Instructions of Forms N-3, N-4, and N-6 regarding the preparation and filing of registration statements. Although commenters did not raise broad objections to our proposed amendments, commenters raised concerns with and/or requested clarification on General Instruction C.3, as discussed in more detail below. To the extent we received no comments on the other General Instructions, we are adopting them as proposed.</P>
                    <P>
                        The amended General Instructions, like the General Instructions in current Form N-6,
                        <SU>590</SU>
                        <FTREF/>
                         are structured to include four parts: (A) Definitions; (B) Filing and Use of Form; (C) Preparation of the Registration Statement; 
                        <SU>591</SU>
                        <FTREF/>
                         and (D) Incorporation by Reference.
                        <SU>592</SU>
                        <FTREF/>
                         With the 
                        <PRTPAGE P="26012"/>
                        exception of General Instruction C.3, these amendments are largely organizational in nature and incorporate minor changes that are not intended to significantly alter the content of the current General Instructions for these forms.
                    </P>
                    <FTNT>
                        <P>
                            <SU>590</SU>
                             While the amended General Instructions in Forms N-3 and N-4 are structured like the General Instructions in current Form N-6, there are certain new instructions that we are adopting to add to each of the forms. 
                            <E T="03">See, e.g.,</E>
                             amended General Instructions C.3.(a), C.3.(b), C.3.(c), C.3.(e), and C.3.(h) to Forms N-3, N-4, and N-6, each described 
                            <E T="03">infra.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>591</SU>
                             The final forms include, as part of the instruction to avoid excessive detail, technical or legal terminology, and complex language, amended General Instruction C.1.(c) which clarifies the instruction to avoid the use of formulas as the primary means of communicating certain terms or features of the contract. This specific text was not included in the proposal, and is not intended to discourage use of a formula, but rather, to clarify that if a formula is used in connection with a term or feature, investors are first provided appropriate plain English disclosure regarding the operation of the term or feature. This amendment is consistent with a frequent staff comment provided as part of the disclosure review process that is intended to help facilitate registration statement disclosures that are clear and concise.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>592</SU>
                             Amended General Instruction D also reflects the amendments recently adopted pursuant to the Commission's FAST Act rulemaking in 2019. 
                            <E T="03">See</E>
                              
                            <PRTPAGE/>
                            FAST Act Adopting Release, 
                            <E T="03">supra</E>
                             note 501 (among other things, consolidating and harmonizing rules and instructions in registration statements regarding incorporation by reference). These amendments became effective April 2 and May 2, 2019.
                        </P>
                        <P> As discussed below in Section II.E, EDGAR will be modified to create a new submission type under which registrants may file required financial statements. Notice of EDGAR system readiness to accept filings pursuant to the new submission type will be provided in a manner similar to notices of EDGAR Filer Manual updates. This submission type will be available to all variable contract registrants, including those with actively selling or discontinued contracts. Thus, registrants may incorporate by reference into their post-effective amendment and other filings the financial statements filed under the new submission type.</P>
                    </FTNT>
                    <P>General Instruction C.3 provides substantive requirements for the preparation of the registration statement, including instructions relating to the organization, presentation, and prospectuses permitted to be included in a registration statement. The instruction parallels Instruction C.3 of current Form N-6 in substance, except as described below.</P>
                    <HD SOURCE="HD3">Organization of Information</HD>
                    <P>
                        As proposed, General Instruction C.3.(a) requires the disclosures in response to Item 2 (Key Information), Item 3 (Overview of the Contract), and Item 4 (Fee Table) of the registration forms to appear in numerical order at the front of the prospectus, and not be preceded by anything other than a cover page (Item 1), a glossary, or a table of contents. One commenter stated that registrants should be given flexibility to present disclosure where it makes most logical sense, and recommended against an approach that would require those disclosures to be segregated and placed at the beginning of the statutory prospectus.
                        <SU>593</SU>
                        <FTREF/>
                         Another commenter disagreed and supported the proposed order of the items in the amended forms and the related General Instructions.
                        <SU>594</SU>
                        <FTREF/>
                         We continue to believe that these disclosures should appear at the beginning of the prospectus because they contain the most salient information about a variable contract's key features, costs, and risks and standardization of these disclosures will aid investors in comparing different products.
                        <SU>595</SU>
                        <FTREF/>
                         We also believe that the instruction incorporates a certain degree of flexibility for issuers. As proposed and adopted, the instruction also provides that if the discussion of the information that Items 2 or 3 requires also responds to disclosure requirements in other items of the prospectus, a registrant need not include additional disclosure that repeats this information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>593</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>594</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>595</SU>
                             The disclosure that amended Items 2 and 3 requires also will appear at the beginning of the initial summary prospectus. 
                            <E T="03">See supra</E>
                             note 60 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Other Information</HD>
                    <P>
                        As proposed, General Instruction C.3.(b) provides that, except in response to Items 2 and 3, a registrant is permitted to include information in the prospectus or SAI that is not otherwise required, so long as it is not incomplete, inaccurate, or misleading and does not, because of its nature, quantity, or manner of presentation, obscure or impede understanding of the information that is required to be included.
                        <SU>596</SU>
                        <FTREF/>
                         This instruction is intended to provide flexibility to registrants to include contextual and other information that could aid investors' understanding of variable contracts and assist them in making informed investment decisions.
                    </P>
                    <FTNT>
                        <P>
                            <SU>596</SU>
                             In a change from the proposal, this instruction further provides that information regarding non-principal risks that is not otherwise required to be in the prospectus must be disclosed in the SAI, as opposed to the prospectus, in accordance with the items regarding principal and non-principal risk disclosure. As discussed below, we believe that prospectus disclosure of non-principal risks that are not otherwise required to be in the prospectus could add complexity and length to the prospectus and obscure principal risks that are more relevant to investors, and therefore such non-principal risks should only be included in the SAI. 
                            <E T="03">See</E>
                             note 690.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Presentation of Information</HD>
                    <P>
                        As proposed, General Instruction C.3.(c) encourages registrants to use, as appropriate, question-and-answer presentations, tables, side-by-side comparisons, captions, bullet points, numeric examples, illustrations or similar presentation methods.
                        <SU>597</SU>
                        <FTREF/>
                         We believe that these alternative ways of presenting information could increase readability and that this instruction could encourage registrants to use these presentation options, where appropriate.
                    </P>
                    <FTNT>
                        <P>
                            <SU>597</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Kleimann Presentation, 
                            <E T="03">supra</E>
                             note 112 (encouraging, for example, the use of question-and-answer format, the use of headings to make structure clear, using a strong design grid to organize elements, making line length readable, and using common words and sentence constructions as ways of designing disclosure to promote readability).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Use of Terms</HD>
                    <P>As proposed, General Instruction C.3.(d)(i) includes in substance the requirements of Item 2 (Definitions) of current Forms N-3 and N-4. The changes conform this instruction to the language in the parallel current General Instruction of Form N-6, which we believe will improve readability and consistency across form types.</P>
                    <P>
                        As discussed above, and in response to requests from commenters, General Instruction C.3.(d) includes new subparagraph (ii) which provides registrants with the flexibility to use alternate terminology other than that used by the form, so long as the alternate terminology clearly conveys the meaning of, or provides comparable information as, the terms used by the form.
                        <SU>598</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>598</SU>
                             
                            <E T="03">See supra</E>
                             note 76 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Use of Form To Register Multiple Contracts</HD>
                    <P>General Instruction C.3.(e) provides new guidance addressing when a registrant may describe multiple contracts in a single prospectus, and include multiple prospectuses in a single registration statement. We are generally adopting these amendments as proposed, with certain modifications described below.</P>
                    <P>
                        As proposed, General Instruction C.3.(e)(i) provides that registrants may describe multiple contracts in a single prospectus when the contracts are “essentially identical.” Whether the contracts are essentially identical will depend on the facts and circumstances. The instruction includes examples to provide guidance on this point, although we have revised one of the proposed examples to clarify that a contract that does not offer optional benefits could still be essentially identical to one that offers optional benefits without charge (
                        <E T="03">e.g.,</E>
                         optional benefits offered without charge may include dollar-cost averaging programs, automatic transfer programs, etc.).
                        <SU>599</SU>
                        <FTREF/>
                         If a prospectus becomes unwieldy because of multiple discontinued or changed features such that an investor might become overwhelmed or confused, the registrant should consider issuing a new prospectus, which could be included in the same registration statement, as discussed further below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>599</SU>
                             The examples clarify that a contract that does not offer optional benefits would not be essentially identical to one that does for a charge. Similarly, group and individual contracts would not be essentially identical. However, contracts that vary only due to state regulatory requirements would be essentially identical.
                        </P>
                    </FTNT>
                    <P>
                        One commenter asserted that the specific examples proposed by the Commission outlining when this practice would be permitted were unnecessarily restrictive. The 
                        <PRTPAGE P="26013"/>
                        commenter suggested that the Commission should permit insurers reasonable flexibility to describe, in a single prospectus, the same contract (or contracts) offering different versions of a particular optional benefit, different combinations of optional benefits, and other variations.
                        <SU>600</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>600</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>As the number of optional benefits offered under variable insurance contracts have proliferated, registrants have gravitated towards increasingly larger and more complex prospectuses, including prospectuses describing multiple contracts offering different versions and combinations of optional benefits, even though not all of those contracts or optional benefits would be relevant for investors to whom the prospectus would be sent or given.</P>
                    <P>To provide guidance to registrants, and in order to avoid overwhelming investors with voluminous and potentially irrelevant prospectus information, General Instruction C.3.(e)(i) provides that registrants may only describe multiple contracts in a single prospectus when the included contracts are “essentially identical,” and further provides specific examples that we believe are helpful in outlining when this condition is met.</P>
                    <P>General Instruction C.3.(e)(ii) further provides that a registrant may combine multiple prospectuses in a single registration statement under certain conditions. The Commission proposed permitting such combinations when the prospectuses describe contracts that are “essentially identical.”</P>
                    <P>
                        One commenter expressed confusion that the same standard would be used to determine when multiple contracts can be described in one prospectus and also when multiple prospectuses can be combined in one registration statement, even though different examples are provided to demonstrate what would be appropriate in each context.
                        <SU>601</SU>
                        <FTREF/>
                         The commenter further stated that registrants currently have reasonable flexibility to include multiple reasonably related prospectuses in a single registration statement, and asserted that practice should be permitted if the prospectuses describe different versions or iterations of contracts that are on the same or substantially similar policy forms, offer different combinations and/or iterations of benefits, or address different distribution arrangements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>601</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        Although we agree that under certain circumstances it would be appropriate to include more than one prospectus in a single registration statement, as discussed above we believe that specific criteria will be helpful to provide guidance to registrants and to limit the potential for investors to become overloaded with voluminous and potentially irrelevant registration statement information. Accordingly, we have modified the General Instruction to permit registrants to combine multiple prospectuses in a single registration statement when the contracts are “substantially similar.” The instruction also includes examples to provide guidance on this point, as proposed, although we are modifying one of the proposed examples to replace the word “enhanced” with “modified,” because not all material changes to riders are necessarily improvements that “enhance” the rider.
                        <SU>602</SU>
                        <FTREF/>
                         We believe these examples are generally consistent with current industry practice.
                    </P>
                    <FTNT>
                        <P>
                            <SU>602</SU>
                             The examples clarify that a registrant could determine it is appropriate to include multiple prospectuses in a registration statement in the following situations: (1) The prospectuses describe the same contract that is sold through different distribution channels; (2) the prospectuses describe contracts that differ only with respect to underlying funds offered; or (3) the prospectuses describe both the original and a “modified” version of the same contract (where the “modified” version modifies the features or options that the registrant offers under that contract).
                        </P>
                    </FTNT>
                    <P>
                        When a registrant files its initial registration statement and post-effective amendments thereto with the Commission, Commission staff could request the registrant to resubmit the filing with separate prospectuses or registration statements if the filing falls outside the guidelines specified in General Instruction C.3.(e). One commenter stated that many prospectuses currently describe more than one contract, and many variable product registration statements currently include more than one prospectus, and suggested that the Commission should grandfather such existing filings.
                        <SU>603</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>603</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Recognizing the potential confusion for existing investors and burdens for registrants associated with splitting up prospectuses and registration statements into multiple documents, we are exempting registrants from the requirement to take such actions as to existing prospectuses and registration statements.
                        <SU>604</SU>
                        <FTREF/>
                         Existing prospectuses and registration statements as of the effective date of the form amendments are exempt from these requirements—that is, existing prospectuses that describe more than one contract, and existing registration statements that include more than one prospectus, will not need to be split into separate documents. However, after the effective date of the form amendments, a registrant that seeks to describe a new contract under a particular prospectus or add a new prospectus to a registration statement, must comply with the guidelines specified in General Instruction C.3.(e) as to that new contract or new prospectus. Further, while we generally believe that insurers should limit the contracts covered in a single prospectus and prospectuses covered in a single registration statement as discussed above, we also believe that the costs and burdens that would be imposed should we not provide this exemption may not justify the benefits of such limitations in the case of existing prospectuses and registration statements.
                        <SU>605</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>604</SU>
                             For the reasons set forth above, we find that this exemption is necessary or appropriate in the public interest and consistent with the protection of investors and the purposes fairly intended by the policy and provisions of the Investment Company Act. 
                            <E T="03">See</E>
                             Section 6(c) of the Investment Company Act; Section 28 of the Securities Act.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>605</SU>
                             
                            <E T="03">See infra</E>
                             Sections II.E.2 and 3.a (taking a similar approach regarding discontinued contracts for similar reasons).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Order of Information in Prospectus</HD>
                    <P>
                        As proposed, while paragraph (a) of General Instruction C.3 generally requires registrants to disclose the information required by Items 2, 3, and 4 in numerical order at the front of the prospectus, General Instruction C.3.(e)(i)(A) allows registrants to depart from this requirement under certain circumstances.
                        <SU>606</SU>
                        <FTREF/>
                         The amended instruction includes an example to provide guidance on this point, largely as proposed.
                        <SU>607</SU>
                        <FTREF/>
                         Registrants that present Items 2, 3, and 4 for each of several contracts sequentially or that utilize another presentation should consider whether investors might benefit from a brief explanation about how the information in the prospectus is presented, such as headings for each contract in the prospectus' table of contents and/or a brief narrative at the beginning of the prospectus explaining 
                        <PRTPAGE P="26014"/>
                        the presentation.
                        <SU>608</SU>
                        <FTREF/>
                         Registrants are encouraged to present information in a manner that limits repetition.
                        <SU>609</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>606</SU>
                             Specifically, registrants may do so when providing disclosure in a single prospectus for more than one contract. However, the order of information required by each item must remain the same, and they must still present the required information clearly and effectively.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>607</SU>
                             The example clarifies that a prospectus may present all of the Item 2 information for several contracts (
                            <E T="03">e.g.,</E>
                             by providing several Key Information Tables sequentially or by providing a single Key Information Table containing separate disclosures for each contract to the extent that such disclosures vary by contract), followed by all of the Item 3 information for the contracts, and followed by all of the Item 4 information for the contracts. Alternatively, the prospectus may present Items 2, 3, and 4 for each of several contracts sequentially. Other presentations also could be acceptable if they are consistent with the form's intent to disclose the information required by Items 2, 3, and 4 in a standard order at the beginning of the prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>608</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(e)(i)(A) to Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>609</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        Regardless of the presentation method chosen, when disclosing information relating to one of several contracts, registrants should clearly identify to which contract the information relates. In a change from the proposal, and consistent with our effort to provide greater clarity to investors,
                        <SU>610</SU>
                        <FTREF/>
                         the amended forms contain a new instruction that requires registrants to generally include appropriate titles, headings, or any other information to promote clarity and facilitate understanding regarding which disclosures apply to which contract, if such disclosures vary based on the contract.
                        <SU>611</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>610</SU>
                             While not specific to use of a single prospectus to describe more than one contract, one commenter did raise a concern about the ability of investors to understand multiple contracts in the context of the initial summary prospectus. 
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>611</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(e)(i)(B).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Interactive Data Files</HD>
                    <P>
                        In the case of contracts currently offered to new investors, paragraph (h) of General Instruction C.3 requires registrants to use the Inline XBRL format for the submission of certain required disclosures in the variable contract statutory prospectus.
                        <SU>612</SU>
                        <FTREF/>
                         We discuss the requirement to file using Inline XBRL in Section II.D below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>612</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(h) to amended Forms N-3, N-4, and N-6; 
                            <E T="03">see also</E>
                             Items 3, 4, 5, 11, 18, and 19 of amended Form N-3; Items 3, 4, 5, 10, and 17 of amended Form N-4; Items 3, 4, 5, 10, 11, and 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Website Addresses</HD>
                    <P>
                        Paragraph (i) of General Instruction C.3 requires any website address that is included in an electronic version of the statutory prospectus (
                        <E T="03">i.e.,</E>
                         electronic versions sent to investors or available online) to include an active hyperlink.
                        <SU>613</SU>
                        <FTREF/>
                         In response to comments discussed below, in a change from the proposal, registrants may also utilize any other means of facilitating access that leads directly to the relevant website address or cross-referenced information. This instruction is intended to ensure that investors viewing electronic versions of the prospectus are able to easily access website addresses that are referenced in the prospectus and to provide registrants with flexibility to take advantage of potential technological improvements. This requirement does not apply to an electronic version of a statutory prospectus filed on the EDGAR system.
                        <SU>614</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>613</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(i) to amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>614</SU>
                             
                            <E T="03">Id.; see also</E>
                             rule 105 of Regulation S-T [17 CFR 232.105] (prohibiting hyperlinking to websites, locations, or other documents that are outside of the EDGAR system). Because this is an existing EDGAR restriction, we do not believe it is necessary to add this provision to registration statements. Thus, in a change from the proposal, amended Forms N-3, N-4, and N-6 do not include this provision.
                        </P>
                    </FTNT>
                    <P>
                        Although we proposed that this requirement would also apply to cross-references included in an electronic version of the statutory prospectus, for the reasons discussed above, and to parallel a similar change with regards to a parallel provision for summary prospectuses, we are not adopting this requirement with regards to electronic versions of the statutory prospectus.
                        <SU>615</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>615</SU>
                             
                            <E T="03">See supra note</E>
                             488 and accompanying and following text.
                        </P>
                    </FTNT>
                    <P>
                        Several commenters asserted that the proposed requirement could be burdensome because it would necessitate continuous maintenance to determine whether the hyperlinked websites have changed locations of information.
                        <SU>616</SU>
                        <FTREF/>
                         From staff's experience with insurer websites, we understand that insurers typically link to landing pages which are unlikely to change locations, and thus any such burden would be minimal relative to the benefits investors and others receive from such hyperlinks. Another commenter asked for guidance regarding what would constitute noncompliance with regards to failure to update an active hyperlink that had become a “dead link.” 
                        <SU>617</SU>
                        <FTREF/>
                         Although a finding of noncompliance would depend on the facts and circumstances in question, we would generally consider the hyperlinking requirement to be met if the insurer has reasonable procedures in place to ensure compliance, and the insurer takes prompt action to ensure that the hyperlink is active as soon as practicable following the earlier of the time at which it knows or reasonably should have known that the hyperlink is not active.
                        <SU>618</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>616</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter; Ameritas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>617</SU>
                             
                            <E T="03">See</E>
                             Chemas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>618</SU>
                             
                            <E T="03">Compare with</E>
                             rule 498A(h)(4) (providing safe harbor under similar circumstances with regards to the requirement to make certain documents available on a website, among other conditions).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Part A (Information Required in a Prospectus)</HD>
                    <P>Table 4 shows how our amendments revise the item requirements of Part A of the variable contract registration forms. Although commenters did not raise broad objections to our proposed amendments, commenters raised concerns with and/or requested clarification on various items, as discussed in more detail below. To the extent we received no comments on certain items, we are adopting them as proposed, as discussed further below.</P>
                    <GPOTABLE COLS="5" OPTS="L2,p7,7/8,i1" CDEF="s50,r50,r50,r50,r50">
                        <TTITLE>Table 4—Amendments to Part A of Forms N-3, N-4, and N-6</TTITLE>
                        <BOXHD>
                            <CHED H="1">Item description</CHED>
                            <CHED H="1">
                                Amended 
                                <LI>item No.</LI>
                            </CHED>
                            <CHED H="1">Form N-3</CHED>
                            <CHED H="1">Form N-4</CHED>
                            <CHED H="1">Form N-6</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Front and Back Cover Pages (in Forms N-3 and N-4, currently “Cover Page”)</ENT>
                            <ENT>
                                • Form N-3: Item 1  (currently Item 1) 
                                <LI>• Form N-4: Item 1  (currently Item 1) </LI>
                                <LI>• Form N-6: Item 1  (currently Item 1)</LI>
                            </ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Definitions</ENT>
                            <ENT>N/A (currently, Item 2 in Forms N-3 and N-4)</ENT>
                            <ENT>Revised  (incorporated in General Instructions)</ENT>
                            <ENT>Revised  (incorporated in General Instructions)</ENT>
                            <ENT>N/A (incorporated in General Instructions).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Key Information</ENT>
                            <ENT>
                                • Form N-3: Item 2
                                <LI>• Form N-4: Item 2</LI>
                                <LI>• Form N-6: Item 2</LI>
                            </ENT>
                            <ENT>New Item (also in ISP, USP)</ENT>
                            <ENT>New Item (also in ISP, USP)</ENT>
                            <ENT>New Item (also in ISP, USP).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Overview of the Contract</ENT>
                            <ENT>
                                • Form N-3: Item 3
                                <LI>• Form N-4: Item 3</LI>
                                <LI>• Form N-6: Item 3</LI>
                            </ENT>
                            <ENT>New Item (also in ISP)</ENT>
                            <ENT>New Item (also in ISP)</ENT>
                            <ENT>New Item (also in ISP).</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="26015"/>
                            <ENT I="01">Fee Table (in Form N-3, currently “Synopsis or Highlights,” in Form N-4, currently “Synopsis,” and in Form N-6, currently “Risk/Benefit Summary: Fee Table”)</ENT>
                            <ENT>
                                • Form N-3: Item 4 (currently Item 3) 
                                <LI>• Form N-4: Item 4 (currently Item 3)</LI>
                                <LI>• Form N-6: Item 4 (currently Item 3).</LI>
                            </ENT>
                            <ENT>Revised (also in ISP)</ENT>
                            <ENT>Revised (also in ISP)</ENT>
                            <ENT>Revised (also in ISP).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Condensed Financial Information</ENT>
                            <ENT>• Form N-3: Item 17 (currently Item 4)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>N/A</ENT>
                            <ENT>N/A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Principal Risks of Investing in the Contract (in Form N-6, currently “Risk/Benefit Summary: Benefits and Risks”)</ENT>
                            <ENT>
                                • Form N-3: Item 5
                                <LI>• Form N-4: Item 5</LI>
                                <LI>• Form N-6: Item 5  (currently Item 2)</LI>
                            </ENT>
                            <ENT>New Item</ENT>
                            <ENT>New Item</ENT>
                            <ENT>Revised.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                In Form N-3: General Description of Registrant, Insurance Company, and Investment Options (currently “General Description of Registrant and Insurance Company”)
                                <LI>In Forms N-4 and N-6: General Description of Registrant, Depositor, and Portfolio Companies</LI>
                            </ENT>
                            <ENT>
                                • Form N-3: Item 6 (currently Item 5)
                                <LI>• Form N-4: Item 6 (currently Item 5)</LI>
                                <LI>• Form N-6: Item 6 (currently Item 4)</LI>
                            </ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Management</ENT>
                            <ENT>• Form N-3: Item 7  (currently Item 6)</ENT>
                            <ENT>Revised</ENT>
                            <ENT>N/A</ENT>
                            <ENT>N/A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Charges (in Form N-3, currently “Deductions and Expenses,” in Form N-4, currently “Deductions”)</ENT>
                            <ENT>
                                • Form N-3: Item 8 (currently Item 7)
                                <LI>• Form N-4: Item 7 (currently Item 6)</LI>
                                <LI>• Form N-6: Item 7  (currently Item 5)</LI>
                            </ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">General Description of Contracts (in Form N-4, currently “General Description of Variable Annuity Contracts”)</ENT>
                            <ENT>
                                • Form N-3: Item 9 (currently Item 8)
                                <LI>• Form N-4: Item 8 (currently Item 7)</LI>
                                <LI>• Form N-6: Item 8  (currently Item 6)</LI>
                            </ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Annuity Period</ENT>
                            <ENT>
                                • Form N-3: Item 10 (currently Item 9)
                                <LI>• Form N-4: Item 9 (currently Item 8)</LI>
                            </ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised</ENT>
                            <ENT>N/A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Premiums</ENT>
                            <ENT>• Form N-6: Item 9  (currently Item 7)</ENT>
                            <ENT>N/A</ENT>
                            <ENT>N/A</ENT>
                            <ENT>
                                Revised
                                <LI>(part also in ISP).</LI>
                            </ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Death Benefits (in Forms N-3 and N-4, currently “Death Benefit,” and in Form N-6, currently “Death Benefits and Contract Values”)</ENT>
                            <ENT>
                                • Form N-3: N/A (currently Item 10)
                                <LI>• Form N-4: N/A (currently Item 9)</LI>
                                <LI>• Form N-6: Item 10  (currently Item 8)</LI>
                            </ENT>
                            <ENT>Eliminated</ENT>
                            <ENT>Eliminated</ENT>
                            <ENT>Revised (part also in ISP).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                In Forms N-3 and N-4: Benefits Available Under the Contract
                                <LI>In Form N-6: Other Benefits Available Under the Contract</LI>
                            </ENT>
                            <ENT>
                                • Form N-3: Item 11
                                <LI>• Form N-4: Item 10</LI>
                                <LI>• Form N-6: Item 11</LI>
                            </ENT>
                            <ENT>New Item (part also in ISP)</ENT>
                            <ENT>New Item (part also in ISP)</ENT>
                            <ENT>New Item (part also in ISP).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Purchases and Contract Value</ENT>
                            <ENT>
                                • Form N-3: Item 12  (currently Item 11)
                                <LI>• Form N-4: Item 11  (currently Item 10)</LI>
                                <LI>• Form N-6: N/A</LI>
                            </ENT>
                            <ENT>Revised (part also in ISP)</ENT>
                            <ENT>Revised (part also in ISP)</ENT>
                            <ENT>N/A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Surrenders and Withdrawals (in Forms N-3 and N-4, currently “Redemptions,” in Form N-6, currently “Surrenders, Partial Surrenders, and Partial Withdrawals”)</ENT>
                            <ENT>
                                • Form N-3: Item 13  (currently Item 12)
                                <LI>• Form N-4: Item 12  (currently Item 11)</LI>
                                <LI>• Form N-6: Item 12  (currently Item 9)</LI>
                            </ENT>
                            <ENT>Revised (part also in ISP)</ENT>
                            <ENT>Revised (part also in ISP)</ENT>
                            <ENT>Revised (part also in ISP).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Loans</ENT>
                            <ENT>
                                • Form N-3: Item 14
                                <LI>• Form N-4: Item 13</LI>
                                <LI>• Form N-6: Item 13  (currently Items 10 and 23)</LI>
                            </ENT>
                            <ENT>New Item</ENT>
                            <ENT>New Item</ENT>
                            <ENT>Revised.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Lapse and Reinstatement</ENT>
                            <ENT>• Form N-6: Item 14  (currently Item 11)</ENT>
                            <ENT>N/A</ENT>
                            <ENT>N/A</ENT>
                            <ENT>Revised (part also in ISP).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Taxes</ENT>
                            <ENT>
                                • Form N-3: Item 15  (currently Item 13)
                                <LI>• Form N-4: Item 14  (currently Item 12)</LI>
                                <LI>• Form N-6: Item 15  (currently Item 12)</LI>
                            </ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Unchanged.</ENT>
                        </ROW>
                        <ROW>
                            <PRTPAGE P="26016"/>
                            <ENT I="01">Legal Proceedings</ENT>
                            <ENT>
                                • Form N-3: Item 16  (currently Item 14)
                                <LI>• Form N-4: Item 15  (currently Item 13)</LI>
                                <LI>• Form N-6: Item 16  (currently Item 13)</LI>
                            </ENT>
                            <ENT>Revised</ENT>
                            <ENT>Revised</ENT>
                            <ENT>Unchanged.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Table of Contents of the SAI</ENT>
                            <ENT>
                                N/A (currently, Item 15 of Form N-3 and Item 14 of Form N-4) 
                                <SU>619</SU>
                            </ENT>
                            <ENT>Eliminated</ENT>
                            <ENT>Eliminated</ENT>
                            <ENT>N/A.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Financial Statements</ENT>
                            <ENT>
                                • Form N-3: Item 17
                                <LI>• Form N-4: Item 16</LI>
                                <LI>• Form N-6: Item 17  (currently Item 14)</LI>
                            </ENT>
                            <ENT>New Item</ENT>
                            <ENT>New Item</ENT>
                            <ENT>Unchanged.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">
                                In Form N-3: Investment Options Available Under the Contract
                                <LI>In Forms N-4 and N-6: Portfolio Companies Available Under the Contract</LI>
                            </ENT>
                            <ENT>
                                • Form N-3: Item 18
                                <LI>• Form N-4: Item 17</LI>
                                <LI>• Form N-6: Item 18</LI>
                            </ENT>
                            <ENT>New Item (also in ISP, USP if disclosures from Item 19 are not included)</ENT>
                            <ENT>New Item (also in ISP, USP)</ENT>
                            <ENT>New Item (also in ISP, USP).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">In Form N-3: Additional Information About Investment Options Available Under the Contract</ENT>
                            <ENT>• Form N-3: Item 19</ENT>
                            <ENT>New Item (also in ISP, USP if disclosures from Item 18 are not included)</ENT>
                            <ENT>New Item</ENT>
                            <ENT>New Item.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">a. Front and Back Cover Pages (Item 1 of Forms N-3, N-4, and N-6)</HD>
                    <P>
                        We are
                        <FTREF/>
                         adopting these amendments to the front and back cover pages of Forms N-3, N-4, and N-6 largely as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>619</SU>
                             As discussed below, we are eliminating the Table of Contents of the SAI that is required by Item 15 of current Form N-3 and Item 14 of current Form N-4. We do so to streamline the prospectus and avoid duplicative disclosure with the SAI, which separately requires a Table of Contents. 
                            <E T="03">See infra</E>
                             Section II.C.3.
                        </P>
                    </FTNT>
                    <P>
                        We are amending Item 1 of each registration form, largely as proposed,
                        <SU>620</SU>
                        <FTREF/>
                         to reflect the requirements for the prospectus cover pages required by Item 1 of current Form N-6, with three additional disclosures that will be made on the front cover page. We received no comments regarding these proposed additional disclosures.
                    </P>
                    <FTNT>
                        <P>
                            <SU>620</SU>
                             We added the legends required by rule 498A(b)(2)(v)(E) and (F) as a new part of Item 1 and made other slight clarifications that were not in Item 1 as proposed. 
                            <E T="03">See supra</E>
                             notes 90 and 91 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        • First, the name of the contract and the class or classes, if any, to which the contract relates to help clarify the specific contract and class or classes covered by the prospectus; 
                        <SU>621</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>621</SU>
                             Item 1(a)(5) of amended Form N-3; Item 1(a)(4) of amended Forms N-4 and N-6.
                        </P>
                    </FTNT>
                    <P>
                        • Second, as with the initial summary prospectus and updating summary prospectus, a statement directing an investor to the Investor.gov website for additional information; 
                        <SU>622</SU>
                        <FTREF/>
                         and
                    </P>
                    <FTNT>
                        <P>
                            <SU>622</SU>
                             Item 1(a)(8) of amended Form N-3; Item 1(a)(7) of amended Forms N-4 and N-6; 
                            <E T="03">see also supra</E>
                             note 88 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        • Third, as with the initial summary prospectus, a legend informing investors about the free look period, if applicable.
                        <SU>623</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>623</SU>
                             Item 1(a)(10) of amended Form N-3; Item 1(a)(8) of amended Forms N-4 and N-6; 
                            <E T="03">see also supra</E>
                             text following note 86 and accompanying text.
                        </P>
                        <P>
                            In addition, the forms include a legend informing investors about the optional internet availability of shareholder reports, if applicable, pursuant to the requirements of rule 30e-3. Item 1(a)(11) of amended Form N-3; Item 1(a)(9) of amended Forms N-4 and N-6; 
                            <E T="03">see also</E>
                             rule 30-3; 
                            <E T="03">supra</E>
                             note 86 and accompanying and following text.
                        </P>
                    </FTNT>
                    <P>
                        To streamline the front cover page and because similar information would appear in tabular presentation in the prospectus, the Commission proposed to eliminate the current requirements in Forms N-3 and N-4 that the registrant include on the front cover page the type of separate account and names of the available portfolio companies. We received one comment letter which supported removal of the names of the available portfolio companies and did not object to removal of the name of the type of separate account, and we are adopting these changes as proposed.
                        <SU>624</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>624</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (stating that such disclosures on the cover page would be unnecessarily duplicative of the new Appendix and further stating that, as the number of portfolio companies has proliferated, listing such options on the cover page has lengthened cover pages to the point that they have strayed far from the concise overview that the Commission originally intended).
                        </P>
                    </FTNT>
                    <P>
                        Additionally, as proposed, we are amending the prospectus back cover page to include certain additional information concerning: (1) The availability of the SAI and how to request other information about the contract; (2) whether and from where information is incorporated by reference into the prospectus as permitted by proposed Part D of the Form's General Instructions; and (3) the EDGAR contract identifier for the contract.
                        <SU>625</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>625</SU>
                             Item 1(b) of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Key Information (Item 2 of Forms N-3, N-4, and N-6)</HD>
                    <P>
                        Largely as proposed, we are adding new Item 2 to the registration forms, which requires a statutory prospectus to include the Key Information Table providing a brief description of key facts about the variable contract.
                        <SU>626</SU>
                        <FTREF/>
                         The Key Information Table also appears in the initial summary prospectus and the updating summary prospectus, except that it can vary depending on the scope of the initial summary prospectus (which can only describe a single contract that the registrant currently offers for sale), in contrast to the updating summary prospectus and statutory prospectus (which can describe multiple contracts under the conditions of the amended General Instructions to the registration forms). An updating summary prospectus that describes multiple contracts can contain a separate Key Information Table for each of the contracts, or use a different presentation approach that consistently discloses the required information for each contract in the required order.
                    </P>
                    <FTNT>
                        <P>
                            <SU>626</SU>
                             
                            <E T="03">See supra</E>
                             Sections II.A.1.c.ii.(a) and II.A.2.c.ii. for a discussion of these requirements in more detail.
                        </P>
                    </FTNT>
                    <P>
                        We received several comments on the substance and location of this Item in the context of the initial summary prospectus and the updating summary prospectus. As discussed above in the context of the summary prospectus, we are largely adopting the disclosure 
                        <PRTPAGE P="26017"/>
                        requirements of this Item as proposed, with certain modifications to address points raised by commenters, including shifting the location of this Item forward to be closer to the beginning of the summary prospectus. For similar reasons discussed with respect to the summary prospectus, we believe that those modifications should apply equally in the context of the statutory prospectus.
                    </P>
                    <HD SOURCE="HD3">c. Overview of the Contract (Item 3 of Forms N-3, N-4, and N-6)</HD>
                    <P>
                        As proposed, we are adding new Item 3 to the registration forms, which requires registrants to include certain basic and introductory information about the contract and its benefits.
                        <FTREF/>
                        <SU>627</SU>
                         These disclosures are also required in initial summary prospectuses.
                        <SU>628</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>627</SU>
                             
                            <E T="03">See supra</E>
                             Sections II.A.1.c.ii.(b) for a discussion of these requirements in more detail. Item 2(d) of amended Form N-6 includes the requirements that appear in Item 2(a) of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>628</SU>
                             Rule 498A(b)(5)(i).
                        </P>
                    </FTNT>
                    <P>
                        We received several comments on the substance of this Item in the context of the initial summary prospectus.
                        <SU>629</SU>
                        <FTREF/>
                         As discussed above, however, we are adopting the disclosure requirements of this Item as proposed for the initial summary prospectus.
                        <SU>630</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>629</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.1.c.ii.(b).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>630</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Fee Table (Item 4 of Forms N-3, N-4, and N-6)</HD>
                    <P>
                        Largely as proposed, we are amending Item 3 of the current registration forms (which we are re-designating as Item 4) to simplify and update current fee and expense disclosure obligations.
                        <SU>631</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>631</SU>
                             We are also changing the title of the Item from “Synopsis of Highlights” in Form N-3, “Synopsis” in Form N-4, and “Risk/Benefit Summary: Fee Table” in Form N-6 to “Fee Table” in all three forms.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">i. General Comments (Forms N-3, N-4, and N-6)</HD>
                    <P>
                        One commenter stated that many statutory prospectuses currently use terminology for fees and charges that differs from the terminology that appears in the proposed Fee Table, and suggested that the imposition of standardized terminology might obligate an insurer to re-file contract forms with state insurance departments.
                        <SU>632</SU>
                        <FTREF/>
                         The commenter concluded that the Commission should permit insurers the flexibility to use existing and prior terminology in the Fee Table, as well as new terminology in the future.
                    </P>
                    <FTNT>
                        <P>
                            <SU>632</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, we are revising the General Instructions of the registration forms to generally provide broad flexibility to use alternate terminology other than that specified in the applicable registration statement, so long as the alternate terminology clearly conveys the meaning of, or provides comparable information as, the terms used in the registration statement.
                        <SU>633</SU>
                        <FTREF/>
                         In addition, as proposed, we are providing further flexibility by allowing registrants to modify a narrative explanation in the Fee Table if the explanation contains comparable information to that shown.
                        <SU>634</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>633</SU>
                             
                            <E T="03">See supra</E>
                             note 598.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>634</SU>
                             
                            <E T="03">See</E>
                             Instruction 1 to Item 4 of amended Forms N-3 and N-4 and Instruction 1(b) to Item 4 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        Another commenter asked generally for clarification whether disclosure is needed for fees that are zero (
                        <E T="03">e.g.,</E>
                         front-end load for a fund with no front-end load).
                        <SU>635</SU>
                        <FTREF/>
                         Largely as proposed, we are adopting Instruction 3 to the Fee Table, which states that a registrant may omit captions if the registrant does not charge or reserve the right to charge the fees or expenses covered by the captions.
                        <SU>636</SU>
                        <FTREF/>
                         Therefore, in response to the commenter, if a registrant that does not charge or reserve the right to charge a particular fee wishes to omit that information, it may.
                    </P>
                    <FTNT>
                        <P>
                            <SU>635</SU>
                             
                            <E T="03">See</E>
                             Breacher Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>636</SU>
                             
                            <E T="03">See</E>
                             Instruction 3 to Item 4 of amended Forms N-3 and N-4 and Instruction 1(c) to Item 4 of amended Form N-6. In a change from the proposal, we are revising those instructions to clarify that a registrant that does not charge the fees or expenses covered by the captions but reserves the right to do so must include those captions in the Fee Table. We understand that this is consistent with insurers' current practices. In a conforming change, we are also removing language in those instructions permitting a registrant to modify or add captions under certain circumstances, because we believe that language is no longer necessary in light of the new flexibility permitted by the General Instructions to the registration statements and the instructions to the fee table. 
                            <E T="03">See supra</E>
                             notes 633-634.
                        </P>
                    </FTNT>
                    <P>
                        Other commenters suggested changes to the Fee Table that are beyond the scope of this current rulemaking, including interactive fee calculators and customized disclosures that would be accessed via links available only through password protected login-in screens.
                        <SU>637</SU>
                        <FTREF/>
                         More generally, one commenter noted that Fee Tables can be long and complex, and suggested that the Commission consider ways to streamline presentation of information in Fee Tables.
                        <SU>638</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>637</SU>
                             
                            <E T="03">See, e.g.,</E>
                             VIP Working Group Comment Letter; AARP Comment Letter. We note that the Commission is looking at disclosures and technology tools as part of a broader modernization initiative. 
                            <E T="03">See supra</E>
                             Section I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>638</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We recognize that variable insurance products can in some cases feature numerous optional benefits and investment options—each of which may be associated with a different fee and collectively may result in lengthy disclosures. However, we continue to believe that the full Fee Table should remain included in variable insurance contract prospectuses to provide investors with comprehensive fee and expense information regarding the optional benefits, investment options, and other charges associated with the contracts being offered. In order to provide investors with shorter, more tailored discussion, as discussed above, we are requiring the disclosure of certain summary information in the Key Information Table to convey the importance of the contract's fee and expense structure. This framework allows an investor to determine the level of fee information that best suits his or her informational needs (
                        <E T="03">i.e.,</E>
                         the summary fee information in the Key Information Table or the more detailed and comprehensive information in the Fee Table).
                    </P>
                    <HD SOURCE="HD3">ii. Transaction Expenses (Forms N-3 and N-4)</HD>
                    <P>
                        The Commission proposed to retitle the current “Contractowner Transaction Expenses” table in Forms N-3 and N-4 as “Annual Transaction Expenses.” Commenters pointed out that certain of the listed fees in the table are not deducted on an annual basis but instead are deducted only when the investor initiates certain transactions (
                        <E T="03">e.g.,</E>
                         sales loads, exchange fees, etc.).
                        <SU>639</SU>
                        <FTREF/>
                         Accordingly, we are retitling this table as “Transaction Expenses.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>639</SU>
                             
                            <E T="03">See</E>
                             Transamerica Comment Letter; CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are removing the current “Surrender Fees” line-item in this table, on the grounds that the current “Deferred Sales Load” line-item in the table should already capture these fees.
                        <SU>640</SU>
                        <FTREF/>
                         Correspondingly, we are revising the title of the “Deferred Sales Load” line-item to include “Deferred Sales Load (or Surrender Charge)” to clarify that a registrant should continue to include surrender charges in the table.
                    </P>
                    <FTNT>
                        <P>
                            <SU>640</SU>
                             As a conforming change, we are removing Instruction 2(c) to Item 3 of current Form N-3 and Instruction 10 to Item 3 of current Form N-4 and revising Instruction 2(b) to Item 3 of current Form N-3 and Instruction 9 to Item 3 of current Form N-4 (which we are re-numbering as Instruction 9 in each form) to clarify that the term “deferred sales load” includes surrender charges.
                        </P>
                    </FTNT>
                    <P>
                        One commenter stated that surrender terms need to be clear and prominent, including penalties for early withdrawal or loans and tax consequences, as well as the date that is specific to that investor when he or she can access the 
                        <PRTPAGE P="26018"/>
                        contract value without penalty.
                        <SU>641</SU>
                        <FTREF/>
                         We note that the disclosures we are adopting in this document are not intended to provide information tailored to the particular circumstances of each investor. We further note, however, that under the form amendments we are adopting in this document, disclosure regarding surrender charges is required in the Fee Table as well as in the new Key Information Table, while additional disclosure requirements will govern the disclosure of surrenders and withdrawals, loans, and taxes elsewhere in the prospectus.
                        <SU>642</SU>
                        <FTREF/>
                         Collectively, we believe these disclosure requirements are sufficient to address the concerns raised by the commenter.
                    </P>
                    <FTNT>
                        <P>
                            <SU>641</SU>
                             
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>642</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 2 of amended Form N-3 (Key Information Table); Item 12 of amended Form N-4 Surrenders and Withdrawals); Item 13 of amended Form N-4 (Loans); Item 15 of amended Form N-6 (Taxes).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">iii. Annual Contract Expenses (Forms N-3 and N-4) and Periodic Charges Other Than Annual Portfolio Company Expenses (Form N-6)</HD>
                    <P>
                        We are adopting, as proposed, several changes to the current “Annual Account Fee” and “Annual Expenses” line-items in Form N-3,
                        <SU>643</SU>
                        <FTREF/>
                         and the current “Annual Contract Fee and Separate Account Annual Expenses” table in Form N-4. As proposed, each is retitled, as a stand-alone table, under the heading “Annual Contract Expenses” in both forms to clarify that the item reflects insurance-related annual contract fees and not the fees related to investment options.
                    </P>
                    <FTNT>
                        <P>
                            <SU>643</SU>
                             In current Form N-3, these items are each presented as line-items in the table that Item 3(a) requires.
                        </P>
                    </FTNT>
                    <P>
                        In addition, largely as proposed, we are modifying the captions for existing line-items, consolidating certain line-items, and adding a new line-item for optional benefits in this table in each form.
                        <SU>644</SU>
                        <FTREF/>
                         Under the amendments, the “Annual Contract Expenses” table in Forms N-3 and N-4 is composed of the following line-items:
                    </P>
                    <FTNT>
                        <P>
                            <SU>644</SU>
                             Although these revisions generally apply to Forms N-3 and N-4, as discussed below, the new line-item for optional benefits is also added to the “Periodic Charges Other Than Annual Portfolio Company Expenses” table in amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Administrative Expenses.</E>
                         As proposed, the line-item “Annual Contract Fee” in Form N-4 (“Annual Expenses” in Form N-3) is replaced with the more plain-English “Administrative Expenses.” 
                        <SU>645</SU>
                        <FTREF/>
                         One commenter requested clarification about what expenses should be included in Administrative Expenses as opposed to Base Contract Expenses.
                        <SU>646</SU>
                        <FTREF/>
                         In response to this comment, we are revising the instruction to the Administrative Expenses line-item to clarify that Administrative Expenses include any contract, account, or similar fee imposed on all investor accounts on a dollar basis (
                        <E T="03">e.g.,</E>
                         $50 per year).
                        <SU>647</SU>
                        <FTREF/>
                         As discussed further below, Base Contract Expenses include similar charges that are imposed on a percentage basis.
                    </P>
                    <FTNT>
                        <P>
                            <SU>645</SU>
                             We also are making conforming changes to Instruction 3 to Item 3 of current Form N-3 and Instruction 7 to Item 3 of current Form N-4, which we are renumbering as new Instruction 12 in both forms.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>646</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>647</SU>
                             Instruction 3 to Item 3 of current Form N-3 and Instruction 7 to Item 3 of current Form N-4. In a conforming change, we are also adding this definition to Form N-6. 
                            <E T="03">See</E>
                             Instruction 3.(e) to Item 4 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Base Contract Expenses.</E>
                         Largely as proposed, we are consolidating the current line-item under “Annual Expenses” in Form N-3 (“Mortality and Expense Risk Fees”), and the current line-items under “Separate Account Annual Expenses” in Form N-4 (“Mortality and Expense Risk Fees,” “Account Fees and Expenses,” and “Total Separate Account Annual Expenses”) under a single new line-item in each table, “Base Contract Expenses,” which discloses those fees in the aggregate as a percentage of average account value. Collapsing these fees into a single line-item is intended to make it easier for investors to understand the annual cost of investing in the basic variable contract.
                        <SU>648</SU>
                        <FTREF/>
                         Any other recurring charge (other than charges associated with the portfolio companies) appears as an additional line-item in the Annual Contract Expenses table in Form N-4, which discloses the maximum amount or basis on which the charge is deducted.
                        <SU>649</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>648</SU>
                             We also are making conforming changes to each form's instructions. We are removing Instruction 4(b) to Item 3 of current Form N-3 and Instruction 13 to Item 3 of current Form N-4, which permit “Mortality and Expense Risk Fees” to be listed separately on two lines in the table. We also are revising Instruction 14 to Item 3 of current Form N-4 (which we are renumbering as Instruction 13), and adding a corresponding new Instruction 13 to Item 4 of amended Form N-3, to state that “Base Contract Expenses” includes mortality and expense risk fees, and account fees and expenses. We are also including a new Instruction 3(g) to Item 4 of amended Form N-6 permitting Registrants to consolidate any charges that are assessed on a similar basis (
                            <E T="03">e.g.,</E>
                             Administrative Fees and Mortality and Expense Risk Fees).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>649</SU>
                             We are revising and renumbering Instruction 15 to Item 3 of current Form N-4 (which currently appears under the heading “Portfolio Company Annual Expenses”) as Instruction 15 to Item 4 of amended Form N-4 (to appear under the heading “Annual Contract Expenses”) to make clear that other annual expenses are required to be disclosed (not just other portfolio company annual expenses, as the current instruction provides). In a conforming change, we are also revising an instruction in Form N-3 regarding when expense reimbursements or fee waiver arrangements that reduce operating expenses can be reflected to parallel a similar instruction in Form N-1A. 
                            <E T="03">Compare</E>
                             Instruction 15(e) to Item 4 of amended Form N-3 
                            <E T="03">with</E>
                             Instruction 3(e) to Item 3 of Form N-1A.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Other Expenses.</E>
                         Similarly, and in a change from the proposal, “Other Expenses” remains a separate line-item in Form N-3 and is not consolidated as part of “Base Contract Expenses.” Registrants on Form N-3 are management investment companies and are subject to certain expenses that do not apply to unit investment trust registrants on Form N-4 and N-6. Because such expenses can vary over time, we believe it may be helpful for investors to continue to see such expenses as part of a separate line-item rather than consolidated as part of Base Contract Expenses.
                    </P>
                    <P>
                        • 
                        <E T="03">Management Fees.</E>
                         Unlike Forms N-4 and N-6, which as discussed below require separate disclosures about annual portfolio company expenses, Form N-3 does not require such disclosures because Form N-3 registrants have a single-tier structure and do not have underlying portfolio companies. However, Form N-3 registrants generally do have distinct management fees for each investment option offered under the contract. Since these management fees can vary significantly, we are requiring disclosure of the management fee for each investment option, as proposed.
                        <SU>650</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>650</SU>
                             
                            <E T="03">See</E>
                             Instruction 7 to Item 4 of amended Form N-3.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Optional Benefits.</E>
                         In recognition of the fact that variable contracts today commonly offer optional benefits, the table in Forms N-3, N-4, and N-6 requires, as proposed, a new line-item that requires registrants to list any optional benefit available under the contract, along with its corresponding annual charge.
                        <SU>651</SU>
                        <FTREF/>
                         In Form N-6, this same new line-item, as proposed, is added in the “Periodic Charges Other Than Portfolio Company Operations Expenses” table.
                        <SU>652</SU>
                        <FTREF/>
                         One commenter suggested that insurers should be permitted, but not required, to include benefits available at no additional charge in the Fee Table.
                        <SU>653</SU>
                        <FTREF/>
                         We believe that inclusion of these benefits could add complexity and length to the Fee Table and obscure significant fees that are more relevant to investors, and therefore benefits available at no additional charge are neither required nor permitted to be included in the Fee Table. As discussed further below, registrants that wish to itemize all these 
                        <PRTPAGE P="26019"/>
                        benefits can do so in their disclosure of benefits available under the contract.
                        <SU>654</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>651</SU>
                             
                            <E T="03">See</E>
                             Instruction 14 to Item 4 of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>652</SU>
                             
                            <E T="03">See</E>
                             Instruction 3.(f) to Item 4 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>653</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>654</SU>
                             
                            <E T="03">See infra</E>
                             text following note 742.
                        </P>
                    </FTNT>
                    <P>
                        • 
                        <E T="03">Total Annual Contract Expenses.</E>
                         In Form N-3, we are adopting, as proposed, a new requirement to disclose total annual contract expenses, and a related instruction specifying that total annual contract expenses should be disclosed as a percentage of account value.
                        <SU>655</SU>
                        <FTREF/>
                         While annual contract expenses are generally calculated as a percentage of account value, optional benefit expenses may be calculated on a different basis, such as a percentage of the benefit base or as a percentage of average net assets. The new instruction provides that if optional benefit expenses are calculated on a basis other than account value, registrants should prominently indicate that those optional benefit expenses are not included in total annual contract expenses (because they are calculated on different bases and cannot be added). However, we understand that most registrants on Form N-3 either do not offer optional benefits or else calculate optional benefit expenses on an account value basis. We therefore believe that requiring disclosure of total annual contract expenses is appropriate for Form N-3 registrants, because the disclosure will be practicable and could help investors understand the total expenses (not including portfolio company fees and expenses) that they will pay each year. The requirement to disclose total annual contract expenses in Form N-3 differs from the approach to disclosing annual contract expenses in amended Form N-4, which requires separate line-items for administrative expenses, base contract expenses, and optional benefit expenses, but does not require the disclosure of a composite total of these line-items.
                        <SU>656</SU>
                        <FTREF/>
                         We understand that most registrants on Form N-4 calculate optional benefit expenses on a basis other than contract value. Because of this, it would generally be infeasible to sum optional benefit expenses with other expenses that are presented as annual contract expense line-items.
                    </P>
                    <FTNT>
                        <P>
                            <SU>655</SU>
                             
                            <E T="03">See</E>
                             Instruction 16 to Item 4 of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>656</SU>
                             
                            <E T="03">See</E>
                             “Annual Contract Expenses” table in Item 4 of amended Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">iv. Annual Portfolio Company Expenses (Forms N-4 and N-6)</HD>
                    <P>
                        Largely as proposed, we are amending the disclosures that registrants provide with respect to the “Annual Portfolio Company Expenses” table in FormsN-4 and N-6.
                        <SU>657</SU>
                        <FTREF/>
                         As proposed, we are revising the legend that precedes the table to direct investors to the new Appendix relating to the portfolio companies available under the contract.
                        <SU>658</SU>
                        <FTREF/>
                         As a conforming change, and as proposed, we are eliminating an instruction in each form stating that a registrant may include additional tables showing annual expenses separately for each portfolio company immediately following the required table, as this information will duplicate the fee information that appears in the new Appendix.
                        <SU>659</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>657</SU>
                             While the text of the Proposing Release only mentioned Form N-4 with regards to this item, both Forms N-4 and N-6 themselves, as proposed, included the changes that we indicate “as proposed.”
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>658</SU>
                             
                            <E T="03">See</E>
                             Item 17 to amended Form N-4; Item 18 to amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>659</SU>
                             
                            <E T="03">See</E>
                             Instruction 20 to Item 3 in Form N-4; Instruction 4.(f) to Item 3 in Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        In a change from the proposal, and in response to commenters, a new instruction in each form provides that if the registrant charges a platform charge to make any of the portfolio companies available as investment options under the contract, the registrant should include the maximum platform charge associated with each portfolio company when calculating minimum and maximum annual portfolio company expenses.
                        <SU>660</SU>
                        <FTREF/>
                         In a conforming change, we are also revising the name of this table from “Total Annual Portfolio Company Operating Expenses” to “Annual Portfolio Company Expenses” to clarify that the expenses included within the table are not limited to total operating expenses. If platform charges are charged, registrants must also provide a brief statement regarding the inclusion of these platform charges.
                        <SU>661</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>660</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Letter (asking how “fund facilitation fees” should be disclosed, and stating these fees are charged by the insurance company for offering a low cost fund that would not otherwise provide sufficient distribution fees or revenue sharing to the insurance company); Instruction 16 to Item 4 of amended Form N-4; Instruction 4.(a) to Item 4 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>661</SU>
                             
                            <E T="03">See</E>
                             Item 4 of amended Form N-4 (“[These amounts also include applicable Platform Charges if you choose to invest in certain Portfolio Companies.”]); Item 4 of amended Form N-6 (same).
                        </P>
                    </FTNT>
                    <P>
                        We are also simplifying other instructions to the table. As proposed, we are revising an instruction in each form to instruct registrants to use the gross expense ratio presented in the fee table of a portfolio company's current prospectus when disclosing the minimum and maximum “Annual Portfolio Company Expenses.” 
                        <SU>662</SU>
                        <FTREF/>
                         The current instruction contains instructions for calculating Annual Portfolio Company Expenses, which results in a figure that is the same as the gross expense ratio presented in a portfolio company's prospectus fee table. Directing registrants to use the gross expense ratio reflected in a portfolio company's current prospectus avoids the need to provide detailed instructions in the form regarding how to calculate this figure (as is the case with the current instruction).
                        <SU>663</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>662</SU>
                             
                            <E T="03">See</E>
                             Instruction 17(a) to Item 3 of Form N-4 (which we are re-designating as Instruction 16 to Item 4 of amended Form N-4); Instruction 4.(b) to Item 3 of Form N-6 (which we are re-designating as Instruction 4.(a) to Item 4 of amended FormN-6).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>663</SU>
                             Because this simplification renders obsolete the rest of Instruction 17, as well as Instructions 16 and 18, to Item 3 of Form N-4, we are eliminating them. Similarly, this simplification renders obsolete the rest of Instruction 4.(b), as well as Instructions 4.(c) through (d), to Item 3 of Form N-6, and therefore we are eliminating those instructions as well.
                        </P>
                    </FTNT>
                    <P>
                        Also, as proposed, we are revising an instruction in each form to modify the way that registrants could reflect operating expenses that include expense reimbursement or fee waiver arrangements.
                        <SU>664</SU>
                        <FTREF/>
                         Currently, the instruction specifies that such expenses could appear in a footnote to the table. The revised instruction instead states that these could appear as an additional line-item to the table. We believe that including these disclosures as a separate line-item in the table provides a clearer presentation for investors than a footnote to the table.
                        <SU>665</SU>
                        <FTREF/>
                         In a change from the proposal, and in response to commenters, this instruction also provides that if the registrant charges a platform charge to make any of the portfolio companies available as investment options under the contract, the registrant should include the current platform charge associated with each portfolio company when calculating minimum and maximum annual portfolio company expenses that include expense reimbursement or fee waiver arrangements.
                        <SU>666</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>664</SU>
                             
                            <E T="03">See</E>
                             Instruction 19 to Item 3 of Form N-4 (which we are renumbering as Instruction 17 to Item 4 of amended Form N-4); Instruction 4.(e) to Item 3 of Form N-6 (which we are renumbering as Instruction 4.(b) to Item 4 of amended Form N-6).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>665</SU>
                             
                            <E T="03">See</E>
                             2002 Adopting Release, 
                            <E T="03">supra</E>
                             note 286, at n.14 and accompanying text (“We intend that the staff construe the amendments to the fee table of Form N-4 consistent with the approach taken under Form N-1A, to permit the addition of one line to the fee table showing the range of net Portfolio Company operating expenses after taking account of contractual limitations that require reimbursement or waiver of expenses.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>666</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Letter. 
                            <E T="03">See</E>
                             Instruction 17 to Item 4 of amended Form N-4; Instruction 4.(b) to Item 4 of amended Form N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">v. Example (Forms N-3 and N-4)</HD>
                    <P>
                        We are updating the requirements for the Example that will appear in the Fee Table in Forms N-3 and N-4 in several respects. First, as proposed, we are revising the legend accompanying the 
                        <PRTPAGE P="26020"/>
                        Example to reflect the revised Fee Table headings and to reference the inclusion of optional benefits in the Example's assumptions. We believe the Example should reflect the highest cost that an investor may pay under the contract, inclusive of any available optional benefits.
                    </P>
                    <P>
                        As proposed, we are increasing the value of the assumed investment from $10,000, as required under Item 3 of current Form N-4 (and $1,000, as required under Item 3 of current Form N-3), to $100,000. Several commenters objected to this change but, as discussed above, we continue to believe that $100,000 more closely approximates the current average value of a variable annuity and is more likely to result in cost projections that align with actual investor expectations and experience.
                        <SU>667</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>667</SU>
                             
                            <E T="03">See supra</E>
                             note 131 and accompanying and following text.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are revising the instructions for the Example to clarify that registrants must provide an example for each contract class, consistent with current practice.
                        <SU>668</SU>
                        <FTREF/>
                         Also, as proposed, we are revising Instruction 21(b) in current Form N-4 (which we are re-numbering as Instruction 18(b)), and adding new Instruction 17(b) in Form N-3, to make clear that that an example showing the most expensive combination of contract features should be shown first, while additional expense examples are permitted, but not required.
                    </P>
                    <FTNT>
                        <P>
                            <SU>668</SU>
                             The instruction for the Example in Item 3 of current Form N-3 (currently unnumbered) is new Instruction 17 to Item 4 of amended Form N-3. Instruction 21 to Item 3 of current Form N-4 is renumbered as Instruction 18 to Item 4 of amended Form N-4.
                        </P>
                    </FTNT>
                    <P>In addition, as proposed, we are removing the last sentence of Instruction 21(b) of current Form N-4, which states that in lieu of providing the required example based on maximum portfolio company expenses, a registrant may include separate expense examples based on the expenses of each portfolio company. In our experience, registrants rarely include separate expense examples based on the expense of each portfolio company (likely because to do so would add extensive length to the Example section of the prospectus). Eliminating this option therefore not only reflects actual practice, but is also consistent with our goal of streamlining prospectus disclosure.</P>
                    <P>
                        As proposed, we are also making certain technical corrections to Instructions 21(a) and (b) of current Form N-4, by eliminating references to amortization costs, which do not apply to variable annuity contracts that are structured as UITs.
                        <SU>669</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>669</SU>
                             When Forms N-3 and N-4 were first adopted, the references in Form N-3 to amortization costs were inadvertently included in Form N-4. Because investors in UITs (Form N-4 and N-6 filers) do not pay amortization costs, we are removing this reference from the instruction. In a conforming change, we are also revising an instruction in Form N-3 regarding amortization of organizational expenses to parallel similar instructions in FormN-1A. 
                            <E T="03">Compare</E>
                             Instruction 17(a) to Item 4 of amended Form N-3 
                            <E T="03">with</E>
                             Instruction 4(a) to Item 3 of Form N-1A.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">vi. Portfolio Turnover (Form N-3)</HD>
                    <P>
                        Because Form N-3 registrants have a single-tier structure, investors do not receive separate prospectuses containing portfolio turnover information for investment options offered under the contract, as is the case for portfolio companies offered under contracts registered on Forms N-4 and N-6. As proposed, we are requiring disclosure of portfolio turnover for each investment option in Form N-3, as well as a brief statement explaining that portfolio turnover has associated transaction costs, and that a higher portfolio turnover rate may indicate higher transaction cost, which affect the investment option's performance.
                        <SU>670</SU>
                        <FTREF/>
                         These disclosure requirements largely restate existing requirements in caption 10 of Item 4(a) of current Form N-3, although they include the brief statement that is required by the parallel item in Form N-1A in order to provide more context and information for investors.
                        <SU>671</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>670</SU>
                             
                            <E T="03">See</E>
                             Item 4 of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>671</SU>
                             
                            <E T="03">See</E>
                             Item 3 of Form N-1A. The brief statement required by Form N-3 will not include the language from the parallel item in Form N-1A stating that a higher portfolio turnover rate may indicate higher taxes, because variable annuity products are tax-deferred and thus that language is inapplicable to registrants on Form N-3.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">vii. General Instructions (Forms N-3,N-4, and N-6)</HD>
                    <P>In addition to specific instructions associated with each of the tables and the Example(s) that appear in response to the amended Item 4 disclosure requirements, we are also updating the general instructions associated with this item.</P>
                    <P>
                        Instruction 1(a) to the Fee Table in current Form N-6 instructs registrants to round all dollar figures to the nearest dollar and all percentages to the nearest hundredth of one percent.
                        <SU>672</SU>
                        <FTREF/>
                         Because of the underwriting process inherent in variable life insurance contracts, rounding dollar figures to the nearest dollar for certain younger and healthier investors may result in disclosures of zero cost for certain fees, which may be misleading for investors. Therefore, as proposed, we are modifying this instruction to only require rounding percentages to the nearest hundredth of one percent.
                        <SU>673</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>672</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(a) to Item 3 of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>673</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(a) to Item 4 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        We are also, as proposed, revising Instruction 5 to the Fee Table in Form N-4 to state that if a fee is calculated based on a benchmark (
                        <E T="03">e.g.,</E>
                         a fee that varies according to volatility levels or Treasury yields), the registrant must disclose a maximum guaranteed charge as a single number. We believe that this revised instruction will help minimize confusion regarding how much an investor can expect to pay under the contract and will better assist investors in understanding the costs they will pay when investing in a variable annuity. Without this clarifying statement, registrants that offer variable annuity contracts that link certain fees to benchmarks might seek only to present the maximum fee as a range (
                        <E T="03">e.g.,</E>
                         a certain percentage plus or minus a stated benchmark).
                        <SU>674</SU>
                        <FTREF/>
                         Under the revised instruction, a registrant that chooses to disclose the fee range (
                        <E T="03">e.g.,</E>
                         a fee that varies based on the 10-year Treasury rate) associated with a particular feature could do so, as long as it also discloses the maximum possible charge (
                        <E T="03">e.g.,</E>
                         3%). We are also, as proposed, adding a parallel provision to Form N-3 as Instruction 5 to the Fee Table.
                    </P>
                    <FTNT>
                        <P>
                            <SU>674</SU>
                             Our staff has observed that some registrants disclose a fee range for certain optional benefits based on a benchmark (
                            <E T="03">e.g.,</E>
                             a fee that varies according to volatility levels or Treasury yields), without also disclosing a firm cap on the maximum amount an investor may have to pay for that contract feature.
                        </P>
                    </FTNT>
                    <P>
                        As part of our effort to update the Fee Table, we are, as proposed, modifying current Instruction 1.(f) to the Fee Table in Form N-3 and Instruction 6 to the Fee Table in Form N-4 to eliminate language that is redundant in light of new General Instruction C.3.(e) of both forms.
                        <SU>675</SU>
                        <FTREF/>
                         We are also including new Instruction 7 to the Fee Table in Forms N-3 and N-4, which requires registrants offering a contract with more than one class to provide fee and expense information for each class (and, for Form N-3 registrants, to require 
                        <PRTPAGE P="26021"/>
                        registrants offering more than one investment option to provide a separate response for each investment option).
                        <SU>676</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>675</SU>
                             We are removing from Instruction 6 to Item 3 of current Form N-4 and Instruction 1.(f) to Item 3 of current Form N-3 the statement that “[i]f a Registrant uses one prospectus to offer a contract in both the group and individual variable annuity contract markets, the Registrant may a) add narrative disclosure following the fee table identifying markets where certain fees are either inapplicable or waived or lower fees charged to investors in group markets, or b) provide a separate fee table for group and individual contracts,” because amended General Instruction C.3.(e) of Forms N-3 and N-4 will address the registration of multiple contracts.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>676</SU>
                             This harmonizes the instructions associated with the Fee Table for Forms N-3 and N-4 with parallel instructions in Form N-1A. 
                            <E T="03">See</E>
                             Instruction 1(d)(ii) to Item 3 of Form N-1A (“If the prospectus offers more than one Class of a Multiple Class Fund or more than one Feeder Fund that invests in the same Master Fund, provide a separate response for each Class or Feeder Fund.”).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">viii. Instructions for New Variable Contract Registrants (Forms N-3, N-4, and N-6)</HD>
                    <P>Finally, as proposed, we are eliminating certain instructions in Item 3 of current Forms N-3, N-4, and N-6 relating to new variable contract registrants. Specifically, we are eliminating Instructions 4(d)(i), 4(f)(ii), 4(g)(vi) and Instruction (f) under “Example” in Form N-3, Instruction 22 of Form N-4, and Instruction 5 of Form N-6 as the staff has found these instructions to be unnecessary.</P>
                    <P>For example, Instruction 4(d)(i) to Item 3 of current Form N-3, Instruction 22(a) to Item 3 of current Form N-4, and Instruction 5(a) to current Item 3 of Form N-6 instruct a registrant to base the percentages in the Annual Portfolio Company Expenses table on estimated amounts for the current fiscal year, but we understand that these operating expenses need not be estimated because they do not vary based on whether the registrant is new or already exists. Likewise, Instructions 4(f)(ii) and 4(g)(vi) to Item 3 of current Form N-3, Instruction 22(b) to Item 3 of current Form N-4, and Instruction 5(b) to Item 3 of current Form N-6 state that a new registrant may disclose any expense reimbursement or fee waiver arrangements that are expected to reduce the expenses that the table would show. Because Instruction 15(e) in Item 4 of amended Form N-3, Instruction 17 in Item 4 of amended Form N-4, and Instruction 4(b) in Item 4 of amended Form N-6 address this same issue, and we do not see a reason to distinguish between new and existing registrants for this purpose, these current Instructions are unnecessary.</P>
                    <P>Lastly, Instruction (f) under the “Example” in Item 3 of current Form N-3 and Instruction 22(c) to Item 3 of current Form N-4 state that new registrants must only complete the 1- and 3- year period portions of the Example and estimate any annual contract fees collected. However, because variable contract charges at the separate account level are contractual and do not vary based on whether the variable contract registrant is new or existing, we believe a new registrant's Example should include the full 1-,3-, 5-, and 10-year periods required of existing registrants. For these reasons, we are, as proposed, eliminating these current Instructions in their entirety from the forms.</P>
                    <HD SOURCE="HD3">e. Accumulation Unit Value Disclosure (Not Included in Amended Forms N-3 and N-4)</HD>
                    <P>
                        In a change from the proposal, we are eliminating the requirement in Forms N-3 and N-4 for a registrant to disclose, for the last ten fiscal years and for each subaccount, the accumulation unit value at the beginning and end of each period and the number of accumulation units outstanding at the end of each period (the “AUV tables”).
                        <SU>677</SU>
                        <FTREF/>
                         For variable annuity contracts, the change in accumulation unit value provides a measure of performance of the registrant's sub-accounts.
                        <SU>678</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>677</SU>
                             Item 4(a) of current Form N-3; Item 4(a) of current Form N-4. The Commission had proposed to relocate the disclosures required by these items from the prospectus to the SAI, with certain other modifications. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.D.3.d.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>678</SU>
                             When Form N-6 was proposed, it did not include AUV tables “[b]ecause [due to] the individual nature of variable life insurance charges, such as the cost of insurance, there does not appear to be a comparable measure of performance that is applicable to all holders of a particular variable life insurance policy.” 
                            <E T="03">See</E>
                             Form N-6 Proposing Release, 
                            <E T="03">supra</E>
                             note 688, at 17.
                        </P>
                    </FTNT>
                    <P>
                        When the AUV tables were adopted in 1985, the approach did not anticipate the proliferation of variations in contract charges and optional benefits that has resulted in numerous possible combinations of contract charges.
                        <SU>679</SU>
                        <FTREF/>
                         Since registrants commonly maintain a separate class of accumulation units for each combination of separate account charges, the AUV tables add considerable length (sometimes hundreds of pages) to the contract prospectus, which may overwhelm other important information.
                        <SU>680</SU>
                        <FTREF/>
                         Because only one combination of contract charges is relevant to any individual investor (depending on the contract features he or she selects), much of the required disclosure is of limited value to most investors.
                        <SU>681</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>679</SU>
                             
                            <E T="03">See</E>
                             Forms N-3 and N-4 Adopting Release, 
                            <E T="03">supra</E>
                             note 29.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>680</SU>
                             As discussed in the Proposing Release, the staff issued a no-action letter stating that the staff would not recommend enforcement action if registrants were to depict in the prospectus only two classes of unit values (one reflecting the highest possible combination of contract charges, the other reflecting the lowest possible combination of contract charges) shown for each available portfolio company, so long as the SAI were to include the full disclosure that current Item 4 would require. 
                            <E T="03">See</E>
                             Nationwide Life Insurance Company, SEC Staff No-Action Letter (pub. avail. Mar. 16, 2001) (“Nationwide 2001 Letter”). With the elimination of the AUV table requirement, the Nationwide 2001 Letter is rendered moot, and this letter will be withdrawn.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>681</SU>
                             In addition, while the AUV tables are designed to reflect the performance of a subaccount after reflecting contract charges that are based on separate account value, many contract charges today are based on other values, such as a benefit base, which cannot be reflected in AUV values. Instead, when these charges are assessed, the number of accumulation units is reduced. As a result, AUV tables may only reflect a portion of a contract's fees, diminishing their usefulness to investors.
                        </P>
                    </FTNT>
                    <P>
                        Several commenters generally stated that the AUV tables do not include all the fees paid by investors because many of the fees are assessed at the contract level, rather than the unit level, and concluded that the AUV tables are confusing to investors, burdensome for insurers, and should be entirely eliminated.
                        <SU>682</SU>
                        <FTREF/>
                         In responding more specifically to the proposed amendments, one commenter stated that registrants would need to engage in massive system investments in order to provide investors with individualized subaccount performance for each subaccount held by that investor, and suggested the Commission should revise its proposed amendments to: (1) Reduce the information required to be included in AUV tables included in registration statements; (2) reduce the information required to be included in account statements for those registrants who wish to provide AUV information there instead of in registration statements; and (3) permit registrants to post AUV tables online rather than in registration statements.
                        <SU>683</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>682</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; Transamerica Comment Letter; IRI Comment Letter II; CAI Comment Letter (stating that while the AUV tables are designed to reflect the performance of a sub-account after reflecting contract charges that are based on separate account value, many contract charges today are based on other values (such as benefit base), and thus instead of these charges reducing the value of a particular class of accumulation units, the assessment of these charges reduces the number of accumulation units in an investor's account).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>683</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        After considering the points raised by commenters and reevaluating the continued utility of these disclosures, we have decided to eliminate the AUV table requirement for variable annuities in its entirety. Although AUV tables served a helpful role at the time those requirements were initially adopted, the current proliferation of variations in optional benefits and contract charges has resulted in AUV tables which in some cases span hundreds of pages in order to encompass all such possible combinations, even though only one combination of optional benefits and contract charges would be applicable to a given investor. In addition, there are separate AUVs for each investment 
                        <PRTPAGE P="26022"/>
                        option based on those individual combinations of optional benefits, further complicating efforts to understand the net performance of the overall account. Further, to the extent an investor seeks to understand the net performance of any individual option, the investor could much more easily get the summary information that is provided in the Appendix to the summary prospectus.
                        <SU>684</SU>
                        <FTREF/>
                         Our decision to eliminate AUV tables is also consistent with our overarching goals of this rule adoption, which are to streamline the forms for variable contracts and to provide investors with pertinent information that is most likely to be used by, and useful to, them.
                    </P>
                    <FTNT>
                        <P>
                            <SU>684</SU>
                             Variable annuities issued through managed separate accounts have not offered optional benefits. Owners of these annuities, however, generally have several investment options to choose from, with the result that understanding the value of their investment in the annuity would require working with several accumulation unit values.
                        </P>
                    </FTNT>
                    <P>
                        When the registration form for variable life insurance contracts was adopted in 2002, the Commission determined not to require disclosure of AUV tables for variable life prospectuses, The Commission recognized that the individualized nature of variable life insurance charges (
                        <E T="03">i.e.,</E>
                         as part of the underwriting process, charges are assessed individually to each investor based on his or her particular characteristics) made it difficult to provide measures of performance that applied were meaningful across the full investor base.
                        <SU>685</SU>
                        <FTREF/>
                         Similarly, because of the numerous permutations of variable annuity contract charges today (due to classes of contracts, availability of multiple optional benefits, etc.), it is difficult to provide a standard set of disclosures that are relevant to the investor base at large of a particular variable annuity contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>685</SU>
                             
                            <E T="03">See</E>
                             Separate Accounts Offering Variable Life Release, 
                            <E T="03">supra</E>
                             note 29.
                        </P>
                    </FTNT>
                    <P>In addition, while the AUV tables are designed to reflect the performance of a sub-account after reflecting contract charges that are based on separate account value, we recognize many contract charges today are based on other values (such as benefit base), which cannot be reflected in AUV values. Instead of these charges reducing the value of a particular class of accumulation units, the assessment of these charges reduces the number of accumulation units in an investor's account.</P>
                    <P>Moreover, we understand that registrants currently provide investors with periodic disclosures about their investments in the contract that include sub-account related information, such as account statements that disclose the number of each class of accumulation units and the dollar value of each such class. Although such disclosures generally do not include the actual performance of each subaccount, we understand that such measures of performance would be difficult to generate and may not be necessary given the other disclosures provided to investors.</P>
                    <P>
                        After considering the limited utility of the AUV table disclosures to investors (as well as to Commission staff) and the substantial burdens necessary for registrants to prepare them, we have decided to eliminate the requirement for these disclosures in their entirety rather than move them to the SAI as proposed (or require them to be posted online as suggested by commenters). As discussed above, however, we are adopting the other amendments to this item (
                        <E T="03">i.e.,</E>
                         re-designating Item 4(c) of current Form N-3 and Item 4(b) of current Form N-4 as Items 17 and 16, respectively) as proposed.
                        <SU>686</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>686</SU>
                             
                            <E T="03">See supra</E>
                             note 779; Item 17 of amended Form N-3 and Item 16 of amended Form N-4; 
                            <E T="03">see also infra</E>
                             Section II.C.2.s.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">f. Principal Risks of Investing in the Contract (Item 5 of Forms N-3, N-4, and N-6)</HD>
                    <P>
                        As proposed, we are adding new Item 5 to Forms N-3 and N-4, which requires registrants to summarize the principal risks of purchasing a contract, including the risks of poor investment performance, that contracts are unsuitable as short-term savings vehicles, limitations on access to cash value through withdrawals, and the possibility of adverse tax consequences. The new disclosure item for Forms N-3 and N-4 generally mirrors Item 2(b) of current Form N-6 (which we are re-designating as Item 5), with the exception of the risk of contract lapse.
                        <SU>687</SU>
                        <FTREF/>
                         Although registrants currently include risk disclosures in their prospectuses without an explicit form requirement to do so, in some cases the risk discussions are provided across various sections of the prospectus. We believe the approach taken in Form N-6 of requiring a consolidated summary of the principal risks associated with the contract provides more effective communication of risks to investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>687</SU>
                             We are not including risk of contract lapse in Item 5 of amended Form N-3 or amended FormN-4 because lapse, which occurs when there is insufficient cash value to pay insurance policy charges, is a less significant risk for variable annuities. Lapse is a greater risk for variable life insurance contracts, which, unlike variable annuities, generally require continuing premium payments (failure to pay premiums generally triggers a lapse and terminates the contract). In addition, the expenses associated with the death benefit for a variable life insurance contract tend to be higher than those for a variable annuity (in proportion to contract cash value). Higher expenses more quickly erode a variable life insurance contract's cash value, which if insufficient to pay policy charges, will cause the contract to lapse.
                        </P>
                    </FTNT>
                    <P>
                        Although current Form N-6 requires risk disclosures to be presented in a summary section at the front of the statutory prospectus, we are requiring for each registration form that the risk section be provided after the Key Information Table and Fee Table. While the Key Information Table includes a condensed discussion of contract risks, new Item 5 gives registrants the flexibility to describe the principal risks of investing in the contract in more detail than what could reasonably appear in a table meant to summarize the contract's key risks and features. While we are not limiting the length of the summary of principal risks in response to new Item 5, we believe that the utility of a summary would be undermined by the long, complex descriptions we sought to avoid when we adopted the summary principal risk section as part of Form N-6.
                        <SU>688</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>688</SU>
                             
                            <E T="03">See</E>
                             Registration Form for Insurance Company Separate Accounts Registered as Unit Investment Trusts that Offer Variable Life Insurance Policies, Investment Company Act Release No. 23066 (Mar. 13, 1998) [63 FR 13988 (Mar. 23, 1998)] (“FormN-6 Proposing Release”), at n.8 (noting that “[v]ariable life insurance prospectuses generally disclose [information required under the item as proposed], particularly risk information, in the context of long, often complex descriptions of the policy. The Commission believes that the proposed narrative summary will help achieve more effective communication of risks.”).
                        </P>
                    </FTNT>
                    <P>
                        One commenter asked whether the inclusion of a consolidated principal risk section meant that registrants were permitted, but not required, to repeat principal risks elsewhere throughout the prospectus.
                        <SU>689</SU>
                        <FTREF/>
                         The commenter also asked whether non-principal risks needed to be included in the principal risk section.
                    </P>
                    <FTNT>
                        <P>
                            <SU>689</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        The principal risks section is designed to provide a consolidated presentation of principal risks which can be cross-referenced by registrants to reduce repetition that might otherwise occur if the same principal risks are repeated in different sections of the prospectus. For example, in order to facilitate the ability of investors to understand principal risks in the context of other, related disclosures, a variable life insurance registrant disclosing other benefits available under the contract could briefly mention and cross-reference the relevant principal risks discussion of limitations on death benefits due to war or active duty service in the military. At the same 
                        <PRTPAGE P="26023"/>
                        time, we believe that the inclusion of non-principal risks (that are not otherwise required to be disclosed in the prospectus) could add complexity and length to the prospectus and obscure principal risks that are more relevant to investors, and therefore such non-principal risks are neither required nor permitted to be included in the prospectus.
                        <SU>690</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>690</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(b) of Forms N-3, N-4, and N-6; 
                            <E T="03">see also supra</E>
                             note 596.
                        </P>
                    </FTNT>
                    <P>In drafting their principal risk disclosures, registrants generally should consider approaches that may improve these disclosures for investors. For example, we encourage registrants to:</P>
                    <P>• List their principal risks in order of importance rather than alphabetically;</P>
                    <P>• Tailor their risk disclosures to the particular contract offered, as opposed to providing generic, standardized risk disclosures or risks that generally are not inherent in an investment in the contract;</P>
                    <P>• Consider disclosing that the contract is not appropriate for certain investors given the particular characteristics of the contract; and</P>
                    <P>
                        • Periodically review their risk disclosures, including the order of their risks, and consider whether the disclosures remain adequate in light of the contract's characteristics and market conditions.
                        <SU>691</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>691</SU>
                             
                            <E T="03">See also</E>
                             ADI 2019-08, SEC, Improving Principal Risks Disclosure (last modified Sept. 9, 2019), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.sec.gov/investment/accounting-and-disclosure-information/principal-risks/adi-2019-08-improving-principal-risks-disclosure</E>
                            <E T="03"/>
                             (providing views of the Division of Investment Management regarding mutual fund principal risk disclosures).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">g. General Description of Registrant, Depositor, and Investment Options/Portfolio Companies (Item 6 of Forms N-3, N-4, and N-6)</HD>
                    <P>
                        As proposed, we are amending Item 5 of current Forms N-3 and N-4, and Item 4 of current Form N-6, which we are re-designating as Item 6 in each of the registration forms. Reflecting the more up-to-date requirements of the parallel item of current Form N-6, we are amending Forms N-3 and N-4 to relocate certain information from the prospectus to the SAI: (1) With respect to the depositor, a description of the general nature of its business, its date and form of organization and the state or other jurisdiction under which it is organized, and information relating to persons controlling the depositor; and (2) with respect to the registrant, its date and form of organization and classification pursuant to Section 4 of the Investment Company Act, and whether there are sub-accounts of the registrant.
                        <SU>692</SU>
                        <FTREF/>
                         In addition, for consistency with Form N-6 and our newer registration forms,
                        <SU>693</SU>
                        <FTREF/>
                         in Forms N-3 and N-4 we are relocating the requirement to identify and state the principal business address of any person who provides significant administrative or business affairs management services, and a description of those services, from the prospectus to the SAI.
                        <SU>694</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>692</SU>
                             Item 6(a) and (b) of amended Forms N-3 and N-4; Item 21(a) and (b) of amended Form N-3; Item 19 of amended Form N-4; 
                            <E T="03">see also</E>
                             Item 5(a) and 5(b) of current Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>693</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 17(c) of current Form N-6; Item 19(h) of Form N-1A.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>694</SU>
                             
                            <E T="03">See</E>
                             Item 24(g) of amended Form N-3; Item 20(c) of amended Form N-4.
                        </P>
                    </FTNT>
                    <P>
                        One commenter noted that our proposed amendments would not affect current prospectus requirements to concisely describe investor rights to instruct the voting of portfolio company shares.
                        <SU>695</SU>
                        <FTREF/>
                         The commenter asserted that this disclosure is largely boilerplate and is typically carried forward each year without change or modification, and recommended that this disclosure be moved to the SAI. We are retaining this disclosure in the prospectus as proposed. We believe that this disclosure provides important information to investors of their rights in this regard, and that the prospectus, rather than the SAI, is the more appropriate location for the disclosure.
                    </P>
                    <FTNT>
                        <P>
                            <SU>695</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter. Under an exemptive provision of the Investment Company Act that insurers serving as depositors of separate accounts organized as unit investment trusts rely on to operate the separate account, those insurers are restricted in how they vote shares of investment companies held on behalf of contract owners. Specifically, Section 12(d)(1)(E) of the Investment Company Act conditionally allows separate accounts organized as unit investment trusts to establish subaccounts each holding shares of an investment company, without violating the limitations in Section 12(a)(1)(A) of the Investment Company Act on investment company ownership. Under one of the conditions, the separate account must either seek instructions from contract owners with regard to the voting of all proxies for the investment company shares held by the subaccount or vote the shares it holds of that investment company in the same proportion as the vote of all other shareholders of that investment company. 
                            <E T="03">See</E>
                             Section 12(d)(1)(E)(iii)(aa).
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also amending the information required by the current item in Forms N-4 and N-6 regarding portfolio companies (and for Form N-3, investment options).
                        <SU>696</SU>
                        <FTREF/>
                         As discussed below, and as proposed, we are moving the summary of certain information about the portfolio companies and investment options to an Appendix in the prospectus.
                        <SU>697</SU>
                        <FTREF/>
                         Therefore, with respect to Forms N-4 and N-6, we are revising this item to replace the current requirement to briefly describe each portfolio company 
                        <SU>698</SU>
                        <FTREF/>
                         with a requirement to state that certain information about the portfolio companies is available in the Appendix and to cross-reference that Appendix, to further state that more detailed information is available in the portfolio companies' prospectuses, and to explain how investors may obtain copies of those prospectuses.
                        <SU>699</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>696</SU>
                             Item 5(c) through (e) of current Form N-3; Item 5(c) and (d) of current Form N-4; Item 4(c) and (d) of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>697</SU>
                             
                            <E T="03">See infra</E>
                             Section II.C.2.r (discussing Item 17 of amended Form N-3, Item 16 of amended Form N-4, and Item 18 of amended Form N-6).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>698</SU>
                             
                            <E T="03">See</E>
                             Item 5(c) of current Form N-4; Item 4(c) of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>699</SU>
                             Item 6(c) of amended Forms N-4 and N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, new Item 18 of Form N-3 similarly requires a comparable Appendix of investment options, but only if the Appendix is included in a summary prospectus.
                        <SU>700</SU>
                        <FTREF/>
                         Registrants also must include more detailed disclosures about investment options as required by new Item 19, as proposed. New Item 19 generally includes the disclosures required by current Item 5(c) through (e) regarding investment objectives and policies and principal risk factors associated with investing, as well as additional disclosures regarding the performance of each investment option.
                        <SU>701</SU>
                        <FTREF/>
                         Similar to Forms N-4 and N-6, amended Item 6 requires a Form N-3 registrant to state that certain information about the investment options is available in the Appendix (pursuant to new Item 18) or elsewhere in the prospectus (pursuant to new Item 19), and provide cross-references as appropriate.
                    </P>
                    <FTNT>
                        <P>
                            <SU>700</SU>
                             Instruction 1(c) to new Item 18 of amended Form N-3; 
                            <E T="03">see also supra</E>
                             text accompanying notes 331 and 388. As discussed above, the summary prospectus disclosure requirements are designed to substantively track parallel disclosure requirements in the statutory prospectuses to ensure that the summary prospectus disclosures are subject to liability under Section 11 of the Securities Act. Requiring a registrant on Form N-3 that includes an Appendix in its summary prospectus to also include an Appendix in its statutory prospectus helps to further this goal. 
                            <E T="03">See generally</E>
                             Section II.A.8.(c) (discussing investor protection and liability under Section 11).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>701</SU>
                             
                            <E T="03">See infra</E>
                             text following note 796 (discussing the disclosure requirements of new Item 19 of amended Form N-3).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">h. Charges (Item 8 of Form N-3, Item 7 of Forms N-4 and N-6)</HD>
                    <P>
                        Largely as proposed, we are amending Item 7 of current Form N-3 and Item 6 of current Form N-4 (which we are re-titling, and re-designating as Item 8 (in the case of Form N-3) and Item 7 (in the case of Form N-4)) to reflect the more up-to-date requirements of the parallel item of current Form N-6.
                        <SU>702</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>702</SU>
                             
                            <E T="03">See</E>
                             Item 5 of current Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, paragraph (a) expands the disclosure requirements of the 
                        <PRTPAGE P="26024"/>
                        current item in Forms N-3 and N-4 to include certain additional disclosure requirements that currently appear in the parallel item of Form N-6. The amended items require a registrant to provide a brief description of charges deducted from “any other source” (in addition to charges specifically deducted from purchase payments, investor accounts or assets of the registrant, which is currently required). These additional charges could include, for example, contract loan charges and optional benefit charges. In addition, and as proposed, we are requiring that the registrant describe: (1) The frequency of deductions (
                        <E T="03">e.g.,</E>
                         daily, monthly or annually) for any recurring charges; and (2) the consideration provided for particular charges (
                        <E T="03">e.g.,</E>
                         use of sales load to pay distribution costs), to the extent it is possible to identify such consideration. We believe these additional disclosures could help alleviate investor confusion about costs by more specifically describing the types of charges that might be incurred under a variable annuity contract.
                    </P>
                    <P>
                        In addition, and as proposed, Instruction 1 to paragraph (a) of the amended item in Forms N-3 and N-4 requires a description of the factors affecting the computation of the amount of the sales load.
                        <SU>703</SU>
                        <FTREF/>
                         For contracts with a deferred sales load, Instruction 1 requires the registrant to describe the sales load as a percentage of the applicable measure of purchase payments (or other basis) that the deferred sales load may represent, rather than the amount withdrawn or surrendered. Additionally, and as proposed, registrants must identify any events that will cause the deduction of a deferred sales load (
                        <E T="03">e.g.,</E>
                         surrender or withdrawal). The description of any deferred sales load must include how the deduction will be allocated if the investor has allocated contract value among multiple sub-accounts and when, if ever, the sales load will be waived (
                        <E T="03">e.g.,</E>
                         if the contract provides a free withdrawal amount).
                    </P>
                    <FTNT>
                        <P>
                            <SU>703</SU>
                             This instruction is based on Instruction 1 to Item 5(a) of current Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also adding new Instruction 4 to paragraph (a) of the amended item of Forms N-3 andN-4.
                        <SU>704</SU>
                        <FTREF/>
                         If the contract's charge for premium taxes or other taxes varies according to jurisdiction, new Instruction 4 clarifies that identifying the range of current premium taxes or other taxes in this paragraph is sufficient.
                    </P>
                    <FTNT>
                        <P>
                            <SU>704</SU>
                             This instruction is based on Instruction 3 to Item 5(a) of current Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter noted that our proposed amendments would not revise the current requirement in paragraph (b) to state the commissions paid to dealers as a percentage of purchase payments.
                        <SU>705</SU>
                        <FTREF/>
                         The commenter suggested the Commission should revise this requirement to include upfront and trail commissions as well as other methods of compensation. We believe that registrants responding to this disclosure requirement currently already include all compensation provided to dealers because the wording of the current instruction does not limit or otherwise specify certain types of compensation and the disclosure, as adopted, mirrors that in Form N-1A, and do not believe that any further changes are needed to this disclosure requirement.
                        <SU>706</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>705</SU>
                             
                            <E T="03">See</E>
                             Anonymous Comment Letter III.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>706</SU>
                             
                            <E T="03">See</E>
                             Item 8(b) of amended Form N-3 (“State the commissions paid to dealers as a percentage of purchase payments.”); Item 7(b) of amended Forms N-4 and N-6 (same).
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also amending the item related to charges in each form to clarify that the required disclosures should relate to “current” charges.
                        <SU>707</SU>
                        <FTREF/>
                         Disclosure of “maximum” charges would be redundant because those charges are encompassed in the Fee Table that would be included in the prospectus.
                        <SU>708</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>707</SU>
                             
                            <E T="03">See</E>
                             Item 8(a) of amended Form N-3; Item 7(a) of amended Forms N-4 and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>708</SU>
                             
                            <E T="03">See</E>
                             Item 4 of amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        In addition, and largely as proposed, we are amending the item of Form N-6 relating to charges in two respects. First, as proposed, we are relocating disclosures on commissions paid to dealers from the SAI 
                        <SU>709</SU>
                        <FTREF/>
                         to the prospectus.
                        <SU>710</SU>
                        <FTREF/>
                         We believe that this disclosure, which is currently required in the prospectus under Forms N-3 and N-4,
                        <SU>711</SU>
                        <FTREF/>
                         is more appropriate in the prospectus due to potential conflict of interest concerns.
                    </P>
                    <FTNT>
                        <P>
                            <SU>709</SU>
                             Item 20(d) of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>710</SU>
                             Item 7(b) of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>711</SU>
                             
                            <E T="03">See</E>
                             Item 7(d) of current Form N-3; Item 6(d) of current Form N-4.
                        </P>
                    </FTNT>
                    <P>
                        Second, the Commission also proposed to require a description of the type of operating expenses for which the registrant is responsible,
                        <SU>712</SU>
                        <FTREF/>
                         which Forms N-3 and N-4 currently require in the prospectus.
                        <SU>713</SU>
                        <FTREF/>
                         One commenter suggested that this requirement is generally not relevant to contracts registered on Forms N-4 and N-6, because those contracts typically have charges deducted at the subaccount level as opposed to the registrant level.
                        <SU>714</SU>
                        <FTREF/>
                         In response to this comment we are modifying this disclosure requirement to cover “any” (as opposed to “the”) type of operating expense for which the registrant is liable. We believe this modification maintains comparability between the forms and also future-proofs the forms to the extent operating expenses may be deducted at the registrant level in the future. Operating expenses paid by the registrant can be significant, and we believe this is appropriate disclosure for an item discussing contract charges.
                    </P>
                    <FTNT>
                        <P>
                            <SU>712</SU>
                             Item 7(e) of proposed Form N-6. If organizational expenses of the registrant are to be paid out of its assets, this item also requires an explanation of how the expenses will be amortized and the period over which the amortization will occur.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>713</SU>
                             
                            <E T="03">See</E>
                             Item 7(f) of current Form N-3; Item 6(f) of current Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>714</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">i. General Description of the Contracts (Item 9 of Form N-3, Item 8 of Forms N-4 and N-6)</HD>
                    <P>As proposed, we are amending Item 8 of current Form N-3, Item 7 of current Form N-4, and Item 6 of current Form N-6 (which we are re-designating as Items 9, 8, and 8, respectively) to reflect the more up-to-date requirements of Form N-6 (in the case of the amendments to Forms N-3 and N-4) and also to harmonize this disclosure item with other amendments to the forms. Except as described below, we do not intend these amendments to significantly alter current disclosure obligations.</P>
                    <P>
                        As proposed, we are amending the current instruction to subparagraph (a) of Forms N-3 and N-4, which states that the registrant need not repeat rights that are described elsewhere in the prospectus, and replacing it with a new instruction to subparagraph (a) in each of the forms 
                        <SU>715</SU>
                        <FTREF/>
                         that requires registrants to disclose all material state variations and intermediary-specific variations (
                        <E T="03">e.g.,</E>
                         certain contract features that may vary by distribution channel). Due to differences in state insurance law, there may be significant variations in a contract based on the state in which a contract is offered. We have also observed that certain contract features may not be available through certain intermediaries.
                    </P>
                    <FTNT>
                        <P>
                            <SU>715</SU>
                             This new instruction is also being added to Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also revising current subparagraph (b) of Forms N-3 and N-4 regarding contract provisions and limitation in two ways.
                        <SU>716</SU>
                        <FTREF/>
                         First, we are requiring registrants to briefly describe any provisions and limitations 
                        <PRTPAGE P="26025"/>
                        for minimum contract value and the consequences of falling below that amount, because those consequences in some cases can be significant.
                        <SU>717</SU>
                        <FTREF/>
                         Second, we are modifying the current requirement in Forms N-3 and N-4 regarding exchanges of contracts to more broadly describe provisions or limitations on conversion or exchange of the contract for another contract (which could include a fixed or variable annuity or life insurance contract) as currently required by Form N-6.
                        <SU>718</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>716</SU>
                             In addition, subparagraph (b)(iii) of current Forms N-3 and N-4 is re-designated as subparagraph (b)(5) and revised to replace “exchanges” with “buyout offers” of variable annuity contracts, including interests of participations therein.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>717</SU>
                             Item 9(b)(1) of amended Form N-3; Item 8(b)(1) of amended Form N-4. For example, some contracts specify that if the contract's value falls below a certain threshold, the contract terminates and an investor's contract value is returned.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>718</SU>
                             Item 9(b)(4) of amended Form N-3 and related proposed instruction; amended Item 8(b)(4) of Form N-4 and related proposed instruction; 
                            <E T="03">see also</E>
                             Item 8(b)(3) and related instruction of amended Form N-6; Item 6(b)(3) of current Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also revising the disclosure requirement in each registration form to clarify that the existing requirement to describe any provisions and limitations on transfer of contract value between sub-accounts includes transfer programs, such as dollar-cost averaging, portfolio rebalancing, asset allocation programs, and automatic transfer programs.
                        <SU>719</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>719</SU>
                             Item 9(b)(3) of amended Form N-3; Item 8(b)(3) of amended Form N-4; Item 8(b)(2) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also newly requiring the prospectus to provide a description of the obligations under the contract that the insurer's general account funds (
                        <E T="03">e.g.,</E>
                         death benefits, living benefits, or other benefits available under the contract) and include a statement that these amounts are subject to the insurer's claims-paying ability and financial strength.
                        <SU>720</SU>
                        <FTREF/>
                         While some of this information will appear in the Key Information Table,
                        <SU>721</SU>
                        <FTREF/>
                         this item requires registrants to provide more detailed disclosure later in the prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>720</SU>
                             Item 9(c) of amended Form N-3; Item 8(c) of amended Form N-4; Item 8(c) of amended FormN-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>721</SU>
                             
                            <E T="03">See</E>
                             Instruction 3(d) to new Item 2 of Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also modifying the instruction to the current subparagraph in each form relating to contract or registrant changes to explicitly require disclosure of reservation of the right to substitute one portfolio company for another.
                        <SU>722</SU>
                        <FTREF/>
                         We received two comment letters in favor of this change, on the grounds that this disclosure provides investors with important information about the possibility of future substitutions.
                        <SU>723</SU>
                        <FTREF/>
                         This amendment is intended to formalize the Commission's long-standing position that investors should be put on notice of the possibility that an insurer may substitute one portfolio company for another portfolio company.
                        <SU>724</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>722</SU>
                             
                            <E T="03">See</E>
                             Instruction to Item 9(d) of amended Form N-3; Instruction to Item 8(d) of amended FormN-4; Instruction to Item 8(d) of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>723</SU>
                             
                            <E T="03">See</E>
                             ICI Comment Letter; Capital Group Comment Letter. One commenter requested that the Commission amend rule 0-2 under the Investment Company Act to require notice to contract holders of the filing of a substitution application, and reconsider the broader process for review and approval of substitution requests under Section 26(c) of the Investment Company Act. 
                            <E T="03">See</E>
                             Capital Group Comment Letter. This request raises issues and considerations beyond the scope of the rule and form amendments we are adopting.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>724</SU>
                             
                            <E T="03">See</E>
                             Changes in Investment Company Act Made by 1970 Amendments Act, Investment Company Act Release No. 6506 [36 FR 9130 (May 5, 1971)] (depositors of UITs should notify investors of the possibility that underlying securities may be substituted).
                        </P>
                    </FTNT>
                    <P>As proposed, we are also eliminating the current subparagraph (d) in Forms N-3 and N-4, which requires a description of how investor inquiries may be made. This description duplicates information required to appear on the back cover page of the prospectus pursuant to Item 1(b)(1) of the amended forms.</P>
                    <P>
                        Finally, with respect to Forms N-3 and N-4 and as proposed, we are relocating disclosures regarding limitations on classes of purchasers from the cover page of the prospectus 
                        <SU>725</SU>
                        <FTREF/>
                         to the item requiring the general description of contracts.
                        <SU>726</SU>
                        <FTREF/>
                         This revision mirrors Item 6(e) of current Form N-6, helps streamline cover page disclosure, and permits registrants to describe this limitation more fully than if the disclosures had to appear on the cover page (which would necessarily entail space constraints).
                        <SU>727</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>725</SU>
                             Item 1(a)(iv) of current Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>726</SU>
                             Item 9(e) of amended Form N-3; Item 8(e) of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>727</SU>
                             
                            <E T="03">See</E>
                             Item 6(e) of current Form N-6. Like Form N-6, Form N-1A also requires disclosure of limitations on the purchasers to whom the Contracts are offered further back in the prospectus, and not on the cover page. 
                            <E T="03">See</E>
                             Items 6 and 11 of Form N-1A.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">j. Annuity Period (Item 10 of FormN-3, Item 9 of Form N-4)</HD>
                    <P>
                        As proposed, we are amending Item 9 of current Form N-3 and Item 8 of current Form N-4 (which we are re-designating as Items 10 and 9, respectively) to include a new requirement that a registrant state, if applicable, that the investor will not be able to withdraw any contract value amounts after the annuity commencement date.
                        <SU>728</SU>
                        <FTREF/>
                         While the new “Overview” section of the prospectus contains similar information,
                        <SU>729</SU>
                        <FTREF/>
                         the amended annuity period item requirement provides investors with more complete disclosure about a key aspect of annuitization that we believe investors often misunderstand in the context of a more detailed discussion about the annuity benefits under the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>728</SU>
                             Item 10(g) of amended Form N-3; Item 9(g) of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>728</SU>
                             Item 2(c)(2) of amended Forms N-3 and N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">k. Standard Death Benefits (Item 10 of Form N-6)</HD>
                    <P>
                        The Commission proposed to amend Item 10 of current Form N-3, Item 9 of current Form N-4, and Item 8 of current Form N-6 (which we are re-designating as Items 11, 10, and 10, respectively) to clarify that the current disclosures required by the item would only apply to the standard death benefit under the contract.
                        <SU>730</SU>
                        <FTREF/>
                         As proposed, registrants would include prospectus disclosure about optional death benefits (as well as standard and optional living benefits) pursuant to proposed Item 12 to Form N-3, and proposed Item 11 to FormsN-4 and N-6.
                    </P>
                    <FTNT>
                        <P>
                            <SU>730</SU>
                             Proposed Item 11 of Form N-3; proposed Item 10 of Forms N-4 and N-6.
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, and in response to issues raised by commenters, we are not requiring this item as a separate disclosure item for variable annuity contracts but are retaining it as a separate disclosure item for variable life insurance contracts.
                        <SU>731</SU>
                        <FTREF/>
                         In addition, as discussed above, and in response to issues raised by commenters, we are largely adopting the substantive disclosure requirements of this item as proposed but are consolidating the disclosure requirements for the initial summary prospectus into paragraph (a) of this item.
                        <SU>732</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>731</SU>
                             
                            <E T="03">See supra</E>
                             note 220 and accompanying and following text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>732</SU>
                             
                            <E T="03">See supra</E>
                             note 222 and accompanying and following text. 
                            <E T="03">See</E>
                             Item 10(a) of amended FormN-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">l. Benefits Available Under the Contract (Item 11 of Form N-3, Item 10 of Form N-4), (Other Benefits Available Under the Contract) Item 11 of Form N-6)</HD>
                    <P>
                        Largely as proposed, we are adding a new item to each registration form that requires a registrant to discuss benefits available under the contract (
                        <E T="03">e.g.,</E>
                         accumulation benefit, withdrawal benefit, long-term care benefit, etc.).
                        <SU>733</SU>
                        <FTREF/>
                         The Commission proposed that this disclosure item would include optional death benefits but not standard death benefits. As discussed above, we are revising this item to encompass all death benefits for variable annuity 
                        <PRTPAGE P="26026"/>
                        contracts but only non-standard death benefits for variable life insurance contracts (
                        <E T="03">i.e.,</E>
                         optional or supplemental death benefits that are available for a separate charge), since standard death benefits for variable life insurance contracts will be disclosed pursuant to a standalone disclosure item titled “Standard Death Benefits.”
                        <SU>734</SU>
                        <FTREF/>
                         Accordingly, we are revising the title of this item to read “Benefits Available Under the Contract” for Forms N-3 and N-4, although it remains “Other Benefits Available Under the Contract” for Form N-6.
                    </P>
                    <FTNT>
                        <P>
                            <SU>733</SU>
                             New Item 11 of amended Form N-3; new Item 10 of amended Form N-4; new Item 11 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>734</SU>
                             
                            <E T="03">See supra</E>
                             text accompanying and following note 223; 
                            <E T="03">see also</E>
                             Item 10 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        Largely as proposed, subparagraph (a) of the new item requires a tabular summary overview of each benefit available under the contract (other than death benefits for variable life insurance contracts).
                        <SU>735</SU>
                        <FTREF/>
                         This tabular summary is also required in any initial summary prospectus.
                        <SU>736</SU>
                        <FTREF/>
                         If the contract offers multiple benefits of the same type (
                        <E T="03">e.g.,</E>
                         death benefit, accumulation benefit, etc.), the registrant may include multiple tables, if doing so might better permit comparisons of different benefits of the same type.
                        <SU>737</SU>
                        <FTREF/>
                         Registrants should include appropriate titles, headings, or any other information to promote clarity and facilitate understanding of the table(s).
                        <SU>738</SU>
                        <FTREF/>
                         These instructions are designed to accommodate the variety of benefits currently offered or that might be offered in the future, and provide registrants flexibility in presenting this information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>735</SU>
                             The summary table will include the name of each benefit, its purpose, whether the benefit is standard or optional, associated fees (as a stated percentage of contract value, benefit base, etc.), and a brief description of limitations or restrictions. 
                            <E T="03">See supra</E>
                             Section II.A.1.c.ii(d).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>736</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(iv); 
                            <E T="03">see also supra</E>
                             Section II.A.1.c.ii(d).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>737</SU>
                             
                            <E T="03">See</E>
                             Instruction 1.(b) to Item 11 of amended Form N-3, Item 10 of amended Form N-4, and Item 11 of amended Form N-6. Registrants that choose to use a single table should consider whether grouping together multiple benefits of the same type, with appropriate headings, might similarly permit better comparisons of those benefits.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>738</SU>
                             
                            <E T="03">See</E>
                             Instruction 1.(c) to Item 11 of amended Form N-3, Item 10 of amended Form N-4, and Item 11 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, and in response to issues raised by commenters, we are revising the instructions to this table in Forms N-3 and N-4 to clarify that registrants must disclose the maximum limit to which each benefit fee may be raised.
                        <SU>739</SU>
                        <FTREF/>
                         The instructions to this table in Forms N-3 and N-4 also permit registrants to disclose the current charge in a separate column, if the disclosure of the current charge is no more prominent than, and does not obscure or impede understanding of, the disclosure of the maximum charge.
                        <SU>740</SU>
                        <FTREF/>
                         For variable life products registered on Form N-6, where fees are based in part on the personal characteristics of the insured, this item in Form N-6 does not require disclosure of maximum fees, but instead requires a statement explaining that the Fee Table contains information about the fees for each benefit.
                        <SU>741</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>739</SU>
                             
                            <E T="03">See</E>
                             Instruction 5 to Item 11 of Form N-3; Instruction 5 to Item 10 of Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>740</SU>
                             
                            <E T="03">See</E>
                             Instruction 6 to Item 11 of Form N-3; Instruction 6 to Item 10 of Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>741</SU>
                             As discussed above, the Fee Table includes the minimum fee, maximum fee, and fee for a representative investor for each benefit. 
                            <E T="03">See supra</E>
                             note 652 and accompanying text. This information should help provide better context for investors to understand the fees for the other benefits available under the contract. 
                            <E T="03">See also supra</E>
                             note 235 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        Another commenter suggested that the Benefits Table should not include actual fees, but instead should refer readers to consult the Fee Table which appears elsewhere in the document.
                        <SU>742</SU>
                        <FTREF/>
                         We believe the fee charged for each benefit is an important piece of information that should be included in the tabular summary required by this item to assist investors wishing to compare benefits available under the contract. To further assist investors in making this comparison, we also would not object if registrants included benefits available without charge in this tabular summary of benefits.
                        <SU>743</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>742</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>743</SU>
                             We understand that many registrants offer benefits that are available without charge, such as dollar-cost averaging programs, automatic transfer programs, etc.
                        </P>
                    </FTNT>
                    <P>
                        Several commenters stated that the tabular summary contemplated by proposed paragraph (a) does not provide sufficient information for investors to fully understand the differences between the benefits and the choices available to investors under each benefit.
                        <SU>744</SU>
                        <FTREF/>
                         As proposed, paragraphs (b) and (c) of the new item require the statutory prospectus to include narrative disclosures that provide more detailed information regarding each of the benefits presented in the tabular summary and we believe that this, coupled with the table in paragraph (a), will provide sufficient detail regarding the contract benefits without being overly complicated. As proposed, a registrant is required to include a brief description of each benefit (other than the standard death benefit in the case of variable life insurance registrants) offered under the contract,
                        <SU>745</SU>
                        <FTREF/>
                         and a brief description of any limitations, restrictions and risks associated with each benefit.
                        <SU>746</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>744</SU>
                             
                            <E T="03">See, e.g.,</E>
                             VIP Working Group Comment Letter (“Some insurance company [sic] offers 3 withdrawal benefits at the same time on a single contract that would be indistinguishable using the table. . . . Also, consider whether a one‐page description of each rider may be more appropriate.”); Anonymous Comment Letter III; Nedar Comment Letter (“Investors should be told more about each benefit, like that you can withdraw 6% per year for the rest of your life.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>745</SU>
                             This brief description is required to include a discussion of: (1) Whether the benefit is standard or elected; (2) the operation of the benefit, including the amount of the benefit and how the benefit amount may vary, the circumstances under which the value of the benefit may increase or be reduced (including the impact of withdrawals), and how the benefit may be terminated; (3) fees and costs, if any, associated with the benefit; and (4) how the benefit amount is calculated and payable, and the effect of choosing a specific method of payment on calculation of the benefit. 
                            <E T="03">See</E>
                             Item 11(b) of amended Form N-3; Item 10(b) of amended Form N-4; Item 11(b) of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>746</SU>
                             For example, this could include restrictions on which portfolio companies may be selected, risk of reduction or termination of benefit or of additional costs resulting from excess withdrawals, etc. 
                            <E T="03">See</E>
                             Item 11(c) of amended Form N-3; Item 10(c) of amended Form N-4; Item 11(c) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>Some benefits offered by a contract may have complicated terms that do not readily lend themselves to being fully described in a tabular summary. The narrative disclosures are intended to complement the tabular summary presentation by allowing registrants to discuss the benefits, as well as the limitations, risks, and restrictions associated with each, in more detail without being constrained by the limitations of a tabular presentation. The requirement to discuss the limitations, risks, and restrictions associated with each benefit will also help ensure that these aspects of contract benefits—along with the value they could provide to investors—are discussed in a standardized manner among contract prospectuses.</P>
                    <P>
                        As proposed, we are including an instruction directing registrants in responding to paragraphs (b) and (c) to provide one or more examples illustrating the operation of each benefit in a clear, concise, and understandable manner.
                        <SU>747</SU>
                        <FTREF/>
                         This instruction is intended to further assist investors in understanding the other benefits offered under the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>747</SU>
                             
                            <E T="03">See</E>
                             Instruction to new Item 11 of amended Form N-3; Instruction to new Item 10 of amended Form N-4; Instruction to new Item 11 of amended Form N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">m. Purchases and Contract Value (Item 12 of Form N-3, Item 11 of Form N-4) and Premiums (Item 9 of Form N-6)</HD>
                    <P>
                        Largely as proposed, we are amending Item 11 of Form N-3 and Item 10 of current Form N-4 (which we are re-designating as Items 12 and 11, respectively) to re-structure the disclosure item and make other minor revisions that do not substantively 
                        <PRTPAGE P="26027"/>
                        change current disclosure requirements.
                        <SU>748</SU>
                        <FTREF/>
                         As discussed above, variable annuity initial summary prospectuses will include the disclosures required by subparagraph (a), which requires registrants to briefly describe the procedures for purchasing a contract.
                        <SU>749</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>748</SU>
                             Item 12 of amended Form N-3; Item 11 of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>749</SU>
                             
                            <E T="03">See supra</E>
                             note 245.
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, and in response to issues raised by commenters, we are consolidating the premiums disclosure requirements for the variable life insurance initial summary prospectus into paragraphs (a) through (c) of this item.
                        <SU>750</SU>
                        <FTREF/>
                         These revisions are not intended to substantively alter the disclosures regarding premiums in variable life insurance statutory prospectuses, but instead are simply intended to implement the final disclosure requirements for the initial summary prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>750</SU>
                             
                            <E T="03">See supra</E>
                             note 248 and accompanying and following text. 
                            <E T="03">See also</E>
                             Item 14(a) through (c) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        In a change from the proposal, and to parallel other similar changes,
                        <SU>751</SU>
                        <FTREF/>
                         we are also restating certain disclosure requirements to clarify that registrants should provide the required disclosures with regards to investment options (which include any fixed account investment option) as opposed to sub-accounts (which do not include any fixed account investment option).
                        <SU>752</SU>
                        <FTREF/>
                         We understand that this is broadly consistent with current disclosure practices, and we do not believe that these changes should alter existing disclosure requirements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>751</SU>
                             
                            <E T="03">See infra</E>
                             notes 757 and 768 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>752</SU>
                             
                            <E T="03">See</E>
                             Item 12(b)(D) of amended Form N-3; Item 11(b)(D) of amended Form N-4; Item 9(e)(4) of amended Form N-6. These provisions require disclosure of how accumulation unit value or premiums are allocated to the investment options, including how such allocation takes place in the absence of instructions from the investor.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">n. Surrenders and Withdrawals (Item 13 of Form N-3, Item 12 of Form N-4, Item 12 of Form N-6)</HD>
                    <P>
                        We are amending Item 12 of current Form N-3 and Item 11 of current Form N-4 (which we are re-titling and re-designating as Items 13 and 12, respectively) to generally reflect the more up-to-date requirements of the parallel item of Form N-6 and standardize these disclosure requirements across variable product registration forms.
                        <SU>753</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>753</SU>
                             
                            <E T="03">See</E>
                             Item 9 of current Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        Largely as proposed, paragraph (a) of the amended item consolidates the current disclosure requirements regarding surrenders and delays in effecting requests for surrender and provides a high-level overview of how an investor can surrender and make withdrawals from a contract, including any limits on the ability to surrender, how the proceeds are calculated, and when they are payable.
                        <SU>754</SU>
                        <FTREF/>
                         As discussed above, the initial summary prospectus also includes the amended paragraph (a) disclosures to provide summary information to investors regarding surrenders and withdrawals.
                        <SU>755</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>754</SU>
                             Item 13(a) of amended Form N-3; Item 12(a) of amended Form N-4.
                        </P>
                        <P> As proposed, we are eliminating Item 12(b) of current Form N-3 and Item 11(b) of current Form N-4 (requirement to disclose any restrictions on redemption that may apply if the registrant offers the contracts in connection with the “Texas Optional Retirement Program”) and Item 12(c) of current Form N-3 and Item 11(c) of current Form N-4 (requirement to briefly describe whether a request for redemption may not be honored for a period of time after an investor makes a purchase payment). We believe that these requirements are generally encompassed by the proposed requirements (discussed in the following paragraph) to disclose any limits on the ability to surrender, including any limits on the availability of surrenders and withdrawals.</P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>755</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(vii); 
                            <E T="03">see also supra</E>
                             Section II.A.1.c.ii(g). To clarify the scope of paragraph (a), and to simplify this item in general, we are also removing references to “partial surrender” and “partial withdrawal.” 
                            <E T="03">See supra</E>
                             note 257.
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, several commenters stated that investors viewing initial summary prospectuses would also benefit from disclosures regarding the negative effects of partial withdrawals on benefits, as well as withdrawals made to pay adviser fees.
                        <SU>756</SU>
                        <FTREF/>
                         We agree with those comments, and accordingly we are revising paragraph (a) to include those disclosures and to require disclosure of this information in initial summary prospectuses.
                    </P>
                    <FTNT>
                        <P>
                            <SU>756</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Transamerica Comment Letter; AARP Comment Letter. 
                            <E T="03">See supra</E>
                             notes 255 and 256 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        Largely as proposed, paragraphs (b) through (d) require additional information related to the operation of surrenders and withdrawals under the contract, including: (1) Whether and under what circumstances they are available; (2) how they will affect a contract's cash value, death benefit(s), and/or any living benefits; and (3) how partial surrenders and withdrawals will be allocated among the investment options.
                        <SU>757</SU>
                        <FTREF/>
                         In a change from the proposal, and to parallel other similar changes,
                        <SU>758</SU>
                        <FTREF/>
                         we are also restating certain disclosure requirements to clarify that registrants should provide the required disclosures with regards to investment options as opposed to sub-accounts.
                        <SU>759</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>757</SU>
                             Item 13(b) through (d) of amended Form N-3; Item 12(b) through (d) of amended Form N-4. These disclosure requirements will conform to those that appear in the parallel provisions of current Form N-6. 
                            <E T="03">See</E>
                             Item 9(b) through (d) of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>758</SU>
                             
                            <E T="03">See supra</E>
                             note 752 and 
                            <E T="03">infra</E>
                             note 768 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>759</SU>
                             
                            <E T="03">See</E>
                             Item 13(d) of amended Form N-3; Item 12(d) of amended Form N-4; Item 12(d) of amended Form N-6. These provisions require registrants to describe allocation of surrenders and withdrawals with respect to the investment options, including how such allocation takes place in the absence of instructions from the investor.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, paragraph (e) requires registrants to describe any provision for involuntary redemptions and the reasons for such provision.
                        <SU>760</SU>
                        <FTREF/>
                         While Item 12(d) of current Form N-3 and Item 11(d) of current Form N-4 specifically also require a description of any provision for lapse, we are eliminating the requirement to discuss lapse provisions because contract lapse is more relevant in the context of variable life products.
                        <SU>761</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>760</SU>
                             Item 13(e) of amended Form N-3; Item 12(e) of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>761</SU>
                             
                            <E T="03">See supra</E>
                             note 687 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, paragraph (f), like Item 12(e) of current Form N-3 and Item 11(e) of current Form N-4, requires the disclosure of any revocation rights. However, to provide additional information relating to an investor's revocation rights, paragraph (f) also requires: (1) A description of how the amount refunded is determined; (2) the method for crediting earnings to purchase payments during the free look period; and (3) whether investment options are limited during the free look period.
                        <SU>762</SU>
                        <FTREF/>
                         We believe these disclosures are particularly important because the free look is typically the only time the investor may leave the contract for multiple years after investing in the contract without paying significant surrender fees and penalties.
                        <SU>763</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>762</SU>
                             These disclosure requirements conform to those that appear in the parallel provisions of current Form N-6. 
                            <E T="03">See</E>
                             Item 9(e) of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>763</SU>
                             
                            <E T="03">See supra</E>
                             paragraphs accompanying note 47.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">o. Loans (Item 14 of Form N-3, Item 13 of Form N-4, Item 13 of Form N-6)</HD>
                    <P>
                        Largely as proposed, we are amending Form N-6 to consolidate required prospectus and SAI disclosures relating to contract loans 
                        <SU>764</SU>
                        <FTREF/>
                         into a single item in the prospectus.
                        <SU>765</SU>
                        <FTREF/>
                         Given that investors will receive summary information relating to loan provisions in the Overview section of the statutory prospectus (and initial summary prospectus), we believe that investors will benefit from having more complete information on contract loans in a single location.
                    </P>
                    <FTNT>
                        <P>
                            <SU>764</SU>
                             
                            <E T="03">See</E>
                             Items 10 and 23 of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>765</SU>
                             New Item 13 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        Specifically, a registrant must briefly describe: (1) The availability of loans; 
                        <PRTPAGE P="26028"/>
                        (2) any limitations on that availability (
                        <E T="03">e.g.,</E>
                         a prohibition on loans during the first contract year); (3) interest provisions; (4) the effects of loans on contract value and death benefits; (5) any other effects that a loan could have on the contract (
                        <E T="03">e.g.,</E>
                         the effect of a contract loan in excess of contract value); and (6) loan procedures.
                    </P>
                    <P>
                        We understand that variable annuities, like variable life insurance contracts, often offer investors the opportunity to borrow money against the cash value of their contract, and that insurers and intermediaries frequently promote this contract feature in their sales of variable annuities. Therefore, we are also adding new Item 14 to Form N-3 and new Item 13 to Form N-4, which require similar prospectus disclosure about the availability and terms of loans under the contract.
                        <SU>766</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>766</SU>
                             New Item 14 of amended Form N-3; new Item 13 of amended Form N-4.
                        </P>
                    </FTNT>
                    <P>
                        In a change from the proposal, and to parallel other similar changes,
                        <SU>767</SU>
                        <FTREF/>
                         we are also restating certain disclosure requirements to clarify that registrants should provide the required disclosures with regards to investment options as opposed to sub-accounts.
                        <SU>768</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>767</SU>
                             
                            <E T="03">See supra</E>
                             notes 752 and 757 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>768</SU>
                             
                            <E T="03">See</E>
                             Item 14(c) through (d) of amended Form N-3; Item 13(c) through (d) of amended Form N-4; Item 13(c) through (d) of amended Form N-6. These provisions require registrants to describe how loans and loan repayments, and interest on loans, will be allocated to the investment options, including, if applicable, how such allocation takes place in the absence of instructions from the investor.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">p. Lapse and Reinstatement (Item 14 of Form N-6)</HD>
                    <P>
                        The Commission proposed no changes to Item 11 of current Form N-6 (other than re-designation as Item 14). We also proposed that the disclosures required by this item would be included in variable life initial summary prospectuses to provide investors with information about lapse and reinstatement.
                        <SU>769</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>769</SU>
                             
                            <E T="03">See</E>
                             proposed rule 498A(b)(5)(vi).
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, and in response to issues raised by commenters, we are consolidating the lapse and reinstatement disclosure requirements for the initial summary prospectus into paragraphs (a) through (c) of this item.
                        <SU>770</SU>
                        <FTREF/>
                         These revisions are not intended to substantively alter the disclosures regarding lapse and reinstatement in variable life insurance statutory prospectuses, but instead are simply intended to implement disclosure requirements for the initial summary prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>770</SU>
                             
                            <E T="03">See supra</E>
                             note 253 and accompanying and following text. 
                            <E T="03">See also</E>
                             Item 14(a) through (c) of amended Form N-6.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">q. Taxes (Item 15 of Form N-3, Item 14 of Form N-4, Item 15 of Form N-6)</HD>
                    <P>
                        As proposed, we are amending Item 13 of current Form N-3 and Item 12 of current Form N-4 (which we are re-designating as Items 15 and 14, respectively) to reflect the more up-to-date presentation and disclosure requirements of the parallel provisions of Form N-6.
                        <SU>771</SU>
                        <FTREF/>
                         As amended, this item continues to require registrants to (a) describe the material tax consequences to the investor and beneficiary of buying, holding, exchanging, or exercising rights under the contract, (b) identify the types of qualified plans for which the contract is intended to be used, and (c) describe the effect, if any, of taxation on the determination of cash values or sub-account values.
                        <SU>772</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>771</SU>
                             
                            <E T="03">See</E>
                             Item 12 of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>772</SU>
                             Item 15 of amended Form N-3; Item 14 of amended Form N-4.
                        </P>
                    </FTNT>
                    <P>However, the amendments specifically limit required disclosures to “material” tax consequences. While the instructions to subparagraph (a) of Item 13 of current Form N-3 and Item 12 of current Form N-4 provide that the “disclosure need not include detailed description of applicable law,” we are eliminating this instruction in light of the amended language limiting disclosures to “material” consequences.</P>
                    <P>We do not expect any of the amendments to this item to significantly alter current disclosure obligations.</P>
                    <HD SOURCE="HD3">r. Legal Proceedings (Item 16 of Form N-3, Item 15 of Form N-4, Item 16 of Form N-6)</HD>
                    <P>
                        As proposed, we are amending Item 14 of current Form N-3 and Item 13 of current Form N-4 (which we are re-designating as Items 16 and 15, respectively) to reflect the more up-to-date presentation and disclosure requirements of the parallel provisions of Form N-6.
                        <SU>773</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>773</SU>
                             
                            <E T="03">See</E>
                             Item 13 of current Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As currently required by Form N-6, the amendments require registrants on Forms N-3 and N-4 to (1) provide a description of the factual basis alleged to underlie the proceeding, and the relief sought, and (2) in addition to describing proceedings that a governmental authority has instituted, include information about proceedings “known to be contemplated” by governmental authorities.
                        <SU>774</SU>
                        <FTREF/>
                         The amendments also eliminate the requirement to discuss pending legal proceedings against any subsidiary of the registrant to mirror the parallel provision in Form N-6 (and Form N-1A) and provide consistency across forms. We believe this is appropriate in the context of separate account registrants, which are unlikely to have subsidiaries.
                        <SU>775</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>774</SU>
                             Item 16 of amended Form N-3; Item 15 of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>775</SU>
                             
                            <E T="03">Id.; see also</E>
                             Item 13 of current Form N-6; Item 10(a)(3) of Form N-1A.
                        </P>
                    </FTNT>
                    <P>These amendments are not expected to significantly alter current disclosure obligations.</P>
                    <HD SOURCE="HD3">s. Financial Statements (Item 17 of Form N-3, Item 16 of Form N-4; Item 17 of Form N-6)</HD>
                    <P>
                        As proposed, we are adding new Item 17 to Form N-3 and new Item 16 to Form N-4, which require a statement, under a separate caption, of where any required financial statements of the registrant and the depositor may be found if they are not included in the prospectus.
                        <SU>776</SU>
                        <FTREF/>
                         As proposed, the registrant also must briefly explain how investors may obtain any financial statements not provided in the SAI.
                        <SU>777</SU>
                        <FTREF/>
                         These disclosure requirements conform to a similar requirement included in Item 14 of current Form N-6.
                    </P>
                    <FTNT>
                        <P>
                            <SU>776</SU>
                             New Item 17 of amended Form N-3; new Item 16 of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>777</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>
                        As proposed, the forms' amended General Instructions provide that registrants are free to include in the prospectus financial statements required to be in the SAI, and may also include in the SAI financial statements that may be placed in Part C.
                        <SU>778</SU>
                        <FTREF/>
                         The new item is intended to assist investors in finding and obtaining any financial statements that have been moved at the registrant's discretion from the location where they would otherwise be provided in the registration statement.
                        <SU>779</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>778</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(b) to amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>779</SU>
                             A similar requirement to this new item appears in paragraph (c) of Item 4 of current Form N-3 and paragraph (b) of Item 4 of current Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">t. Appendix: Portfolio Companies/Investment Options Available Under the Contract (Item 18 of Form N-3, Item 17 of Form N-4, and Item 18 of Form N-6)</HD>
                    <P>
                        Largely as proposed, we are adding a new disclosure item to each registration form (new Item 18 of Form N-3, new Item 17 of Form N-4, and new Item 18 of Form N-6), which requires registrants to include as an Appendix to the prospectus a table that will streamline and replace current prospectus disclosures about the portfolio companies and investment options 
                        <PRTPAGE P="26029"/>
                        available under the contract.
                        <SU>780</SU>
                        <FTREF/>
                         This table will appear under the heading “Portfolio Companies/Investment Options Available Under the Contract” and will consolidate certain summary information about each portfolio company into a concise, easy-to-read tabular presentation.
                        <SU>781</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>780</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 1(a)(viii) of current Form N-4 (requiring the outside cover page of the prospectus to include the names of portfolio companies); Item 4(c) of current Form N-6 (requiring registrants to briefly describe the registrant's sub-accounts and each portfolio company, including its name, its type or a brief statement concerning its investment objectives, and its investment adviser and any sub-adviser).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>781</SU>
                             
                            <E T="03">See supra</E>
                             discussion at note 265 and accompanying and following text.
                        </P>
                    </FTNT>
                    <P>
                        As discussed above, in response to commenters' suggestions regarding the summary prospectuses, we are making several changes to the content requirements for the Appendix.
                        <SU>782</SU>
                        <FTREF/>
                         In particular, and in response to commenters, we are broadening the scope of the Appendix to encompass all portfolio companies/investment options available as investment options under the contract, as opposed to all portfolio companies/investment options currently offered under the contract, as proposed.
                        <SU>783</SU>
                        <FTREF/>
                         This change is intended to improve disclosures about portfolio companies/investment options that are restricted to investors because of a “soft” or “hard” close, and consequently those portfolio companies/investment options will also be required to be identified as such.
                        <SU>784</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>782</SU>
                             
                            <E T="03">Id.</E>
                             (revising the proposed Appendix requirements to, among other things, revise the introductory legend, require presentation of current expense ratios (either net or gross), require disclosure of platform charges, require disclosure only of those portfolio company sub-advisers that manage a significant portion of the portfolio).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>783</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (seeking clarification regarding whether the “currently offered” standard includes portfolio company options in which current, but not new, investors are permitted to invest (“soft closed” fund options)); 
                            <E T="03">see also</E>
                             Instruction 1(a) to Item 18 of amended Form N-13, Item 17 of amended Form N-4, and Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>784</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(a) to Item 18 of amended Form N-13, Item 17 of amended Form N-4, and Item 18 of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, if the availability of one or more portfolio companies varies by benefit offered under the contract, registrants are required to include a separate table or any other presentation that might promote clarity and facilitate understanding of which portfolio companies were available under each of those benefits.
                        <SU>785</SU>
                        <FTREF/>
                         These same disclosures will also appear in the initial summary prospectuses and updating summary prospectus,
                        <SU>786</SU>
                        <FTREF/>
                         except for variations due to the more limited scope of the initial summary prospectus (which can only describe one contract) in contrast to the updating summary prospectus and statutory prospectus (which could describe more than one contract).
                        <SU>787</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>785</SU>
                             
                            <E T="03">See supra</E>
                             note 313 and accompanying and following text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>786</SU>
                             
                            <E T="03">See</E>
                             rule 498A(b)(5)(ix); rule 498A(c)(6)(iv); 
                            <E T="03">see also supra</E>
                             Sections II.A.1.c.ii(
                            <E T="03">i</E>
                            ), II.A.2.c.ii(c).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>787</SU>
                             As discussed above, an initial summary prospectus may only describe a single contract that the registrant currently offers for sale, whereas the updating summary prospectus and statutory prospectus may describe multiple contracts under the conditions of the General Instructions to Forms N-3, N-4, and N-6. 
                            <E T="03">See supra</E>
                             Sections II.A.1.b, II.A.2.b.
                        </P>
                    </FTNT>
                    <P>
                        Because we understand that certain variable contracts registered on Form N-3 have very few investment options (and sometimes have only one investment option), we recognize that the Appendix could have limited utility for certain Form N-3 registrants and their investors. For this reason, and as proposed, registrants on Form N-3 can omit the Appendix and instead provide the more detailed disclosures about the investment options offered under the contract required by new Item 19 of Form N-3.
                        <SU>788</SU>
                        <FTREF/>
                         For Form N-3 registrants, the Appendix is required to appear in a statutory prospectus only if the Appendix is included in a summary prospectus.
                        <SU>789</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>788</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(a) to new Item 18 of amended Form N-3; 
                            <E T="03">see also</E>
                             rule 498A(b)(5)(ix), (c)(6)(iv) (the Appendix also can be omitted from the summary prospectus); 
                            <E T="03">infra</E>
                             paragraphs following note 796 (discussing new Item 19 of amended Form N-3).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>789</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(a) to new Item 18 of amended Form N-3; 
                            <E T="03">see also supra</E>
                             notes 331, 388, and 700.
                        </P>
                    </FTNT>
                    <P>
                        Largely as proposed, the same legends that precede the Appendix in the summary prospectus will generally also precede the Appendix in the statutory prospectus.
                        <SU>790</SU>
                        <FTREF/>
                         As discussed above, in response to commenters' suggestions, we are revising these legends to add additional disclosures about the availability of updated performance information, to clarify that performance information does not include platform charges, to state that certain investment options may not be available depending on the optional benefits selected, and to generally streamline the overall presentation.
                        <SU>791</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>790</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.1.c.ii(i). The sole exception involves registrants on Form N-3 that use a summary prospectus that includes the disclosures required by new Item 18. In this case, the portion of the legend in the summary prospectus explaining how more information about the investment options may be obtained will not be required to be included in the statutory prospectus. 
                            <E T="03">See</E>
                             note 792 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>791</SU>
                             
                            <E T="03">See supra</E>
                             note 313 and accompanying and following text.
                        </P>
                    </FTNT>
                    <P>
                        Under amended Form N-3, the legend preceding the Appendix must state, in part, as follows: “The current expenses and performance information below reflects contract fees and expenses that are paid by each investor” (in contrast, the parallel legend for Forms N-4 and N-6 will state that current expenses and performance 
                        <E T="03">do not</E>
                         reflect contract fees and expenses that are paid by each investor). This difference is intended to reflect the fact that insurance charges are inherently reflected in the expenses and performance of investment options for contracts registered on Form N-3, since those investment options are offered as part of the variable contract. The expenses and performance of portfolio companies offered under contracts registered on Forms N-4 and N-6 do not reflect insurance charges, because those portfolio companies are separately registered as entities distinct from the variable contract. Additionally, only registrants on Forms N-4 and N-6 that chose to utilize the new portfolio company prospectus delivery option are required to include in the Appendix an internet address to a landing page, toll-free telephone number, and email address that investors could use to obtain or request portfolio company statutory and summary prospectuses.
                        <SU>792</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>792</SU>
                             
                            <E T="03">See</E>
                             Instruction 1(b) to new Item 17 of amended Form N-4 and new Item 18 of amended Form N-6 (“Registrants not relying upon rule 498A(j) under the Securities Act [17 CFR 230.498A(j)] with respect to the Portfolio Companies that are offered under the Contract may, but are not required to, provide the next-to-last sentence of the first paragraph of the introductory legend to the table regarding online availability of the prospectuses.”). 
                        </P>
                        <P>
                             Registrants on Form N-3 that use a summary prospectus that includes the disclosures required by new Item 18 of amended Form N-3 will be required to include in that Appendix an introductory legend explaining how more information about the investment options may be obtained. 
                            <E T="03">See</E>
                             rule 498A(b)(5)(ix) and 
                            <E T="03">supra</E>
                             notes 323-326 (discussing legend in initial summary prospectus); rule 498A (c)(6)(iv) and note 387 (discussing legend in updating summary prospectus). However, that legend will not be required to be included in the statutory prospectus, because the statutory prospectus will already include those disclosures pursuant to new Item 19 (which requires more detailed disclosure regarding each of the investment options available under the contract). 
                            <E T="03">See</E>
                             Instruction 1(a) to new Item 18 of amended Form N-3; new Item 19 of amended Form N-3.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">u. Additional Amendments to FormN-3</HD>
                    <P>As proposed, we are adopting additional amendments to Form N-3 that are generally intended to update and enhance disclosures related to investment options by requiring similar disclosures required for open-end management companies registered on Form N-1A.</P>
                    <HD SOURCE="HD3">v. Management (Item 7 of Form N-3)</HD>
                    <P>
                        As proposed, we are revising Item 6 of current Form N-3 (which we are re-designating as Item 7) to increase 
                        <PRTPAGE P="26030"/>
                        consistency among forms used to register management investment companies.
                        <SU>793</SU>
                        <FTREF/>
                         Except as described below, we do not intend these amendments to significantly alter current disclosure obligations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>793</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Items 5 and 10 of Form N-1A.
                        </P>
                    </FTNT>
                    <P>
                        Among other things, the amendments require disclosure of the compensation paid to each investment adviser of the registrant.
                        <SU>794</SU>
                        <FTREF/>
                         Form N-3 currently includes three fiscal years of such disclosures in the SAI, where they will remain under our amendments, but our amendments also include such disclosures for the most recent fiscal year in the prospectus to highlight this information for investors and to update this aspect of Form N-3 to parallel Form N-1A.
                        <SU>795</SU>
                        <FTREF/>
                         As proposed, the amendments also move certain information from the prospectus to the SAI, including responsibilities of the board of managers, disclosure regarding persons providing administrative or business affairs services, and information regarding brokerage allocations.
                        <SU>796</SU>
                        <FTREF/>
                         We believe this information is more appropriate for disclosure in the SAI, and is consistent with how such information is presented in Form N-1A.
                    </P>
                    <FTNT>
                        <P>
                            <SU>794</SU>
                             Registrants will disclose the aggregate fee paid to each investment adviser for the most recent fiscal year as a percentage of net assets or, if the adviser's fee is not based on a percentage of net assets, a description of the basis of the adviser's compensation. 
                            <E T="03">See</E>
                             Item 7(a)(1)(i) and (ii) of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>795</SU>
                             
                            <E T="03">Compare</E>
                             current Item 21(a)(iii) of Form N-3 (requiring total compensation paid to the adviser under the investment advisory contract for the last three fiscal years) 
                            <E T="03">with</E>
                             Item 24(a)(3) of amended Form N-3 (same); 
                            <E T="03">see also</E>
                             Item 10 of Form N-1A.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>796</SU>
                             These disclosure requirements will be moved, respectively, to the following items of amended Form N-3: Item 23(b)(1) (“Management of the Registrant”); Item 24(g) (“Investment Advisory and Other Services”); and Item 26 (“Brokerage Allocation and Other Practices”).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">w. Additional Information About Investment Options Available Under the Contract (Item 19 of Form N-3)</HD>
                    <P>As proposed, we are requiring a new item that will provide more detailed information about each of the investment options available under the contract.</P>
                    <P>As proposed, new paragraphs (a) and (b) restate existing disclosure requirements contained in paragraphs (c), (d), and (e) of current Item 5 regarding investment strategies and risks to reflect the updated presentation and disclosure requirements of the parallel provisions of Form N-1A. These paragraphs re-focus these disclosure requirements to require more granular disclosure related to each investment option as opposed to broader disclosure regarding registrants.</P>
                    <P>Specifically, among other things, these amendments require disclosure of whether the investment option may take temporary defensive positions that are inconsistent with the investment option's principal investment strategies in attempting to respond to adverse market, economic, political, or other conditions. We believe that investors should be informed about investment positions that an investment option can take from time to time that are inconsistent with the investment option's central investment focus.</P>
                    <P>
                        As proposed, these amendments also require the registrant to disclose, for each investment option, whether it may engage in active and frequent trading of portfolio securities and, if so, the consequences of increased portfolio turnover to investors and the investment option's performance. Increased portfolio turnover can result in increased transaction costs that are ultimately borne by investors. Collectively, these amendments are intended to clarify and enhance the disclosure requirements relating to investment options' strategies and risks, and to increase consistency and thereby promote comparability among forms used to register management investment companies.
                        <SU>797</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>797</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 9 of current Form N-1A.
                        </P>
                    </FTNT>
                    <P>As proposed, new paragraph (c) requires registrants with annual returns for at least one calendar year to provide, for each investment option:</P>
                    <P>• A bar chart showing the investment option's annual total returns for each of the last 10 calendar years (or for the life of the investment option, if less than 10 years), as well as the investment option's highest and lowest return for a quarter during the period displayed in the chart;</P>
                    <P>• A table showing the investment option's average annual total returns (with and without taxes on distributions and redemptions) for 1-, 5-, and 10-year calendar periods ending on the date of the most recently completed calendar year (or for the life of the investment option, if shorter), as well as the returns of an appropriate broad-based securities market index for those same periods; and</P>
                    <P>• Certain explanatory statements, such as how the information in the chart and table illustrates the variability of the investment option's returns, the investment option's past performance is not necessarily an indication of how the investment option will perform in the future, and, if applicable, how updated performance information may be obtained.</P>
                    <P>
                        The disclosures that new paragraph (c) requires are modeled after the risk/return bar chart and table that Form N-1A currently requires and are intended to supplement the disclosures currently required by Form N-3 regarding accumulation unit income and capital changes 
                        <SU>798</SU>
                        <FTREF/>
                         by providing investors and potential investors with more information about the performance of the investment options offered under the contract.
                        <SU>799</SU>
                        <FTREF/>
                         In particular, the bar chart will illustrate the variability of the investment options' returns and give investors an idea of the attendant risks of each investment option. Likewise, the accompanying table will help investors evaluate an investment option's risks and returns relative to the market.
                    </P>
                    <FTNT>
                        <P>
                            <SU>798</SU>
                             
                            <E T="03">See infra</E>
                             Section II.C.3.d.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>799</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Item 4(b)(2) of Form N-1A; 
                            <E T="03">see also</E>
                             Registration Form Used by Open-End Management Investment Companies, Investment Company Act Release No. 23064 (Mar. 13, 1998) [98 FR 13968 (Mar. 23, 1998)] (“Form N-1A Adopting Release”) at text accompanying and following n.51 (discussing the risk/return bar chart/table requirement).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. Part B (Information Required in a Statement of Additional Information)</HD>
                    <P>Table 5 shows how our amendments will revise the item requirements of Part B of our variable contract registration forms. Except as described below, our amendments to Part B of Forms N-3 and N-4 generally conform to the language of the related Part B disclosure items in current Form N-6. Although commenters did not raise broad objections to our proposed amendments, commenters raised concerns with and/or requested clarification on various items, as discussed in more detail below. To the extent we received no comments on certain items, we are adopting them as proposed, as discussed further below.</P>
                    <GPH SPAN="3" DEEP="493">
                        <PRTPAGE P="26031"/>
                        <GID>ER01MY20.001</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="588">
                        <PRTPAGE P="26032"/>
                        <GID>ER01MY20.002</GID>
                    </GPH>
                    <HD SOURCE="HD3">a. Amendments Conforming Part B Items of Forms N-3 and N-4 to Presentation in Form N-6</HD>
                    <P>
                        As proposed, we are amending certain items of Part B of Forms N-3 and N-4 to reflect the more up-to-date presentation of corresponding items in Form N-6, and re-designating their numbering as shown in Table 5 above. To the extent that these amended items incorporate only minor wording changes,
                        <SU>800</SU>
                        <FTREF/>
                         they are indicated as 
                        <PRTPAGE P="26033"/>
                        “unchanged items” in Table 5. Otherwise, each of these amended items is discussed in more detail below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>800</SU>
                             For example, edits to use defined terms where appropriate, to use synonyms for consistency across forms (
                            <E T="03">e.g.,</E>
                             “State the name . . .” instead of “Give the name . . .”), and to add titles to sub-paragraphs for clarity and consistency across forms (and to help the reader navigate the form).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Cover Page (Item 20 of Form N-3, Item 18 of Form N-4; Item 19 of Form N-6)</HD>
                    <P>
                        As proposed, we are amending the outside front cover page requirements for each registration form to include the name of the contract and classes to which the contract relates.
                        <SU>801</SU>
                        <FTREF/>
                         As proposed, we are also amending Forms N-3 and N-4 to: (1) Require a statement whether and from where information is incorporated by reference; 
                        <SU>802</SU>
                        <FTREF/>
                         (2) remove the current required statement that the SAI should be read with the prospectus; 
                        <SU>803</SU>
                        <FTREF/>
                         and (3) consolidate the current item requiring a table of contents into the item specifying cover page disclosures.
                        <SU>804</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>801</SU>
                             Item 20(a)(3) of amended Form N-3; Item 18(a)(3) of amended Form N-4; Item 19(a)(3) of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>802</SU>
                             Item 20(a)(4)(iii) of amended Form N-3; Item 18(a)(4)(iii) of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>803</SU>
                             Item 16(a)(iii)(B) of current Form N-3; Item 15(a)(iii)(B) of current Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>804</SU>
                             Item 20(b) of amended Form N-3; Item 18(b) of amended Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">General Information and History (Item 21 of Form N-3, Item 19 of Form N-4, Item 20 of Form N-6)</HD>
                    <P>
                        As proposed, we are amending Item 18 of current Form N-3 and Item 17 of current Form N-4 (which we are re-designating as Items 21 and 19, respectively) to require: (1) The date and form of organization of the depositor, the name of the state or other jurisdiction in which the depositor is organized, and a description of the general nature of the depositor's business; and (2) the date and form of organization of the registrant and the registrant's classification pursuant to Section 4 of the Investment Company Act.
                        <SU>805</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>805</SU>
                             Item 21 of amended Form N-3; Item 19 of amended Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">
                        Services (Item 24 of Form N-3,
                        <SU>806</SU>
                        <FTREF/>
                         Item 20 of Form N-4, Item 21 of Form N-6)
                    </HD>
                    <FTNT>
                        <P>
                            <SU>806</SU>
                             In Form N-3, the title of this disclosure item is “Investment Advisory and Other Services.” In addition to the amendments we are adopting to conform this disclosure item to the parallel item in Form N-6, we also are making additional amendments to this disclosure item, as discussed below, that will reflect the presentation of Item 19 in Form N-1A. 
                            <E T="03">See infra</E>
                             Section II.C.3.e.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are amending Item 21 of current Form N-3 and Item 18 of current Form N-4 (which we are re-designating as Items 24 and 20, respectively) to require registrants to, unless disclosed elsewhere, identify and state the principal business address of any person who provides significant administrative or business affairs management services for the registrant (
                        <E T="03">e.g.,</E>
                         an “administrator,” “sub-administrator,” “servicing agent”), describe the services provided, and the compensation paid for the services.
                        <SU>807</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>807</SU>
                             Item 24(g) of amended Form N-3; Item 20(c) of amended Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Financial Statements (Item 31 of Form N-3, Item 26 of Form N-4, Item 28 of Form N-6)</HD>
                    <P>
                        As proposed, we are amending Item 28 of current Form N-3 and Item 23 of current Form N-4 (which we are re-designating as Items 31 and 26, respectively) to: (1) Clarify that the depositor's financial statements must be prepared in accordance with generally accepted accounting principles (“GAAP”) if the depositor prepares financial information in accordance with GAAP for use by the depositor's parent in any report under Sections 13(a) and 15(d) of the Exchange Act or registration statement filed under the Securities Act; 
                        <SU>808</SU>
                        <FTREF/>
                         (2) specify how an investor may request certain additional financial information about the depositor that is omitted from the SAI and is included in Part C of the registration statement; 
                        <SU>809</SU>
                        <FTREF/>
                         and (3) clarify how current the depositor's financial statements must be when the anticipated effective date of the registration statement falls within 90 days after the depositor's fiscal year-end.
                        <SU>810</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>808</SU>
                             Instruction 1 to Item 31(b) of amended Form N-3; Instruction 1 to Item 26(b) of amended Form N-4. This instruction will be consistent with prior guidance we have provided in the context of registration statements on Form N-6, namely that statutory financial statements could be used in those limited circumstances when GAAP financial statements are not otherwise required to be prepared for either the depositor or its parent. 
                            <E T="03">See</E>
                             Separate Accounts Offering Variable Life Release, 
                            <E T="03">supra</E>
                             note 29, at n.58 and accompanying and following text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>809</SU>
                             Instruction 2 to amended Item 31(b) of Form N-3; Instruction 2 to amended Item 26(b) of Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>810</SU>
                             Instruction 3 to amended Item 31(b) of Form N-3; Instruction 3 to amended Item 26(b) of Form N-4.
                        </P>
                    </FTNT>
                    <P>
                        Several commenters requested that the Commission allow insurers to use financial statements prepared according to statutory accounting principles (“SAP”) instead of generally accepted accounting principles.
                        <SU>811</SU>
                        <FTREF/>
                         Forms N-4 and Form N-6 currently permit a separate account depositor to file financial statements prepared using SAP in registration statements for contracts issued through the separate account if it would not have to prepare GAAP financial statements for use in its own registration statements or periodic reports or those of its parent company.
                        <SU>812</SU>
                        <FTREF/>
                         As noted in the release adopting Form N-6 (“Form N-6 Adopting Release”), the Commission believes allowing the use of SAP financials statements permitted by these forms appropriately recognizes the cost burdens that would be imposed if we required GAAP financial statements in these circumstances.
                        <SU>813</SU>
                        <FTREF/>
                         To promote uniformity and consistency in financial reporting, however, we do not believe it is appropriate to broaden the use of SAP financial statements by separate account depositors beyond these limited circumstances. The Commission generally requires that all financial statements be presented on a GAAP basis. However, the Commission has permitted the use of SAP financial statements—which insurers use to comply with state insurance regulation—in these limited instances because preparing GAAP financial statements would be overly burdensome.
                    </P>
                    <FTNT>
                        <P>
                            <SU>811</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>812</SU>
                             
                            <E T="03">See</E>
                             Instruction 1 to Item 23(b) of Form N-3; Instruction 1 to Item 24(b) of Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>813</SU>
                             
                            <E T="03">See</E>
                             Registration Form for Insurance Company Separate Accounts Registered as Unit Investment Trusts that Offer Variable Life Insurance Policies, Securities Act Release No. 8088, Investment Company Act Release No. 25552 (Apr. 11, 2002) (“Form N-6 Adopting Release”), text preceding n.56.
                        </P>
                    </FTNT>
                    <P>
                        In addition, one commenter stated that financial statements are difficult to comprehend, and suggested the Commission should remove the requirement to include separate account financial statements in registration statements or instead create a risk metric to show the financial strength of the depositor.
                        <SU>814</SU>
                        <FTREF/>
                         We decline to adopt the suggestion to remove the requirement to include the separate account depositor's financial statements in these filings. As noted in the Form N-6 Adopting Release, the financial condition of the depositor is relevant to its ability to pay the insurance benefits offered under variable life insurance policies, and therefore investors may find financial information about the depositor useful.
                        <SU>815</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>814</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>815</SU>
                             See Form N-6 Adopting Release, 
                            <E T="03">supra</E>
                             note 813, text following n.58.
                        </P>
                    </FTNT>
                    <P>
                        We also note that the Commission has recently amended certain rules applicable to and registration forms used by certain investment companies,
                        <SU>816</SU>
                        <FTREF/>
                         in compliance with the Congressional mandate in the Dodd Frank Act to remove references to credit quality ratings in these rules and forms to avoid any potential overreliance by 
                        <PRTPAGE P="26034"/>
                        investors of those ratings that might result from a perceived government endorsement of those ratings.
                        <SU>817</SU>
                        <FTREF/>
                         In adopting these amendments, the Commission noted the absence of “reliable and objective shorthand measure[s] of credit risk.” 
                        <SU>818</SU>
                        <FTREF/>
                         As discussed above, however, the Commission is currently engaged in an overall review of the retail fund investor experience, and will continue to consider ways to improve and simplify disclosure relating to separate account depositors.
                        <SU>819</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>816</SU>
                             
                            <E T="03">See</E>
                             Removal of Certain References to Credit Ratings Under the Investment Company Act, Securities Act No. 9506, Investment Company Act No. 30847 (Sept. 27, 2013) (“Removal of Certain References to Credit Ratings Release”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>817</SU>
                             
                            <E T="03">See</E>
                             Section 939A of the Dodd-Frank Act.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>818</SU>
                             
                            <E T="03">See</E>
                             Removal of Certain References to Credit Ratings Release, 
                            <E T="03">supra</E>
                             note 816, text accompanying n.44.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>819</SU>
                             
                            <E T="03">See</E>
                             Request for Comment on Fund Retail Investor Experience, 
                            <E T="03">supra</E>
                             note 548.
                        </P>
                    </FTNT>
                    <P>
                        Amended Form N-3 will also retain certain requirements regarding the preparation of shareholder reports and disclosure of proxy voting information currently required by the form. These requirements were inadvertently omitted from the proposed Form N-3 at the time of our proposed amendments to that form and will be carried forward without change to the amended form.
                        <SU>820</SU>
                        <FTREF/>
                         In a conforming change, we are also eliminating the current Form N-3 requirement to include accumulation unit value tables in shareholder reports to parallel our elimination of those tables from variable contract prospectuses.
                        <SU>821</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>820</SU>
                             
                            <E T="03">See</E>
                             Instructions 2-6 to Item 31(a) of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>821</SU>
                             
                            <E T="03">See</E>
                             Instruction 5(ii) to Item 28 of Form N-3 (requiring the inclusion of AUV tables in shareholder reports); 
                            <E T="03">see also infra</E>
                             Section C.3.d (discussing elimination of the requirement to include AUV tables in variable contract prospectuses).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Non-Principal Risks of Investing in the Contract (Item 20 of Form N-4, Item 21 of Form N-6)</HD>
                    <P>
                        In a change from the proposal and in response to commenters requesting clarification on where non-principal risk disclosures should be located,
                        <SU>822</SU>
                        <FTREF/>
                         we are adding a new item to Forms N-4 and N-6 regarding the non-principal risks of investing in the contract, to the extent not otherwise required to be disclosed in the prospectus.
                        <SU>823</SU>
                        <FTREF/>
                         Although registrants on Forms N-4 and N-6 currently include non-principal risks of investing in their registration statements, the forms lack an explicit disclosure requirement to do so. We believe the approach taken in Form N-3 of including an explicit requirement in the SAI of the non-principal risks associated with the contract is appropriate to clarify the scope of registrants' disclosure obligations.
                        <SU>824</SU>
                        <FTREF/>
                         Having a separate disclosure requirement for non-principal risks in the SAI also helps to provide a clear delineation between disclosure of principal risks (in the prospectus) and non-principal risks (in the SAI). For these reasons, we are adopting this new item, which should also provide greater consistency among the registration forms for variable contracts and allow investors to more easily compare risks between different variable contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>822</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>823</SU>
                             As discussed above, we believe that the inclusion of non-principal risks could add complexity and length to the prospectus's principal risks section and obscure principal risks that are more relevant to investors, and therefore non-principal risks (that are not otherwise required to be disclosed in the prospectus) are neither required nor permitted to be included in the prospectus. 
                            <E T="03">See supra</E>
                             note 690; General Instruction C.3.(b) to Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>824</SU>
                             
                            <E T="03">See</E>
                             Item 22 of amended Form N-3.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Underwriters (Item 28 of Form N-3, Item 23 of Form N-4, Item 25 of Form N-6)</HD>
                    <P>
                        As proposed, we are amending Item 25 of current Form N-3 and Item 20 of current Form N-4 (which we are re-designating as Items 28 and 23, respectively) to specifically require identification of all principal underwriters of the registrant (other than the depositor), their principal business addresses, and the source of any affiliation.
                        <SU>825</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>825</SU>
                             Item 28(a) of amended Form N-3; Item 23(a) of amended Form N-4. Item 25(a) of current Form N-3 and Item 20(a) of current Form N-4 only require a registrant to state if the depositor or the affiliate of the depositor is the principal underwriter of the contract.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are also adding an instruction to this item in Forms N-3, N-4, and N-6 stating that information need not be provided about bona fide contracts with the registrant or its insurance company for outside legal or auditing services, or bona fide contracts for personal employment entered into with the registrant or its depositor in the ordinary course of business. This instruction is intended to focus disclosures on underwriting costs, as opposed to costs for legal or auditing services or other ancillary matters, and will parallel similar instructions in Part C of these same forms regarding disclosures for principal underwriters.
                        <SU>826</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>826</SU>
                             
                            <E T="03">See infra</E>
                             text accompanying and preceding note 878. Forms N-3, N-4, and N-6 also include in their disclosure requirements regarding underwriters other similar instructions, such as instructions stating that information need not be given about the service of mailing proxies or periodic reports of the registrant.
                        </P>
                    </FTNT>
                    <P>
                        Also as proposed, because we are amending Item 5 of current Form N-6 to include the disclosures on commissions to dealers currently required by current Item 20 in the SAI, we also are removing this disclosure from current Item 20 (which we are re-designating as Item 25).
                        <SU>827</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>827</SU>
                             
                            <E T="03">See supra</E>
                             note 710 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Calculation of Performance Data (Item 29 of Form N-3, Item 24 of Form N-4)</HD>
                    <P>
                        Largely as proposed, we are amending Item 26 of current Form N-3 and Item 21 of current Form N-4 (which we are re-designating as Items 29 and 24, respectively), to remove the instruction specifically permitting the registrant to furnish separate yield quotations for individual and group contracts.
                        <SU>828</SU>
                        <FTREF/>
                         Because the amended General Instructions state that individual and group contracts are not essentially identical, we would not expect to see both types of contracts presented in a single prospectus.
                        <SU>829</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>828</SU>
                             Item 29 of amended Form N-3; Item 24 of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>829</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.e.(i) to amended Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter asked whether this item is still relevant or needs to be adjusted to reflect features such as optional benefits, which were not commonly used when these disclosure requirements were drafted.
                        <SU>830</SU>
                        <FTREF/>
                         Accordingly, we are adding instructions to require registrants to disclose, if applicable, that the performance information may not reflect all contract charges, and that performance would be lower if these charges were included.
                        <SU>831</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>830</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>831</SU>
                             
                            <E T="03">See</E>
                             Instruction 4 to Item 29(a), Instruction 7 to Item 29(b)(1), and Instruction 9 to Item 29(b)(2) of amended Form N-3; Instruction 4 to Item 24(a), Instruction 7 to Item 24(b)(1), and Instruction 5 to Item 24(b)(2) of amended Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">e. Adjustment to Disclosure Thresholds (Items 28 and 31 of Form N-3, Items 23 and 26 of Form N-4, Items 25 and 28 of Form N-6)</HD>
                    <P>
                        Our variable contract registration forms currently include various dollar thresholds that date back to their initial adoption. In the SAI, for example, information need not be given about any service required to be disclosed pursuant to current Item 25 of Form N-3, current Item 20 of Form N-4, and current Item 20 of Form N-6, for which total payments of less than $5,000 were made during each of the last three fiscal years.
                        <SU>832</SU>
                        <FTREF/>
                         In addition, financial statements of the insurance company required to be included in the registration statement need not be more current than as of the end of the most recent fiscal year of the insurance company unless certain balance sheets 
                        <PRTPAGE P="26035"/>
                        of the sponsor show a combined capital and surplus (if a stock company) or an unassigned surplus (if a mutual company), of less than $1,000,000.
                        <SU>833</SU>
                        <FTREF/>
                         As part of our efforts to update the registration forms, and as proposed, we are increasing these thresholds to $15,000 
                        <SU>834</SU>
                        <FTREF/>
                         and $2,500,000,
                        <SU>835</SU>
                        <FTREF/>
                         respectively, to account for the effects of inflation since 1985, the year of inception for Forms N-3 and N-4.
                        <SU>836</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>832</SU>
                             
                            <E T="03">See</E>
                             Instruction 2 to Item 25 of current Form N-3; Instruction 2 to Item 20 of current Form N-4; Instruction 2 to Item 20 of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>833</SU>
                             
                            <E T="03">See</E>
                             Instructions 3(ii) and (iii) to Item 28 of current Form N-3; Instructions 3(ii) and (iii) to Item 23 of current Form N-4; Instructions 3(ii) and (iii) to Item 24 of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>834</SU>
                             
                            <E T="03">See</E>
                             Instruction 3 to Item 28 of amended Form N-3; Instruction 2 to Item 23 of amended Form N-4; Instruction 2 to Item 25 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>835</SU>
                             
                            <E T="03">See</E>
                             Instructions 3(b) and (c) to Item 31(b) of amended Form N-3; Instructions 3(b) and (c) to Item 26 of amended Form N-4; Instructions 3(b) and (c) to Item 28 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>836</SU>
                             Indexing the $5,000 thresholds for inflation results in revised thresholds of $11,950, and indexing the $1,000,000 thresholds for inflation results in revised thresholds of $2,390,009. Calculations are based on the Bureau of Labor Statistics consumer price index average for all urban consumers (CPI-U) between January 1985 and August 2018. 
                            <E T="03">See</E>
                             CPI Inflation Calculator, Bureau of Labor Statistics, 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.bls.gov/data/inflation_calculator.htm</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">f. Additional Amendments to FormN-3</HD>
                    <P>As proposed, we are adopting additional amendments to Form N-3 that are generally intended to update and enhance disclosures related to investment options by requiring similar disclosures required for open-end management companies registered on Form N-1A. The revisions generally reflect the updated presentation and disclosure requirements of the parallel item in Form N-1A and harmonize the disclosure requirements across registration statements for different products.</P>
                    <HD SOURCE="HD3">Investment Objectives and Risks (Item 22 of Form N-3)</HD>
                    <P>
                        As proposed, we are making certain amendments to Item 19 of Form N-3, which we are re-designating as Item 22.
                        <SU>837</SU>
                        <FTREF/>
                         Amended Item 22 contains a new instruction clarifying that if the registrant offers more than one investment option, the required disclosures should be made for each investment option. Paragraph (a) of amended Item 22 requires the registrant to describe any investment strategies that are not principal strategies, as well as the risks of those strategies. These disclosures complement the prospectus disclosures of principal investment strategies that will be required by amended Item 19.
                    </P>
                    <FTNT>
                        <P>
                            <SU>837</SU>
                             
                            <E T="03">See</E>
                             Item 22 of amended Form N-3. The amendments to this item will reflect the presentation of Item 16 of Form N-1A.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, paragraph (b) of amended Item 22 requires the discussion of all policies regarding: (1) Issuing senior securities; (2) borrowing money, including the purpose for which the proceeds will be used; (3) underwriting securities of other issuers; (4) concentrating investments in a particular industry or group of industries; (5) purchasing or selling real estate or commodities; (6) making loans; and (7) any other policy that the registrant deems fundamental or that may not be changed without shareholder approval, including, if applicable, the registrant's investment objectives. In contrast, Item 19 of current Form N-3 generally requires the disclosure of: (1) Fundamental policies not described in the prospectus regarding those same topics, as well as short sales, purchases on margin, and writing of put and call options, and any other policy the registrant deems fundamental; and (2) any significant but non-fundamental investment policies not described in the prospectus and which can be changed without the approval of the majority of votes available to eligible voters. We believe that the amended disclosure requirements better correspond with the requirements of Section 8 of the Investment Company Act than the current Form N-3 item requirements, since they more specifically reflect the disclosure that Section 8 mandates.
                        <SU>838</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>838</SU>
                             Section 8 of the Investment Company Act requires a fund to disclose in its registration statement, among other things, the fund's policies with respect to borrowing money, issuing senior securities, underwriting securities issued by other persons, investing in real estate or commodities, and making loans. Section 8 also requires a fund to disclose in the registration statement its policies on concentration and portfolio turnover, and any other policies that the fund deems fundamental or that may not be changed without shareholder approval. 
                        </P>
                        <P>
                             When the Commission proposed amendments to Form N-1A in 1997, it noted that, although they are not required to do so, some funds disclose in the prospectus their policies with respect to the practices identified under Section 8. 
                            <E T="03">See</E>
                             Proposed New Disclosure Option for Open-End Management Investment Companies, Investment Company Act Release No. 22529 (Feb. 27, 1997) [62 FR 10943 (Mar. 10, 1997)]. To provide a clearer directive to disclose this information in the SAI, the Commission proposed (and later adopted) amendments to specifically require disclosure about these policies in the SAI. 
                            <E T="03">See</E>
                             Form N-1A Adopting Release, 
                            <E T="03">supra</E>
                             note 799. This amended Form N-1A requirement forms the basis for the amendments to paragraph (b) of amended Item 22 of Form N-3 described herein.
                        </P>
                    </FTNT>
                    <P>As proposed, paragraph (c) of amended Item 22 requires registrants to disclose the types of investments that a registrant may make while assuming a temporary defensive position. We believe that investors should be informed about investment positions that an investment option can take from time to time that are inconsistent with the investment option's central investment focus.</P>
                    <P>
                        Paragraph (e) of amended Form N-3 reflects amendments adopted by the Commission in 2017 that will become effective on May 1, 2020.
                        <SU>839</SU>
                        <FTREF/>
                         These amendments remove references to Form N-Q and replace them with references to Form N-PORT.
                        <SU>840</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>839</SU>
                             
                            <E T="03">See</E>
                             Investment Company Reporting Modernization, Investment Company Act Release No. 32936 (Dec. 8, 2017) [82 FR 58731 (Dec. 14, 2017)] (delaying the rescission of Form N-Q and the filing of Form N-PORT).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>840</SU>
                             
                            <E T="03">See</E>
                             paragraph (e) of Item 22 of amended Form N-3 (requiring the registrant to describe any ongoing arrangements to make available information about the registrant's portfolio securities to any person, except if certain conditions are met including certain disclosures about those portfolio securities being made available and remaining available until no earlier than the registrant's filing on Form N-PORT). Other items of amended Form N-3 reflect similar amendments. 
                            <E T="03">See</E>
                             Instruction 4.b to Item 31(a) of amended Form N-3 (requiring the SAI to state that the registrant's portfolio holdings are filed on Form N-PORT and to explain how those reports on Form N-PORT may be obtained).
                        </P>
                    </FTNT>
                    <P>
                        As proposed, paragraph (f) of amended Item 22 requires certain disclosures regarding material events by registrants or investment options that hold themselves out as “money market funds” or “money market accounts” pursuant to rule 2a-7 under the Investment Company Act.
                        <SU>841</SU>
                        <FTREF/>
                         That rule requires these same disclosures to appear on a fund's website, and for information about money market fund material events to be reported to the Commission on Form N-CR.
                        <SU>842</SU>
                        <FTREF/>
                         We believe that, to the extent investors may not be familiar with researching filings on EDGAR (or other equivalent platform), including these disclosures in a registrant's SAI (which investors may receive in hard copy through the U.S. Postal Service or may access on a registrant's website, as well as accessing on EDGAR or other equivalent platform) may make this information more readily available to these investors.
                        <SU>843</SU>
                        <FTREF/>
                         The 
                        <PRTPAGE P="26036"/>
                        remaining paragraphs of amended Item 22 restate existing disclosure requirements to reflect the updated presentation and disclosure requirements of the parallel item in Form N-1A.
                        <SU>844</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>841</SU>
                             
                            <E T="03">See</E>
                             Item 22(e) of amended Form N-3 (requiring prospectus disclosure of imposition of liquidity fees, temporary suspension of registrant redemptions, and financial support provided to money market funds or money market accounts).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>842</SU>
                             
                            <E T="03">See</E>
                             rule 2a-7 under the Investment Company Act (requiring a money market fund to prominently post this same information on its website); Form N-CR (requiring a money market fund to report this same information to the Commission); 
                            <E T="03">see also</E>
                             Item 16(g) of Form N-1A (requiring disclosure of certain material events for money market funds). Portfolio companies registered on Form N-1A and offered by registrants on Forms N-4 and N-6 are currently required to include these disclosures in their SAIs.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>843</SU>
                             
                            <E T="03">See</E>
                             Money Market Reform; Amendments to Form PF, Investment Company Act Release No. 31166 (July 23, 2014) [79 FR 47736 (Aug. 14, 2014)], at text accompanying and following n.1258.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>844</SU>
                             Amended paragraphs (b), (d), and (e) will require disclosure regarding certain investment policies, portfolio turnover, and disclosure of portfolio holdings, respectively.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Management of the Registrant (Item 23 of Form N-3)</HD>
                    <P>
                        As proposed, we are making certain amendments to Item 20 of Form N-3, which we are re-designating as Item 23, to restate existing disclosure requirements to reflect the updated presentation and disclosure requirements of the parallel item in Form N-1A.
                        <SU>845</SU>
                        <FTREF/>
                         Except as discussed below, these changes are not intended to significantly alter current disclosure obligations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>845</SU>
                             
                            <E T="03">See</E>
                             Item 23 of amended Form N-3. The amendments to this item reflect the presentation of Item 17 of Form N-1A.
                        </P>
                    </FTNT>
                    <P>
                        The amendments: (1) Require disclosure of the responsibilities of the board of directors with respect to the registrant's management and any arrangements that result in breakpoints in, or elimination of, sales loads for directors and other affiliated persons of the registrant; 
                        <SU>846</SU>
                        <FTREF/>
                         and (2) remove the current requirement to state that codes of ethics adopted by the registrant, its investment adviser, and principal underwriter can be viewed and copied at the Commission's Public Reference Room, because the Public Reference Room no longer maintains paper copies of filings on Form N-3.
                        <SU>847</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>846</SU>
                             
                            <E T="03">See</E>
                             paragraphs (b)(1) and (d) of Item 23 of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>847</SU>
                             
                            <E T="03">See</E>
                             paragraph (e) of Item 23 of amended Form N-3. These codes of ethics will continue to be filed as exhibits to Part C of the registrant's registration statement. 
                            <E T="03">See</E>
                             Item 32(q) of amended Form N-3.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Investment Advisory and Other Services (Item 24 of Form N-3)</HD>
                    <P>
                        As proposed, in addition to the amendments to Item 21 of Form N-3 (which we are re-designating as Item 24) that we discuss above, which conforms certain aspects of this item to the disclosure requirements of Form N-6,
                        <SU>848</SU>
                        <FTREF/>
                         we are also making amendments to restate existing disclosure requirements to reflect the updated presentation and disclosure requirements of the parallel item in Form N-1A.
                        <SU>849</SU>
                        <FTREF/>
                         Except as discussed below, these changes are not intended to significantly alter current disclosure obligations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>848</SU>
                             
                            <E T="03">See supra</E>
                             note 807 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>849</SU>
                             
                            <E T="03">See</E>
                             Item 24 of amended Form N-3. The amendments to this item will reflect the presentation of Item 19 of Form N-1A.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are amending the current requirement to disclose the total dollar amount that the registrant or the insurance company paid under the investment advisory contract for the last three fiscal years to also require disclosure of amounts paid to “to the adviser (aggregated with amounts paid to affiliated advisers, if any), and any advisers who are not affiliated persons of the adviser.” 
                        <SU>850</SU>
                        <FTREF/>
                         As proposed, we are also requiring a registrant to disclose any front-end sales load reallowed to dealers as a percentage of the registrant's units.
                        <SU>851</SU>
                        <FTREF/>
                         Finally, and as proposed, we are requiring additional disclosures regarding plans adopted under rule 12b-1 under the Investment Company Act.
                        <SU>852</SU>
                        <FTREF/>
                         Industry practices regarding the use of “12b-1 plans” have evolved since Form N-3 was adopted in 1985, and the new disclosures are intended to enhance the information provided to investors by requiring information similar to that required by Form N-1A.
                    </P>
                    <FTNT>
                        <P>
                            <SU>850</SU>
                             
                            <E T="03">See</E>
                             paragraph (a)(3)(i) of Item 24 of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>851</SU>
                             
                            <E T="03">See</E>
                             paragraph (e) of Item 24 of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>852</SU>
                             Amended Form N-3 requires a registrant to disclose the relationship between amounts paid to the distributor and the expenses that the registrant incurs; the amount of any unreimbursed expenses incurred under the 12b-1 plan in a previous year and carried over to future years; and whether the registrant participates in any joint distribution activities with another investment company and, if so, whether fees paid under the plan may be used to finance the distribution of the shares of another investment company and the method of allocating distribution costs (
                            <E T="03">e.g.,</E>
                             relative net asset size, number of shareholder accounts). 
                            <E T="03">See</E>
                             paragraphs (f)(2) through (4) of Item 24 of amended Form N-3.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Portfolio Managers (Item 25 of Form N-3)</HD>
                    <P>
                        As proposed, we are making certain amendments to Item 22 of Form N-3, which we are re-designating as Item 25.
                        <SU>853</SU>
                        <FTREF/>
                         We are amending the current requirement to describe the compensation of each portfolio manager by including relocation expenses among the list of items that may be excluded from compensation disclosures, provided that those items do not discriminate in scope, terms, or operation in favor of the portfolio manager and are available generally to all salaried employees.
                        <SU>854</SU>
                        <FTREF/>
                         Otherwise, these changes rephrase certain disclosure requirements to conform to current presentation requirements in Form N-1A but are not intended to significantly alter current disclosure obligations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>853</SU>
                             
                            <E T="03">See</E>
                             Item 25 of amended Form N-3. The amendments to this item will reflect the presentation of Item 20 of Form N-1A.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>854</SU>
                             
                            <E T="03">See</E>
                             Instruction 2 to Item 25(b) of amended Form N-3 (discussing relocation expenses).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Brokerage Allocation and Other Practices (Item 26 of Form N-3)</HD>
                    <P>
                        As proposed, we are making certain amendments to Item 23 of Form N-3, which we are re-designating as Item 26.
                        <SU>855</SU>
                        <FTREF/>
                         As proposed, the amendments will amend the current requirement to describe how transactions in portfolio securities are effected, by newly including markdowns on principal transactions among the items that must be discussed in a general statement about brokerage commissions and markups.
                        <SU>856</SU>
                        <FTREF/>
                         This will mirror the parallel requirement of Form N-1A 
                        <SU>857</SU>
                        <FTREF/>
                         and will provide additional relevant information regarding the ways portfolio security transactions involving negative, as well as positive, spreads could impact the separate account and its investors. As proposed, the amendments also slightly alter the instruction regarding the identification of securities issued by the registrant's regular broker or dealer and which the registrant has acquired by deleting the statement that if the registrant has issued more than one class or series of stock, information must be disclosed for the class or series that has securities that are being registered on Form N-3.
                        <SU>858</SU>
                        <FTREF/>
                         Otherwise, these changes rephrase certain disclosure requirements to conform to current presentation requirements in Form N-1A but are not intended to significantly alter current disclosure obligations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>855</SU>
                             
                            <E T="03">See</E>
                             Item 26 of amended Form N-3. The amendments to this item will reflect the presentation of Item 21 of Form N-1A.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>856</SU>
                             
                            <E T="03">See</E>
                             Item 26(a) of amended Form N-3.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>857</SU>
                             
                            <E T="03">See</E>
                             Item 21(a) of Form N-1A.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>858</SU>
                             
                            <E T="03">See</E>
                             Instruction to Item 26(e) of amended Form N-3. We believe this aspect of the current instruction is not necessary, as disclosure in response to a registration form's requirements generally relates to the class or series for which securities are being registered.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">g. Additional Amendments to Form N-6</HD>
                    <P>
                        Together with the cover page amendments described above,
                        <SU>859</SU>
                        <FTREF/>
                         we are making two additional amendments to Part B of Form N-6. First, as discussed above, and as proposed, we are relocating the disclosure on commissions paid to dealers from the SAI to the prospectus.
                        <SU>860</SU>
                        <FTREF/>
                         Second, as discussed above, and as proposed, we are eliminating current Item 23 (Loans) and consolidating required disclosures 
                        <PRTPAGE P="26037"/>
                        relating to contract loans into the prospectus.
                        <SU>861</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>859</SU>
                             
                            <E T="03">See supra</E>
                             note 801 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>860</SU>
                             
                            <E T="03">See supra</E>
                             note 710 and accompanying text; 
                            <E T="03">see also</E>
                             Item 20 of current Form N-6; Item 7 of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>861</SU>
                             The disclosures required by current Item 23 will be consolidated with current Item 10 into a single amended Item 13. 
                            <E T="03">See supra</E>
                             paragraphs accompanying and immediately following note 765.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. Part C (Other Information)</HD>
                    <P>Table 6 shows how our amendments will amend the item requirements of Part C of our variable contract registration forms. These amendments are largely intended to update the disclosure requirements and provide greater consistency among variable contract registration forms. As proposed, we are eliminating certain disclosure items in light of recent regulatory developments and our goal of reducing duplicative disclosure requirements. Although commenters did not raise broad objections to our proposed amendments, commenters raised concerns with and/or requested clarification on various items, as discussed in more detail below. To the extent we received no comments on certain items, we are adopting them as proposed, as discussed further below. </P>
                    <GPH SPAN="3" DEEP="584">
                        <PRTPAGE P="26038"/>
                        <GID>ER01MY20.003</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="223">
                        <PRTPAGE P="26039"/>
                        <GID>ER01MY20.004</GID>
                    </GPH>
                    <HD SOURCE="HD3">a. Amendments Conforming Part C Items of Form N-3 and N-4 to Presentation in Form N-6</HD>
                    <P>
                        As proposed, we are amending certain items of Part C of Form N-4 to reflect the more up-to-date presentation of corresponding items in Form N-6, and re-designating their numbering as shown in Table 6 above. To the extent that these amended items incorporate only minor wording changes,
                        <SU>862</SU>
                        <FTREF/>
                         they are indicated as “unchanged items” in Table 6. Otherwise, each of these amended items is discussed in more detail below.
                    </P>
                    <FTNT>
                        <P>
                            <SU>862</SU>
                             
                            <E T="03">See supra</E>
                             note 800.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">
                        Exhibits (Item 32 of Form N-3, Item 27 of Form N-4, Item 30 of Form N-6) 
                        <SU>863</SU>
                        <FTREF/>
                    </HD>
                    <FTNT>
                        <P>
                            <SU>863</SU>
                             In 2019, the Commission adopted amendments to its registration forms, including Forms N-3, N-4, and N-6, to require hyperlinks to most exhibits required to be filed with the registration statement. 
                            <E T="03">See</E>
                             FAST Act Adopting Release, 
                            <E T="03">supra</E>
                             note 501.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, we are amending the Exhibits item: (1) For Forms N-3 and N-4, to eliminate the requirement to list the financial statements filed as part of the registration statement; 
                        <SU>864</SU>
                        <FTREF/>
                         (2) for Form N-4, to require the filing of participation agreements; 
                        <SU>865</SU>
                        <FTREF/>
                         and (3) for Forms N-3 and N-4, to require the filing of administrative contracts.
                        <SU>866</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>864</SU>
                             
                            <E T="03">See</E>
                             Item 29(a) of current Form N-3; Item 24(a) of current Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>865</SU>
                             Item 27(h) of amended Form N-4.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>866</SU>
                             Item 32(k) of amended Form N-3; Item 27(i) of amended Form N-4.
                        </P>
                    </FTNT>
                    <P>
                        Pursuant to amendments adopted by the Commission in 2019,
                        <SU>867</SU>
                        <FTREF/>
                         this Item also includes instructions regarding redaction or omission of schedules or information, as well as linking to exhibits filed with the registration statement or incorporated by reference.
                        <SU>868</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>867</SU>
                             
                            <E T="03">See</E>
                             FAST Act Adopting Release, 
                            <E T="03">supra</E>
                             note 501 (among other things, revising instructions regarding exhibits to registration statements). These rules became effective April 2 and May 2, 2019.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>868</SU>
                             
                            <E T="03">See</E>
                             Instructions 1-4 to Item 32(r) of amended Form N-3, Item 27(o) of amended Form N-4, and Item 30(r) of amended Form N-6.
                        </P>
                    </FTNT>
                    <P>
                        One commenter suggested that many of the exhibits are not particularly useful, but did not identify specific exhibits or provide further explanation.
                        <SU>869</SU>
                        <FTREF/>
                         Although the lack of specificity makes it difficult for us to consider this comment further, we continue to believe that the list of required exhibits should include the material documents relating to the creation, administration, and offering of the contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>869</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Persons Controlled by or Under Common Control With the Depositor or Registrant (Item 34 of Form N-3, Item 29 of Form N-4, Item 32 of Form N-6)</HD>
                    <P>
                        As proposed, we are amending Forms N-3 and N-4 to no longer require registrants to disclose the principal business of any persons controlled by or under common control with the depositor or registrant.
                        <SU>870</SU>
                        <FTREF/>
                         We believe that the revised item provides sufficient information for investors to assess the effects of control arrangements affecting the registrant (which effects are based largely on the percentage of voting securities owned by controlling persons, or other bases of control, as required to be disclosed under the item).
                    </P>
                    <FTNT>
                        <P>
                            <SU>870</SU>
                             
                            <E T="03">See</E>
                             Item 31 of current Form N-3; Item 26 of current Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Indemnification (Item 35 of Form N-3, Item 30 of Form N-4, Item 33 of Form N-6)</HD>
                    <P>
                        For Forms N-3 and N-4, as proposed, we are amending the item relating to indemnification to eliminate the instruction specifying that, in responding to the item's requirements, a registrant should note the requirements of Securities Act rules 461 and 484, and Section 17 of the Investment Company Act.
                        <SU>871</SU>
                        <FTREF/>
                         We do not believe that specifically noting these legal requirements is necessary to remind registrants of the existence of separate legal requirements, since the forms are not intended to be a comprehensive source of all disclosure obligations relevant to registrants. Eliminating this item will also conform this aspect of Forms N-3 and N-4 to other registration statement forms and reflect the more streamlined presentation used in Form N-6.
                    </P>
                    <FTNT>
                        <P>
                            <SU>871</SU>
                             
                            <E T="03">See</E>
                             Item 33 of current Form N-3; Item 28 of current Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Fee Representation (Item 40 of Form N-3, Item 34 of Form N-4)</HD>
                    <P>
                        As proposed, we are adding new Item 40 to Form N-3 and new Item 34 to Form N-4, which require registrants to provide a representation of the insurance company or depositor that the fees and charges deducted under the contracts, in the aggregate, are reasonable in relation to the services rendered, the expenses expected to be incurred, and the risks assumed by the insurance company or depositor. The new disclosure item mirrors Item 33 of current Form N-6 (which we are re-designating as Item 37). Because Section 
                        <PRTPAGE P="26040"/>
                        26(f) of the Investment Company Act requires that the representation be made in the registration statement,
                        <SU>872</SU>
                        <FTREF/>
                         this new item merely requests the representation required by Section 26(f) and does not impose any new obligations on a Form N-3 or Form N-4 registrant.
                    </P>
                    <FTNT>
                        <P>
                            <SU>872</SU>
                             Section 26(f)(2)(A) of the Investment Company Act provides that it shall be unlawful for any unit investment trust that is a registered separate account funding variable insurance contracts to sell any such contract unless the registration statement for the contract represents that the fees and charges deducted under the contract, in the aggregate, are reasonable in relation to the services rendered, the expenses expected to be incurred, and the risks assumed by the insurance company. Section 27(i)(2) of the Investment Company Act makes Section 26(f) of the Investment Company Act applicable to Form N-3 registrants.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Amendments Requiring Filing of Preliminary Form of Summary Prospectus</HD>
                    <P>
                        For each form, and as proposed, we are amending the “Exhibits” disclosure item to require a registrant to file a preliminary “form of” any initial summary prospectus that the registrant intends to use on or after the effective date of the registration statement as an exhibit.
                        <SU>873</SU>
                        <FTREF/>
                         As discussed above, and as proposed, registrants will only be required to file the form of initial summary prospectus in any initial registration statement filing, or in any pre-effective amendment or post-effective amendment filed in accordance with paragraph (a) of rule 485.
                        <SU>874</SU>
                        <FTREF/>
                         In a change from the proposal, we are not requiring the filing of the updating summary prospectus because its contents should either be derivative of information provided in the statutory prospectus (
                        <E T="03">e.g.,</E>
                         the Key Information Table and the Appendix: Portfolio Companies/Investment Options Available Under the Contract) or readily discernible from comparison with the prior filing (
                        <E T="03">e.g.,</E>
                         by examining redline tags in the updating summary prospectus filing).
                    </P>
                    <FTNT>
                        <P>
                            <SU>873</SU>
                             Item 32(r) of amended Form N-3; Item 27(o) of amended Form N-4; Item 30(r) of amended Form N-6. To avoid confusion on the part of investors who might accidentally discover the form of a summary prospectus and mistake it for an effective prospectus, registrants must add a legend clearly identifying the document as a form of summary prospectus that the registrant intends to use on or after the effective date of the registration statement. 
                            <E T="03">See</E>
                             Instruction 5 to Item 32(r) of amended Form N-3; Item 27(o) of amended Form N-4; Item 30(r) of amended Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>874</SU>
                             
                            <E T="03">See generally supra</E>
                             Section II.A.8.a.
                        </P>
                    </FTNT>
                    <P>
                        This requirement is intended to permit the staff to review a summary prospectus in the form and manner in which a registrant would provide it to investors, prior to the registration statement's effective date. These amendments to the “Exhibits” item of each form accompany the other amendments that we propose to the “Exhibits” item of Forms N-3 and N-4 to conform to the parallel disclosure requirements in Form N-6.
                        <SU>875</SU>
                        <FTREF/>
                         Several commenters requested that the Commission permit registrants to file as an exhibit a “form of” summary prospectus that could be filed for multiple contracts that are substantially similar to or meaningfully representative of each other.
                        <SU>876</SU>
                        <FTREF/>
                         As discussed above, we will permit this practice under certain circumstances.
                        <SU>877</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>875</SU>
                             
                            <E T="03">See supra</E>
                             notes 864-866 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>876</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Lincoln Comment Letter; Brighthouse Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>877</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.8.a.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Principal Underwriters (Item 37 of Form N-3, Item 31 of Form N-4, Item 34 of Form N-6)</HD>
                    <P>
                        For Form N-3, as proposed, we are adding an instruction stating that information need not be provided about bona fide contracts with the registrant or its insurance company for outside legal or auditing services, or bona fide contracts for personal employment entered into with the registrant or its depositor in the ordinary course of business. Likewise, for Forms N-4 and N-6, as proposed, we are adding a similar instruction stating that information need not be given about the service of mailing proxies or periodic reports of the registrant. Collectively, these instructions are intended to focus disclosures on underwriting costs, as opposed to costs for legal or auditing services or other ancillary matters, and parallel similar instructions in Part B of these same forms regarding disclosures for underwriters.
                        <SU>878</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>878</SU>
                             
                            <E T="03">See supra</E>
                             Section II.C.3.c.
                        </P>
                    </FTNT>
                    <P>
                        Also, for Form N-3, as proposed, we are amending the instruction to subparagraph (c) of Item 35 of current Form N-3 to eliminate the portion of the first instruction requiring to include as “other compensation” any compensation received by an underwriter for keeping the registrant's securities in the hands of the public.
                        <SU>879</SU>
                        <FTREF/>
                         The category of “other compensation” is intended to encompass compensation that is not otherwise enumerated in one of the other categories. We believe deletion of this instruction will help streamline the form and remove any suggestion that this category is limited only to disclosure of compensation received for keeping the registrant's securities in the hands of the public.
                    </P>
                    <FTNT>
                        <P>
                            <SU>879</SU>
                             Instruction 1 to Item 35(c) of current Form N-3.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">d. Adjustment to Disclosure Thresholds (Items 37 and 39 of Form N-3, Items 31 and 33 of Form N-4, Items 34 and 36 of Form N-6)</HD>
                    <P>
                        As proposed, in addition to amending certain updated disclosure thresholds in the SAI, we are similarly increasing certain disclosure thresholds in Part C. For example, when providing information required regarding commissions and other compensation received, directly or indirectly, from the registrant during the registrant's last fiscal year by each principal underwriter, a registrant currently may exclude information about any service for which total payments of less than $5,000 were made during each of the registrant's last three fiscal years.
                        <SU>880</SU>
                        <FTREF/>
                         In addition, when providing a summary of certain contracts under which management-related services are provided to the registrant, a registrant currently need not provide information about any service for which total payments of less than $5,000 were made during each of the last three fiscal years.
                        <SU>881</SU>
                        <FTREF/>
                         As part of our efforts to update the registration forms, and as proposed, we are increasing these thresholds to $15,000 
                        <SU>882</SU>
                        <FTREF/>
                         to reflect the effects of inflation since 1985.
                        <SU>883</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>880</SU>
                             
                            <E T="03">See</E>
                             Instruction 3 to Item 35(c) of current Form N-3; Instruction 3 to Item 29(c) of current Form N-4; Instruction 3 to Item 30(c) of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>881</SU>
                             
                            <E T="03">See</E>
                             Instruction 2 to Item 37 of current Form N-3; Instruction 2 to Item 31 of current Form N-4; Instruction 2 to Item 32 of current Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>882</SU>
                             
                            <E T="03">See</E>
                             Instruction 3 to amended Item 37 and Instruction 2 to amended Item 39 of Form N-3; Instruction 3 to amended Item 31 and Instruction 2 to amended Item 33 of Form N-4; Instruction 3 to amended Item 34 and Instruction 2 to amended Item 36 of Form N-6.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>883</SU>
                             For a discussion of the calculation methodology, 
                            <E T="03">see supra</E>
                             note 836.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">e. Amendments Eliminating Current Part C Disclosure Requirements</HD>
                    <P>
                        As proposed, to reduce overlapping regulatory requirements, we are eliminating Item 32 of current Form N-3 and Item 27 of current Form N-4 (“Number of Contractowners”), because registrants are separately required to disclose the number of contractowners in the registrant's filings on Form N-CEN.
                        <SU>884</SU>
                        <FTREF/>
                         Unlike registration statements on Forms N-3 and N-4, reports on Form N-CEN are filed with the Commission in a structured data format that permits the Commission and its staff to more easily collect, aggregate, and analyze the reported information. As proposed, we are also eliminating Item 38 of current Form N-3 and Item 32 of Form N-4 
                        <PRTPAGE P="26041"/>
                        (“Undertakings”). These requirements are outdated 
                        <SU>885</SU>
                        <FTREF/>
                         or redundant with similar requirements under the amendments to Forms N-3 and N-4.
                        <SU>886</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>884</SU>
                             
                            <E T="03">See</E>
                             Item F.13 of Form N-CEN (requiring disclosure of the number of individual contracts that are in force at the end of the reporting period).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>885</SU>
                             Item 38(c) of current Form N-3 and Item 32(b) of current Form N-4 require an undertaking to include either (1) as part of any application to purchase a contract offered by the prospectus, a space that an applicant can check to request an SAI, or (2) a post card or similar written communication affixed to or included in the prospectus that the applicant can remove to send for an SAI. Because we understand that investors typically use the internet or—for investors who do not use the internet, telephonic means—to request an SAI, we believe that this undertaking is outdated.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>886</SU>
                             Because the Commission's view is that issuers of variable insurance contracts are required by Section 10(a)(3) of the Securities Act to maintain a current prospectus for so long as payments may be accepted under the contracts, regardless of whether new policies are being sold, the undertakings to file post-effective amendments required by Items 38(a) and (b) of current Form N-3 and Item 32(a) of current Form N-4 simply restate an issuer's obligation under the Securities Act. 
                            <E T="03">See</E>
                             Form N-6 Proposing Release, 
                            <E T="03">supra</E>
                             note 688, at text following n.83
                        </P>
                        <P>
                              
                            <E T="03">Compare</E>
                             Item 38(d) of current Form N-3 and Item 32(c) of current Form N-3 (requiring undertaking to deliver any SAI and any required financial statements promptly upon written or oral request) 
                            <E T="03">with</E>
                             Item 1(b) of amended Forms N-3 and N-4 (requiring registrants to state that the SAI is available, without charge, upon request and further requiring registrants to send the SAI within three business days of receipt of the request, by first-class mail or other means designed to ensure equally prompt delivery) and Item 17 of amended Form N-3 and Item 16 of amended Form N-4 (requiring registrants to explain how financial statements may be found or obtained).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">f. Additional Amendments to Form N-6</HD>
                    <P>
                        As proposed, we are amending the third column of the table required by Item 30 of current Form N-6 (“Principal Underwriters,” which we are re-designating as Item 34) to reflect compensation received from the registrant on all redemptions, rather than the more narrow requirement to disclose only compensation from events occasioning the deduction of a deferred sales load.
                        <SU>887</SU>
                        <FTREF/>
                         Because compensation may be paid upon redemptions not defined as deferred sales loads, we believe this change will clarify for investors the amount of redemption compensation received from the registrant.
                    </P>
                    <FTNT>
                        <P>
                            <SU>887</SU>
                             Item 34(c) of amended Form N-6. This change conforms Form N-6 with the comparable item of Form N-4. 
                            <E T="03">See</E>
                             Item 29(c) of current Form N-4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">5. Guidelines</HD>
                    <P>
                        The guidelines to current Forms N-3 and N-4 (the “Guidelines”) were prepared by the Division of Investment Management when the Commission adopted the forms in 1985.
                        <SU>888</SU>
                        <FTREF/>
                         The Guidelines, which generally restate certain Division positions that may affect fund disclosure, were intended to assist funds in preparing and filing their registration statements.
                    </P>
                    <FTNT>
                        <P>
                            <SU>888</SU>
                             
                            <E T="03">See</E>
                             Forms N-3 and N-4 Adopting Release, 
                            <E T="03">supra</E>
                             note 29, at text following n.51 (stating that publication of the Guidelines was not intended to elevate their status beyond that of staff guidance).
                        </P>
                    </FTNT>
                    <P>
                        Although certain Guidelines have been revised and new ones added in connection with the adoption of various rules, the Guidelines collectively have not been reviewed since 1985. As discussed in the Proposing Release, the Guidelines have become outdated and less useful, and have generally been superseded by other resources that are more frequently updated and accessible to the public.
                        <SU>889</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>889</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.D.5.
                        </P>
                    </FTNT>
                    <P>
                        As with other registration forms that have more recently been amended to eliminate the guidelines for those forms,
                        <SU>890</SU>
                        <FTREF/>
                         the Commission proposed to rescind the Guidelines to Forms N-3 and N-4 but requested comment on whether all or parts of the Guidelines should be retained (either as form items or instructions, or addressed as Commission guidance). We received no comments on our proposed elimination of the Guidelines, and are rescinding them as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>890</SU>
                             
                            <E T="03">See</E>
                             Form N-1A Adopting Release, 
                            <E T="03">supra</E>
                             note 799 (eliminating similar guidelines from Form N-1A).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">D. Inline XBRL</HD>
                    <P>
                        We are adopting, generally as proposed, the requirement to use the Inline XBRL format for the submission of certain required disclosures in the variable contract statutory prospectus.
                        <SU>891</SU>
                        <FTREF/>
                         Inline XBRL is a specification of the XBRL format that allows filers to embed XBRL data directly into an HTML document, eliminating any need to submit a copy of the tagged information in a machine-readable document separate from the human-readable document. Information structured using the Inline XBRL format is both human-readable and machine-readable for purposes of validation, aggregation, and analysis. This is the same format required for operating companies, mutual funds, and ETFs.
                        <SU>892</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>891</SU>
                             General Instruction 3.C.(h) of amended Forms N-3, N-4, and N-6; amendments to rules 485 and 497 under the Securities Act; amendments to rules 11 and 405 of Regulation S-T.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>892</SU>
                             
                            <E T="03">See</E>
                             Inline XBRL Filing of Tagged Data, Investment Company Act Release No. 33139 (June 29, 2018) [83 FR 40846 (Aug. 16, 2018)] (“Inline XBRL Adopting Release”). We believe the public's access to the specified disclosures will be facilitated by making the data available in a format with which many market participants will already be familiar as a result of reviewing and analyzing other disclosures in Inline XBRL.
                        </P>
                    </FTNT>
                    <P>The amendments harness Inline XBRL technology to enhance the ability of an investor to analyze and compare variable contracts (directly and through his or her investment professional). That technology also assists the investor by facilitating the analysis of variable contracts by Commission staff, as well as data aggregators, financial analysts, and other data users who often provide information to an investor. This aspect of the amendments is in keeping with our ongoing efforts to implement reporting and disclosure reforms that take advantage of the benefits of advanced technology to modernize the investment company reporting regime and to, among other things, help investors and other market participants better assess different products.</P>
                    <P>
                        For filers, Inline XBRL can enhance the efficiency of review, yield savings in time and cost of preparing machine-readable data, and potentially enhance the quality of the data over other machine-readable standards as certain errors will be easier to identify and correct because the data is also human-readable. For investors and other data users, requiring information to be tagged in a structured format could facilitate analysis and comparison of variable contracts. In addition, making the data available in Inline XBRL should enhance the usability and ease of accessibility to the disclosures because users will not have to access two different documents (one machine-readable and one human-readable) for the same data, and users can leverage the enhanced search and filtering capabilities of the Commission's Inline XBRL Viewer.
                        <SU>893</SU>
                        <FTREF/>
                         Given the complexity of variable contracts, tagging certain sections within the statutory prospectus in Inline XBRL format could provide greater transparency regarding the products' features and risks.
                    </P>
                    <FTNT>
                        <P>
                            <SU>893</SU>
                             
                            <E T="03">See</E>
                             Inline XBRL Adopting Release, 
                            <E T="03">supra</E>
                             note 892 (discussing the Commission's Inline XBRL Viewer).
                        </P>
                    </FTNT>
                    <P>
                        Variable contract registrants will be required to embed a part of the Interactive Data File 
                        <SU>894</SU>
                        <FTREF/>
                         within an HTML document using Inline XBRL and to include the rest in an exhibit to that document. The portion filed as an exhibit to the filing contains contextual information about the XBRL tags embedded in the filing. The information as tagged will continue to be required to satisfy all other requirements of rule 405 under Regulation S-T, including the 
                        <PRTPAGE P="26042"/>
                        technical requirements in the EDGAR Filer Manual.
                    </P>
                    <FTNT>
                        <P>
                            <SU>894</SU>
                             Regulation S-T defines the term “Interactive Data File” to mean the machine-readable computer code that presents information in XBRL electronic format pursuant to rule 405 of Regulation S-T and as specified by the EDGAR Filer Manual. 
                            <E T="03">See</E>
                             rule 11 of Regulation S-T; rule 405 of Regulation S-T. The EDGAR Filer Manual sets forth the technical formatting requirements for the presentation and submission of electronic filings through the EDGAR system.
                        </P>
                    </FTNT>
                    <P>
                        Comments regarding our proposal to require variable contract filings to be tagged using Inline XBRL were mixed. Some commenters supported the proposed Inline XBRL requirements.
                        <SU>895</SU>
                        <FTREF/>
                         One commenter stated that making information about variable annuities available in a structured, machine-readable format would benefit investors by making the information more transparent and comparable.
                        <SU>896</SU>
                        <FTREF/>
                         Several commenters believed the proposed requirement would enable data aggregators, financial analysts, and other data users to offer services that would empower variable contract investors to make comparisons and better investment decisions.
                        <SU>897</SU>
                        <FTREF/>
                         Two commenters stated that the Inline XBRL requirement would encourage competition in the variable contract marketplace, serving to protect investors and promote efficiency and, potentially, innovation.
                        <SU>898</SU>
                        <FTREF/>
                         Another commenter stated that “requiring disclosures to be made in Inline XBRL has the potential to do more than the most innovative disclosure design changes to assist the many investors who lack the time and expertise to pore through disclosure documents to select the variable annuity and contract features that best meet their needs.” 
                        <SU>899</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>895</SU>
                             
                            <E T="03">See</E>
                             Comment Letter of XBRL US (Mar. 13, 2019) (“XBRL US Comment Letter”); Better Markets Comment Letter; CFA Comment Letter; and Chemas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>896</SU>
                             
                            <E T="03">See</E>
                             XBRL US Comment Letter; s
                            <E T="03">ee also</E>
                             CAI Comment Letter (supporting the use of Inline XBRL for contracts currently offered for sale, noting that structured disclosures “would allow investors and their investment professionals (as well as data aggregators, financial analysts, and other data users) to efficiently analyze and compare available information about available contracts.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>897</SU>
                             
                            <E T="03">See</E>
                             Better Markets Comment Letter; CFA Comment Letter; Chemas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>898</SU>
                             
                            <E T="03">See</E>
                             CFA Comment Letter; Chemas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>899</SU>
                             
                            <E T="03">See</E>
                             CFA Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        By contrast, three commenters opposed requiring a variable contract registrant to tag its disclosures.
                        <SU>900</SU>
                        <FTREF/>
                         These commenters questioned the utility of tagged variable contract data, stating that XBRL data filed by funds has been minimally used by investors, Commission staff, or data aggregators.
                        <SU>901</SU>
                        <FTREF/>
                         One commenter concluded that because variable annuities are even more complicated and less standardized than mutual funds, Inline XBRL tagging of variable contract prospectuses “is simply not worth the cost.” 
                        <SU>902</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>900</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; Ameritas Comment Letter; Anonymous Comment Letter III.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>901</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; Anonymous Comment Letter III; Ameritas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>902</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter (also suggesting that tagging may not be necessary “as a data mining tool should be able to pull the data without tagging.”).
                        </P>
                    </FTNT>
                    <P>
                        One commenter supported requiring structured data for current offerings, stating that Inline XBRL is primarily designed to help investors and other market participants compare investments for purposes of an initial investment decision, but opposed applying the requirements to insurance contracts no longer being sold as to do so would “impose unnecessary costs and burdens on insurers without providing any benefit to investors.” 
                        <SU>903</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>903</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>We are adopting the Inline XBRL requirements for variable contracts as proposed, but in response to commenters, these requirements will only apply to contracts being sold to new investors. We believe that investors and other data users will benefit from information provided using the Inline XBRL format. In contrast to statements by some commenters that mutual fund XBRL disclosures are minimally used, staff have observed that the risk/return XBRL data are accessed on a regular basis by the public. Moreover, based on our experience with operating company and mutual fund XBRL data use, we expect that data aggregators likely will begin using structured data, once it is available, to provide information to variable contract investors, Commission staff, financial analysts, and other data users. Requiring the use of the Inline XBRL format makes it easier and less costly for such entities to efficiently access and analyze variable contract data, because those entities will not have to spend time rekeying the filings to structure the data and correcting for data quality. And because variable contracts are primarily held by retail investors who often look to third-party information sites when evaluating their investment options, this data should help investors compare variable contracts, including their features, costs, and portfolio company options.</P>
                    <P>We agree with commenters' assertions that Inline XBRL will be primarily of use in connection with the initial investment decision, when investors can use tagged data to more readily compare key features of multiple variable contracts to find the variable contract that best meets their investment needs. We expect that Inline XBRL will be of more limited use to existing investors because variable contracts are intended to be long-term investments and variable contracts are priced and sold accordingly. For example, under some variable contracts, if an investor were to make a withdrawal in contract year 15 from his or her variable contract that has a 10-year surrender period (measured by each purchase payment), that withdrawal still could be assessed a surrender charge. In that case, the surrender charge would apply to any purchase payment made during the last ten years, even if the investor had submitted his or her initial purchase payment for the variable contract more than ten years ago. For these reasons, variable contract investors likely will have limited incentives to seek out alternative variable contracts following their initial investment. Existing investors may be offered a buyout of their contract by their issuing insurance company or offered to exchange their contract into a new contract that may have different fees, benefits, or other terms. However, in those cases, the investor is typically presented with a specific alternative that the investor can more easily compare to his or her existing contract—as opposed to the initial investment decision process when the investor potentially is selecting from among a number of variable contracts and could benefit from the ability to use tagged data.</P>
                    <P>
                        Accordingly, the requirement to structure the disclosure using the Inline XBRL format will apply to all contracts for which an insurance company is maintaining a current registration statement and that are being sold to new investors.
                        <SU>904</SU>
                        <FTREF/>
                         Thus, for registration statements with multiple contracts, tagging will be required for contracts that are still being sold to new investors, but will not be required for contracts that are not being sold to new investors even if those contracts are still accepting purchase payments or premiums from existing investors. We believe that this balances the benefits of these amendments to investors with the costs and burdens that would be associated with tagging contracts that are no longer being sold to new investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>904</SU>
                             Discontinued contracts that are “Eligible Contracts” as defined below in Section II.E.3 are not subject to the Inline XBRL requirement. 
                            <E T="03">See infra</E>
                             Section II.E.
                        </P>
                    </FTNT>
                    <P>While we believe the use of Inline XBRL will ultimately benefit investors and other data users, we recognize that many insurers will face burdens in transitioning to the Inline XBRL format and as a result, are adopting a delayed compliance date for this new requirement, as discussed below in Section II.G of this release.</P>
                    <P>
                        <E T="03">Filings to be tagged.</E>
                         Like mutual funds and ETFs, registrants will be 
                        <PRTPAGE P="26043"/>
                        required to submit to the Commission in Inline XBRL certain information discussed below in registration statements or post-effective amendments filed on Forms N-3, N-4, and N-6, and forms of prospectuses filed pursuant to rule 497(c) or rule 497(e) under the Securities Act that include information that varies from the registration statement. We received no comments on this aspect of the proposal.
                    </P>
                    <P>
                        <E T="03">Information to be tagged.</E>
                         We are requiring, largely as proposed, that registrants tag the following statutory prospectus disclosure items using Inline XBRL: The Key Information Table; Fee Table; Principal Risks of Investing in the Contract; for Form N-6 registrants, Standard Death Benefits; [Other] Benefits Available Under the Contract; Portfolio Companies [Investment Options] Available Under the Contract; and for Form N-3 registrants, Additional Information About Investment Options Available Under the Contract.
                        <SU>905</SU>
                        <FTREF/>
                         We believe that these items—which provide important information about a variable contract's key features, costs, and risks— are most suited to being tagged in a structured format and will be of greatest utility for investors and other data users that seek structured data to analyze and compare variable contracts. We received no comments regarding the substantive disclosure items proposed to be tagged.
                    </P>
                    <FTNT>
                        <P>
                            <SU>905</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(h) to Forms N-3, N-4, and N-6; 
                            <E T="03">see also</E>
                             Items 2, 4, 5, 11, 18, 19 of amended Form N-3; Items 2, 4, 5, 10, and 17 of amended Form N-4; Items 2, 4, 5, 10, 11, and 18 of amended Form N-6. This information largely parallels similar information contained in the Form N-1A risk/return summary. 
                            <E T="03">See</E>
                             Item 2 of Form N-1A (Risk/Return Summary: Investment Objectives/Goals); Item 3 of Form N-1A (Risk/Return Summary: Fee Table); Item 4 of Form N-1A (Risk/Return Summary: Investments, Risks and Performance).
                        </P>
                    </FTNT>
                    <P>As proposed, we are requiring registrants to tag the Key Information Table, which provides a concise summary of fees and expenses, risks, restrictions, taxes, and conflicts of interest. We are also requiring that registrants tag the Fee Table, which provides detailed information about the variable contract's costs. We believe that tagging could facilitate analysis of the costs associated with variable contracts, and allow investors and their investment professionals to compare the costs of a particular contract with the costs of other variable contracts or other investment products, such as mutual funds. Registrants will also be required to tag the Principal Risks disclosures so investors and their investment professionals can analyze a contract's risks alongside the contract's features and benefits.</P>
                    <P>
                        As proposed, we are requiring registrants to tag [Other] Benefits Available Under the Contract because these product features may be easier to analyze and compare if information pertaining to those features is available in a structured data format. While the Commission did not propose to require registrants to tag standard death benefit information, as discussed above, the Benefits Available Under the Contract disclosure item for Form N-3 and N-4 registrants will now include standard, as well as optional, death benefits.
                        <SU>906</SU>
                        <FTREF/>
                         As a result, Form N-3 and N-4 registrants will also be required to tag standard death benefit information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>906</SU>
                             
                            <E T="03">See supra</E>
                             note 734 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        As proposed, standard death benefits for variable life insurance contracts will be described in response to a separate Form N-6 item limited to for Standard Death Benefits.
                        <SU>907</SU>
                        <FTREF/>
                         To parallel the (standard and optional) death benefits tagging requirements for variable annuities, we are requiring variable life insurance registrants to tag the item for Standard Death Benefits.
                        <SU>908</SU>
                        <FTREF/>
                         Because investors principally, if not exclusively, buy variable life insurance contracts for their death benefits, which often include a choice among two or three death benefit options, tagging this information will make it easier to compare the key features of these products.
                    </P>
                    <FTNT>
                        <P>
                            <SU>907</SU>
                             
                            <E T="03">See supra</E>
                             note 694 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>908</SU>
                             
                            <E T="03">See</E>
                             General Instruction C.3.(h)(i) of amended Form N-6 (referencing Item 10 (Death Benefits)).
                        </P>
                    </FTNT>
                    <P>Finally, as proposed, we are requiring registrants to tag Investment Options Available Under the Contract, as this may allow investors and their investment professionals to more easily compare the mutual funds or other investment options that are offered by different variable contracts and assess whether a particular contract's investment options meet the investor's needs or goals.</P>
                    <P>
                        While we received no comments regarding the substantive disclosure items to be tagged, several commenters inquired about a taxonomy for variable contracts.
                        <SU>909</SU>
                        <FTREF/>
                         One commenter expressed concern that “there is no taxonomy in existence [for variable contracts] and it would be exceptionally difficult to develop a taxonomy for these products with their bespoke features.” 
                        <SU>910</SU>
                        <FTREF/>
                         Another commenter stated that to help illustrate how such standards can be built and used to improve the usability of variable annuity data, it had developed a prototype Annuity Taxonomy, to which it provided a link in its comment letter.
                        <SU>911</SU>
                        <FTREF/>
                         This commenter suggested that to facilitate product comparisons and aid investors in their investment decisions, we should consider requiring insurers to tag additional elements beyond those likely to fall within the scope of the disclosure items proposed to be tagged.
                        <SU>912</SU>
                        <FTREF/>
                         A third commenter asked for guidance regarding whether a new XBRL taxonomy would be developed and circulated for comment, and if it the prototype Annuity Taxonomy developed by the other commenter might be an indicator of the actual taxonomy.
                        <SU>913</SU>
                        <FTREF/>
                         One commenter, though not supporting an Inline XBRL requirement, observed that if tagging is mandated, we should require certain identifying information for the portfolio companies to be tagged to facilitate the cross-referencing of such information.
                        <SU>914</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>909</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; XBRL U.S. Comment Letter; IRI Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>910</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>911</SU>
                             
                            <E T="03">See</E>
                             XBRL US Comment Letter. (“[W]e developed a prototype Annuity Taxonomy (
                            <E T="03">https://xbrl.us/xbrl-taxonomy/2019-var/</E>
                            ) which . . . is available for the Commission or any other interested parties to download.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>912</SU>
                             
                            <E T="03">Id.</E>
                             (identifying 57 additional terms to be tagged in XBRL format).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>913</SU>
                             
                            <E T="03">See</E>
                             IRI Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>914</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter (stating that “if you do tag, you should make sure you capture the class ID/tickers for the underlying funds so mutual fund information can easily be cross-referenced.”).
                        </P>
                    </FTNT>
                    <P>
                        As with other Commission XBRL taxonomies, staff will post a draft variable contracts XBRL taxonomy for public review and feedback.
                        <SU>915</SU>
                        <FTREF/>
                         When available, filers will be required to use the most recent version of the variable contracts XBRL taxonomy as specified by the EDGAR Filer Manual.
                        <SU>916</SU>
                        <FTREF/>
                         As discussed below, we are extending the proposed compliance period for the new Inline XBRL requirements, which will allow sufficient time for us to consider public comments on the draft taxonomy and subsequently adopt and publish a final taxonomy before variable contract registrants must comply with the new structured data reporting regime.
                        <SU>917</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>915</SU>
                             Taxonomies are 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.sec.gov/structureddata/dera_taxonomies</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>916</SU>
                             
                            <E T="03">See</E>
                             rule 405(c)(1) of Regulation S-T.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>917</SU>
                             
                            <E T="03">See infra</E>
                             Section II.G.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Submission of Interactive Data File.</E>
                         As proposed, in a framework similar to that for mutual funds and ETFs under the recently adopted Inline XBRL regime,
                        <SU>918</SU>
                        <FTREF/>
                         we are requiring variable contract registrants to submit Interactive Data Files as follows:
                    </P>
                    <FTNT>
                        <P>
                            <SU>918</SU>
                             
                            <E T="03">See</E>
                             Inline XBRL Adopting Release, 
                            <E T="03">supra</E>
                             note 892.
                        </P>
                    </FTNT>
                    <P>
                        • For post-effective amendments filed pursuant to paragraph (b)(1)(i), (ii), (v), or (vii) of rule 485, and in the case of registrants on Forms N-4 or N-6, 
                        <PRTPAGE P="26044"/>
                        paragraph (b)(1)(vi) of rule 485,
                        <SU>919</SU>
                        <FTREF/>
                         Interactive Data Files must be filed either concurrently with the filing or in a subsequent amendment that is filed on or before the date that the post-effective amendment that contains the related information becomes effective; 
                        <SU>920</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>919</SU>
                             To help facilitate efficiencies in the variable contract post-effective amendment filing process, we will permit variable contracts to submit Interactive Data Files concurrently with these post-effective amendments because post-effective amendments filed pursuant to these paragraphs of rule 485 generally are not subject to further revision.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>920</SU>
                             General Instruction C.3.(h)(i)(B) of FormsN-3, N-4, and N-6; 
                            <E T="03">cf.</E>
                             General Instruction C.3.(g)(i)(B) of Form N-1A.
                        </P>
                    </FTNT>
                    <P>
                        • For initial registration statements and post-effective amendments filed other than pursuant to paragraph (b)(1)(i), (ii), (v), or (vii) of rule 485, and in the case of registrants on FormsN-4 or N-6, paragraph (b)(1)(vi) of rule 485, Interactive Data Files must be filed in a subsequent amendment on or before the date the registration statement or post-effective amendment that contains the related information becomes effective; 
                        <SU>921</SU>
                        <FTREF/>
                         and
                    </P>
                    <FTNT>
                        <P>
                            <SU>921</SU>
                             General Instruction C.3.(h)(i)(A) to FormsN-3, N-4, and N-6; 
                            <E T="03">cf.</E>
                             General Instruction C.3.(g)(i)(A) of Form N-1A.
                        </P>
                    </FTNT>
                    <P>
                        • For any form of prospectus filed pursuant to rule 497(c) or (e), Interactive Data Files must be submitted concurrently with the filing.
                        <SU>922</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>922</SU>
                             General Instruction C.3.(h)(ii) to Forms N-3, N-4, and N-6; 
                            <E T="03">cf.</E>
                             General Instruction C.3.(g)(ii) of Form N-1A.
                        </P>
                    </FTNT>
                    <P>We believe this approach will facilitate the timely availability of important information in a structured format for investors, their investment professionals, and other data users yielding substantial benefits. For data aggregators responding to investor demand for the data, the availability of the required disclosures using the Inline XBRL format concurrent with filing or before the date of effectiveness will allow them to quickly process and share the data and related analysis with investors. We received no comments regarding this proposed approach.</P>
                    <P>
                        <E T="03">Identification of Classes.</E>
                         As proposed, the Interactive Data File will be required to be submitted in such a manner that will permit the information for each contract (and, for any information that does not relate to all of the classes in a filing, each class of the contract) to be separately identified.
                        <SU>923</SU>
                        <FTREF/>
                         We received no comments regarding this aspect of the proposal.
                    </P>
                    <FTNT>
                        <P>
                            <SU>923</SU>
                             General Instruction C.3.(h)(iii) to Forms N-3, N-4, and N-6.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Consequence of failure to submit required Interactive Data File.</E>
                         Similar to the framework for mutual funds and ETFs, we are adopting, as proposed, amendments to rule 485 under the Securities Act to provide that if a registrant does not submit a required Interactive Data File, the registrant's ability to file post-effective amendments to its registration statement under subparagraph (b) of the rule will be automatically suspended until the required Interactive Data File is submitted.
                        <SU>924</SU>
                        <FTREF/>
                         We received no comments on this aspect of the proposal.
                    </P>
                    <FTNT>
                        <P>
                            <SU>924</SU>
                             Rule 485(c)(3).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Availability of hardship exemptions.</E>
                         The Commission proposed that under the final rules registrants may request temporary and continuing hardship exemptions for the inability to timely file electronically the Interactive Data File.
                        <SU>925</SU>
                        <FTREF/>
                         One commenter expressed support for this aspect of the proposal,
                        <SU>926</SU>
                        <FTREF/>
                         and we are adopting this provision as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>925</SU>
                             
                            <E T="03">See</E>
                             17 CFR 232.201 (rule 201 of RegulationS-T) (temporary hardship exemption) and 17 CFR 232.202 (rule 202 of Regulation S-T) (continuing hardship exemption).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>926</SU>
                             
                            <E T="03">See</E>
                             Chemas Comment Letter.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">E. Discontinued Variable Contracts</HD>
                    <P>Today, many variable contracts no longer offered to the public operate in a manner consistent with certain staff no-action letters and provide alternative disclosures to investors in lieu of filing post-effective amendments to update a registration statement and providing updated prospectuses to existing investors (these discontinued contracts are referred to as “Alternative Disclosure Contracts”). The staff letters will be withdrawn. In addition, the Commission is taking the position that, if an issuer of an Alternative Disclosure Contract that is discontinued as of July 1, 2020 that provides alternative disclosures does not file post-effective amendments to update a variable contract registration statement and does not provide updated prospectuses to existing investors, this would not provide a basis for enforcement action so long as investors are provided with the alternative disclosures or modernized alternative disclosures described below. We are not adopting any form of going-forward relief for discontinued contracts at this time, although we will continue to consider whether any form of going-forward relief for discontinued contracts might be appropriate. We welcome input as described below in Section II.E.4.</P>
                    <HD SOURCE="HD3">1. Background</HD>
                    <P>
                        An insurance company may choose to stop offering a variable contract to new investors while continuing to accept additional payments from existing investors. Each additional purchase payment under a variable contract, or reallocation of contract value from one sub-account to another, is considered a “sale” under Section 5 of the Securities Act requiring delivery of a current prospectus, and variable contract issuers generally maintain current prospectuses for their products through the filing of annual post-effective amendments to the registration statements and, as necessary, supplementing or “stickering” the contract prospectus or SAI.
                        <SU>927</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>927</SU>
                             
                            <E T="03">See</E>
                             Forms N-3 and N-4 Adopting Release, 
                            <E T="03">supra</E>
                             note 29, at n.14 and accompanying text.
                        </P>
                    </FTNT>
                    <P>As the number of contracts outstanding declines over time, the proportion of fixed costs per contract and other burdens associated with maintaining a current registration statement and mailing prospectuses increase over a diminishing asset base. Unlike other types of registered investment companies that can liquidate or merge with another investment company when assets are reduced to such a level that continuing the investment company is not viable, an insurance company is unable to liquidate or otherwise terminate a variable contract. We understand that an insurance company may sometimes seek to encourage investors to exchange into new contracts or make buyout offers, but it cannot unilaterally terminate an investor's contract.</P>
                    <HD SOURCE="HD3">a. Staff No-Action Letters</HD>
                    <P>
                        Beginning in 1977, the staff of the Division of Investment Management issued a series of no-action letters stating that the staff would not recommend enforcement action if issuers did not update the variable contract registration statement and deliver updated prospectuses to existing investors, so long as certain conditions were met, including distributing alternative disclosures to investors (each, a “Staff Letter,” and collectively, the “Staff Letters”).
                        <SU>928</SU>
                        <FTREF/>
                         The last Staff Letter was issued in 1995.
                        <SU>929</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>928</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Great-West Life and Annuity Insurance Company, SEC Staff No-Action Letter (pub. avail. Oct. 23, 1990) (“1990 Letter”); MML Bay State Life Ins. Co., SEC Staff No-Action Letter (pub. avail. Apr. 12, 1990); Transamerica Occidental Life Insurance Co., SEC Staff No-Action Letter (pub. avail. Mar. 16, 1990); Connecticut Mutual Life Insurance Company, SEC Staff No-Action Letter (pub. avail. Mar. 7, 1990).
                        </P>
                        <P>
                             The staff declined to extend its no-action position to variable annuities funded by managed separate accounts. 
                            <E T="03">See</E>
                             Provident National Assurance Company, SEC Staff No-Action Letter (pub. avail. June 2, 1987); Great-West Life Assurance Company, SEC Staff No-Action Letter (pub. avail. June 4, 1987).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>929</SU>
                             
                            <E T="03">See</E>
                             Metropolitan Life Insurance Co., SEC Staff No-Action Letter (pub. avail. Apr. 26, 1995) (“Metropolitan Letter”).
                        </P>
                    </FTNT>
                    <PRTPAGE P="26045"/>
                    <P>
                        The Staff Letters generally were limited to Securities Act registration statements for contracts that are no longer offered to new purchasers and that have fewer than 5,000 investors (or participants in the case of group contracts).
                        <SU>930</SU>
                        <FTREF/>
                         The Staff Letters also identified a set of circumstances in which the staff would not recommend enforcement action once the registration statement is no longer updated: 
                        <SU>931</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>930</SU>
                             In the 1990 Letter, the staff stated that it would no longer respond to no-action requests “in this area unless they raise novel issues or involve more than 5,000 variable annuity or variable life insurance contracts.” There are four Staff Letters concerning contracts where the number of contract owners exceeded 5,000. 
                            <E T="03">See</E>
                             Metropolitan Letter (42,910 contract owners); Monarch Life Insurance Co., SEC Staff No-Action Letter (pub. avail. June 9, 1992) (“Monarch Letter”) (5,900 contract owners); New York Life Insurance and Annuity Corp., SEC Staff No-Action Letter (pub. avail. Nov. 15, 1989) (13,713 contract owners); Security Benefit Life Insurance Company, SEC Staff No-Action Letter (pub. avail. July 2, 1987) (28,019 contract owners).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>931</SU>
                             Some of the circumstances identified in which the staff would not recommend enforcement action varied slightly across the Staff Letters over time, specifically with respect to the delivery and availability of the insurance company's audited financial statements. The circumstances discussed below reflect those identified in the most recent Staff Letters.
                        </P>
                    </FTNT>
                    <P>• There are no material changes made to the contract;</P>
                    <P>
                        • New contracts are not offered to the public, and the registrant does not contemplate such an offering in the future; 
                        <SU>932</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>932</SU>
                             The Staff Letters do not address existing investors making additional purchase payments.
                        </P>
                    </FTNT>
                    <P>• Investors are provided the following disclosures:</P>
                    <P>○ The portfolio companies' current prospectuses (or summary prospectuses) and any updates thereto, annual and semi-annual reports, proxy materials, and any other periodic reports or other shareholder materials for the portfolio companies;</P>
                    <P>○ Confirmations of transactions in accordance with 17 CFR 240.10b-10 (rule 10b-10 under the Exchange Act);</P>
                    <P>
                        ○ Within 120 days after the close of the fiscal year, updated audited financial statements of the registrant, and in the case of variable life insurance contracts, the depositor's updated audited financial statements; 
                        <SU>933</SU>
                        <FTREF/>
                         and
                    </P>
                    <FTNT>
                        <P>
                            <SU>933</SU>
                             With respect to variable annuities, the depositor's updated audited financial statements would be available upon request. 
                            <E T="03">See, e.g.,</E>
                             Metropolitan Letter; Monarch Letter.
                        </P>
                    </FTNT>
                    <P>○ At least once a year, a statement of the number of units and values in each investor's account (collectively, the “Alternative Disclosures”).</P>
                    <P>
                        • The registrant files periodic reports with the Commission pursuant to Section 30 of the Investment Company Act (
                        <E T="03">i.e.,</E>
                         reports on Form N-CEN).
                        <SU>934</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>934</SU>
                             The Staff Letters specifically identified a registrant's filing of reports on Form N-SAR as one of the set of applicable circumstances. Form N-SAR was recently rescinded and succeeded by Form N-CEN. 
                            <E T="03">See</E>
                             Investment Company Reporting Modernization, Investment Company Act Release No. 32314 (Oct. 13, 2016) [81 FR 81870 (Nov. 18, 2016)] (“Investment Company Reporting Modernization Adopting Release”), at n.744 and accompanying text.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Liability</HD>
                    <P>
                        As of August 2019, we estimate that the Alternative Disclosures that the Staff Letters describe are being provided for more than half of variable contract Securities Act registration statements: 
                        <SU>935</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>935</SU>
                             Our understanding is based on staff review of filings with the Commission and discussions with industry participants.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="208">
                        <GID>ER01MY20.005</GID>
                    </GPH>
                    <P>
                        Providing the Alternative Disclosures, in lieu of updates to an issuer's registration statement, may have the effect of potentially limiting issuers' liability under certain provisions of Sections 11 and 12(a)(2) of the Securities Act, which require a registration statement or prospectus to contain whatever information may be necessary or appropriate to avoid material misstatements or omissions.
                        <SU>936</SU>
                        <FTREF/>
                         In addition, Section 34(b) of the Investment Company Act also imposes liability for misstatements in a registration statement; however, unlike Sections 11 and 12(a)(2), there is no private right of action available to aggrieved investors.
                        <SU>937</SU>
                        <FTREF/>
                         Although these Alternative Disclosures may not be subject to liability under Sections 11 or 12 of the Securities Act, or Section 34(b) of the Investment Company Act, they are subject to provisions prohibiting material misstatements in the offer or sale of a security.
                        <SU>938</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>936</SU>
                             
                            <E T="03">See supra</E>
                             discussion at notes 505 (discussing Section 12(a)(2) liability) and 524 (discussing Section 11 liability).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>937</SU>
                             
                            <E T="03">See Bellikoff</E>
                             v. 
                            <E T="03">Eaton Vance Corp.,</E>
                             481 F.3d 110 (2d Cir. 2007).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>938</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Section 17(a) of the Securities Act; Section 10(b) and 17 CFR 240.10b-5 (rule 10b-5 under the Exchange Act). There may also be additional remedies for investors, for example, under state insurance law, state securities law, and contract law.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Approaches to Framework for Discontinued Contracts</HD>
                    <P>
                        In proposing the new variable contract summary prospectus disclosure 
                        <PRTPAGE P="26046"/>
                        framework, the Commission acknowledged the industry practice of providing Alternative Disclosures (which are significantly different from the requirements of both the current prospectus and the new summary prospectus regimes) under specific circumstances that the Staff Letters identify. The Commission proposed to take the position that if certain issuers currently operating under the Staff Letters do not file post-effective amendments to update a variable contract registration statement and do not provide updated prospectuses to existing investors, under certain circumstances, this would not provide a basis for Commission enforcement action so long as investors continue to receive the Alternative Disclosures.
                    </P>
                    <P>
                        The Commission proposed to apply this position only to Alternative Disclosure Contracts operating in the manner that the Staff Letters describe as of the effective date of any final summary prospectus rules. The Commission proposed that all other variable contract issuers would be required to file post-effective amendments to update their registration statements and provide updated prospectuses under current regulatory requirements, and could avail themselves of the summary prospectus framework as adopted. Additionally, the Commission requested comment on two alternative approaches for discontinued contracts, including two methods of implementation that would apply these approaches to either contracts discontinued after the effective date of any final summary prospectus rules or all discontinued contracts (including Alternative Disclosure Contracts).
                        <SU>939</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>939</SU>
                             The Commission stated that it was considering two alternative approaches for discontinued contracts, “Approach 1,” which would codify existing practices under the Staff Letters with certain modifications, as well as “Approach 2,” which would permit registration statements to be updated using forward incorporation by reference. The Commission also stated that each of these approaches could be implemented using either “Method One,” which would apply only on a going-forward basis, or “Method Two,” which would apply to all discontinued contracts. 
                            <E T="03">See</E>
                             Proposing Release, Section II.C.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Comments Received on Proposal</HD>
                    <P>
                        While one commenter stated that all investors should receive the same disclosures through a summary prospectus regardless of whether or not the variable contract is discontinued,
                        <SU>940</SU>
                        <FTREF/>
                         other commenters supported the general framework for discontinued contracts under the Staff Letters,
                        <SU>941</SU>
                        <FTREF/>
                         with a number citing the many decades that insurers have structured their operations consistent with the Staff Letters.
                        <SU>942</SU>
                        <FTREF/>
                         These commenters stated that the framework allowed insurers to reduce the disproportionate costs associated with updating the registration statement and delivering updated prospectuses for discontinued contracts over a diminishing asset base.
                        <SU>943</SU>
                        <FTREF/>
                         Some of these commenters also stated that the framework has enabled insurers to continually innovate and introduce new products for investors.
                        <SU>944</SU>
                        <FTREF/>
                         In addition, some of these commenters stated that the framework has helped to moderate fees and charges for variable contracts.
                        <SU>945</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>940</SU>
                             
                            <E T="03">See</E>
                             Better Markets Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>941</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Brighthouse Comment Letter; Transamerica Comment Letter; ACLI Comment Letter; Lincoln Comment Letter; Ameritas Comment Letter; IRI Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>942</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Brighthouse Comment Letter; ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>943</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Brighthouse Comment Letter; Transamerica Comment Letter; ACLI Comment Letter; Lincoln Comment Letter; Ameritas Comment Letter; IRI Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>944</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Brighthouse Comment Letter; Transamerica. One commenter indicated that in the absence of this relief, “insurers generally will be more hesitant to innovate and offer new products,” which may “dampen competition in the variable contract market, limit investor choice, and stall innovation in the retirement income market where innovation is sorely needed.” 
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>945</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Brighthouse Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Commenters stressed the importance of grandfathering Alternative Disclosure Contracts, as proposed.
                        <SU>946</SU>
                        <FTREF/>
                         These commenters urged, at a minimum, that we provide some form of grandfathering for registrants currently operating in a manner consistent with the Staff Letters due to the difficulties involved in updating those registration statements. One commenter urged that any grandfathering be codified by rule rather than through a Commission position to provide more assurance to these registrants.
                        <SU>947</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>946</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Transamerica Comment Letter (“failing to permit grandfathering . . . would cause significant disruption to our variable product business”); Brighthouse Comment Letter (“un-Great-Westing” contracts “would present a tremendous initial resource strain . . . to `revive' registration statements, many of which have not been sold or updated in decades”); ACLI Comment Letter (the costs of eliminating relief “would greatly outweigh the very marginal benefits of such an action”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>947</SU>
                             
                            <E T="03">See</E>
                             IRI Comment Letter II.
                        </P>
                    </FTNT>
                    <P>
                        Commenters emphasized that some of these contract prospectuses have not been updated for many years, and in some cases several decades, and that preparing new registration statements and prospectuses would involve significant costs and burdens.
                        <SU>948</SU>
                        <FTREF/>
                         One commenter stated that the maintenance costs of discontinued contracts would be high, and that the cost for obtaining auditor opinions alone would be significant.
                        <SU>949</SU>
                        <FTREF/>
                         Other commenters stated it may be impossible to prepare new disclosure documents for Alternative Disclosure Contracts that have operated in a manner consistent with the Staff Letters for many years. For example, one commenter stated that certain Alternative Disclosure Contracts have operated in a manner consistent with the Staff Letters for several decades and have never filed on EDGAR.
                        <SU>950</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>948</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter; Brighthouse Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>949</SU>
                             
                            <E T="03">See</E>
                             Ameritas Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>950</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We also received a number of comments on the importance of some form of going-forward relief for contracts that are discontinued after the date that the Staff Letters are withdrawn.
                        <SU>951</SU>
                        <FTREF/>
                         These commenters generally noted the benefits experienced by insurers operating in a manner consistent with the Staff Letters discussed above (
                        <E T="03">i.e.,</E>
                         reduction in costs experienced over a diminishing asset base, increased product innovation, and moderation in product costs). Commenters also submitted views on the two alternative approaches for discontinued contracts, including the two possible methods of implementation. We discuss these comments below in Section II.E.4.
                    </P>
                    <FTNT>
                        <P>
                            <SU>951</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; ACLI Comment Letter; Transamerica Comment Letter; IRI Comment Letter I; IRI Comment Letter II.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. Commission Position on Existing Contracts Whose Issuers Provide Alternative Disclosures to Investors</HD>
                    <HD SOURCE="HD3">a. Commission Position</HD>
                    <P>We are taking the position that if an issuer of an Alternative Disclosure Contract that is discontinued as of July 1, 2020 that provides Alternative Disclosures does not file post-effective amendments to update a variable contract registration statement and does not provide updated prospectuses to existing investors, this would not provide a basis for enforcement action so long as investors are provided with the Alternative Disclosures, or certain modernized alternative disclosures, under the Commission position described below. For the reasons discussed below, we have determined to not codify this approach. Rather, we are providing notice of the Commission's position with respect to the circumstances under which certain actions will not provide a basis for enforcement action.</P>
                    <P>
                        We generally believe that all variable contract issuers should provide investors the same information and be 
                        <PRTPAGE P="26047"/>
                        subject to the same liability standards. We are only taking this Commission position to recognize the unique circumstances facing certain variable contracts currently operating in a manner consistent with the Staff Letters. The Commission's position is an exercise of its discretion and is designed primarily to assist the phase-out of these discontinued contracts. We believe that the need for this position will likely be temporary since the number of these contracts will diminish gradually over time. Accordingly, under the Commission position these issuers may continue to operate much as they do today, while also providing them the flexibility to provide more modern disclosure to investors.
                    </P>
                    <P>
                        <E T="03">Eligible contracts.</E>
                         We are taking the position that if an issuer of an existing discontinued contract that is discontinued as of July 1, 2020 that provides Alternative Disclosures does not file post-effective amendments to update a variable contract registration statement and does not provide updated prospectuses to existing investors (each, an “Eligible Contract”), this would not provide a basis for enforcement action if:
                    </P>
                    <P>
                        • 
                        <E T="03">Registration statement.</E>
                         It has a Securities Act registration statement with fewer than 5,000 investors, as of July 1, 2020.
                    </P>
                    <P>
                        • 
                        <E T="03">No material changes.</E>
                         There are no material changes made to the contract.
                    </P>
                    <P>
                        • 
                        <E T="03">No new contracts offered to the public.</E>
                         New contracts are not offered to the public, and the registrant does not contemplate such an offering in the future.
                    </P>
                    <P>
                        • 
                        <E T="03">Alternative disclosures.</E>
                         Investors are provided each of the following disclosures:
                    </P>
                    <P>
                        ○ 
                        <E T="03">Portfolio company disclosures.</E>
                         The portfolio companies' current prospectuses (or summary prospectuses) and any updates thereto, annual and semi-annual reports, proxy materials, and any other periodic reports or other shareholder materials for the portfolio companies.
                    </P>
                    <P>
                        ○ 
                        <E T="03">Financial statements.</E>
                         Within 120 days after the close of the fiscal year, updated audited financial statements of the registrant, and in the case of variable life insurance contracts, the depositor's updated audited financial statements. In the case of variable annuity contracts, the depositor's updated audited financial statements are available upon request.
                        <SU>952</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>952</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Metropolitan Letter; Monarch Letter.
                        </P>
                    </FTNT>
                    <P>
                        ○ 
                        <E T="03">Transaction confirmations.</E>
                         Confirmations of transactions in accordance with rule 10b-10 under the Exchange Act.
                    </P>
                    <P>
                        ○ 
                        <E T="03">Statement of units and values.</E>
                         At least once a year, a statement of the number of units and values in each investor's account.
                    </P>
                    <P>
                        • 
                        <E T="03">Option to provide modernized alternative disclosures.</E>
                         In lieu of providing the portfolio company prospectuses (or summary prospectuses) and any updates thereto and financial statements described in the first two sub-bullets in the list of alternative disclosures immediately above, a registrant may instead provide investors with the following:
                    </P>
                    <P>
                        ○ 
                        <E T="03">Notice document.</E>
                         The issuer annually provides investors with, and files with the Commission, a notice document containing the same information as that required in an updating summary prospectus (“Notice Document”).
                        <SU>953</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>953</SU>
                             The Notice Document must contain the same information as required in the updating summary prospectus under rule 498A and be filed with the Commission each year. Registrants are not required to use the Inline XBRL format for the submission of the Notice Document.
                        </P>
                    </FTNT>
                    <P>
                        ○ 
                        <E T="03">Portfolio company prospectuses.</E>
                         An issuer may elect to post a portfolio company's current summary prospectus, statutory prospectus, SAI, and most recent shareholder reports online in lieu of mailing the portfolio company's prospectuses (or summary prospectuses) and any updates thereto to investors, provided that:
                    </P>
                    <P>○ A summary prospectus is used for the portfolio company (if the portfolio company is registered on Form N-1A); and</P>
                    <P>○ The materials for the portfolio company are publicly accessible, free of charge, at the website address specified on the cover page or beginning of the Notice Document, and delivered (in paper or electronic format) upon request.</P>
                    <P>
                        ○ 
                        <E T="03">Financial statements.</E>
                         The financial statements that would be delivered to investors as part of the alternative disclosures described above are instead made publicly accessible, free of charge, at the website address specified on the cover page or beginning of the Notice Document, and delivered (in paper or electronic format) upon request.
                    </P>
                    <P>
                        • 
                        <E T="03">Filings.</E>
                         The registrant makes the following filings with the Commission:
                    </P>
                    <P>
                        ○ 
                        <E T="03">Reports on Form N-CEN.</E>
                         The registrant files periodic reports with the Commission pursuant to Section 30 of the Investment Company Act (
                        <E T="03">i.e.,</E>
                         reports on Form N-CEN).
                    </P>
                    <P>
                        ○ 
                        <E T="03">Financial statements.</E>
                         Within 120 days after the close of the registrant's fiscal year, the registrant files with the Commission its updated audited financial statements, and in the case of variable life insurance contracts, the depositor's updated audited financial statements.
                        <SU>954</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>954</SU>
                             The filing of financial statements with the Commission has not been a condition of the Staff Letters. Most of the Staff Letters predate EDGAR's adoption in 1993. EDGAR will be modified to create a new submission type under which registrants may file the required financial statements. Notice of EDGAR system readiness to accept filings pursuant to the new submission type will be provided in a manner similar to notices of EDGAR Filer Manual updates.
                        </P>
                    </FTNT>
                    <P>
                        ○ 
                        <E T="03">Notice Document.</E>
                         A copy of any Notice Document sent to investors.
                        <SU>955</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>955</SU>
                             EDGAR will be modified to create a new submission type under which registrants may file Notice Documents. Notice of EDGAR system readiness to accept filings pursuant to the new submission type will be provided in a manner similar to notices of EDGAR Filer Manual updates.
                        </P>
                    </FTNT>
                    <P>In addition, if an issuer's Securities Act registration statement includes multiple contracts, the Commission position applies only if all of the contracts covered by the registration statement are consistent with the above. For purposes of the 5,000 investor threshold, the number includes investors in all contracts covered by the registration statement in the aggregate. This is consistent with the scope of the Staff Letters.</P>
                    <P>
                        Table 7 below summarizes the disclosures that may be provided to investors in Alternative Disclosure Contracts, as compared with those of the new summary prospectus framework under rule 498A, for certain documents to either be: (1) Delivered to all investors; (2) made available online; or (3) delivered to those investors who so request.
                        <PRTPAGE P="26048"/>
                    </P>
                    <GPOTABLE COLS="4" OPTS="L2,i1" CDEF="s75,r50,r50,r75">
                        <TTITLE>Table 7—Documents Available to Alternative Disclosure Contract Investors Compared With Summary Prospectus Framework</TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1">Alternative disclosures</CHED>
                            <CHED H="1">Modernized alternative disclosures</CHED>
                            <CHED H="1">Summary prospectus framework under rule 498A</CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">Contract Statutory Prospectus</ENT>
                            <ENT A="01">N/A *</ENT>
                            <ENT>Required to be available online and delivered (in paper or electronic format) upon request.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Contract SAI</ENT>
                            <ENT A="01">N/A</ENT>
                            <ENT>Required to be available online and delivered (in paper or electronic format) upon request.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Contract Part C Information</ENT>
                            <ENT A="01">N/A</ENT>
                            <ENT>Filed with registration statement (available on EDGAR).</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Initial Summary Prospectus</ENT>
                            <ENT A="01">N/A</ENT>
                            <ENT>Delivered to all new investors.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Updating Summary Prospectus or Comparable Notice Document</ENT>
                            <ENT>N/A</ENT>
                            <ENT A="L01">Delivered to all existing investors.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Financial Statements * *</ENT>
                            <ENT>Delivered to all investors, and also available on EDGAR</ENT>
                            <ENT A="L01">Required to be available online and delivered (in paper or electronic format) upon request, and also available on EDGAR * * *</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Portfolio Company Prospectuses</ENT>
                            <ENT>Delivered to all investors</ENT>
                            <ENT A="L01">Delivered to investors, or, if the new option under rule 498A(j) to satisfy portfolio company prospectus delivery is relied-upon, required to be available online and delivered (in paper or electronic format) upon request.</ENT>
                        </ROW>
                        <ROW RUL="s">
                            <ENT I="01">Portfolio Company Shareholder Reports * * * *</ENT>
                            <ENT>Delivered to all investors</ENT>
                            <ENT A="L01">Delivered to all investors, and, if the new option under rule 498A(j) to satisfy portfolio company prospectus delivery is relied-upon, required to be available online and delivered (in paper or electronic format) upon request.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Portfolio Company Proxy Materials</ENT>
                            <ENT A="02">Delivered to all investors.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Transaction Confirmations</ENT>
                            <ENT A="02">Delivered to all investors.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">Statement of Units and Values</ENT>
                            <ENT A="02">Delivered to all investors.</ENT>
                        </ROW>
                        <TNOTE>* While the contract prospectus (and SAI and Part C information) would have been filed with the Commission earlier in the contract's life cycle, under the Commission position these documents need not be updated annually, and registrants would not need to make these documents available to investors either online or in paper format.</TNOTE>
                        <TNOTE>
                            ** These include updated audited financial statements of the registrant, and in the case of variable life insurance contracts, the depositor's updated audited financial statements. 
                            <E T="03">See supra</E>
                             note 933 and accompanying text.
                        </TNOTE>
                        <TNOTE>
                            *** The financial statements are part of the contract SAI, and rule 498A requires a registrant relying on the rule to make the SAI available online. 
                            <E T="03">See</E>
                             rule 498A(h)(1); Item 25 of Form N-4; Item 27 of Form N-6. Issuers providing modernized alternative disclosures under the Commission position will file financial statements separately on EDGAR.
                        </TNOTE>
                        <TNOTE>**** Delivery of portfolio company shareholder reports may be made pursuant to rule 30e-3, which provides an optional method to transmit shareholder reports by making such reports and other materials accessible at a website address specified in a notice to investors.</TNOTE>
                    </GPOTABLE>
                    <HD SOURCE="HD3">b. Notice Document</HD>
                    <P>
                        As we stated above with regards to the updating summary prospectus,
                        <SU>956</SU>
                        <FTREF/>
                         we believe that investors would benefit from a brief summary of the changes to their contracts along with certain information that we consider most relevant to investors when considering additional investment decisions. Thus, the Notice Document will include all the same information as an updating summary prospectus under rule 498A, and will therefore include, among other things, a brief description of certain changes to the contract that occurred during the previous year, as well as a Key Information Table and Appendix of portfolio companies or investment options.
                        <SU>957</SU>
                        <FTREF/>
                         We believe these disclosures will provide more useful information to investors in Alternative Disclosure Contracts than the financial statements they currently receive. Investors could continue to receive financial statements upon request or access them on EDGAR.
                    </P>
                    <FTNT>
                        <P>
                            <SU>956</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.2.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>957</SU>
                             The Notice Document would not be deemed a prospectus under Section 2(a)(10) of the Securities Act, and therefore it would be not subject to liability under Section 12(a)(2) of the Securities Act. 
                            <E T="03">See</E>
                             Section 12(a)(2) of the Securities Act; 
                            <E T="03">see also</E>
                             discussion 
                            <E T="03">supra</E>
                             note 505. The Notice Document would, however, be subject to the general antifraud provisions of the federal securities laws. 
                            <E T="03">See, e.g.,</E>
                             Section 17(a) of the Securities Act; Section 10(b) of the Exchange Act; Section 34(b) of the Investment Company Act.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">c. Option To Provide Modernized Alternative Disclosures</HD>
                    <P>
                        Some commenters suggested that we grandfather Alternative Disclosure Contracts while also facilitating registrants providing enhanced disclosures to investors. For example, one commenter suggested that we permit registrants operating in a manner consistent with the Staff Letters to deliver audited financial statements only upon request, and to permit them to rely on the new method of delivering portfolio company prospectuses by providing investors the information required in the Appendix and posting the portfolio company prospectuses and other materials online.
                        <SU>958</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>958</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>We believe that investors will benefit from these modernized alternative disclosures for the same reasons that investors in active contracts will benefit when issuers utilize the summary prospectus regime available under rule 498A. For example, we believe that delivering a Notice Document similar to an updating summary prospectus will provide more usable and relevant information to investors than the financial statements of the registrant and/or depositor. In particular, we believe that providing key information relating to the contract's terms, benefits, and risks in a concise and reader-friendly presentation, will improve investor understanding of variable contracts.</P>
                    <P>
                        Additionally, because issuers could experience cost savings by providing the modernized alternative disclosures, we expect many registrants may adopt this approach. However, we are also 
                        <PRTPAGE P="26049"/>
                        cognizant that many variable contracts have registration statements that have not been updated in many years, or decades, and it may be significantly burdensome for these issuers to provide a notice document with the same information as the updating summary prospectus. For this reason, we are providing issuers the flexibility to provide either set of alternative disclosures.
                    </P>
                    <HD SOURCE="HD3">d. Other Considerations for Alternative Disclosure Contracts</HD>
                    <P>
                        <E T="03">Loss of Status as Eligible Contract.</E>
                         The Commission position will not be relevant to any discontinued contract if at any point in the future, the discontinued contract does not meet the criteria for being an Eligible Contract described above. Therefore, a contract that, for example, is subject to material changes, offered to new investors, or contemplated to be offered to new investors in the future, would no longer be considered an Eligible Contract for purposes of the Commission position.
                    </P>
                    <P>
                        A number of commenters suggested that we take the position that Alternative Disclosure Contracts will not lose their status in the event of a material change to the contract.
                        <SU>959</SU>
                        <FTREF/>
                         One commenter asserted that not providing this relief would disadvantage insurers that make material changes, including those beneficial to investors, and may inhibit common corporate transactions involving such contracts.
                        <SU>960</SU>
                        <FTREF/>
                         Another commenter suggested we provide a narrow range of conditions that would allow those contracts that lost their status to regain it.
                        <SU>961</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>959</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Lincoln Comment Letter; and Brighthouse Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>960</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>961</SU>
                             
                            <E T="03">See</E>
                             Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <P>As discussed above, we generally believe that all variable contract issuers should provide investors the same information and be subject to the same liability standards. Considering a contract to continue to be an Eligible Contract in instances where the contract does not meet the criteria for being an Eligible Contract would not be consistent with these objectives. However, certain corporate transactions (such as insurance company or separate account merger) where a contract was an Eligible Contract prior to the transaction and there are no other material changes to the contract will be considered on a case-by-case basis.</P>
                    <P>
                        <E T="03">Transition Date for Eligible Contracts under Commission Position.</E>
                         The Commission proposed that the position with respect to Alternative Disclosure Contracts and/or any final rules associated with discontinued contracts would start as of the effective date of rule 498A. We requested comment on whether the Commission should adopt a transition period after that time for its position with respect to Alternative Disclosure Contracts if a summary prospectus framework is adopted.
                    </P>
                    <P>
                        Several commenters urged that we grandfather not as of the effective date of the final rule, as proposed, but as of the May 1 following the effective date, or if the effective date was less than 6 months prior to that May 1, then as of the subsequent May 1.
                        <SU>962</SU>
                        <FTREF/>
                         One commenter asserted that using May 1 as a cut-off date would avoid ambiguity over whether a contract that could operate in a manner consistent with the Staff Letters has actually operated as such, since May 1 coincides with the annual update of the registration statement.
                        <SU>963</SU>
                        <FTREF/>
                         The same commenter also believed that a transition would provide insurers with meaningful time to react to any Commission action and develop business plans accordingly.
                        <SU>964</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>962</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter. 
                            <E T="03">See also</E>
                             Transamerica Comment Letter (proposing a cut-off date of May 1 following the effectiveness of the rule) and Lincoln Comment Letter (proposing the same unless the effective date falls between January 1 and April 30, in which case the cut-off should occur the following May 1).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>963</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>964</SU>
                             
                            <E T="03">Id. See also</E>
                             Lincoln Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We decline to provide a transition period for Alternative Disclosure Contracts beyond July 1, 2020. As discussed below, the effective date of the rule and form amendments is also July 1, 2020.
                        <SU>965</SU>
                        <FTREF/>
                         We believe that having the same date for the end of the transition period for Alternative Disclosure Contracts and the start of the summary prospectus framework will provide more regulatory consistency and certainty than a regime where dates differ. In addition, we believe that the July 1, 2020 date addresses concerns as to ambiguity and sufficient time for insurers to develop business plans in response to the adoption of the Commission position. Insurers by that date will have already made a determination whether a contract could operate in a manner consistent with the Staff Letters as part of their 2020 annual update of their registration statements. As to all other contracts, insurers will have a period of time to modify their business plans to reflect the new framework prior to their 2021 annual registration statement updates.
                    </P>
                    <FTNT>
                        <P>
                            <SU>965</SU>
                             
                            <E T="03">See infra</E>
                             Section II.G.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. Commission Declines To Adopt Going-Forward Relief</HD>
                    <P>
                        We are declining to adopt any form of going-forward relief for discontinued contracts at this time. A number of commenters urged the Commission to provide some form of going-forward relief for these contracts in the event the Staff Letters are withdrawn.
                        <SU>966</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>966</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter; Lincoln Comment Letter; Ameritas Comment Letter; Transamerica Comment Letter; Brighthouse Comment Letter; ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We received considerable support from commenters for Approach 1,
                        <SU>967</SU>
                        <FTREF/>
                         which would adopt final rules reflecting practices under the Staff Letters with certain modifications.
                        <SU>968</SU>
                        <FTREF/>
                         For example, one commenter noted that Approach 1 would facilitate the disclosure of useful information to investors,
                        <SU>969</SU>
                        <FTREF/>
                         while another noted its substantial similarity to the approach available under the Staff Letters meant it would be less disruptive to its variable contract business than other alternatives.
                        <SU>970</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>967</SU>
                             
                            <E T="03">See</E>
                             note 939 
                            <E T="03">supra</E>
                             for a description of the alternative approaches.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>968</SU>
                             
                            <E T="03">See, e.g.,</E>
                             CAI Comment Letter; Transamerica Comment Letter; ACLI Comment Letter; IRI Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>969</SU>
                             
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>970</SU>
                             
                            <E T="03">See</E>
                             Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <P>While we considered these comments, we note that Approach 1 would not require registrants to maintain a current registration statement and therefore the liability provisions available under the federal securities laws would not apply to Approach 1 to the same extent as under the current variable contract prospectus delivery regime and under the summary prospectus regime for registrants that choose to rely on rule 498A. We believe it is important for investors to retain these liability protections and decline to adopt a form of going-forward relief at this time.</P>
                    <P>
                        We received one comment supporting Approach 2,
                        <SU>971</SU>
                        <FTREF/>
                         which would permit registration statements for discontinued contracts to be updated by forward incorporation by reference. Another commenter stated it could support Approach 2 as preferable to having no form of going-forward relief at all, but had concerns regarding the costs to maintain an updated registration statement and post updated statutory prospectuses and SAIs online.
                        <SU>972</SU>
                        <FTREF/>
                         This commenter also believed the incremental increases in investor protection may not justify the additional burdens on issuers. Another commenter cited increased regulatory and 
                        <PRTPAGE P="26050"/>
                        administrative burdens on issuers under Approach 2.
                    </P>
                    <FTNT>
                        <P>
                            <SU>971</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>972</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>After considering these comments, we are also declining to adopt going-forward relief under Approach 2. We believe that the Commission and its staff would benefit from further study and data regarding the potential cost savings and other burden reductions under this approach. We welcome input from the public as we undertake this further study. In particular, the Commission and its staff would benefit from input on topics including (1) the internal and external costs and other burdens associated with maintaining a registration statement under the summary prospectus framework versus those associated with providing the Alternative Disclosures or the modernized alternative disclosures under the Commission position (particularly any specific items that parties believe create inordinate burdens), and, if interested parties would recommend any alternative approach that may reduce those burdens relative to the adopted summary prospectus framework, (2) recommendations as to the set of proposed rules and general framework that implement the recommendation and an analysis of how the recommendation would retain investor protections. We encourage interested parties to share their views by contacting staff in the Division of Investment Management.</P>
                    <HD SOURCE="HD2">F. Technical and Conforming Amendments to Other Aspects of the Regulatory  Framework for Variable Contracts</HD>
                    <HD SOURCE="HD3">Conforming Amendments To Reflect Rule 498A, the Commission Position and Amended Registration Forms</HD>
                    <P>We are adopting, as proposed, conforming amendments to various cross-references in our rules to reflect rule 498A, and the amendments to Forms N-3, N-4, and N-6. These cross-references are reflected in our amendments to: Rules 159A, 431, 482, 485, 497, and 498 under the Securities Act; rules 11 and 405 of Regulation S-T; and rule 14a-16 under the Exchange Act. We are also adopting an amendment to rule 496 under the Securities Act acknowledging the Commission position regarding certain discontinued contracts, as discussed in Section II.E.</P>
                    <HD SOURCE="HD3">Rescission of Form N-1</HD>
                    <P>
                        We are rescinding, as proposed, Form N-1 under the Securities Act and the Investment Company Act. We received no comments on this aspect of the proposal. In 1984, the Commission prescribed Form N-1 as the registration form to be used by open-end management investment companies that are separate accounts of insurance companies for registering under the Investment Company Act and for registering their securities under the Securities Act.
                        <SU>973</SU>
                        <FTREF/>
                         In 1985, Form N-3 superseded Form N-1 for open-end management investment companies that are separate accounts of insurance companies issuing variable annuity contracts.
                        <SU>974</SU>
                        <FTREF/>
                         As a result, only an open-end management investment company that is a separate account of an insurance company offering variable life insurance contracts would use FormN-1.
                        <SU>975</SU>
                        <FTREF/>
                         Today, it appears that all separate accounts issuing variable life insurance contracts are organized as unit investment trusts. For that reason, we do not believe any registrants continue to use Form N-1 and we are therefore rescinding the form.
                        <SU>976</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>973</SU>
                             Form N-1 Amendments, Investment Company Act Release No. 14084 (Aug. 7, 1984) [49 FR 32058 (Aug. 10, 1984)].
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>974</SU>
                             Forms N-3 and N-4 Adopting Release, 
                            <E T="03">supra</E>
                             note 29, at text accompanying n.51.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>975</SU>
                             When Form N-3 was adopted, separate accounts funding variable annuity contracts were permitted to continue to use Form N-1 if they no longer offered the contracts to new purchasers. Forms N-3 and N-4 Adopting Release, 
                            <E T="03">supra</E>
                             note 29, at text accompanying n.51. The Commission is not aware of any such variable annuity registrants that continue to use Form N-1.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>976</SU>
                             Based on a review of EDGAR filings, it appears that Form N-1 has not been used in more than 20 years. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at n.629.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Technical Amendments to, and Rescission of, Certain Rules and Forms Governing Variable Life Insurance Contracts and Variable Annuity Contracts</HD>
                    <P>
                        We are adopting, generally as proposed, certain technical amendments to rules relating to variable life insurance contracts. As noted in the Proposing Release, the detailed regulation of sales loads and other fees and charges required by Sections 26 and 27 of the Investment Company Act no longer applies to variable insurance contracts as a consequence of the amendments to those sections enacted by the National Securities Market Improvement Act of 1996 (“NSMIA”).
                        <SU>977</SU>
                        <FTREF/>
                         In lieu of these detailed provisions, NSMIA instituted a requirement that all charges on variable insurance contracts, including sales charges, be reasonable “in the aggregate.” 
                        <SU>978</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>977</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.F; 
                            <E T="03">see also</E>
                             National Securities Market Improvement Act of 1996 (Pub. L. 104-290, 110 Stat. 3416 (1996).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>978</SU>
                             
                            <E T="03">See</E>
                             Section 26(f)(2) of the Act (requiring that all such fees and charges “in the aggregate [be] reasonable in relation to the services rendered, the expenses expected to be incurred and the risks assumed by the insurance company . . .”).
                        </P>
                    </FTNT>
                    <P>
                        The amendments we adopt in this document remove the rate regulatory provisions in rules 6e-2 and 6e-3 (former rule 6e-3(T)) under the Investment Company Act relating to variable life insurance contracts, and make conforming changes to other related rules and forms.
                        <SU>979</SU>
                        <FTREF/>
                         In addition, these amendments remove certain minimum capital requirements from Commission rules that insurers must satisfy for those insurers' separate accounts to qualify for exemptions from the capital requirements of Section 14(a) of the Investment Company Act.
                        <SU>980</SU>
                        <FTREF/>
                         The minimum capital requirements in those rules (
                        <E T="03">i.e.,</E>
                         that an insurer have a minimum combined capital and surplus, if a stock company, or an unassigned surplus, if a mutual company, of not less than $1,000,000) are no longer necessary because NSMIA amended Section 26 of the Investment Company Act to require that any insurer serving as a variable life or variable annuity separate account depositor have at least that level of combined capital and surplus or unassigned surplus, as applicable.
                        <SU>981</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>979</SU>
                             These rules include rules 0-1, 6c-7, 6c-8, 26a-1, and 27i-1 (former rule 27c-1) under the Investment Company Act. As part of these technical amendments, we are also rescinding rules 26a-2, 27a-1, 27a-2, 27a-3, 27d-2, 27g-1, and 27h-1 under the Investment Company Act, and FormsN-27I-1 and N-27I-2 under the Investment Company Act. Former rule 27c-1, relating to the redeemability of variable contracts, has been renamed as rule 27i-1, since as a result of NSMIA, the redeemability requirement addressed in the rule is now described in Section 27(i) of the Investment Company Act. Additionally, the proposal inadvertently omitted the elimination of the provision in rule 11a-2 under the Investment Company Act that specifies a numerical limit on the aggregate of deferred sales loads applicable to the exchanged and acquired contracts involved in an exchange. Therefore, for consistency with the other conforming amendments that were proposed, we are also rescinding paragraph (d)(2) of rule 11a-2. Finally, we are also amending rule 0-1 to correct an outdated reference to 17 CFR 270.22d-3 (rule 22d-3), which has since been renamed as 17 CFR 270.22d-2 (rule 22d-2).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>980</SU>
                             The provisions affected are (1) renumbered paragraphs (b)(5) and (b)(14)(v) of rule 6e-2; (2) renumbered paragraphs (b)(6) and (b)(15)(iv) of renamed rule 6e-3; and (3) rule 14a-2(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>981</SU>
                             
                            <E T="03">See</E>
                             Section 26(f)(2)(B) of the Investment Company Act.
                        </P>
                    </FTNT>
                    <P>
                        We received three comments on these proposals 
                        <SU>982</SU>
                        <FTREF/>
                         and, with one exception, the commenters supported the proposed amendments. One commenter objected to removing numerical load limits that are currently in place in two related rules, rules 6c-8 and 11a-2 under the Investment Company Act.
                        <SU>983</SU>
                        <FTREF/>
                         Rule 6c-8, among other things, provides an 
                        <PRTPAGE P="26051"/>
                        exemption from the redeemability requirements for sales charges deducted upon redemption or annuitization of all or a part of a variable annuity owner's interest in a registered separate account, by imposing a numerical limit on those charges.
                        <SU>984</SU>
                        <FTREF/>
                         Rule 11a-2 allows a separate account depositor to offer an exchange of variable annuity contracts to an investor owning a variable annuity issued by an account of the depositor without prior Commission review otherwise required by Section 11 of the Investment Company Act, but imposes sales load limits on both the acquired and exchanged contracts.
                        <SU>985</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>982</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter; CAI Comment Letter; and IRI Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>983</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>984</SU>
                             
                            <E T="03">See</E>
                             rule 6c-8(b)(1) (limiting the amount of sales load deducted upon redemption, when added to any sales load previously paid to nine percent of the purchase payments made to date).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>985</SU>
                             
                            <E T="03">See</E>
                             rule 11a-2(c)(2) (limiting the amount of front-end sales charges imposed on the exchanged and acquired contracts together to no more than nine percent), and rule 11a-2(d)(2) (limiting the sales charges imposed on the exchanged and acquired contracts together that are deducted upon redemption to no more than nine percent).
                        </P>
                    </FTNT>
                    <P>
                        This commenter asserted that NSMIA did not expressly touch on these provisions and that the limits in these rules are necessary to prevent excessive sales loads being imposed on the contracts.
                        <SU>986</SU>
                        <FTREF/>
                         On this point, we agree that the requirement in Section 27 that these securities be redeemable was not removed by NSMIA, and rule 6c-8 includes the redeemability requirement of Section 27 as one of the provisions from which the rule provides an exemption if the conditions specified in the rule, including sales charge limitations, are satisfied.
                    </P>
                    <FTNT>
                        <P>
                            <SU>986</SU>
                             
                            <E T="03">See</E>
                             VIP Working Group Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        However, we decline to adopt the commenter's suggestion to retain the numerical sales load limits in rules6c-8 and 11a-2. In the proposing releases for both rule 6c-8 and rule 11a-2, the Commission made clear that each of the rule limitations on sales charges is imposed as an “analogue” to the detailed rate regulation provisions in Sections 26 and 27 of the Investment Company Act—provisions that NSMIA subsequently made inapplicable to these contracts.
                        <SU>987</SU>
                        <FTREF/>
                         Therefore, with the enactment of the “reasonableness in the aggregate” standard for sales charges (considered together with all other contract fees and charges),
                        <SU>988</SU>
                        <FTREF/>
                         the numerical sales load limits in rules6c-8 and 11a-2 were rendered moot and we are removing such limits as proposed.
                    </P>
                    <FTNT>
                        <P>
                            <SU>987</SU>
                             
                            <E T="03">See</E>
                             Exemptive Relief For Separate Accounts to Impose A Deferred Sales Load On Variable Annuity Contracts Participating in Such Accounts and to Deduct from Such Contracts in Certain Instances an Annual Fee for Administrative Services That is Not Prorated, Investment Company Act Release No. 13048 (Feb. 28, 1983) [48 FR 9532, 9534 (Mar. 7, 1983)] (noting that the limitation on variable annuity deferred sales loads in rule 6c-8 being proposed in the release was “analogous to the [numerical load limitation] requirement in Section 27(a)(1)” of the Investment Company Act). 
                            <E T="03">See also</E>
                             Exchange Offers By Certain Registered Separate Accounts Or Others The Terms of Which Do Not Require Prior Commission Approval, Investment Company Act Release No. 12675 (Sept. 20, 1982) [47 FR 42374 (Sept. 27, 1982)] (noting that the front-end load limit in paragraph (c)(2) of rule 11a-2 being proposed in the release was “analogous to the [numerical load limitation] requirement in Section 27(a)(1)” of the Investment Company Act, and that the numerical load limitation requirement on deferred sales loads in paragraph (d)(2) of the rule was “similar in theory to paragraph (c)(2)”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>988</SU>
                             Each registration statement for a variable contract must contain the representation that the fees and charges deducted under the contract satisfy this standard. 
                            <E T="03">See</E>
                             Section 26(f)(2)(A) of the Investment Company Act. Form N-6 was adopted after NSMIA was enacted and incorporates this requirement. 
                            <E T="03">See</E>
                             Form N-6, Item 36. Although Forms N-3 and N-4 were adopted before NSMIA was enacted, registrants have been providing the required fee representation, pursuant to a staff statement published in 1996, together with the undertakings required by Part C of each form. 
                            <E T="03">See</E>
                             Letter to Registrants from Susan Nash, Assistant Director, Division of Investment Management, SEC (Nov. 7, 1996). These forms are being amended to explicitly incorporate the fee representation requirement. 
                            <E T="03">See supra</E>
                             note 872 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        We are mindful of the regulatory concerns behind each of these rules, which have remained following the enactment of NSMIA, but we do not believe that it is necessary to retain specific numerical limits to address those concerns. With respect to rule 6c-8, we acknowledge the possibility that sales charges imposed upon redemption of variable contracts could raise an issue as to whether such charges present an undue burden on the contract's redeemability. In this regard, we affirm the position taken by the Commission in adopting rule 6c-8 that the rule provides no relief “where the facts and circumstances indicate the deduction [for a deferred sales load] is not intended to compensate the issuer for [distribution] expenses.” 
                        <SU>989</SU>
                        <FTREF/>
                         With respect to rule 11a-2, we note that the other protections contained in the rule against the potential for abuse in variable annuity exchanges remain in place. For example, the amended rule retains the provision that a separate account depositor offering an exchange of variable annuity contracts must give credit for any deferred sales loads paid on the original variable annuity contract when calculating a deferred sales load on the newly purchased variable annuity contract.
                        <SU>990</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>989</SU>
                             
                            <E T="03">See</E>
                             Exemptive Relief for Separate Accounts To Impose A Deferred Sales Load And To Deduct in Certain Instances a Non-Prorated Annual Fee for Administrative Services, Investment Company Act Release No. 13406 (July 28, 1983) [48 FR 36097, 36098 (Aug. 9, 1983)], at 2. In addition, as noted above, these charges must satisfy the “reasonableness in the aggregate” standard imposed on all charges under a variable insurance contract by Section 26(f)(2)(A) of the Investment Company Act. Staff will continue monitoring charges to guard against each of these concerns.
                        </P>
                        <P>
                             Separately, one commenter requested that the redeemability relief provided in rule 6c-8(d) for certain administrative charges imposed on variable annuity contracts on withdrawal or surrender be expanded to include relief for other charges, citing optional benefits as an example of those charges. 
                            <E T="03">See</E>
                             CAI Comment Letter. Because this request raises issues and considerations beyond the scope of the technical amendments proposed in light of NSMIA, we decline to adopt the requested amendments at this time.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>990</SU>
                             
                            <E T="03">See</E>
                             amended rule 11a-2(d).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Rescission of Rules 27e-1 and 27f-1 and Related Forms</HD>
                    <P>
                        We are also rescinding, as proposed, rules 27e-1 and 27f-1 under the Investment Company Act and related Forms N-27E-1 and N-27F-1. We received no comments on this aspect of the proposal. These rules and forms were promulgated to prescribe the form of notices required by Sections 27(d) and (e) of the Investment Company Act relating to refund and withdrawal rights of periodic payment plan certificate holders, including those certificates not issued by insurance company separate accounts. We are rescinding these rules and forms because since 2006, Section 27(j) of the Investment Company Act has barred new certificate issuances,
                        <SU>991</SU>
                        <FTREF/>
                         and notice rights of holders of certificates issued before then have expired.
                    </P>
                    <FTNT>
                        <P>
                            <SU>991</SU>
                             Section 27(j) was enacted into law by the Military Personnel Financial Services Protection Act (Pub. L. 109-290, 120 Stat. 127) (2006).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Technical Amendments to Rule 8b-1</HD>
                    <P>
                        We are also revising rule 8b-1 under the Investment Company Act to remove references to 17 CFR 270.8b-32 (rule 8b-32 under the Investment Company Act).
                        <SU>992</SU>
                        <FTREF/>
                         Rule 8b-32 was recently rescinded in a separate rulemaking pursuant to the Commission's implementation of the FAST Act.
                        <SU>993</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>992</SU>
                             
                            <E T="03">See</E>
                             amended rule 8b-1.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>993</SU>
                             
                            <E T="03">See</E>
                             FAST Act Adopting Release, 
                            <E T="03">supra</E>
                             note 501.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">G. Compliance Dates</HD>
                    <P>
                        To provide a transition period after the effective date of the amendments to give registrants sufficient time to update their prospectuses and to prepare new registration statements under the amendments, the Commission is adopting the following compliance and other dates:
                        <PRTPAGE P="26052"/>
                    </P>
                    <GPOTABLE COLS="02" OPTS="L0,tp0,p0,8/9,g1,t1,i1" CDEF="s50,r150">
                        <TTITLE> </TTITLE>
                        <BOXHD>
                            <CHED H="1"> </CHED>
                            <CHED H="1"> </CHED>
                        </BOXHD>
                        <ROW>
                            <ENT I="01">July 1, 2020</ENT>
                            <ENT>A registrant can rely on rule 498A to satisfy its obligations to deliver a variable contract's statutory prospectus by delivering a summary prospectus if the registrant is also in compliance with the amendments to Forms N-3, N-4, or N-6 (as applicable).</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="22"> </ENT>
                            <ENT>The Staff Letters will be withdrawn and the Commission position for eligible discontinued contracts will take effect.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">January 1, 2022</ENT>
                            <ENT>All initial registration statements on Forms N-3, N-4, and N-6, and all post-effective amendments that are annual updates to effective registration statements on these forms, must comply with the rule and form amendments.</ENT>
                        </ROW>
                        <ROW>
                            <ENT I="01">January 1, 2023</ENT>
                            <ENT>Registrants must submit to the Commission certain specified disclosures in Inline XBRL.</ENT>
                        </ROW>
                    </GPOTABLE>
                    <HD SOURCE="HD3">Use of Summary Prospectus</HD>
                    <P>As proposed, a registrant could rely on rule 498A to satisfy its obligations to deliver a variable contract's statutory prospectus beginning on the effective date of the rule and form amendments (July 1, 2020) provided that the registrant is also in compliance with the amendments to Forms N-3, N-4, or N-6 (as applicable). We believe that this date will allow registrants to begin using summary prospectuses in advance of the compliance date discussed below, and will provide the Commission staff with sufficient time to prepare to review filings under the new summary prospectus framework.</P>
                    <P>
                        One commenter recommended that like the optional shareholder report delivery framework under rule 30e-3, there should be a two-year transition period during which investors would be (1) notified of the transition from delivery of statutory prospectuses to summary prospectuses, and (2) able to choose whether they preferred to receive summary prospectuses or statutory prospectuses.
                        <SU>994</SU>
                        <FTREF/>
                         Another commenter recommended that advance notice was unnecessary, given that the updating summary prospectus would serve as effective notice that the type of disclosure document that an investor expects to receive has changed.
                        <SU>995</SU>
                        <FTREF/>
                         The commenter further stated that the updating summary prospectus would provide information about how the previously provided documents may be obtained, and “a level of information about the variable contract that may itself be sufficient for most investors.”
                    </P>
                    <FTNT>
                        <P>
                            <SU>994</SU>
                             
                            <E T="03">See</E>
                             Donnelley Financial Comment Letter I.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>995</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter (noting that under rule 30e-3, “if a notice was not required, an investor would have no indication that the method of delivery of the documents he or she expects to receive is changing.”).
                        </P>
                    </FTNT>
                    <P>
                        We decline to build these requirements into the final rule as we believe that given the documents at issue (
                        <E T="03">i.e.,</E>
                         the prospectus as opposed to the shareholder report) and the contents of the documents permitted to be transmitted (
                        <E T="03">i.e.,</E>
                         a summary prospectus under rule 498A versus a notice under rule 30e-3), the more appropriate analogous framework is that of the mutual fund summary prospectus. Under that framework as well as the variable product summary prospectus framework we are adopting in this document, investors receive a summary prospectus and can request a print or electronic copy of the current statutory prospectus, but investors cannot elect to receive statutory prospectuses instead of summary prospectuses.
                    </P>
                    <HD SOURCE="HD3">Compliance With New Form Requirements</HD>
                    <P>
                        All initial registration statements on Forms N-3, N-4, and N-6, and all post-effective amendments that are annual updates to effective registration statements on these forms, filed on or after January 1, 2022 are required to comply with the final rule and form amendments.
                        <SU>996</SU>
                        <FTREF/>
                         We believe that this period will give registrants sufficient time to update their prospectuses and to prepare new registration statements under the amendments.
                    </P>
                    <FTNT>
                        <P>
                            <SU>996</SU>
                             As part of the proposal, the Commission proposed an 18-month compliance period. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.G. One commenter supported this compliance period. 
                            <E T="03">See</E>
                             CAI Comment Letter (“the 18-month compliance period for updating variable product registration statements is necessary and appropriate”). Another commenter, in recommending that the Commission mandate use of the summary prospectus, recommended that there be a rolling effective date based on the size of the company starting 24 months after publication. 
                            <E T="03">See</E>
                             AARP Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Although post-effective amendments to existing registration statements filed to comply with the amendments to Forms N-3, N-4, and N-6 should be filed under Securities Act rule 485(a),
                        <SU>997</SU>
                        <FTREF/>
                         in appropriate circumstances, we will consider requests by registrants with respect to existing variable contracts to file these post-effective amendments pursuant to Securities Act rule 485(b)(1)(vii).
                        <SU>998</SU>
                        <FTREF/>
                         Appropriate circumstances may include, for example, situations where a registrant has previously filed under rule 485(a) post-effective amendments for a number of variable contracts that implement the new requirements, and the staff determines not to review additional such filings by the registrant in light of the staff's experience with the previously filed amendments.
                    </P>
                    <FTNT>
                        <P>
                            <SU>997</SU>
                             A post-effective amendment filed under rule 485(a) [17 CFR 230.485(a)] generally becomes effective either 60 days or 75 days after filing, unless the effective date is accelerated by the Commission. A post-effective amendment filed under rule 485(b) may become effective immediately upon filing. A post-effective amendment may be filed under rule 485(b) if it is filed for one or more specified purposes, including to make nonmaterial changes to the registration statement. A post-effective amendment filed for any purpose not specified in rule 485(b) generally must be filed pursuant to rule 485(a).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>998</SU>
                             Under rule 485(b)(1)(vii), the Commission may approve the filing of a post-effective amendment to a registration statement under rule 485(b) for a purpose other than those specifically enumerated in the rule. The Commission's staff has been delegated the authority to approve registrants' requests under rule 485(b)(1)(vii). 17 CFR 200.30-5(b-3)(1).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Inline XBRL</HD>
                    <P>In a change from the proposal, we are requiring that registrants must submit to the Commission certain specified disclosures in Inline XBRL in specified filings made on or after January 1, 2023. This will provide registrants an additional year after the January 1, 2022 compliance date when all initial registration statements and post-effective amendments must comply with the final rule and form amendments.</P>
                    <P>
                        The Commission proposed to require variable contract registrants to submit to the Commission certain specified disclosures using the Inline XBRL format within the same 18-month compliance period proposed for compliance with the new form requirements. While one commenter urged us to move forward expeditiously with the Inline XBRL requirement to support informed investment decision-making,
                        <SU>999</SU>
                        <FTREF/>
                         other commenters requested that the Inline XBRL compliance date be extended beyond the proposed 18-month compliance period to provide sufficient time to adapt to the new Inline XBRL requirements.
                        <SU>1000</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>999</SU>
                             
                            <E T="03">See</E>
                             CFA Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1000</SU>
                             
                            <E T="03">See</E>
                             IRI Comment Letters I and II; XBRL US Comment Letter; CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        One commenter recommended allowing at least another 12 months after the 18-month compliance date for the new form requirements (or 30 months total) to give filers sufficient time to adapt to the new Inline XBRL requirements and to enable the development of vendor systems and client self-service tools that can generate Inline XBRL tagged documents from the 
                        <PRTPAGE P="26053"/>
                        document content.
                        <SU>1001</SU>
                        <FTREF/>
                         Another commenter recommended extending the Inline XBRL compliance period to 24 months.
                        <SU>1002</SU>
                        <FTREF/>
                         This commenter stated that insurers will face greater challenges in making the transition than mutual funds because variable contract registrants have never filed in XBRL and will need extra time to identify an XBRL preparation solution and learn how to accurately tag their reported data. This commenter also noted that, unlike mutual funds, some large insurers currently use modules under EDGARLink to help prepare registration statement filings on EDGAR,
                        <SU>1003</SU>
                        <FTREF/>
                         and stated that because Type 1 and type 2 modules are currently only supported by HTML format, while filings using Inline XBRL require XHTML format, any future availability of modules would require upgrades to EDGAR.
                        <SU>1004</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1001</SU>
                             
                            <E T="03">See</E>
                             IRI Comment Letter I (noting that the phased-in compliance period for tagging the mutual fund risk/return summary in Inline XBRL allowed two years after the effective date of the amendments for large fund groups, and three years for small fund groups).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1002</SU>
                             
                            <E T="03">See</E>
                             XBRL US Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1003</SU>
                             EDGARLink is an application that is used by electronic filers to facilitate the preparation, validation, and transmission of electronic format documents to EDGAR. EDGARLink works interactively with EDGAR and is accessible on the Commission's website. Modules are partial or complete documents that are intended to be included in an electronic submission. Insurers commonly use type 1 modules for the inclusion of a set of financial statements that will be included as part of multiple registration statement filings.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1004</SU>
                             On June 10, 2019, EDGAR was upgraded to allow filers to reference modules and segments constructed in either ASCII or HTML format in their HTML submission documents, including Types 1 and 2. 
                            <E T="03">See</E>
                             Chapter 5 (Constructing Attached Documents and Document Types), Chapter 6 (Interactive Data), and Appendix A (Messages Reported by EDGAR) of the EDGAR Filer Manual, Volume II: “EDGAR Filing.”
                        </P>
                    </FTNT>
                    <P>
                        A third commenter advocated for a 36-month compliance period, consistent with the amount of time small fund groups were given to comply with the 2018 Inline XBRL requirements.
                        <SU>1005</SU>
                        <FTREF/>
                         The commenter asserted that insurers are similarly situated to, but less prepared than, small funds with respect the transition to Inline XBRL. Unlike mutual funds and ETFs, insurers have not been required to tag variable product registration statements using XBRL, and the greater complexity of variable product disclosures could make such documents more difficult to tag than fund disclosures.
                        <SU>1006</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1005</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; 
                            <E T="03">see also</E>
                             Inline XBRL Adopting Release, 
                            <E T="03">supra</E>
                             note 892.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1006</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        After considering commenters' suggestions, we are extending the proposed compliance period by an additional year. Registrants must comply with the Inline XBRL tagging requirements in all required filings made on or after January 1, 2023. We believe that this compliance date will provide sufficient time for filers, filing agents, and software vendors to transition to Inline XBRL.
                        <SU>1007</SU>
                        <FTREF/>
                         We decline to extend the compliance period to a 36-month period, as on commenter suggested, because due to registrants updating their registration statements by May 1 of each year, this would effectively delay the compliance period by an additional year until 2024. The extended compliance period will also provide time to adopt a new taxonomy, and to implement and pilot iXBRL, make any necessary taxonomy or EDGAR changes resulting from the pilot, and ensure compatibility of modules and iXBRL.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1007</SU>
                             Because operating companies and mutual funds must transition to Inline XBRL no later than June 2021, we expect that many filing agents and software vendors will have already developed the Inline XBRL-related expertise necessary to assist variable contract registrants with meeting Inline XBRL requirements under the final rules.
                        </P>
                    </FTNT>
                    <P>Similar to our transition approach with requiring Inline XBRL for operating companies, mutual funds, and ETFs, variable contract registrants will be permitted to file using Inline XBRL prior to the compliance date. Filers will be able to file in Inline XBRL once EDGAR has been modified to accept submissions in Inline XBRL for all forms subject to the amendments. Notice of EDGAR system readiness to accept filings in Inline XBRL will be provided in a manner similar to notices of taxonomy updates and EDGAR Filer Manual updates. We believe that offering filers the option to file using Inline XBRL before the compliance date will enable filers that are ready to transition to Inline XBRL to begin realizing the benefits of Inline XBRL sooner. It will also enable vendors and filing agents used by early Inline XBRL adopters to gain valuable expertise that may help facilitate the transition to Inline XBRL for variable contract registrants that transition to Inline XBRL at a later time.</P>
                    <HD SOURCE="HD3">Commission Position With Respect to Alternative Disclosure Contracts</HD>
                    <P>
                        Consistent with the proposal, the Staff Letters will be withdrawn as of July 1, 2020. Additionally, the Commission is taking a position that if an issuer of a contract that is discontinued as of July 1, 2020 that provides alternative disclosures does not file post-effective amendments and does not provide updated prospectuses to existing investors, this would not provide a basis for enforcement action so long as investors are provided the Alternative Disclosures or modernized alternative disclosures) and the registrant meets all specified conditions of the Commission position as of July 1, 2020.
                        <SU>1008</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1008</SU>
                             
                            <E T="03">See</E>
                             Section II.E.3.d. above for further discussion of this compliance date.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD1">III. Other Matters</HD>
                    <P>
                        Pursuant to the Congressional Review Act,
                        <SU>1009</SU>
                        <FTREF/>
                         the Office of Information and Regulatory Affairs has designated this rule a “major rule,” as defined by 5 U.S.C. 804(2). If any of the provisions of these rules, or the application thereof to any person or circumstance, is held to be invalid, such invalidity shall not affect other provisions or application of such provisions to other persons or circumstances that can be given effect without the invalid provision or application.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1009</SU>
                             5 U.S.C. 801 
                            <E T="03">et seq.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD1">IV. Economic Analysis</HD>
                    <P>We are mindful of the costs imposed by, and the benefits obtained from, our rules. Section 3(f) of the Exchange Act, Section 2(b) of the Securities Act, and Section 2(c) of the Investment Company Act state that when the Commission is engaging in rulemaking under such titles and is required to consider or determine whether the action is necessary or appropriate in (or, with respect to the Investment Company Act, consistent with) the public interest, the Commission shall consider whether the action will promote efficiency, competition, and capital formation, in addition to the protection of investors. Further, Section 23(a)(2) of the Exchange Act requires the Commission to consider, among other matters, the impact such rules would have on competition and states that the Commission shall not adopt any rule that would impose a burden on competition not necessary or appropriate in furtherance of the purposes of the Exchange Act. The following analysis considers, in detail, the potential economic effects that may result from the rule and form amendments, including the benefits and costs to investors and other market participants as well as the broader implications of the rule for efficiency, competition, and capital formation.</P>
                    <HD SOURCE="HD2">A. Introduction</HD>
                    <P>
                        New rule 498A allows insurers the option to satisfy prospectus delivery requirements for variable contracts by providing investors with a summary prospectus while making the statutory prospectus and other disclosure documents available online. The approach involves the use of two types 
                        <PRTPAGE P="26054"/>
                        of summary prospectus: An initial summary prospectus to be provided to new investors, and an updating summary prospectus to be provided to existing investors. To help investors make informed investment decisions, each type of summary prospectus uses a layered disclosure approach designed to provide investors with key information relating to the contract's terms, benefits, and risks in a concise and more reader-friendly format, with access to more detailed information available online and electronically or in paper format on request. The new disclosure framework permits issuers to satisfy portfolio company prospectus delivery obligations by, among other conditions, posting the portfolio company summary and statutory prospectus at a website address specified on the variable contract summary prospectus.
                    </P>
                    <P>
                        The Commission is amending the registration forms for variable contracts to update and enhance the disclosure regime for these investment products. Additionally, our rule and form amendments require registrants to use Inline XBRL for the submission of certain disclosures contained in the contract statutory prospectus with the Commission with respect to contracts currently offered to new investors. We are also taking the position that if an issuer of a discontinued contract that is discontinued as of July 1, 2020 that provides Alternative Disclosures does not file post-effective amendments to update a variable contract registration statement and does not provide updated prospectuses to existing investors, this would not provide a basis for enforcement action so long as investors are provided the Alternative Disclosures or certain modernized alternative disclosures discussed above.
                        <SU>1010</SU>
                        <FTREF/>
                         Finally, we are also adopting certain technical and conforming amendments to our rules and forms, including amendments to rules relating to variable life insurance contracts, and rescinding certain related rules and forms.
                        <SU>1011</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1010</SU>
                             
                            <E T="03">See supra</E>
                             Section II.E.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1011</SU>
                             With respect to those amendments intended to reflect new rule 498A and the amendments to the registration forms, we do not believe there are any economic effects of these amendments that can be separated from the economic effects of amendments to rule 498A and the registration forms. In addition, we do not believe there are any economic effects of the technical amendments regarding certain variable life insurance rules, since market participants have already adjusted to the changes enacted by NSMIA that the amendments reflect in the rules. Similarly, we do not believe there are any economic effects of the rescission of certain rules and forms relating to the rights of periodic payment plan certificate holders, as the 2006 amendments to Section 27 of the Investment Company Act barred new issuances of such certificates; and we believe the notice rights of holders of certificates issued before those amendments have since expired. For those reasons, the economic effects of these technical and conforming amendments are not addressed separately in this section.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">B. Economic Baseline</HD>
                    <HD SOURCE="HD3">1. Overview of Variable Products Market</HD>
                    <P>
                        In 2019 there were a total of 3,534 unique variable products offered by 73 insurance companies.
                        <SU>1012</SU>
                        <FTREF/>
                         Total assets were $1,714 billion 
                        <SU>1013</SU>
                        <FTREF/>
                         held in 25.9 million accounts.
                        <SU>1014</SU>
                        <FTREF/>
                         Average contract value was $66,400.
                        <SU>1015</SU>
                        <FTREF/>
                         Also in 2019, insurance companies sold 1,289,500 contracts 
                        <SU>1016</SU>
                        <FTREF/>
                         with sales totaling $132.1 billion.
                        <SU>1017</SU>
                        <FTREF/>
                         Our understanding is that investors typically purchase variable products through various distribution channels.
                        <SU>1018</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1012</SU>
                             Based on Form N-CEN reports filed in calendar year 2019. The 3,534 variable products consist of 2,491 variable annuity products and 1,043 variable life insurance products.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1013</SU>
                             
                            <E T="03">Id.</E>
                             The total assets of $1,714 billion consist of $1,576 billion of variable annuity assets and $138 billion of variable life insurance assets.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1014</SU>
                             
                            <E T="03">Id.</E>
                             The 25.9 million accounts consist of 22.2 million variable annuity accounts and 3.7 million variable life insurance accounts.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1015</SU>
                             
                            <E T="03">Id.</E>
                             Average contract value for variable annuity products and variable life insurance products was $71,100 and $37,800, respectively.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1016</SU>
                             
                            <E T="03">Id.</E>
                             The 1,289,500 contracts consisted of 1,189,100 variable annuity contracts and 100,400 variable life insurance accounts.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1017</SU>
                             
                            <E T="03">Id.</E>
                             The $132.1 billion in sales (after rounding) consisted of $122.2 billion for variable annuity products and $10.0 billion for variable life insurance products.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1018</SU>
                             
                            <E T="03">See</E>
                             IRI Fact Book, 
                            <E T="03">supra</E>
                             note 7, at 161. For example, in 2018, investors purchased variable annuities across various distribution channels—independent broker-dealers, 23.9 percent of total sales; career agents, 20.6 percent; independent agents, 20.2 percent; banks, 18.9 percent; regional broker-dealers, 9.0 percent; full service national broker-dealers, 4.6 percent; and direct response 2.8 percent.
                        </P>
                    </FTNT>
                    <P>
                        A variable contract investor may allocate his or her contract purchase payments to a range of options offered through an insurance company's separate account.
                        <SU>1019</SU>
                        <FTREF/>
                         Separate accounts may be registered as management companies or UITs. As of 2019, there were five separate accounts registered as management companies and 670 structured as UITs.
                        <SU>1020</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1019</SU>
                             
                            <E T="03">Id.</E>
                             at 167. In 2018, the average number of portfolio companies per registered variable annuity contract was 60.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1020</SU>
                             Based on Form N-CEN reports filed in 2019. Of the 670 separate accounts organized as UITs, 426 were variable annuity separate accounts and 246 were variable life separate accounts. This information is based on registration statement filings on Form N-3, Form N-4, and Form N-6 with the Commission.
                        </P>
                    </FTNT>
                    <P>
                        Eighty-six percent of individual annuity investors purchased their first annuity before age 65, including 47 percent who were between the ages of 50 and 64 years old.
                        <SU>1021</SU>
                        <FTREF/>
                         The average age of investors at first purchase of an annuity is 51.
                        <SU>1022</SU>
                        <FTREF/>
                         The average current age of annuity investors is 70.
                        <SU>1023</SU>
                        <FTREF/>
                         Eighty percent of individual annuity investor households have incomes under $100,000.
                        <SU>1024</SU>
                        <FTREF/>
                         Sixty percent of household incomes are below $75,000, and 35 percent are below $50,000.
                        <SU>1025</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1021</SU>
                             Gallup Survey, 
                            <E T="03">supra</E>
                             note 7, at 8.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1022</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1023</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1024</SU>
                             
                            <E T="03">Id.</E>
                             at 8 and 9.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1025</SU>
                             
                            <E T="03">Id.</E>
                             at 9. According the U.S. Census Bureau, in 2018 70 percent of households had incomes of less than $100,000, 57 percent had incomes of less than $75,000, and 40 percent had incomes of less than $50,000. 
                            <E T="03">See</E>
                             U.S. Census Bureau, U.S. Income and Poverty in the United States: 2018 (Sept. 2019), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.census.gov/data/tables/2019/demo/income-poverty/p60-266.html</E>
                            .
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Statutory and Regulatory Disclosure Requirements</HD>
                    <P>
                        Currently, the default method for delivering the variable contract prospectus and the underlying portfolio company prospectuses is printing and mailing paper copies of the documents to investors. While the costs of providing paper copies of variable contract prospectuses are borne by the insurer, the allocation of the costs of printing and mailing the portfolio company prospectuses depends on the terms of the participation agreement between the insurance company and the portfolio company.
                        <SU>1026</SU>
                        <FTREF/>
                         We understand that most insurers also offer investors the option to elect to receive the variable contract prospectus and portfolio company prospectuses electronically. Investors who have opted for electronic delivery of prospectuses typically receive an email from the insurer containing a link to a website where the materials are available.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1026</SU>
                             We expect that costs borne by insurers and portfolio companies in supplying variable contracts to the market will ultimately be borne by contract investors through the fees that investors pay.
                        </P>
                    </FTNT>
                    <P>
                        Because insurers are not required to report investors' delivery elections to the Commission, we lack verifiable data on the percentage of variable contract prospectuses that are currently delivered electronically. In a 2016 letter to the Commission, one commenter estimated based on a survey of insurers conducted in 2015 that, generally, less than 15 percent of contract owners have affirmatively consented to electronic delivery.
                        <SU>1027</SU>
                        <FTREF/>
                         Another industry source estimated in a 2016 report that approximately five percent of annuity investors had opted for electronic delivery at that time.
                        <SU>1028</SU>
                        <FTREF/>
                         Based on these 
                        <PRTPAGE P="26055"/>
                        estimates, and with consideration for the general increase in electronic delivery rates over time demonstrated in other investment products,
                        <SU>1029</SU>
                        <FTREF/>
                         we estimate that currently 15 percent of variable contract statutory prospectuses and portfolio company summary prospectuses are delivered electronically.
                        <SU>1030</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1027</SU>
                             Comment Letter of the Committee of Annuity Insurers on Proposed Rule 30e-3 (July 22, 2016), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.sec.gov/comments/s7-08-15/s70815-612.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1028</SU>
                             
                            <E T="03">See</E>
                             Broadridge, 
                            <E T="03">Digital Transformation of Insurance Communications</E>
                             (2016), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.broadridge.com/_assets/pdf/digital-transformation-ins-comm.pdf</E>
                            .
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1029</SU>
                             
                            <E T="03">See, e.g.,</E>
                             Memorandum from the Division of Investment Management re: Meeting with Broadridge (Sept. 27, 2017) (including attachments thereto containing the survey data presented), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.sec.gov/comments/s7-08-15/s70815-2604201-161127.pdf</E>
                             (demonstrating increasing rates of electronic delivery in investment company fund reports).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1030</SU>
                             We understand that variable contract investors typically make a single delivery method election that applies to both the variable contract statutory prospectus and the portfolio company prospectuses.
                        </P>
                    </FTNT>
                    <P>
                        As discussed in Section II.E above, Commission staff has issued a series of no-action letters, referred to in this release as the “Staff Letters,” stating that the staff would not recommend enforcement action if issuers did not update the variable contract registration statement and deliver updated prospectuses to existing investors, so long as certain conditions were met, including distributing certain alternative disclosures to investors. We estimate that as of the end of calendar year 2019, approximately 13 percent of existing variable annuity contracts and 49 percent of variable life contracts were Alternative Disclosure Contracts.
                        <SU>1031</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1031</SU>
                             Of the 1,061 Form N-4 variable annuity registration statements on file, 584 registration statements appear to be for Alternative Disclosure Contracts. Of the 584, there are four Staff Letters concerning contracts where the number of contract owners exceeds 5,000. As a result, we estimate that these 580 registration statements represent a maximum of 2.9 million investors. Staff estimates that the remaining four registration statements represent at most 90,542 investors. 
                            <E T="03">See supra</E>
                             note 930. As a result, we estimate that up to 2.99 million (= 90,542 + (580 * 5,000)) investors may hold Alternative Disclosure Contracts (13 percent of the total number of contracts = 2.99 million/22.2 million). Of the 583 variable life registration statements on file, 360 registration statements appear to be for Alternative Disclosure Contracts. We estimate that these registration statements represent at most 1.8 million (= 360 * 5,000) contracts, or 49 percent (= 1.8 million/3.7 million) of the total number of contracts.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">C. Benefits and Costs of the Rule and Form Amendments</HD>
                    <P>
                        Where possible, we have attempted to quantify the costs, benefits, and effects on efficiency, competition, and capital formation expected to result from the rule and form amendments. In some cases, however, we are unable to quantify the economic effects because we lack the information necessary to provide a reasonable and reliable estimate. For example, because summary prospectuses offer a less lengthy, less complex disclosure alternative compared to statutory prospectuses, we expect that readership of variable contract disclosure would increase. We do not have data on the extent to which the use of summary prospectuses enhances readership compared to a scenario in which variable contract investors were only to receive a statutory prospectus and not a summary prospectus.
                        <SU>1032</SU>
                        <FTREF/>
                         Similarly, summary prospectuses could reduce the amount of time and effort investors require making an investment decision. Also, summary prospectuses could facilitate investor comparison of different variable product contracts. We do not have data on the extent to which variable contract summary prospectuses would reduce the amount of time and effort investors require to make an investment decision or to compare different variable product contracts, or the value of that time and effort to investors.
                        <SU>1033</SU>
                        <FTREF/>
                         In those circumstances in which we do not have the requisite data to assess the impact of the rule and form amendments quantitatively, we have qualitatively analyzed the economic impact of the rule and form amendments.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1032</SU>
                             Prior to the Commission's 2009 adoption of mutual fund summary prospectus rules, the Commission engaged a consultant to conduct focus group interviews and a telephone survey concerning investors' views and opinions about various disclosure documents filed by companies, including mutual funds. During this process, investors participating in focus groups were asked questions about a hypothetical summary prospectus. Investors participating in the telephone survey were asked questions relating to several disclosure documents, including mutual fund prospectuses. 
                            <E T="03">See</E>
                             Abt SRBI, Inc., 
                            <E T="03">Final Report: Focus Groups on a Summary Mutual Fund Prospectus</E>
                             (May 2008), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.sec.gov/comments/s7-28-07/s72807-142.pdf</E>
                            . Although the results from the investor testing reflect stated investor preferences, they do not provide us with information with respect to the extent to which variable contract investors will actually be more likely to read a variable contract summary prospectus relative to a statutory prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1033</SU>
                             
                            <E T="03">Id.</E>
                             The survey results do not provide data on the extent to which a variable contract summary prospectus will actually reduce the amount of time and effort required to make an investment decision using summary prospectuses rather than statutory prospectuses.
                        </P>
                    </FTNT>
                    <P>Direct costs incurred by insurers discussed below may, to some extent, be absorbed by the insurance company or be passed on to investors in the form of increased fees. The share of these costs borne by insurers and investors depends on multiple factors, including the nature of competition among insurers and investors' relative sensitivity to changes in fees.</P>
                    <HD SOURCE="HD3">1. Optional Summary Prospectus Regime</HD>
                    <P>
                        New rule 498A creates a choice for insurers. Insurers may continue to meet their prospectus delivery obligations by providing the statutory prospectus, or they may satisfy these obligations by providing a summary prospectus and making the statutory prospectus and other required documents available online. Those insurers that expect to benefit by providing summary prospectuses will choose to rely on the rule to meet their prospectus delivery obligations.
                        <SU>1034</SU>
                        <FTREF/>
                         Those insurers that do not expect to benefit from this optional prospectus delivery regime will choose to continue to provide statutory prospectuses to investors.
                        <SU>1035</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1034</SU>
                             If the expected costs of using summary prospectuses exceed the expected benefits of doing so, insurers could simply choose to maintain the status quo and continue to deliver statutory prospectuses to investors.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1035</SU>
                             Insurers that do not use summary prospectuses could be at a competitive disadvantage if investors choose variable products based on a preference for summary prospectuses, either because investors prefer summary prospectuses or because insurers that use summary prospectuses have lower expenses due to savings of printing and mailing costs. We expect that insurers will take any such competitive effects into account when assessing the costs of using summary prospectuses.
                        </P>
                    </FTNT>
                    <P>Insurers' choices of delivery methods will not reduce the information available to investors. If insurers choose to meet their prospectus delivery obligations by delivering summary prospectuses to investors, with other documents available online, investors will have a choice. Under the rule's layered disclosure framework, investors will receive information in the form of a summary prospectus, with more detailed information available online if the investor chooses to access it. Thus, investors can choose to continue to review the statutory prospectuses by accessing them online, or they may request paper or electronic delivery of statutory prospectuses on an ad hoc basis. Alternatively, investors may choose only to consult the summary prospectuses. Further, if investors want to rely on some combination of summary and statutory prospectuses to receive information about the contract, that choice is available to them as well.</P>
                    <P>
                        We expect a vast majority of insurers will choose to use summary prospectuses. Thus, we expect that the vast majority of investors will have the option to use both summary prospectuses and statutory prospectuses in their decision-making, in whatever proportion investors think is best for their preferences. We discuss below the benefits and costs to both investors and 
                        <PRTPAGE P="26056"/>
                        insurers of the new options presented by the contract summary prospectus regime and associated new optional delivery method for portfolio company prospectuses.
                    </P>
                    <HD SOURCE="HD3">a. Benefits and Costs for Investors</HD>
                    <HD SOURCE="HD3">i. Summary Prospectus for Variable Contracts</HD>
                    <HD SOURCE="HD3">(a) Benefits</HD>
                    <HD SOURCE="HD3">(1) Initial Summary Prospectus</HD>
                    <P>
                        Should insurers choose to use summary prospectuses, investors may benefit in a number of ways.
                        <SU>1036</SU>
                        <FTREF/>
                         Variable contract prospectuses (particularly those that include optional benefits) are typically lengthy and complex,
                        <SU>1037</SU>
                        <FTREF/>
                         and they also may describe different versions of the contract in one prospectus, some of which may no longer be available to new investors. In addition, investors generally allocate their purchase payments to one or more portfolio companies, each of which also has its own prospectus. Because industry practice is to bundle all portfolio company prospectuses with the variable contract prospectus, the disclosure documents that are delivered to investors at purchase and on an annual basis can be voluminous.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1036</SU>
                             Some investors may prefer to read statutory prospectuses, and therefore, the advantages associated with summary disclosure, as described in this section, may not apply to those investors. Because the statutory prospectus will, under the rule, be available online and in paper or electronic format upon request, we recognize that the need to take additional action to review a statutory prospectus imposes some costs for these investors, which are discussed below.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1037</SU>
                             One commenter stated that variable annuity contracts are among the most complex investment products sold. The commenter also analyzed variable annuity contracts in terms of reading level assessment and stated that variable annuity contracts are written in language that requires an advanced degree or at least a college level of comprehension. 
                            <E T="03">See</E>
                             Cardozo Clinic Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        We believe investors will benefit from the simplification of disclosure associated with initial summary prospectuses.
                        <SU>1038</SU>
                        <FTREF/>
                         We understand that contract statutory prospectuses may include disclosure about contract features and options that the registrant may no longer offer to new investors. Aggregating disclosures for multiple contracts, or currently offered and no-longer-offered features and options of a single contract, creates complexity that may make it more difficult for investors to distinguish between contract features and options that apply to them and those that do not.
                        <SU>1039</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1038</SU>
                             One commenter, citing academic research, stated that to the extent summary disclosure reduces information overload, it could, in turn, increase financial literacy. 
                            <E T="03">See</E>
                             ACLI Comment Letter; Julie Agnew &amp; Lisa Szykman, 
                            <E T="03">Annuities, Financial Literacy and Information Overload</E>
                             (Pension Research Council WP 2010-33, Nov. 11, 2010) 
                            <E T="03">available at</E>
                              
                            <E T="03">https://ssrn.com/abstract=1707659</E>
                            . Three commenters were skeptical that certain aspects of the proposed initial summary prospectus would result in better investor comprehension of how a variable contract works, and recommended that we engage in investor testing to validate our assumptions. 
                            <E T="03">See supra</E>
                             note 38.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1039</SU>
                             Existing research notes that individuals bear costs in absorbing information and that the ability of individuals to process information is not unbounded. 
                            <E T="03">See</E>
                             Richard Nisbett &amp; Lee Ross, HUMAN INFERENCE: STRATEGIES AND SHORTCOMINGS OF SOCIAL JUDGMENT (1980); David Hirshleifer &amp; Siew Hong Teoh, 
                            <E T="03">Limited Attention, Information Disclosure, and Financial Reporting,</E>
                             36 J. ACCT. &amp; ECON. 337 (2003).
                        </P>
                    </FTNT>
                    <P>For example, a separate account could offer different contracts over time, but with the contracts having substantially similar names. Likewise, separate accounts could offer different contracts at a single point in time, but with the contracts also having substantially similar names. Thus, contract investors reviewing lengthy statutory prospectuses may find it difficult, confusing, and time-consuming to identify disclosures related to contract terms and features that are relevant to their investments. These characteristics of existing variable contract statutory prospectuses could result in a risk of inefficient allocation of funds among portfolio companies in variable contracts or inefficient matching of investors to variable contracts. Incomplete information about the variable contracts made available to investors may cause them to over- or underinvest in variable contracts or to misallocate parts of their investment portfolio held outside of variable contracts.</P>
                    <P>
                        Whereas statutory prospectuses may describe contracts and features no longer offered to new investors in addition to contracts currently offered to investors, the new initial summary prospectus is limited to describing only the contract and features currently available under the statutory prospectus. We believe this narrower focus will facilitate investors' understanding of their variable contract's features and risks and make these features and risks more salient. In reviewing the more targeted information in the initial summary prospectus, investors will be able to more easily and more efficiently understand the product they are investing in, leading to more informed investment choices. We believe the concise content provided in the initial summary prospectus, presented in a standardized manner, will also facilitate investors' comparison of contracts at the time of investment and re-evaluation of contracts during the free look period.
                        <SU>1040</SU>
                        <FTREF/>
                         This could reduce the risk of investors selecting variable contracts that do not align with their needs or inefficient matching of investors to variable contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1040</SU>
                             One commenter stated that the proposed summary prospectus requires too high a level of comprehension. Their analysis of the proposed initial summary prospectus concluded that it would require a college level of comprehension to understand. 
                            <E T="03">See</E>
                             Cardozo Clinic Comment Letter. We drew on our investor testing efforts in developing the summary prospectus framework and believe the adopted summary prospectus framework will help investors make an informed investment decision. Also, one commenter, citing academic research, questioned the relevance of the free look period to decision making, stating that choice-supportive bias is likely to cause consumers to ascribe benefits to their purchases in order to confirm that they made the right decision, and that this tendency increases with age. 
                            <E T="03">See</E>
                             CFA Comment Letter; Mara Maher &amp; Marci Johnson, 
                            <E T="03">Choice-Supportive Source Monitoring: Do Our Decisions Seem Better to Us as We Age?,</E>
                             15 Psychol. &amp; Aging 596 (2000). We acknowledge that certain investors may not re-evaluate contracts during the free look period, but for those investors that do, we believe the concise content provided in the initial summary prospectus will facilitate their re-examination of the contract.
                        </P>
                    </FTNT>
                    <P>
                        To facilitate investor understanding and investor comparison of contract, the initial summary prospectus is designed to provide investors with key information relating to the contract's terms, benefits, and risks. The Key Information Table includes aspects of variable contracts that investors have most frequently stated that they failed to fully understand according to the complaints database maintained by the Commission's Office of Investor Education and Advocacy,
                        <SU>1041</SU>
                        <FTREF/>
                         including: (1) Risk of loss of principal and/or lack of guarantees of income; (2) fees, including surrender charges; (3) illiquidity prior to the pay-out period; (4) tax consequences; (5) death benefits; and (6) conflicts of interest.
                        <SU>1042</SU>
                        <FTREF/>
                         The overview describes the parties to the contract (the issuer and investor), and provides readers with basic information about the purpose of the contract, phases of the contract (for variable annuity contracts), premiums (for variable life insurance contracts), and contract features. We are also requiring registrants to summarize standard and optional benefits available to the investor under the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1041</SU>
                             
                            <E T="03">See supra</E>
                             note 108.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1042</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.1.c.ii.(a).
                        </P>
                    </FTNT>
                    <P>
                        Later sections of the initial summary prospectus provide investors more detailed information about the cash flows related to contract purchase. One section provides information about cash flows to the insurer, such as initial and subsequent purchase and premium payments. Other sections discuss cash flows investors can expect to receive, such as death benefits and other 
                        <PRTPAGE P="26057"/>
                        benefits. The initial summary prospectus for variable life insurance contracts also includes a section on how a contract could lapse, and thereby reduce payouts to investors. Also, a section on withdrawal and surrenders discusses how accessing the money in a variable contract early affects the payouts that an investor should expect to receive.
                    </P>
                    <P>Initial summary prospectuses also include additional information about fees and expenses investors will pay when buying, owning, and surrendering the contract, as well as those paid each year during the time the investor owns the contract. Finally, initial summary prospectuses include an appendix that provides summary information in a tabular form about the portfolio companies or investment options offered under the contract.</P>
                    <P>
                        In addition, given the time required to review a statutory prospectus, investors may benefit from summary prospectuses because they offer a shorter alternative to statutory prospectus disclosure. Indeed, there is evidence that suggests that consumers benefit from summary disclosures.
                        <SU>1043</SU>
                        <FTREF/>
                         Within the specific context of investing, there is evidence from related contexts that suggests that summary prospectuses allow investors to spend less time and effort to arrive at the same portfolio decision as if they had relied on a statutory prospectus.
                        <SU>1044</SU>
                        <FTREF/>
                         This research is consistent with the 2012 Financial Literacy Study, which showed that at least certain investors favor a layered approach to disclosure with the use, wherever possible, of summary documents containing key information about an investment product or service.
                        <SU>1045</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1043</SU>
                             There is evidence that the summarization of key information is useful to consumers. 
                            <E T="03">See, e.g.,</E>
                             Sumit Agarwal et al., 
                            <E T="03">Regulating Consumer Financial Products: Evidence from Credit Cards,</E>
                             (Nat'l Bureau of Econ. Research, Working Paper 19484, 2013). The authors find that a series of requirements in the CARD Act, including provisions designed to promote simplified disclosure, has produced decreases in both over-limit and late fees, saving U.S. credit card users $20.8 billion annually; 
                            <E T="03">see also</E>
                             Robert Clark et al., 
                            <E T="03">Can Simple Informational Nudges Increase Employee Participation in a 401(k) Plan?,</E>
                             (Nat'l Bureau of Econ. Research, Working Paper 19591, 2013). The authors find that a flyer with simplified information about an employer's 401(k) plan, and about the value of contributions compounding over a career, had a significant effect on participation rates.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1044</SU>
                             
                            <E T="03">See</E>
                             John Beshears et al., 
                            <E T="03">How Does Simplified Disclosure Affect Individuals' Mutual Funds Choices?,</E>
                             in Explorations in the Economics of Aging, 75 (David A. Wise ed., 2011), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.nber.org/chapters/c11933.pdf</E>
                            . We note, however, that while the authors find evidence that investors spend less time making their investment decision when they are able to use summary prospectuses, there is no evidence that the quality of their investment decisions is improved. In particular, “On the positive side, the Summary Prospectus reduces the amount of time spent on the investment decision without adversely affecting portfolio quality. On the negative side, the Summary Prospectus does not change, let alone improve, portfolio choices. Hence, simpler disclosure does not appear to be a useful channel for making mutual fund investors more sophisticated . . .” 
                            <E T="03">Id.</E>
                             at 13.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1045</SU>
                             
                            <E T="03">See</E>
                             2012 Financial Literacy Study, 
                            <E T="03">supra</E>
                             note 108. Commenters also stated that their own client research found that investors prefer summary disclosure. 
                            <E T="03">See</E>
                             IRI Comment Letter I and WFA Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Further, investors allocate their attention selectively,
                        <SU>1046</SU>
                        <FTREF/>
                         and the sheer volume of disclosure that investors receive about variable contracts and the underlying portfolio companies may discourage investors from reading contract statutory prospectuses (and the prospectuses of the underlying portfolio companies).
                        <SU>1047</SU>
                        <FTREF/>
                         The observations of a telephone survey conducted on behalf of the Commission with respect to mutual fund statutory prospectuses (which are typically shorter than variable contract statutory prospectuses) are consistent with the view that the volume of disclosure may discourage investors from reading statutory prospectuses.
                        <SU>1048</SU>
                        <FTREF/>
                         That survey observed that many mutual fund investors do not read statutory prospectuses because they are long, complicated, and hard to understand. To the extent summary prospectuses increase readership of variable contract disclosures, they could improve the efficiency of portfolio allocations made on the basis of disclosed information for those investors who otherwise would not have read the statutory prospectus.
                        <SU>1049</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1046</SU>
                             
                            <E T="03">See</E>
                             George Loewenstein et al., 
                            <E T="03">Disclosure Psychology Changes Everything,</E>
                             6 Ann. Rev. Econ. 391 (2014).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1047</SU>
                             
                            <E T="03">See supra</E>
                             note 548.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1048</SU>
                             
                            <E T="03">See supra</E>
                             note 1032.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1049</SU>
                             Review of the complaints database maintained by the Commission's Office of Investor Education and Advocacy revealed that the most common type of complaint submitted by variable contract investors involved an investor's belief that a sales agent had made misrepresentations about the variable contract and/or recommended a variable contract despite the product being unsuitable for the investor. To the extent that summary prospectuses increase readership of variable contract disclosures, they may also facilitate stronger investor protection.
                        </P>
                    </FTNT>
                    <P>
                        Moreover, potential variable contract investors that choose to read disclosures despite their length may face “information overload,” causing them to make inefficient decisions about the size of their variable contract positions, their selection of optional benefits, or the allocation of funds across underlying portfolio companies.
                        <SU>1050</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1050</SU>
                             
                            <E T="03">See</E>
                             Troy Paredes, 
                            <E T="03">Blinded by the Light: Information Overload and Its Consequences for Securities Regulation,</E>
                             81 Wash. U. Law Rev. 417 (2003).
                        </P>
                    </FTNT>
                    <P>
                        These benefits are potentially magnified given the demographic profile of variable contract investors. The average age of annuity investors is 70.
                        <SU>1051</SU>
                        <FTREF/>
                         Studies indicate that exposure to financial harms may increase with age, potentially exacerbated by a decline in the capacity to process financial information for some individuals.
                        <SU>1052</SU>
                        <FTREF/>
                         To the extent that summary prospectuses allow investors to spend less time and effort to understand their investments and arrive at investment decisions, that benefit is magnified in the context of variable contracts given the demographic profile of the underlying investor base.
                        <SU>1053</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1051</SU>
                             
                            <E T="03">See supra</E>
                             note 1023 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1052</SU>
                             
                            <E T="03">See e.g.,</E>
                             David Schroeder &amp; Timothy Salthouse, 
                            <E T="03">Age Related Effects on Cognition Between 20 and 50 Years of Age,</E>
                             36 Personality &amp; Individual Differences 393 (2004); Timothy Salthouse, 
                            <E T="03">Aging and Measures Of Processing Speed,</E>
                             54 Biological Psychology 35 (2000); Ray Fair, 
                            <E T="03">How Fast Do Old Men Slow Down?,</E>
                             76 Rev. Econ. &amp; Stat. 103 (1994); Ulman Lindberger &amp; Paul B. Baltes, 
                            <E T="03">Sensory Functioning and Intelligence in Old Age: A Strong Correlation,</E>
                             9 Psychol. &amp; Aging 339 (1994); Ulman Lindberger &amp; Paul B. Baltes, 
                            <E T="03">Intellectual Functioning in Old and Very Old Age: Cross-Sectional Results From the Berlin Aging Study,</E>
                             12 Psychol. &amp; Aging 410 (1997); Patricia D. Struck, 
                            <E T="03">NASAA Statement at SEC Seniors Summit, available at</E>
                              
                            <E T="03">http://www.nasaa.org/860/nasaa-presidents-statement-at-sec-seniors-summit/</E>
                            ; Karla Pak &amp; Doug Shadel, 
                            <E T="03">AARP Foundation National Fraud Victim Study</E>
                             (2011).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1053</SU>
                             If there are investors who would choose to rely on statutory prospectuses, one option available to them is to access the statutory prospectuses in electronic form online. If older investors are less likely to use the internet, that would attenuate the overall benefits of the rule for the older demographic.
                        </P>
                    </FTNT>
                    <P>
                        The initial summary prospectus may also reduce the investor effort required to compare variable products when an investor considers a new investment. Information provided in a concise, user-friendly presentation could allow investors to compare information across products and as a result, may lead investors to make decisions that better align with their investment goals.
                        <SU>1054</SU>
                        <FTREF/>
                         For example, the new rule requires insurers to distill certain key product information into tables, which could facilitate comparison across different products. The effect of the initial 
                        <PRTPAGE P="26058"/>
                        summary prospectus alone on the ability of the investor to compare products may be limited, however, by the extent to which variable contracts are sold through agents.
                        <SU>1055</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1054</SU>
                             Research suggests that individuals are generally able to make more efficient decisions when they have comparative information that allows them to assess relevant trade-offs. 
                            <E T="03">See, e.g.,</E>
                             Christopher Hsee et al., 
                            <E T="03">Preference Reversals between Joint and Separate Evaluations of Options: A Review and Theoretical Analysis,</E>
                             125 Psychol. Bull. 576 (1999); 
                            <E T="03">see also</E>
                             Jeffrey Kling et al., 
                            <E T="03">Comparison Friction: Experimental Evidence from Medicare Drug Plans,</E>
                             127 Q. J. Econ. 199 (2012). In a randomized field experiment, some senior citizens choosing between Medicare drug plans were randomly selected to receive a letter with personalized, standardized, comparative cost information. Plan switching was 28 percent in the intervention group, but only 17 percent in the comparison group, and the intervention caused an average decline in predicted consumer cost of about $100 a year among letter recipients.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1055</SU>
                             However, we expect the requirement to file certain information from variable contract statutory prospectuses in Inline XBRL will facilitate data collection by third-party aggregators and financial analysts, as well as facilitate investors' comparison of variable products. 
                            <E T="03">See infra</E>
                             Section IV.C.3.
                        </P>
                    </FTNT>
                    <P>
                        Additionally, the framework for variable contract summary and statutory prospectuses also includes design elements to facilitate investor use. In particular, the new rule includes requirements for linking within the electronic versions of the contract statutory prospectus and SAI that are available online, and also for linking between electronic versions of contract summary and statutory prospectuses that are available online. The linking requirements permit investors who use the electronic versions of contract prospectuses to quickly navigate between a table of contents of the contract statutory prospectus or SAI and the related sections of that document, as well as each section of the summary prospectus and any related section of the contract statutory prospectus and contract SAI that provides additional detail.
                        <SU>1056</SU>
                        <FTREF/>
                         Further, the new rule also requires that investors either be able to view the definition of each special term used in an online summary prospectus upon command, or to move directly back and forth between each special term and the corresponding entry in any glossary or list of definitions that the summary prospectus includes. This requirement should facilitate understanding of terms that may be confusing or unfamiliar among investors viewing the documents online.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1056</SU>
                             The Commission recently adopted rules requiring registrants to include a hyperlink to each exhibit identified in the exhibit index in any registration statement or report that is required to include exhibits under 17 CFR 29.601 (Item 601 of Regulation S-K) or under Form F-10 or Form 20-F. In connection with this rulemaking, commenters indicated that hyperlinking would make it easier and reduce the amount of time required for investors to navigate to related documents. 
                            <E T="03">See</E>
                             Exhibit Hyperlinks and HTML Format, Release No. 34-80132 (Mar. 1, 2017) [82 FR 14130 (Mar. 17, 2017)] at nn.85 and 86. In 2019, the Commission adopted amendments to its investment company registration forms, including Forms N-3, N-4, and N-6, to require hyperlinks to exhibits required to be filed with the registration statement. 
                            <E T="03">See</E>
                             FAST Act Adopting Release, 
                            <E T="03">supra</E>
                             note 501.
                        </P>
                    </FTNT>
                    <P>Finally, the new rule requires that contract documents required to be posted online remain available on the website for at least 90 days. This requirement mirrors the online availability requirement for the mutual fund summary prospectuses. As a result, investors who prefer to access the disclosure documents online could be certain that the documents for both the contract and the portfolio companies would be available for the same period of time.</P>
                    <HD SOURCE="HD3">(2) Updating Summary Prospectus</HD>
                    <P>The new updating summary prospectus will have many of the same benefits for investors associated with the initial summary prospectus discussed above associated with presenting key information in an easier and less time-consuming manner for investors. Specifically, because many terms of the variable contract do not change from year-to-year, the contract statutory prospectus may contain a large amount of disclosure that is duplicative of disclosure that the investor has previously received. Those changes that do occur may be important to investors, but the disclosure about these changes could be difficult for the investor to identify given the volume of prospectus disclosure that investors currently receive, and the current lack of a requirement to identify new or changed information.</P>
                    <P>
                        Under the new rule, the updating summary prospectus includes a concise description of important changes affecting the statutory prospectus disclosure relating to certain topics that occurred within the prior year—namely the availability of portfolio companies (or investment options under a variable annuity registered on Form N-3) under the contract, the Key Information Table, the overview of the contract, the Fee Table, purchases and contract value (or premiums for variable life insurance contracts), lapse (for variable life insurance contracts), surrenders and withdrawals, the standard death benefit (for variable life insurance contracts), and the benefits available under the contract. We believe that these are the topics most likely to be important to investors because they affect how investors evaluate variable contracts and are relevant to investors when considering additional investment decisions. The updating summary prospectus, if used by insurers to satisfy their prospectus delivery obligations, would likely reduce the burden on investors and increase their understanding of their contract by highlighting certain changes to the contract made during the previous year, while forgoing the repetition of most information that had remained unchanged.
                        <SU>1057</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1057</SU>
                             Unlike with the initial summary prospectus, the new rule permits insurers to describe multiple contracts in the updating summary prospectus. However, given the limited number of changes in each contract on an annual basis, we do not believe that permitting multiple contracts in the updating summary prospectus will create significant confusion for investors or reduce any of the benefits associated with the description of key changes for each contract.
                        </P>
                        <P>We further recognize that the changes highlighted in the updating summary prospectus are only those relative to the immediately preceding updating summary prospectus and statutory prospectus. Accordingly, if an investor wanted to understand the changes to his or her contract since he or she initially purchased the contract, the investor will need to review all of the updating summary prospectuses (or each updated statutory prospectus). However, we have designed the updating summary prospectus to allow investors to better focus their attention on new or updated information relating to the contract. As noted above, we believe that existing investors in a variable contract will benefit more from a brief summary of changes that have occurred in the contract than a document like the initial summary prospectus, which is designed for someone making an initial investment decision. Therefore, we believe that requiring the updating summary prospectus to only provide information on the most recent changes strikes the appropriate balance between increasing investor's understanding of and access to information about changes in the updated statutory prospectus and imposing additional costs on insurers to create more tailored updating disclosures comparing the current state of the contract to the original contract for each contract holder.</P>
                    </FTNT>
                    <P>The updating summary prospectus also includes the Key Information Table. The inclusion of this disclosure will benefit investors by reminding them of key facts about the variable contract, including the contract's fees and expenses, risks, restrictions, tax implications, and conflicts of interest. Finally, the updating summary prospectus includes an Appendix that provides summary information about the portfolio companies that the registrant offers under the contract. The inclusion of this portfolio company information could benefit investors by providing them information to inform one of the most important decisions they face during the lifecycle of a contract—that is, whether and where to reallocate funds among the portfolio companies or investment options available to them.</P>
                    <HD SOURCE="HD3">(b) Costs</HD>
                    <P>
                        Should insurers opt to use summary prospectuses, we believe that the majority of investors will benefit from their disclosures; however, certain investors may also incur costs. For example, although research indicates that investors generally prefer to receive summary disclosures,
                        <SU>1058</SU>
                        <FTREF/>
                         there may be investors who prefer to rely on statutory prospectuses when making investment decisions. While statutory prospectuses will be available online and in paper or electronic copy upon request, access to those statutory prospectuses will require investors to take additional steps, 
                        <PRTPAGE P="26059"/>
                        imposing some burden. For example, investors choosing to access the statutory prospectus online rather than requesting a paper copy may need to manually enter a hyperlink from a paper updating summary prospectus or open an email link to a website containing the statutory prospectus.
                        <SU>1059</SU>
                        <FTREF/>
                         To the extent that internet access and use among variable contract investors is not universal, those investors without home internet access might experience a reduction in their ability to quickly and easily access statutory prospectus information.
                        <SU>1060</SU>
                        <FTREF/>
                         Even for those investors with home internet access, there may be some resistance to taking the additional step of accessing the statutory prospectus online.
                        <SU>1061</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1058</SU>
                             
                            <E T="03">See supra</E>
                             note 10455.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1059</SU>
                             Investors may also call or email to obtain the statutory prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1060</SU>
                             According to the most recent U.S. census data, approximately 81.9 percent of U.S. households had some form of internet access in their home in 2016, and 89.3 percent had a computer (
                            <E T="03">e.g.,</E>
                             desktop, laptop, tablet or smartphone). 
                            <E T="03">See</E>
                             Camille Ryan, 
                            <E T="03">Computer and Internet Usage in the United States: 2016</E>
                             (Aug. 2018), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.census.gov/content/dam/Census/library/publications/2018/acs/ACS-39.pdf</E>
                            . According to data provided by the Pew Research Center, in 2019 90 percent of U.S. adults use the internet with usage varying by age with 88 percent of U.S. adults between the ages of 50 and 64 using the internet and 73 percent of U.S. adults 65 and older using the internet. 
                            <E T="03">See</E>
                             Internet/Broadband Fact Sheet, 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.pewresearch.org/internet/fact-sheet/internet-broadband/#who-uses-the-internet</E>
                            . 
                            <E T="03">See also</E>
                             Sarah Holden, Daniel Schrass &amp; Michael Bogdan, 
                            <E T="03">Ownership of Mutual Funds, Shareholder Sentiment, and Use of the Internet, 2019,</E>
                             25:8 ICI Res. Perspective (Oct. 2019), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.ici.org/pdf/per25-08.pdf</E>
                             (“In 2019, 94 percent of households owning mutual funds had internet access, up from about two-thirds in 2000” and “86 percent of mutual fund-owning households with a household head aged 65 or older had internet access in 2019”); Andrew Perrin &amp; Maeve Duggan, 
                            <E T="03">Americans' Internet Access: 2000-2015</E>
                             (June 2015), 
                            <E T="03">available at</E>
                              
                            <E T="03">http://www.pewinternet.org/2015/06/26/americans-internet-access-2000-2015/</E>
                             (finding in 2015, 84 percent of all U.S. adults use the internet).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1061</SU>
                             One commenter urged us to require paper delivery as the default delivery of their prospectuses or summary prospectuses unless the retail investor has affirmatively chosen to receive these documents electronically. That commenter noted that in 2012 they commissioned a national survey of over 1,000 retirement plan participants and found that 66 percent of respondents ages 25-49 and 84 percent of those 50 plus preferred paper document delivery. 
                            <E T="03">See</E>
                             AARP Comment Letter, 
                            <E T="03">supra</E>
                             note 33. Investors who prefer paper delivery of the statutory prospectus may request paper copies from the insurer. To the extent that investors request paper copies of the statutory prospectus, insurers will incur associated printing and mailing costs. 
                            <E T="03">See infra</E>
                             Section IV.C.1.b.i.
                        </P>
                    </FTNT>
                    <P>
                        Moreover, those investors who prefer paper copies of statutory prospectuses and do not have ready access to the internet (and the ability to print out the statutory prospectus that is made available online 
                        <SU>1062</SU>
                        <FTREF/>
                        ), will not be able to elect paper delivery of statutory prospectuses on a going-forward basis. Rather, they will need to make an ad hoc request for paper delivery of the statutory prospectus each time one is made available. This may delay their review of the statutory prospectus as they await paper delivery, or, in some cases, if the investor does not take the additional step to request paper delivery, may result in the investor not receiving the statutory prospectus in his or her preferred format and ultimately receiving less information than they would like about their contract.
                        <SU>1063</SU>
                        <FTREF/>
                         We believe that possibility is unlikely in this circumstance, however. We believe investors who prefer statutory prospectuses rather than summary prospectuses are likely investors who are willing to seek out detailed information to inform their investment decisions. We believe that for these investors, the additional effort required to access the statutory prospectus online or request paper or electronic statutory prospectuses would be incrementally minimal.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1062</SU>
                             
                            <E T="03">See supra</E>
                             Section II.A.5.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1063</SU>
                             This outcome is suggested by research which finds that investors can experience a “status quo bias.” 
                            <E T="03">See, e.g.,</E>
                             Richard H. Thaler &amp; Shlomo Bernatzi, 
                            <E T="03">
                                Save More Tomorrow
                                <SU>TM</SU>
                                : Using Behavioral Economics to Increase Employee Saving,
                            </E>
                             112 J. Pol. Econ. S164 (2004); Richard H. Thaler &amp; Cass R. Sunstein, 
                            <E T="03">Libertarian Paternalism,</E>
                             93 Am. Econ. Rev. 175 (2003). Thaler and Sunstein argue that a “status quo” bias results in the continuance of existing arrangements even if better options are available. The authors illustrate their argument with higher rates of initial enrollments in employee savings plans when enrollment is automatic as compared to when employees must first complete an enrollment form.
                        </P>
                    </FTNT>
                    <P>Also, the rule requires that a current version of each of the required contract documents remain available online for at least 90 days after the date of delivery of a security or communication in reliance on the rule. Some investors may not have the flexibility to access this online information within 90 days after receiving the summary prospectus. As discussed above, however, because variable contracts (and their underlying portfolio companies) are generally continuously offered, a current contract prospectus and related documents would likely remain online for longer than 90 days. As a result, we believe any loss of flexibility to access online information more than 90 days after receiving a summary prospectus would be minimal.</P>
                    <HD SOURCE="HD3">ii. Portfolio Company Prospectus Delivery</HD>
                    <P>
                        As described in Section IV.C.1.b below, we anticipate that the new optional delivery method for portfolio company prospectuses will result in cost savings from reduced printing expenses. To the extent that a portfolio company bears the printing expenses associated with portfolio company prospectuses, we expect that the reductions will benefit the portfolio company, as well as variable contract investors who have allocated contract value to the portfolio company (except perhaps in certain circumstances such as where the portfolio company is operating under an expense limitation arrangement). To the extent that the insurance company bears these costs, we expect that the reductions will benefit the insurance company, which may pass on such cost savings to existing variable contract investors and to new variable contract investors in the pricing of variable contracts offered in the future.
                        <SU>1064</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1064</SU>
                             Because the fees charged under variable contracts investors are typically fixed when the contract is purchased, we recognize that cost savings realized by the insurance company may not be passed along to existing investors except in the case of contracts offered by mutualized insurance companies, which return any profits they make to their investors.
                        </P>
                        <P>
                            We expect the benefit in terms of lower pricing of variable contracts will be small. One commenter estimated a unit cost of $6.00 to print and mail a statutory prospectus to new investors and $2.20 to existing investors, inclusive of summary prospectuses for all portfolio companies offered by the contract. The commenter also estimated that portfolio company summary prospectuses would make up 300 pages of the 400-page mailing that includes the variable contract statutory prospectus and portfolio company prospectuses. 
                            <E T="03">See</E>
                             Broadridge Comment Letter. The average value of a variable contract investor's investment is $66,400.
                        </P>
                    </FTNT>
                    <P>Certain investors may incur additional costs. While the portfolio company prospectuses will be available online and in paper or electronically upon request on an ad hoc basis, investors may experience additional burdens when accessing the prospectuses. As with the summary prospectus for variable contracts discussed above, investors who prefer to review paper copies of the portfolio company prospectuses will be required to either affirmatively request delivery of paper copies, or bear the costs of printing the electronic versions of documents accessed through the website.</P>
                    <P>
                        Also, as discussed with respect to variable contract prospectuses above, internet access is not universal among variable contract investors, and investors who would prefer paper copies of prospectuses will be required to request paper delivery of those prospectuses on an ad hoc basis which could, in turn, delay investor review of those prospectuses.
                        <SU>1065</SU>
                        <FTREF/>
                         Further, to the 
                        <PRTPAGE P="26060"/>
                        extent that investors prefer paper copies of prospectuses, but do not request a paper copy or access the document online, there will be no investor review of those prospectuses.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1065</SU>
                             As we discuss in Section IV.C.3 below, we understand that sales agents assist investors by providing information about underlying portfolio companies and sometimes recommending that investors allocate their contract value into specific 
                            <PRTPAGE/>
                            portfolio companies. We anticipate that this will continue under the adopted framework, and that sales agents will assist investors in understanding key facts about the portfolio companies, obtaining portfolio company prospectuses, and understanding the proposed portfolio company prospectus delivery framework. For this reason, to the extent that sales agents continue to play a significant role in providing information about portfolio companies to investors, even if investors were to no longer automatically receive paper copies of portfolio company prospectuses, we expect the adopted framework to yield lower costs and higher benefits for investors.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Benefits and Costs for Insurers</HD>
                    <HD SOURCE="HD3">i. Summary Prospectus for Variable Contracts</HD>
                    <P>The total cost of providing disclosure in any particular framework is the sum of costs associated with producing the disclosure materials, including labor and legal fees, and the costs associated with delivery of the disclosure materials, including printing and mailing costs and costs of making the disclosures available on a website. Insurers will benefit from the options provided by the new rule, to the extent that providing layered disclosure through a summary contract prospectus regime (including costs of producing and delivering initial summary and updating summary prospectuses and of making statutory prospectuses, portfolio company prospectuses, and other documents available online) is less expensive than providing statutory prospectuses to new investors and updated statutory prospectuses to existing investors annually, along with portfolio company prospectuses and other related documents.</P>
                    <P>
                        As discussed later in this section, because we expect a primary driver of the benefit for insurers providing summary prospectuses to be cost savings associated with no longer printing and mailing lengthy statutory prospectuses for investors that currently receive these documents in paper, the magnitude of the benefit depends in part on the extent to which investors currently elect electronic delivery of materials associated with their variable contract. The higher the percentage of investors currently electing electronic delivery rather than paper, the smaller the benefit derived from forgoing the printing and mailing costs. Accordingly, to estimate the potential cost reduction associated with the rule, as noted above, we assume that 15 percent of the contract investors currently elect electronic delivery of the statutory prospectus both at sale, and annually thereafter.
                        <SU>1066</SU>
                        <FTREF/>
                         Moreover, we assume that at least 15 percent of variable contract investors will elect electronic delivery of the summary prospectus going forward.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1066</SU>
                             We lack verifiable data on current electronic delivery election rates among variable contract investors but are estimating 15 percent based, in part, on the range of estimates provided by commenters and with consideration for the general increase in electronic delivery rates over time demonstrated in other investment products. 
                            <E T="03">See supra</E>
                             notes 1027 through 1029. If variable contract investors exhibit lower electronic delivery rates today than we estimate, the cost savings from reducing the amount of paper mailings under the amendments will be higher than estimated here. If variable contract investors exhibit higher electronic delivery rates today than we have estimated, the cost savings from reducing the amount of paper mailings under the amendments will be lower than estimated here.
                        </P>
                    </FTNT>
                    <P>To estimate the overall impact of the rule on insurers' cost of prospectus delivery, we begin by estimating the number of variable contract statutory prospectuses delivered in paper format. This requires a number of assumptions:</P>
                    <P>
                        • We estimate that insurers will ultimately use summary prospectuses for 90 percent of contracts 
                        <SU>1067</SU>
                        <FTREF/>
                         that are not Alternative Disclosure Contracts.
                        <SU>1068</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1067</SU>
                             In response to the 2012 Financial Literacy Study, the Committee of Annuity Insurers submitted a comment letter in which it states that “The Committee believes the Commission should embrace the use of layered disclosure for variable annuities (and other retail products, including other SEC-registered annuities), as it has done for mutual funds.” According to its comment letter, the Committee of Annuity Insurers “represent more than 80% of the annuity business in the United States.” Although the layered disclosure framework for variable contracts is not identical to the corresponding framework for mutual funds and the creation of initial and updating summary prospectuses may be more costly for variable contracts than the creation of mutual fund summary prospectuses, we nevertheless anticipate that choosing to deliver summary prospectuses will provide cost savings for insurers. Given expressed industry support for layered disclosure with summary prospectuses, our experience that approximately 95 percent of mutual funds have adopted layered disclosure with summary prospectuses, and our anticipation that the rule will provide costs savings to insurers, we believe it is appropriate to assume that 90 percent of insurers will choose delivery of summary prospectuses.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1068</SU>
                             
                            <E T="03">See supra</E>
                             note 1066 and accompanying text.
                        </P>
                    </FTNT>
                    <P>
                        • Issuers of Alternative Disclosure Contracts provide alternative disclosures in lieu of statutory prospectuses.
                        <SU>1069</SU>
                        <FTREF/>
                         Based on staff analysis, approximately 57 percent of variable contract registration statements are for Alternative Disclosure Contracts, and these registration statements apply to up to approximately 18 percent of variable contracts.
                        <SU>1070</SU>
                        <FTREF/>
                         We further assume that each investor in an Alternative Disclosure Contract owns exactly one contract issued under a registration statement for an Alternative Disclosure Contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1069</SU>
                             
                            <E T="03">See supra</E>
                             note 928 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1070</SU>
                             (2.99 million variable annuity contracts + 1.8 million variable life contracts)/25.9 million variable contracts.
                        </P>
                    </FTNT>
                    <P>• We assume 15 percent of investors elect electronic delivery of prospectuses.</P>
                    <P>
                        Together with the baseline estimate of 25.9 million contracts in force at the end of 2019, these assumptions imply that insurers will no longer send approximately 16.1 million statutory prospectuses each year.
                        <SU>1071</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1071</SU>
                             25.9 million × (1-18 percent) × 90 percent × (1-15 percent) = 16.1 million contracts.
                        </P>
                    </FTNT>
                    <P>
                        Next, we estimate the number of statutory prospectuses that will no longer be provided to investors in paper in connection with new contract purchases. In 2019, there were 25.9 million contracts in force.
                        <SU>1072</SU>
                        <FTREF/>
                         Total sales of variable annuity contracts during 2019 was 1,289,500 contracts. Based on these estimates, we further estimate that among investors who elect to receive paper copies of prospectuses, the new option to use a summary prospectus will be applied to 986,000 new contracts annually.
                        <SU>1073</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1072</SU>
                             
                            <E T="03">See supra</E>
                             Section IV.B.1.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1073</SU>
                             
                            <E T="03">See supra</E>
                             note 1071. The number of new contracts falling within the proposed regime is calculated as: 1,289,500 contracts × (1−0.15) × 0.90 = 986,468 contracts.
                        </P>
                    </FTNT>
                    <P>
                        We next estimate the cost difference, per prospectus, of sending summary prospectuses (initial summary prospectuses, as well as updating prospectuses) rather than statutory prospectuses.
                        <SU>1074</SU>
                        <FTREF/>
                         In the Proposing Release, we estimated that printing and mailing expenses for statutory prospectuses are $0.53 per statutory prospectus. We received additional information on printing and mailing expenses from a commenter that persuaded us to revise our estimate.
                        <SU>1075</SU>
                        <FTREF/>
                         In a change from the proposal, we estimate that printing and mailing expenses for statutory prospectuses are $1.50 per statutory prospectus for new investors and $0.55 for existing investors.
                        <SU>1076</SU>
                        <FTREF/>
                         Also in a change from the 
                        <PRTPAGE P="26061"/>
                        proposal, we estimate that printing and mailing expenses for initial summary prospectuses and updating summary prospectuses to be $1.20 and $0.55, respectively.
                        <SU>1077</SU>
                        <FTREF/>
                         Assuming the 2019 level of contracts in force and contract purchases remains stable, we estimate the printing and mailing cost to insurers of meeting their disclosure requirements, as they relate to the delivery of disclosure documents, using initial and updating prospectuses will decline by up to $4,845,000.
                        <SU>1078</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1074</SU>
                             Variable contract issuers generally maintain current prospectuses for their products through the filing of annual post-effective amendments to the registration statements. 
                            <E T="03">See supra</E>
                             note 333. As a result, we assume updating prospectuses will be delivered annually.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1075</SU>
                             
                            <E T="03">See</E>
                             Broadridge Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1076</SU>
                             
                            <E T="03">See id.</E>
                             The commenter assumes the use of First Class or Priority Mail for documents mailed to new investors and the use of Standard Class “bulk” mail for documents mailed to existing investors. The commenter estimates the cost of printing and mailing expenses of statutory prospectuses, inclusive of summary prospectuses for each of the funds the contract offers, to be $6.00 for new investors and $2.20 for existing investors. The commenter also estimates that the variable contract prospectus constitutes 25 percent of the printed and mailed material and summary prospectuses for each of the portfolio companies 
                            <PRTPAGE/>
                            offered constituting the other 75 percent. As a result, we estimate the cost of printing and mailing variable contract prospectuses to be $1.50 (= $6.00 × 25 percent) for new investors and $0.55 (= $2.20 × 25 percent) for existing investors. Also, we estimate the cost of printing and mailing summary prospectuses for each of the portfolio companies offered by the contract to be to be $4.50 (= $6.00 × 75 percent) for new investors and $1.65 (= $2.20 × 75 percent) for existing investors.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1077</SU>
                             
                            <E T="03">See id.</E>
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1078</SU>
                             Calculated as ($1.50−$1.20) × 16,148,735 = $4,844,621. The calculation only includes initial disclosures as the printing and mailing costs of providing updated disclosure with respect to existing investors is assumed to be the same, $0.55. 
                            <E T="03">See supra</E>
                             note 1076.
                        </P>
                    </FTNT>
                    <P>
                        As noted earlier in this section, another key component of costs that insurer will consider when determining whether to provide summary prospectuses under the new rule is the cost of producing the initial and updating summary prospectuses. Insurers choosing to provide summary prospectuses will bear a one-time cost of preparing both the initial summary prospectus and the updating summary prospectus, as well as costs associated with preparing updated versions of both documents in the future on at least an annual basis.
                        <SU>1079</SU>
                        <FTREF/>
                         We estimate the aggregate cost to prepare initial and updating summary prospectuses to be $3,299,285.
                        <SU>1080</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1079</SU>
                             We understand that even those contracts with existing initial summary prospectuses may have changes that need to be reflected in an initial summary prospectus sent to new investors, which will require modifications to the existing initial summary prospectus. However, we believe that once an initial summary prospectus is drafted for a particular contract, that document can serve as a basis for future versions of the initial summary prospectuses sent to new investors of the contract. Thus, we believe that drafting an “updated” initial summary prospectus will be less costly than drafting the original initial summary prospectus. Similarly, we believe that preparing subsequent updating summary prospectuses will be less costly than preparing the original updating summary prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1080</SU>
                             
                            <E T="03">See infra</E>
                             note 1230.
                        </P>
                    </FTNT>
                    <P>
                        Insurers that choose to provide summary prospectuses are required to make statutory prospectuses and other materials available online.
                        <SU>1081</SU>
                        <FTREF/>
                         We estimate the annual burden to comply with the website posting requirements of the rule for documents relating to variable contracts will be 1,217 hours,
                        <SU>1082</SU>
                        <FTREF/>
                         at an internal cost equivalent of $301,816.
                        <SU>1083</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1081</SU>
                             The requirement that contract disclosure materials be available online for a period of 90 days mirrors the online availability requirement for disclosure materials associated with mutual funds using summary prospectuses, including most portfolio companies. While there are operational differences between the variable contract and mutual fund summary prospectus regimes, to the extent that the new rule harmonizes certain requirements, this could create efficiencies for contracts organized as UITs. This efficiency will not apply to Form N-3 registrants, which do not have underlying portfolio companies due to a single-tier investment company structure.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1082</SU>
                             
                            <E T="03">See infra</E>
                             note 1234.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1083</SU>
                             
                            <E T="03">See infra</E>
                             note 1235.
                        </P>
                    </FTNT>
                    <P>Insurers are also required to include inter- and intra-document linking and special terms definitions. One linking requirement will allow the reader to move back and forth between a table of contents of the contract statutory prospectus or SAI and the related sections of each document. Although prospectuses and SAIs are not required to have individual headings corresponding to the items in the registration forms, we assume that the sections of a prospectus or SAI will correspond with the item requirements of the forms. We estimate that Form N-3 registrants will require 33 back-and-forth internal links, Form N-4 registrants will require 27, and Form N-6 registrants will require 28. The other linking requirement will allow the reader to move back and forth between each section of the summary prospectus and any related section of the contract statutory prospectus and SAI that provides additional detail. This back-and-forth movement could occur either directly from the summary prospectus to the relevant section of the statutory prospectus or SAI, or indirectly by linking from the summary prospectus to a table of contents for the statutory prospectus or SAI, and vice versa. For our analysis, we assume direct links will tend to be more costly when compared with indirect linking through a table of contents.</P>
                    <P>An initial summary prospectus for a Form N-3 registrant or a Form N-4 registrant includes seven sections and an initial summary prospectus for a Form N-6 registrant includes nine sections. However, the Key Information Table has instructions stating that a registrant should provide cross-references or links to the location in the statutory prospectus where the subject matter is described in greater detail, or should provide a means of facilitating access to that information through equivalent methods or technologies. There are 12 sections of the Key Information Table. Therefore, we estimate that there will be 18 back-and-forth links between Form N-3 and Form N-4 registrant initial summary prospectuses and statutory prospectuses, and 20 back-and-forth links between Form N-6 registrant initial summary prospectuses and statutory prospectuses.</P>
                    <P>An updating summary prospectus for a Form N-3, Form N-4, or Form N-6 registrant includes three sections, one of which, the Key Information Table, includes 12 sections. One section is the “Updated Information About Your Contract” section. The number of links in this section will depend on the number of updates discussed. For example, assuming discussion of four updates, we estimate the number of back-and-forth links between a Form N-3, Form N-4, or Form N-6 registrant's updating summary prospectus and statutory prospectus to be 18.</P>
                    <P>
                        The rule will also require that investors either be able to view the definition of each special term used in an online summary prospectus upon command (
                        <E T="03">e.g.,</E>
                         by “hovering” the computer's pointer or mouse over the term), or to move directly back-and-forth between each special term and the corresponding entry in any glossary or list of definitions that the summary prospectus includes. We assume that registrants could replicate links to a glossary or the computer code required to implement access to definitions by “hovering” over a term with little or no burden, but that there will be a burden associated with creating the requisite link or code for each special term. Accordingly, we estimate the aggregate cost to comply with the requirement to include inter- and intra-document linking and special terms definitions as described above will include 3,812 burden hours and a cost of $508,320 annually.
                        <SU>1084</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1084</SU>
                             These burden hours and cost estimates are a portion of the overall burden and cost estimates associated with the collection of information for rule 498A discussed below in Section V.E. In a separate rulemaking, we required registrants that file registration statements and reports subject to the exhibit requirements under Item 601 of Regulation S-K, or that file Forms F-10 or 20-F, to include a hyperlink for each exhibit listed in the exhibit index of these filings. 
                            <E T="03">See</E>
                             Exhibit Hyperlinks and HTML Format Adopting Release, 
                            <E T="03">supra</E>
                             note 1056. We estimated the burden of including hyperlinks to be between one and four hours with 75 percent of the burden carried by the registrant internally and 25 percent of the burden carried by outside professionals retained by the registrant at an average cost of $400 per hour. Filings for which we estimated a burden of four hours had approximately 33 to 35 hyperlinks, on average. We do not have data on extent to which providing the “two-way” inter- and intra-document linking and special terms definitions differs from providing “one-way” hyperlinks from one document to another. We estimate the burden of including inter- and intra-document linking and 
                            <PRTPAGE/>
                            special terms definitions to be eight hours with 75 percent of the burden carried by the registrant internally and 25 percent of the burden carried by outside professionals at an average cost of $400 per hour. In the proposal, based on 726 registrants, we estimated total burden hours to be 5,518 with 4,138 hours burden hours being carried by registrants internally and the cost of the burden carried by outside professionals to be $552,000. We are revising our estimates to reflect the number of registrants, 706], that filed during 2019. Revising our estimate of the number of registrants to 706, we estimate the total burden hours to be 5,083 = (706 registrants) × (90 percent relying on rule) × (8 burden hours per registrant). We estimate the burden hours carried by the registrants internally to be 3,807 = 5,083 × .75. We estimate the cost of the burden carried by outside professionals to be $508,320 = (5,083 × .25) × $400.
                        </P>
                    </FTNT>
                    <PRTPAGE P="26062"/>
                    <P>
                        Finally, insurers may incur costs in connection with the requirement to provide a statutory prospectus and other documents upon request of an investor. We estimate that the annual cost associated with printing and mailing these documents will be $500 per registrant.
                        <SU>1085</SU>
                        <FTREF/>
                         We estimate that the aggregate annual costs associated with printing and mailing statutory prospectuses will be $304,200.
                        <SU>1086</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1085</SU>
                             
                            <E T="03">See infra</E>
                             note 1233.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1086</SU>
                             
                            <E T="03">See infra</E>
                             note 1236.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">ii. Portfolio Company Prospectus Delivery Option</HD>
                    <P>
                        Form N-4 and Form N-6 registrants that use summary prospectuses may also benefit from the option to provide prospectuses for all underlying portfolio companies online.
                        <SU>1087</SU>
                        <FTREF/>
                         While there will be certain costs associated with complying with the requirements for posting the portfolio company materials online, as discussed below, we anticipate that this new optional delivery method will result in overall reduced costs due to a reduction in printing and mailing costs. To the extent that insurers bear these costs, we expect the reductions will benefit the insurance company, which may pass such cost savings on to new variable contract investors in the pricing of variable contracts offered in the future, and possibly to existing variable contract investors. To the extent that a portfolio company bears these costs, cost savings will typically be passed along to investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1087</SU>
                             
                            <E T="03">See supra</E>
                             Section II.B. This new delivery option will not be available to Form N-3 registrants because they do not have underlying portfolio companies. As of the end of calendar 2019, 700 of 706 (99 percent) registrants were either Form N-4 registrants (477) or Form N-6 registrants (223).
                        </P>
                    </FTNT>
                    <P>
                        Moreover, as with the reduction in printing and mailing costs associated with the delivery of the contract statutory prospectus, the magnitude of these cost savings is dependent on the extent to which investors currently elect to receive electronic versions of the portfolio company prospectuses rather than receive them in paper. The higher the percentage of investors who currently receive paper copies of portfolio company prospectuses, the greater the reduction in printing and mailing costs arising from the new delivery option. We estimate that 85 percent of investors currently receive paper copies of these documents.
                        <SU>1088</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1088</SU>
                             We recognize that by permitting the satisfaction of delivery obligations through the posting of portfolio company statutory prospectuses online (under the conditions specified in the rule), there may be a disincentive for portfolio companies to use a summary prospectus, as concerns about costs of printing and mailing the statutory prospectus will be reduced. However, the rule requires, as a condition of relying on the new delivery method, that the mutual fund summary prospectus be made available online. In addition, the Commission continues to believe that the costs of continuing to produce the mutual fund summary prospectus, which reflects a portion of the statutory prospectus, will be minimal. 
                            <E T="03">See</E>
                             2009 Summary Prospectus Adopting Release, 
                            <E T="03">supra</E>
                             note 17.
                        </P>
                    </FTNT>
                    <P>
                        In the Proposing Release, we estimated that printing and mailing expenses for summary prospectuses for underlying portfolio companies would be $0.53 per summary prospectus. We received additional information from a commenter that persuaded us to revise our estimate.
                        <SU>1089</SU>
                        <FTREF/>
                         In a change from the proposal, we estimate that printing and mailing expenses for summary prospectuses for underlying portfolio companies to be $4.50 per set of prospectuses for new investors and $1.65 for existing investors.
                        <SU>1090</SU>
                        <FTREF/>
                         Assuming the 2019 level of contracts in force and contract purchases remains stable, we estimate the printing and mailing cost will decline by $4,439,000 for new investors and $26,645,000 for existing investors,
                        <SU>1091</SU>
                        <FTREF/>
                         for aggregate cost savings of $31,085,000.
                        <SU>1092</SU>
                        <FTREF/>
                         Registrants will incur costs associated with making the underlying portfolio company summary prospectus, statutory prospectus, SAI, and most recent shareholder reports available online under the conditions set forth in the rule. We estimate the annual burden to comply with the website posting requirements of the rule for documents relating to portfolio companies will be 1,206 hours,
                        <SU>1093</SU>
                        <FTREF/>
                         at an internal cost equivalent of $299,088.
                        <SU>1094</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1089</SU>
                             
                            <E T="03">See</E>
                             Broadridge Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1090</SU>
                             
                            <E T="03">See supra</E>
                             note 1076.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1091</SU>
                             Calculated as $4.50 × 986,468 = $4,439,104 for new investors and $1.65 × $16,148,735 = $26,645,413 for existing investors.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1092</SU>
                             Calculated as $4,439,104 + $26,645,413 = $31,084,517.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1093</SU>
                             
                            <E T="03">See infra</E>
                             note 1234.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1094</SU>
                             
                            <E T="03">Id.</E>
                             Although we do not have data on the use of summary prospectuses for the underlying portfolio companies offered in variable contracts, we understand that delivery of summary prospectuses is typical. To the extent that there are portfolio companies for which no summary prospectus has been created, there will be costs associated with the summary prospectus requirement. Those costs will include the cost of creating the document, making sure that the summary prospectus is structured appropriately, and costs associated with filing the summary prospectus after it is first used under rule 497. We believe that these costs will be small, however. For example, the content of a mutual fund summary prospectus consists of Items 2 through 8 of Form N-1A, with the cover page as specified by rule 498.
                        </P>
                    </FTNT>
                    <P>
                        Insurers and portfolio companies may incur costs in connection with the requirement to provide summary prospectuses for underlying portfolio companies upon request of an investor. We estimate that the annual cost associated with printing and mailing these prospectuses will be $500 per registrant.
                        <SU>1095</SU>
                        <FTREF/>
                         We estimate that the aggregate annual costs associated with printing and mailing portfolio summary prospectuses will be $301,500.
                        <SU>1096</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1095</SU>
                             
                            <E T="03">See infra</E>
                             note 1241. Also, currently contract investors may request paper copies of online documents related to portfolio investments (
                            <E T="03">e.g.,</E>
                             SAIs). As a result, we estimate the cost of updating systems to accommodate requests for paper copies of prospectuses for portfolio investments will be minimal.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1096</SU>
                             $500 × 90 percent × (477 Form N-4 registrants + 223 Form N-6 registrants) = $315,000.
                        </P>
                    </FTNT>
                    <P>
                        Thus, we estimate a reduction of costs related to delivery of portfolio company summary prospectuses of $30,479,000.
                        <SU>1097</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1097</SU>
                             $31,084,517−$304,200−$301,500 = $30,478,817.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">2. Changes to Forms N-3, N-4, and N-6</HD>
                    <HD SOURCE="HD3">a. Benefits and Costs for Investors</HD>
                    <P>The amendments to Forms N-3, N-4, and N-6 are intended to reflect the evolution of variable contract features including, in particular, the prevalence of optional benefits that insurers offer under these contracts, and to provide greater consistency among the forms. For example, the amended forms require additional information about standard and optional benefits that a contract may offer. There is no current form requirement regarding optional benefits.</P>
                    <P>
                        The amended forms also increase consistency of disclosure presentation requirements among variable contracts that register on different form types. This increased consistency could help investors compare variable contracts that register on different form types. Certain investors who are considering variable annuities may also be considering variable life insurance (and vice versa). We believe a consistent presentation and common disclosure of elements that we consider useful in explaining variable contracts' features and risks could reduce investor confusion and promote investor understanding across types of variable products. Also, we believe that more 
                        <PRTPAGE P="26063"/>
                        uniformity of disclosures across variable contract types may make it easier for investors to compare similar products.
                    </P>
                    <P>We are amending the General Instructions of Forms N-3, N-4, and N-6 regarding the preparation and filing of registration statements. First, these amendments prescribe the ordering and location of the Key Information Table, the Overview of the Variable Annuity Contract, and the Fee Table. In particular, the amendments place this information at the beginning of the prospectus, benefitting investors to the extent that this placement makes information about a variable contract's key features, costs, and risks more readily available. We do not anticipate that these changes will impose substantial costs on investors. We acknowledge that investors familiar with the current ordering of information on Forms N-3, N-4, and N-6 could bear one-time costs associated with adjusting to the presentation of information on these forms.</P>
                    <P>Second, we are amending the General Instructions to provide new guidance in each of the forms that addresses when a single prospectus may be used to describe multiple contracts and when multiple prospectuses may be included in a single registration statement. To the extent that ensuring that prospectuses and registration statements cover contracts with similar features, costs, and risks facilitates investors' understanding of contract characteristics, these amendments may benefit investors. While we do not have information available to quantify these benefits, we believe that these amendments are consistent with current industry practice and we therefore do not expect these benefits to be substantial. We do not anticipate that these changes will impose substantial costs on investors. We acknowledge that to the extent that the guidance results in presentation of information that investors are unaccustomed to, investors may bear one-time costs associated with adjusting to a new presentation of variable contract information.</P>
                    <P>
                        In a change from the proposal, we have decided to eliminate AUV tables currently in Forms N-3 and N-4 in their entirety.
                        <SU>1098</SU>
                        <FTREF/>
                         Eliminating AUV tables may impose costs on current and potential investors, to the extent that such investors could make use of historical summary performance information as part of their decision to make additional investments or their decision to choose between insurers or variable products. We believe these costs are substantially mitigated, however, because investors can get summary information with respect to the net performance of an individual option from the Appendix to the summary prospectus.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1098</SU>
                             
                            <E T="03">See supra</E>
                             Section II.C.2.e.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">b. Benefits and Costs for Insurers</HD>
                    <P>
                        The form amendments will increase consistency of disclosure presentation requirements among variable contracts that are registered on different form types. We anticipate that this increased consistency among Forms N-3, N-4, and N-6 could have the benefit of reducing costs among sponsors that register variable contracts on multiple registration form types. For example, we anticipate that this will make the production of registration statements simpler, in that form instructions and content requirements will in many cases be the same (except in cases where structural differences or product differences that the different form types indicate will lead to requirements that will differ across the form types).
                        <SU>1099</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1099</SU>
                             In 2019, 73 insurers filed Form N-CEN reports for separate accounts with registrations on Forms 
                        </P>
                        <P>N-3, N-4, and N-6. 5 of the 73 (7 percent) insurers filed Form N-CEN reports for all three form types (N-3, N-4, and N-6). 58 of the 73 (79 percent) issuers filed Form N-CEN reports for two form types. Overall, 63 (86 percent) insurers filed Form N-CEN reports for more than one form type.</P>
                    </FTNT>
                    <P>In a change from the proposal and as discussed above, we have decided to eliminate AUV tables currently in Forms N-3 and N-4 in their entirety. For registrants utilizing these forms, we believe the amendments will reduce the costs related to preparing registration statement disclosure of information relating to the contract's accumulation unit values. We estimate the implementation costs for each of the three registrant types, while netting the reduced burden for Form N-3 and Form N-4 registrants, below.</P>
                    <P>
                        <E T="03">Form N-3 Estimates.</E>
                         We estimate that there are currently six insurer separate accounts that file on Form N-3. We estimate the total annual hour burden to comply with amended Form N-3 to be 2,836 hours, at an internal time cost equivalent of $762,884.
                        <SU>1100</SU>
                        <FTREF/>
                         We also estimate the total external cost burden to comply with amended Form N-3 to be $123,114.
                        <SU>1101</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1100</SU>
                             
                            <E T="03">See infra</E>
                             note 1172.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1101</SU>
                             
                            <E T="03">See infra</E>
                             note 1173.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Form N-4 Estimates.</E>
                         We estimate that there are currently 477 insurer separate accounts that file on Form N-4. We estimate the total annual hour burden to comply with amended Form N-4 to be 300,937 hours, at an internal time cost equivalent of $80,952,053.
                        <SU>1102</SU>
                        <FTREF/>
                         We also estimate the total external cost burden to comply with amended Form N-4 to be $30,342,168.
                        <SU>1103</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1102</SU>
                             
                            <E T="03">See infra</E>
                             note 1183.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1103</SU>
                             
                            <E T="03">See infra</E>
                             note 1184.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Form N-6 Estimates.</E>
                         We estimate that there are currently 223 insurer separate accounts that file on Form N-6. We estimate the total annual hour burden to comply with amended Form N-6 to be 65,123 hours, at an internal time cost equivalent of $17,518,087.
                        <SU>1104</SU>
                        <FTREF/>
                         We also estimate the total external burden to comply with amended Form N-6 to be $7,840,000.
                        <SU>1105</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1104</SU>
                             
                            <E T="03">See infra</E>
                             note 1194.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1105</SU>
                             
                            <E T="03">See infra</E>
                             note 1195.
                        </P>
                    </FTNT>
                    <P>In addition to these implementation costs, the form amendments could impose costs related to changes in presentation of information. In particular, the amendments may impose costs on insurers to the extent that they limit insurers' flexibility in choosing the placement of information within the statutory prospectuses. While we do not have data necessary to quantify these costs, we do not expect them to be substantial.</P>
                    <HD SOURCE="HD3">3. Inline XBRL</HD>
                    <P>Generally as proposed, except as discussed below, we are requiring certain information from variable contract statutory prospectuses to be filed with the Commission in Inline XBRL. Inline XBRL is a specification of XBRL that is both human-readable and machine-readable for purposes of validation, aggregation, and analysis.</P>
                    <P>The Inline XBRL requirement is expected to benefit investors directly by facilitating and enhancing the analysis and comparison of variable contracts by investors and by investment professionals working on their behalf, and indirectly by facilitating the analysis of variable contracts by financial analysts, data aggregators, Commission staff, variable contract issuers, and others. For example, we expect that investors will benefit from more accurate and timely information provided by data aggregators as a result of the Inline XBRL requirement.</P>
                    <P>
                        These benefits are expected to be greatest in instances of filings by a large number of registrants and for information from variable contract disclosures that is not aggregated by data aggregators today and therefore requires greater effort to extract and analyze on the part of investors. To the extent that some of the variable contract investors and other data users also review disclosures of mutual funds and ETFs, those investors and other data users will have familiarity with using Inline XBRL to view and analyze disclosures from having reviewed 
                        <PRTPAGE P="26064"/>
                        prospectus risk/return summaries filed in Inline XBRL under the recently adopted Inline XBRL requirements for mutual funds and ETFs.
                        <SU>1106</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1106</SU>
                             
                            <E T="03">See</E>
                             Inline XBRL Adopting Release, 
                            <E T="03">supra</E>
                             note 892.
                        </P>
                    </FTNT>
                    <P>
                        For contracts being sold to new investors, variable contract registrants will incur costs to tag and review the required information in Inline XBRL. Some filers may perform the tagging in-house while others may retain outside service providers. We expect the outside service providers to pass along their costs to filers. Various XBRL preparation solutions have been developed and used by operating companies and open-end fund filers, and some evidence suggests that, for operating companies, XBRL tagging costs have decreased over time.
                        <SU>1107</SU>
                        <FTREF/>
                         Because Inline XBRL allows filers to embed XBRL data directly into an HTML document, we expect costs to be even lower than with XBRL since Inline XBRL eliminates the need to tag a copy of the information in a separate XBRL exhibit. For filers that currently report information in Inline XBRL for other investment products they offer, such as open-end funds, filing variable contract information in Inline XBRL under the amendments will likely incur lower costs of compliance than filers adopting Inline XBRL for the first time.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1107</SU>
                             
                            <E T="03">See, e.g.,</E>
                              
                            <E T="03">XBRL Costs for Small Companies Have Declined 45%, According to AICPA Study</E>
                             (Aug. 15, 2018), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.aicpa.org/press/pressreleases/2018/xbrl-costs-have-declined-according-to-aicpa-study.html</E>
                             (stating that “the cost of XBRL formatting for small reporting companies has declined 45 percent since 2014, according to an updated pricing survey. . . 68.6 percent of the companies paid $5,500 or less on an annual basis (as compared to 29.9 percent of companies in the 2014 survey) for fully outsourced creation and filing solutions for their XBRL filings. Meanwhile, 11.8 percent of the companies paid annual costs between $5,500 to as much as $8,000 for their full-service outsourced solutions.”).
                        </P>
                    </FTNT>
                    <P>
                        In a departure from the proposal, we are applying the Inline XBRL requirement only to contracts that are being sold to new investors. As discussed in further detail below, we believe the benefits of structured data are less significant for contracts that are not being sold to new investors and do not justify the additional yearly tagging cost on filers of such contracts.
                        <SU>1108</SU>
                        <FTREF/>
                         As a result, contracts that are offered to new investors after the Inline XBRL compliance date will include current structured data only until those contracts are no longer offered to new investors, at which point the structured data will no longer reflect any subsequent changes to the formerly tagged disclosures. Investors that use this structured data could therefore incur the cost of using potentially outdated information in their analysis. However, because prospectus disclosures related to contracts that are no longer sold to new investors are unlikely to materially change from year to year, and because these contracts are not potential investments for new investors comparing variable contract options, we believe this cost is of low significance.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1108</SU>
                             
                            <E T="03">See infra</E>
                             Section IV.E.5.
                        </P>
                    </FTNT>
                    <P>Similar to the risk/return summary requirements for mutual funds and ETFs, (1) the amendments require variable contract registrants to submit to the Commission in Inline XBRL certain information from registration statements, post-effective amendments, and prospectuses with certain information that varies from the registration statement, and (2) the Interactive Data File will be submitted in post-effective amendment filings to the registration statement, which may make the filing incrementally more efficient than if the Interactive Data File was submitted in a separate filing.</P>
                    <P>
                        Those registrants affected by the requirement that have not had experience structuring disclosures in other contexts will likely incur initial costs to acquire the necessary expertise and/or software as well as ongoing costs of tagging required information in Inline XBRL, and any fixed costs of complying with the Inline XBRL requirement may have a relatively greater impact on smaller filers.
                        <SU>1109</SU>
                        <FTREF/>
                         On an ongoing basis, registrants are expected to expend time to review the tagged information in Inline XBRL using their in-house staff. Some registrants may also incur an initial cost to license filing preparation software with Inline XBRL capabilities from a software vendor, and some may also incur an ongoing licensing cost. Other registrants may incur an initial cost to modify their existing filing preparation software to accommodate Inline XBRL preparation. Some registrants will incur the costs of filing agent services to rely on a filing agent to prepare their Inline XBRL filings. Initial costs involving investments in expertise and modifications to disclosure preparation solutions, or switching to a different software vendor or outside service provider, may result in a higher compliance cost during the first year of using Inline XBRL than in subsequent years. While the costs of compliance with the Inline XBRL requirement are likely to vary across registrants, we estimate that the average annual internal burden for a variable contract registrant on Forms N-3, N-4, and N-6 will be approximately $20,880, $14,616, and $14,616 per year, respectively, and the average external cost will be approximately $1,800, $900, and $900 per year, respectively.
                        <SU>1110</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1109</SU>
                             
                            <E T="03">See supra</E>
                             note 897.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1110</SU>
                             
                            <E T="03">See infra</E>
                             Section V.D.
                        </P>
                    </FTNT>
                    <P>The compliance dates under the amendments are expected to give registrants additional time to obtain the necessary expertise and software, and mitigate the impact of transition on all filers, including smaller filers. However, we also expect that filers may realize benefits from the Inline XBRL requirement to the extent that making disclosures available in a structured format reduces some of the information barriers that make it costly for variable contract registrants to find new investors, as discussed in Section IV.D below.</P>
                    <P>
                        By making it easier to perform automated comparisons of disclosures across variable contracts, the amendments also might affect sales agents. Sales agents play a significant role in the distribution of variable contract products. For non-captive sales agents that independently compare variable contract products for recommendation to investors and prepare their own sales materials, we believe that those sales agents could benefit from the easier access and enhanced usability of information about variable contracts in Inline XBRL. Inline XBRL can facilitate faster search features across a larger set of variable contracts, with the Inline XBRL Viewer providing enhanced filtering and aggregation features. By using these features, sales agents may be able to select variable contract offerings that are better tailored to investors' demands. Similar benefits could also accrue to captive sales agents, to the extent that Inline XBRL permits them to more easily compare different variable contracts offered by a single issuer compared to manual review. Because having the required data in a structured format facilitates the analysis, aggregation, and comparison of information about variable contracts, the amendments might increase competition for investor capital among sales agents offering variable contract products of individual insurers or a narrow range of variable contract products.
                        <SU>1111</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1111</SU>
                             Requiring variable contract registrants to file certain key information in Inline XBRL could facilitate comparisons of information across registrants which could increase competition among variable contract registrants for investor capital. Also, requiring variable contract registrants to file certain key information in Inline XBRL could reduce barriers to entry for third-party aggregators and induce competition among firms that supply information about variable contracts to investors. 
                            <PRTPAGE/>
                            These possibilities are discussed in greater detail below.
                        </P>
                    </FTNT>
                    <PRTPAGE P="26065"/>
                    <HD SOURCE="HD3">4. Treatment of Discontinued Variable Contracts</HD>
                    <P>
                        As discussed above, the Commission is taking the position that if an issuer of an Eligible Contract that is discontinued as of July 1, 2020 that provides alternative disclosures does not file post-effective amendments to update a variable contract registration statement and does not provide updated prospectuses to existing investors, this would not provide a basis for enforcement action so long as investors are provided with the Alternative Disclosures or certain modernized alternative disclosures.
                        <SU>1112</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1112</SU>
                             
                            <E T="03">See supra</E>
                             Section II.E.
                        </P>
                    </FTNT>
                    <P>Issuers providing alternative disclosures currently experience reductions in costs associated with updating registration statements and delivering updated prospectuses, compared to other variable contract issuers. In addition, the Commission position creates an option for issuers of Eligible Contracts. In lieu of providing financial statements and portfolio company prospectuses, issuers can send a Notice Document and post the portfolio company prospectuses and other required documents online. Issuers of Eligible Contracts will benefit from this position to the extent preparing and sending the Notice Document, in lieu of providing portfolio company prospectuses and financial statements, is less costly than providing Alternative Disclosures. This determination will be specific to agreements between insurers and portfolio companies as well as the circumstances of each contract, including the number of remaining contract investors, the number of underlying portfolio companies, and the proportion of the costs of printing and mailing the portfolio company prospectuses allocated to the variable contract issuer.</P>
                    <P>
                        We acknowledge that there are certain other costs and burdens that are currently reduced for issuers providing alternative disclosures, but would not be similarly reduced under the rule and form amendments. For example, a registrant relying on rule 498A will bear burdens of maintaining and updating the contract registration statement,
                        <SU>1113</SU>
                        <FTREF/>
                         preparing and filing updating summary prospectuses, delivering the updating summary prospectus to investors annually, and making the contract statutory prospectus and SAI and other required documents available online. In addition, while the form amendments will simplify certain current disclosure requirements,
                        <SU>1114</SU>
                        <FTREF/>
                         in other instances they will result in new or amended disclosures that, in the aggregate, we anticipate will result in a net increase in the burden associated with preparing an initial registration statement and post-effective amendments thereto.
                        <SU>1115</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1113</SU>
                             Even when there are not material updates to the contract, the updating process still will entail internal burdens (
                            <E T="03">e.g.,</E>
                             for the registrant to confirm the continued accuracy of the information in the registration statement and to update information about the portfolio companies) and external expenses (
                            <E T="03">e.g.,</E>
                             for outside legal and auditor services).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1114</SU>
                             For example, the amendments to Form N-3 and Form N-4 include certain changes that eliminate burdens related to preparing and disclosing contract accumulation unit values. 
                            <E T="03">See supra</E>
                             Section II.C.2.e.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1115</SU>
                             
                            <E T="03">See infra</E>
                             Section IV.C.2.b.
                        </P>
                    </FTNT>
                    <P>
                        We estimate that approximately 4.79 million variable contracts are currently providing alternative disclosures.
                        <SU>1116</SU>
                        <FTREF/>
                         For those contracts, the extent of the impact, compared to the baseline, of the Commission's position with respect to Eligible Contracts will depend on the extent to which insurers choose to provide modernized alternative disclosures. If insurers choose to provide the Alternative Disclosures, the impact would be minimal.
                        <SU>1117</SU>
                        <FTREF/>
                         Alternatively, if issuers choose to provide modernized alternative disclosures, we believe investors will receive more useful information than the financial statements they currently receive.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1116</SU>
                             
                            <E T="03">See supra</E>
                             note 1031.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1117</SU>
                             We note that insurers will have to file financial statements with the Commission as described in Section II.E.3.a above. 
                            <E T="03">See supra</E>
                             note 954.
                        </P>
                    </FTNT>
                    <P>With respect to insurers with variable contracts outstanding, the Commission position likely will result in some costs. Existing contracts whose issuers are not currently operating in the manner described in the Staff Letters may have been structured or offered by insurers with the expectation that the insurer could provide alternative disclosures if a product launch is unsuccessful or the number of investors diminishes over time. Those contracts may experience unexpected future costs associated with updating the registration statement and delivering prospectuses under current regulatory requirements. However, those contracts could avail themselves of the summary prospectus regime, which, as discussed above, may mitigate some of those costs.</P>
                    <P>
                        Many of the burdens that are currently reduced for issuers providing alternative disclosures are also expected to be reduced under the summary prospectus framework; in particular, we expect reductions in costs associated with printing and mailing the contract summary prospectus and underlying portfolio company prospectuses to investors.
                        <SU>1118</SU>
                        <FTREF/>
                         However, to the extent that the summary prospectus framework does not reduce future costs to the same extent as currently for issuers providing alternative disclosures, insurers may seek to terminate contracts with few remaining investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1118</SU>
                             
                            <E T="03">See supra</E>
                             Section IV.C.1.b.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">D. Effects on Efficiency, Competition, and Capital Formation</HD>
                    <P>This section describes the effects we expect the rule and form amendments to have on efficiency, competition, and capital formation.</P>
                    <P>
                        <E T="03">Efficiency.</E>
                         To investors, the costs of purchasing a variable contract are more than just the dollar cost of the contract and include the value of an individual's time spent gaining an understanding of the contract as well as various aspects of the contract including optional benefits and fee structures, both prior to contract purchase and during the free look period following purchase. Further, for those investors who do not gain a full understanding of the contract, there could be a cost stemming from a potential mismatch between an investor's goals and the purchased contract. Depending on the size of an individual's potential purchase, certain of these additional costs could be considerable in comparison to the monetary costs associated with contract purchase and could discourage investors from considering variable contracts even in circumstances where investment in a variable contract would be beneficial.
                    </P>
                    <P>
                        For their part, insurers only supply variable contracts to the extent they expect the benefits derived from providing the contracts to be greater than cost of supplying the contract.
                        <SU>1119</SU>
                        <FTREF/>
                         For insurers, costs include not only those costs associated with producing and servicing variable contracts, but also those costs associated with meeting various statutory and regulatory obligations.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1119</SU>
                             Insurers who expect the benefits derived from supplying contracts to be equal to the cost of supplying the contract will be indifferent between supplying and not supplying the contract.
                        </P>
                    </FTNT>
                    <P>
                        These costs borne by both insurers and individuals are examples of market “frictions.” Market frictions have the effect of reducing the benefits from contracting between market participants.
                        <SU>1120</SU>
                        <FTREF/>
                         Rules that reduce costs for investors, insurers, or both, reduce market frictions. The summary 
                        <PRTPAGE P="26066"/>
                        prospectus framework offers the opportunity for both insurers and investors to reduce their costs associated with variable contracts. Summary prospectuses provide information in a concise, user-friendly way that may allow investors to better understand variable products. The summary prospectus framework offers opportunities for insurers to reduce the costs of producing and delivering required disclosures to investors.
                        <SU>1121</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1120</SU>
                             If market frictions are sufficiently large, market frictions could eliminate exchange altogether.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1121</SU>
                             For example, as discussed above, greater investor understanding of variable products could lead to a better match between investor goals and purchased variable contracts. In other words, investment efficiency could increase.
                        </P>
                    </FTNT>
                    <P>
                        Similarly, the amendments to the registration forms will make key information more salient for investors and will make the presentation of this information more consistent across variable contract types. Additional consistency across forms will also reduce compliance burdens for insurers that are required to file using multiple form types, as will the amendments that reduce or eliminate certain disclosure requirements such as the AUV table requirement. The resulting decrease in market frictions should lead to greater efficiency by reducing barriers that insurers may face in supplying variable contracts to investors, and reducing barriers investors may face in evaluating variable contracts sold to them by insurers, particularly during the free look period.
                        <SU>1122</SU>
                        <FTREF/>
                         In addition, requiring variable contract registrants to file certain information in Inline XBRL will enable investors to capture and analyze that information more quickly and efficiently than is possible using the same information provided in a static, text-based format. This improved functionality is expected to also facilitate the analysis performed by other data users (such as financial analysts, data aggregators, Commission staff, academics, and financial journalists) to the ultimate benefit of investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1122</SU>
                             As noted above, there may be investors who prefer to rely on statutory prospectuses when making an investment decision who may not take the steps necessary to access the statutory prospectus. To the extent there are both investors who prefer to rely on statutory prospectuses when making an investment decision and who do not take the steps necessary to access the statutory prospectus, the increased barrier (the steps necessary to access the statutory prospectus) could lead to reduced efficiency in investor evaluation of variable contracts.
                        </P>
                    </FTNT>
                    <P>These increases in efficiency could manifest as a higher likelihood that investors make investment decisions that are informationally efficient. First, it may increase the likelihood that investors choose a level of participation in variable contracts that is consistent with their overall financial needs and objectives—a level that may be higher or lower than current levels. The rule and form amendments may help promote investment in variable contracts by investors who would benefit from them. Second, more concise, user-friendly disclosure facilitates comparison across variable contracts and could make it more likely that investors choose the contracts that best meet their needs and reject those that do not. We also note that in facilitating comparison across variable products, concise, user-friendly disclosures may promote competition among insurers on dimensions such as fees, costs, and conflicts which could, in turn, improve investor welfare. Third, improved access to information resulting from more concise disclosure could facilitate more efficient investor allocation of assets across portfolio companies within variable contracts. Finally, access to clearer information about the contract terms may reduce the chances that an investor surrenders a variable contract when the costs of surrender do not justify the benefits of surrender.</P>
                    <P>Furthermore, we considered the potential impact of our position on Alternative Disclosure Contracts on efficiency. We recognize that our position likely will cause insurers with non-Alternative Disclosure Contracts outstanding to incur additional costs due to the disclosure obligations that they may not have anticipated. To the extent that these unexpected costs drive insurers to take actions to encourage investors to exchange old contracts for new contracts or to buy out existing contracts, the Commission's position may result in inefficiencies. However, we believe that this reduction in efficiency may be offset by the expected increase in informational efficiency associated with the disclosures that will be afforded to contract holders in lieu of the alternative disclosures described in the Staff Letters.</P>
                    <P>
                        <E T="03">Competition.</E>
                         If the rule and form amendments increase efficiency of exchange in the variable contracts market, then we may observe a change in investment in variable contracts. For example, if there are individuals who currently do not invest in variable contracts (or invest less than they would have) because the costs other than the price of the contract are too high, then to the extent the rule lowers those costs we would expect to observe more people entering the variable contract market. Conversely, there may be investors who, because of the burden, choose not to read statutory prospectuses. To the extent those investors are more likely to read summary prospectuses, those investors may decide, as a result, that other investments or products are better suited to their investment goals. This could result in fewer investments in variable contracts. If there are insurers who limit their participation in the variable contract market, or limit the portfolio companies they offer as a result of the costs of current prospectus delivery requirements, those insurers may increase participation or increase the number of portfolio companies they offer as a result of this rule. To the extent that competition in a market is related to the size of the market, the net effect of these potential changes in investor demand for, and insurer supply of, variable contracts could affect competition in the variable contract market.
                    </P>
                    <P>
                        The rule could also affect competition by requiring that information about the variable contract be presented in a concise, user-friendly way in the summary prospectus, which enhances the ability of investors to compare information across products. Requiring variable contract registrants to file certain information in Inline XBRL will further facilitate comparisons of information across contracts by making it easier for investors (directly or through data aggregators) to extract and aggregate information through automated means for analysis and comparison, which could increase competition among variable contract registrants for investor capital, particularly in combination with the free look period.
                        <SU>1123</SU>
                        <FTREF/>
                         For example, the rule and form amendments require insurers to distill certain information into tables. The presentation of this information in a table facilitates comparison across different products. Greater comparison across different variable products could lead to greater 
                        <PRTPAGE P="26067"/>
                        competition on dimensions which could improve investor welfare. Insurers could leverage the enhanced comparative capabilities arising from the Inline XBRL requirement (as well as the broader informational benefits arising from the summary prospectus and registration statement updating requirements) to better survey the variable contract products offered by their competitors and develop innovations to differentiate their own products from those offered by their competitors. Furthermore, the comparative benefits discussed above could increase further to the extent third-party data aggregators enter the market and use information disclosed in prospectuses to provide consolidated data on variable products, as search and processing costs could be reduced even further for investors. By reducing the costs associated with aggregating data across variable contracts, the Inline XBRL requirements could reduce barriers to entry for third-party data aggregators and induce competition among firms that supply information about variable contracts to investors, including other third-party aggregators and sales agents.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1123</SU>
                             Competitive dynamics are more effective in areas where comparisons can be more easily made. For example, we believe that in the market for mutual funds and exchange-traded funds—particularly index funds—the enhanced comparability provided by mutual fund summary prospectuses and competition, among other factors, have driven down fees significantly. Comparability among index funds that follow the same market index is facilitated in part by their passive style of investing. Actively managed funds that follow the same investment strategy can show different performance due to, among other things, the “skill” of the manager of outperforming the market (or any other benchmark). This skill is unobservable and generally hard to measure, which makes comparisons across actively managed funds difficult. In contrast, comparisons across index funds that follow the same market index and that have passive investment styles are based more on observable variables, such as fees, rather than unobservable variables, such as managerial skill. In this context, disclosure that is more salient with respect to these observable variables may facilitate comparisons across index funds.
                        </P>
                    </FTNT>
                    <P>
                        The effect on competition between insurers could be limited, however, to the extent variable contract investors continue to rely on an agent to help them select and customize their variable contract(s) and do not have access to broad comparisons of variable contracts enabled by the Inline XBRL requirements at the time of sale or during the free look period.
                        <SU>1124</SU>
                        <FTREF/>
                         Agents generally only provide their customers with a subset of the variable contracts available in the general marketplace. Thus, while the product information in summary prospectuses will facilitate comparison across products offered by the agent, the effect will likely be limited to the agent's set of products rather than to the broader market.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1124</SU>
                             
                            <E T="03">See</E>
                             IRI Fact Book, 
                            <E T="03">supra</E>
                             note 16, at 176.
                        </P>
                    </FTNT>
                    <P>We recognize that any fixed costs of compliance with the new requirements, including Inline XBRL requirements, could have a relatively greater impact on small filers. However, the overall magnitude of such costs, discussed in greater detail in Section V below, and thus the magnitude of the associated competitive effects, is expected to be modest.</P>
                    <P>
                        We also considered the potential impact of our position on Alternative Disclosure Contracts on competition between insurers. Above, we discussed the possibility that, because contracts that are not Alternative Disclosure Contracts as of the effective date of the final summary prospectus rules could not provide alternative disclosures after such date, the Commission's position could cause these insurers to experience future costs of disclosure obligations that they may not have anticipated. The Commission's position thus may place at a competitive advantage those insurers with a greater proportion of contracts that may operate under the Commission position.
                        <SU>1125</SU>
                        <FTREF/>
                         We note, however, that Alternative Disclosure Contracts are no longer offered for sale to the public and, therefore, do not compete for investment by new investors. The competitive effect will be limited to additional investment by existing investors in existing Alternative Disclosure Contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1125</SU>
                             One commenter stated that our position on Alternative Disclosure Contracts would create an advantage to insurance companies with large existing bases of variable contract investors. 
                            <E T="03">See</E>
                             Better Markets Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Commenters stated that the Alternative Disclosure Contract framework has enabled insurers to continually innovate and introduce new products for investors.
                        <SU>1126</SU>
                        <FTREF/>
                         One commenter indicated that in the absence of the Alternative Disclosure Contract framework, insurers would be less likely to innovate and offer new products which could, in turn, limit investor choice and dampen competition among insurers.
                        <SU>1127</SU>
                        <FTREF/>
                         As discussed above, however, we generally believe that all variable contract issuers should provide investors the same information and be subject to the same liability standards.
                        <SU>1128</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1126</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter; Brighthouse Comment Letter; Transamerica Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1127</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1128</SU>
                             
                            <E T="03">See</E>
                             Section II.E.3.a.
                        </P>
                    </FTNT>
                    <P>
                        Finally, four commenters stated that our requirement to base certain fee calculations in the Key Information Table on an assumed account balance of $100,000 would put insurers offering variable contracts at a competitive disadvantage to mutual funds which are required to assume a $10,000 balance.
                        <SU>1129</SU>
                        <FTREF/>
                         As we note above, $100,000 more closely approximates the current average value of a variable annuity, and therefore we continue to believe that figure is more likely to result in cost projections that align with actual investor expectations and experience.
                        <SU>1130</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1129</SU>
                             
                            <E T="03">See supra</E>
                             note 132.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1130</SU>
                             
                            <E T="03">See supra</E>
                             note 133. We note also that while variable contracts and mutual funds share certain characteristics, variable contracts provide insurance benefits that mutual funds do not. 
                            <E T="03">See, e.g.,</E>
                             “How is a Variable Annuity Different from a Mutual Fund?” 
                            <E T="03">available at https://irionline.org/consumer-articles/how-is-a-variable-annuity-different-from-a-mutual-fund-</E>
                            . The insurance benefits of variable contracts may limit competition between variable contracts and mutual funds. The extent of competition between insurers and mutual funds depends on the extent to which investors view variable products and mutual funds as substitutes for one another, even though variable contracts provide insurance benefits that mutual funds do not.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Capital Formation.</E>
                         As discussed in connection with the potential effects of the rule on competition, if the rule increases the efficiency of exchange in the variable contracts market, then we may observe a change in investment in variable contracts. Greater investment in variable contracts could lead to increased demand for securities held by the portfolio companies that underlie the variable contracts (or held directly by the separate account in the case of a Form N-3 registrant).
                        <SU>1131</SU>
                        <FTREF/>
                         The increased demand for securities could, in turn, facilitate capital formation.
                        <SU>1132</SU>
                        <FTREF/>
                         Diminished investment, however, could lead to reduced demand for such securities. We expect either of these effects to be small. We further note that to the extent increased or decreased investment in variable contracts reflects substitution from other investment vehicles, the effect on capital formation will be attenuated.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1131</SU>
                             This would be true to the extent funds invested in variable contracts would not otherwise have been invested in securities.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1132</SU>
                             One commenter stated that summary disclosure could facilitate capital formation by enabling consumers to understand the role of variable life insurance and variable annuities in financial and retirement security. 
                            <E T="03">See</E>
                             ACLI Comment Letter.
                        </P>
                    </FTNT>
                    <P>The Inline XBRL requirements could increase the efficiency of capital formation to the extent that making disclosures available in a structured format reduces some of the information barriers that make it costly for variable contract registrants to find new investors. Smaller registrants in particular may benefit more from enhanced exposure to investors. If reporting the disclosures in a structured format increases the availability, or reduces the cost of collecting and analyzing, key information about variable contracts, smaller variable contract registrants may benefit from improved coverage by third-party information providers and data aggregators.</P>
                    <P>
                        To the extent that the rule reduces costs for some variable contract registrants, we expect reduced costs to increase the portion of investor money that is retained as the investor's contract value, rather than used to cover expenses, resulting, over time, in a net positive effect on the level of capital invested through variable contracts. Furthermore, to the extent that reductions in expenses have a positive effect on the performance of variable 
                        <PRTPAGE P="26068"/>
                        contracts and attract new investors or additional capital from existing investors, the rule may result in greater capital formation. We expect this effect to be small.
                    </P>
                    <HD SOURCE="HD2">E. Reasonable Alternatives</HD>
                    <HD SOURCE="HD3">1. Mandating Summary Prospectuses</HD>
                    <P>
                        New rule 498A will provide registrants the option to use the summary prospectus regime the rule establishes. Alternatively, we considered mandating the use of summary prospectuses.
                        <SU>1133</SU>
                        <FTREF/>
                         We expect that use of summary prospectuses will provide net benefits to investors because they are shorter, simpler, and designed to make salient the most important variable contract terms. A mandatory regime would ensure that those benefits are available to all investors, not just those who have invested in variable contracts offered by insurers that would elect to deliver summary prospectuses.
                        <SU>1134</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1133</SU>
                             
                            <E T="03">See supra</E>
                             note 42
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1134</SU>
                             As discussed above, we understand that some investors who prefer statutory prospectuses may experience costs if they are given summary prospectuses and need to request statutory prospectuses. Under a mandatory regime, this cost would be borne by all investors who prefer statutory prospectuses, not just those who have invested in variable contracts offered by insurers that would elect to deliver summary prospectuses. Regardless, as noted above, we believe the number of investors who would prefer statutory prospectuses, as well as the number of insurers that would not elect to deliver summary prospectuses, to be a minority.
                        </P>
                    </FTNT>
                    <P>We believe that insurers will only choose to rely on the optional summary prospectus regime where they expect that the benefits will outweigh the costs. While we believe that reliance on the summary prospectus regime will yield cost savings for insurers, we acknowledge that these cost savings will vary across insurers and there may be insurers that do not expect benefits in excess of the expected costs of relying on summary prospectuses. Registrants will likely assess the relative benefit of using a summary prospectus based on the types of products they offer and the length of their current prospectuses—as well as the benefit of more concise disclosure to investors—when evaluating whether to opt into the new layered disclosure regime. Imposing a mandatory summary prospectus regime would entail imposing net costs on these insurers.</P>
                    <P>Based on our analysis of cost savings and other efficiencies above, our expectation is that insurers offering variable contracts to new investors will choose to use summary prospectuses. We believe that making reliance on rule 498A optional will give insurers the opportunity to gradually transition to the new summary prospectus regime while minimizing disruption to their current registration and business processes. Given our expectation that most insurers offering variable contracts to new investors will chose to use summary prospectuses, and the anticipated cost-savings and other efficiencies available to insurers that rely on the rule, we do not at this time believe a mandatory approach is necessary to achieve the goals of the variable contract summary prospectus regime.</P>
                    <HD SOURCE="HD3">2. Summary Prospectuses Delivered With Statutory Prospectuses</HD>
                    <P>New rule 498A requires the variable contract statutory prospectus, as well as the contract's SAI, to be publicly accessible, free of charge, at a website address specified on the cover of the summary prospectus. As we discuss above, investors who wish to use statutory prospectuses as well as summary prospectuses will bear an additional burden of accessing statutory prospectuses online. Alternatively, the rule could require insurers to provide both summary and statutory prospectuses together in paper or, if the investor has elected to receive the document electronically, in electronic form. This alternative would offer the benefit, for those investors choosing to receive the documents in paper, that any investor wishing to use both summary and statutory prospectuses in his or her decision making would not be required to bear the additional burden of accessing statutory prospectuses online.</P>
                    <P>
                        While providing both summary and statutory prospectuses together would eliminate the necessity of those investors who wish to use both summary and statutory prospectuses having to bear the burden of accessing statutory prospectuses online, we have decided against this alternative for two reasons. First, rather than reducing printing and mailing costs, this alternative would create additional printing and mailing costs. We believe that the increased printing and mailing costs would cause few insurers to choose to provide both summary and statutory prospectuses. Thus, 
                        <E T="03">de facto,</E>
                         the potential benefits of layered disclosure would likely not be available to most investors.
                    </P>
                    <P>
                        Second, summary prospectuses will provide investors with key information relating to the contract's terms, benefits, and risks in a concise and more reader-friendly document. We are concerned that variable contract investors may not read or understand the disclosures they currently receive. If investors were to receive both summary and statutory prospectuses, the increase in materials received could lead to potentially fewer investors reading either of the documents.
                        <SU>1135</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1135</SU>
                             This effect is mitigated to the extent that investors want to receive the additional disclosure. For example, those investors who currently read statutory prospectuses in consideration of their investment decisions may find the incremental burden associated with receiving the additional disclosure in the form of summary prospectuses to be small.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">3. Contract-Specific Updating Summary Prospectuses</HD>
                    <P>
                        The adopted variable contract summary prospectus regime requires that the initial summary prospectus only describe a single contract that the registrant currently offers for sale, but permits an updating summary prospectus to describe more than one contract covered in the statutory prospectus to which the updating summary prospectus relates. Commenters supported the optionality to allow the updating summary prospectus to include multiple contracts under the statutory prospectus to which the summary prospectus relates.
                        <SU>1136</SU>
                        <FTREF/>
                         As an alternative, we considered requiring that the updating summary prospectus describe only a single contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1136</SU>
                             
                            <E T="03">See supra</E>
                             note 344.
                        </P>
                    </FTNT>
                    <P>An updating summary prospectus that describes solely the contract held by an investor could be easier for that investor to consume than an updating summary prospectus that describes more than one contract, and therefore could be more beneficial to investors than the final rule's approach. The magnitude of this increase in benefits depends on the extent to which information about multiple contracts confuses investors or causes investors not to read the information, which, in turn, likely depends on the number of changes to contracts and the number of different contracts that would be presented in the updating summary prospectus.</P>
                    <P>
                        We acknowledge that this alternative would permit investors to easily focus on key information on a single contract. However, we believe this increase in benefits would be limited because, based on our current understanding of variable contracts, there are a limited number of changes to contracts in any given year, and many of those changes (such as changes to the available portfolio companies or the addition of new optional benefits) typically apply to similar contracts in the same prospectus. Accordingly, although the section of the updating prospectus that describes changes to the contracts will 
                        <PRTPAGE P="26069"/>
                        cover multiple contracts, the number of changes concerning any individual contract is expected to be relatively brief, thus minimizing the amount of inapplicable information the investor would read.
                    </P>
                    <P>
                        We do note that under this alternative, an insurer could limit the costs associated with printing and mailing by only delivering those updating summary prospectuses to an investor that holds the contracts they describe. However, such a process would likely entail systems upgrades and changes to back-office operations needed to tailor mailings on an investor-by-investor basis.
                        <SU>1137</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1137</SU>
                             We understand that the process involved in drafting and printing an updating summary prospectus that only describes the changes made to a single contract (and then distributing a tailored updating summary prospectus to each investor based on their particular contract) is quite complex. In contrast, the same process with respect to the initial summary prospectus is relatively straightforward since the document, which would only describe the currently available contract, would be provided all new investors.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">4. Do Not Provide Updating Summary Prospectuses</HD>
                    <P>We considered two closely related alternative approaches to the final summary prospectus regime in which only initial contract purchasers would receive a summary prospectus, and afterwards, investors who make additional purchase payments or who reallocate contract value would either (1) receive no updating summary prospectus or (2) receive only a notice that the statutory prospectus is available online. Such an alternative would likely yield larger cost savings for insurers because insurers would not be required to produce, print, and mail updating summary prospectuses and would instead incur only costs associated with providing the initial summary prospectus when an investor first purchases the contract or reallocates contract value.</P>
                    <P>However, under either of these alternatives, investors would not benefit from the ongoing layered disclosure provided by the updating summary prospectus. As discussed above, the Commission believes that the updating summary prospectus's brief description of any important changes to the contract that occurred within the prior year will allow investors to better focus their attention on new or updated information relating to the contract. Relatedly, the updating summary prospectus includes certain information required in the initial summary prospectus that we consider most relevant to investors when considering additional investment decisions, and investors would not have access to this concise presentation of key information under either alternative.</P>
                    <HD SOURCE="HD3">5. Inline XBRL</HD>
                    <P>
                        The amendments require variable contract registrants to file certain information from statutory prospectuses with the Commission in Inline XBRL. As an alternative, we considered allowing, but not requiring, variable contract registrants to file the information in Inline XBRL. Compared to the amendments, a fully voluntary Inline XBRL program would lower costs for those filers, particularly filers that do not already file information in Inline XBRL.
                        <SU>1138</SU>
                        <FTREF/>
                         However, a voluntary program would reduce the usability of the required data. If information was not submitted by the registrant in a structured, machine-readable format, investors and other data users who wish to instantly analyze, aggregate, and compare the data would be required to incur the costs of paying a third-party provider to manually rekey the data, review the data for data quality problems during the duplication process, and disseminate the data to the users. Alternatively, investors or data users unwilling to pay a third-party provider would incur the time to conduct that process themselves. In either scenario, the data would not be usable in as timely a manner as if it were made machine-readable. In addition, under a voluntary program, data that is not submitted in Inline XBRL would not be validated in EDGAR. Validations are technical restrictions that test for completeness of the data and that the data is appropriately formatted. Validations enable the Commission to ensure consistency of the data so that the disclosures can be immediately used for aggregation, comparison, and analysis. Without validations, data would likely be submitted inconsistently, thus decreasing the overall data quality of the data submitted. Poor data quality reduces any data user's ability to meaningfully analyze, aggregate, and compare data.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1138</SU>
                             In expressing support for the availability of hardship exemptions for Inline XBRL tagging, one commenter stated, “Generally speaking, it could be helpful to conceive of a transition from voluntary to mandated use, especially with respect to smaller organizations for which implementation could potentially be unduly burdensome.” 
                            <E T="03">See</E>
                             Chemas Comment Letter.
                        </P>
                    </FTNT>
                    <P>Under the amendments, filing the information in Inline XBRL will be required for the Key Information Table, Fee Table, Principal Risks of Investing in the Contract, Standard Death Benefits (for Form N-6), Benefits Available Under the Contract (for Forms N-3 and N-4), Other Benefits Available Under the Contract (for Form N-6), Portfolio Companies Available Under the Contract (for Forms N-4 and N-6), Investment Options Available Under the Contract (for Form N-3), and Additional Information about Investment Options Available Under the Contract (for Form N-3). The information required to be filed in Inline XBRL largely parallels the information that is required of mutual funds and ETFs, and we believe it is likely to be of greatest utility for investors and others that seek to use the information in a structured format to assist with decisions about variable products.</P>
                    <P>As another alternative, we considered requiring variable contract registrants to submit all, or a larger subset, of the information from the statutory prospectus, rather than only the information covered by the amendments, in Inline XBRL. Compared to the amendments, this alternative would improve the timeliness and usability of the required disclosures, but potentially impose additional costs on registrants. To the extent that the other required disclosures in the affected forms contain information that is more specific to individual registrants without any comparability or aggregation utility, the benefits of having those additional required disclosures in a structured format may be lower than the more limited subset of disclosures required to be filed in Inline XBRL under the amendments.</P>
                    <P>
                        Under the proposal, the Inline XBRL requirement would have applied to all variable contracts. As discussed above, under the amendments, the Inline XBRL requirement will not apply to contracts that are not being sold to new investors.
                        <SU>1139</SU>
                        <FTREF/>
                         One commenter who opposed the requirement to tag such contracts stated, “Inline XBRL is primarily designed to help investors and other market participants compare investments and decide which, if any, to buy. Applying the Inline XBRL requirements to insurance contracts no longer being sold would impose unnecessary costs and burdens on insurers without providing any benefit to investors.” 
                        <SU>1140</SU>
                        <FTREF/>
                         Other commenters emphasized the need for all filers to structure disclosures in the Inline XBRL format, and noted that comparability of information would be impaired if only some products reported data in 
                        <PRTPAGE P="26070"/>
                        structured format.
                        <SU>1141</SU>
                        <FTREF/>
                         We agree that applying the Inline XBRL requirements to contracts no longer being sold to new investors could provide some additional benefit to investors by expanding the overall comparability of variable contracts, however as discussed below, we believe this additional benefit would be limited and would not justify the additional tagging costs to filers because such contracts do not represent potential investment targets for new investors.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1139</SU>
                             
                            <E T="03">See supra</E>
                             Section II.D.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1140</SU>
                             
                            <E T="03">See</E>
                             CAI Comment Letter.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1141</SU>
                             
                            <E T="03">See</E>
                             XBRL US Comment Letter; Better Markets Comment Letter.
                        </P>
                    </FTNT>
                    <P>
                        Requiring filers to structure contracts that are not being sold to new investors on an ongoing basis would impose additional costs on filers each year, although we expect such costs would be limited. As discussed in further detail below, a significant portion of the costs to filers associated with the tagging requirement will be incurred the first time a registration statement for the contract is filed.
                        <SU>1142</SU>
                        <FTREF/>
                         Furthermore, prospectuses for contracts that become discontinued after the effective date of the amendments are unlikely to materially change from year to year.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1142</SU>
                             
                            <E T="03">See infra</E>
                             Section V.D.
                        </P>
                    </FTNT>
                    <P>
                        Existing investors in a contract that is not being sold to new investors often consider various investment decisions that would likely derive some benefit from analysis facilitated by Inline XBRL tagging. For example, such investors may decide to make additional investments in the contract, purchase different optional benefits available under the contract, or reallocate value among the contract's investment options. In addition, as discussed above, investors in a contract that is not being sold to new investors may consider whether to accept a buyout offer from their insurer or exchange their current contract for a new contract with different optional benefits.
                        <SU>1143</SU>
                        <FTREF/>
                         In such instances, having their contract's disclosures available in structured format could benefit investors by simplifying the comparison of their current contract to other available contracts. However, these investors would likely already be familiar with the disclosures in their contracts, and would only need to compare those disclosures to the disclosures in other currently offered contracts, which will be tagged in Inline XBRL and therefore suitable for instant comparison and analysis. Thus, the benefit to investors of tagging disclosures in contracts that are not being offered to new investors is significantly lower than the benefit to investors of tagging contracts that are being offered to new investors. In addition, while Inline XBRL does facilitate comparisons across reporting periods, investors would derive a related benefit from the Inline XBRL tagging of contracts that are not being sold to new investors only to the extent they find historical information of what was formerly offered to be useful in their review of currently offered products.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1143</SU>
                             
                            <E T="03">See supra</E>
                             Section II.D.
                        </P>
                    </FTNT>
                    <P>
                        The proposed amendments would have provided filers with an 18-month transition period after the effective date of the amendments to give registrants sufficient time to update their prospectuses and to prepare new registration statements that comply with the amendments, including with the Inline XBRL tagging requirement. As discussed in Section II.G above, in a departure from the proposal, the new rule includes an additional 12-month transition period for compliance with the Inline XBRL tagging requirement. Compared to the proposed amendments, this additional transition period will permit filers to defer Inline XBRL compliance costs and may ease the transition for filers, particularly smaller filers and filers that encounter challenges in acquiring expertise and software solutions needed to prepare Inline XBRL filings.
                        <SU>1144</SU>
                        <FTREF/>
                         However, the longer transition period will also defer the benefits of making the information available in a structured format to investors in variable contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1144</SU>
                             As noted in Section IV.C.3 above, some evidence suggests that, for operating companies, the costs of tagging in XBRL format have decreased over time. 
                            <E T="03">See supra</E>
                             note 1107. To the extent this trend applies to Inline XBRL tagging of variable contract registration statements, providing an additional 12-month transition period may impose lower initial tagging costs compared to the proposal.
                        </P>
                    </FTNT>
                    <P>As another alternative, we considered requiring the disclosures to be filed in another structured format, such as the XBRL or XML format. Compared to the Inline XBRL requirement, the use of the XBRL format entails complete duplication of the data, which can adversely affect the quality and usability of the structured data as well as the efficiency and cost of preparation and review of the structured data. Compared to the requirement to use Inline XBRL, the alternative to requiring the use of XML could have resulted in lower costs for filers. However, compared to the amendments, XML would have provided less flexibility in tagging complex information as well as less extensive data quality validation capabilities. In addition, neither the XBRL nor XML options are human-readable. As a result, investors and other data users would not have the benefits of having a document that is both machine-readable and human-readable, or the benefits of using an inline viewer when accessing the filing, such as enhanced search features, filtering capabilities, and built-in definitional references. Investors and other data users would have needed to access two different documents to view and analyze the same data. Filers would also have diminished data quality benefits. Because Inline XBRL embeds structured data directly into an HTML document, filers will not need to review a separate structured data document to identify and correct data quality errors. Moreover, by using an Inline XBRL viewer, filers can more easily identify discrepancies in their data before filing.</P>
                    <HD SOURCE="HD3">6. Alternatives to Form N-3, N-4, and N-6 Amendments</HD>
                    <P>The Commission is adopting amendments to Forms N-3, N-4, and N-6. Collectively, these amendments are meant to update and enhance the disclosures to investors in variable annuity contracts, and to implement the summary prospectus regime.</P>
                    <P>We considered adopting a subset of the amendments to the registration forms. Fewer amendments to the registration forms could be less costly for registrants, because registrants would be required to make fewer changes to their disclosure. However, the adopted form amendments also simplify certain current disclosure requirements, and so the net economic effects of proposing only a subset of the amendments depends on the particular subset of amendments. As described in Section II.C above, we believe that the form amendments that we have adopted promote investor understanding of variable contracts by presenting information in a clear manner and by reflecting industry developments. Requiring only a subset of these amendments could result in less investor understanding relative to the understanding resulting from the adopted amendments.</P>
                    <P>
                        Additionally, the Commission is adopting a new General Instruction in each of Forms N-3, N-4, and N-6 to encourage the use of disclosure effectiveness principles in variable contract disclosure. Specifically, General Instruction C.3.(c) in each form encourages registrants to use, as appropriate, question-and-answer presentations, tables, side-by-side comparisons, captions, bullet points, numeric examples, illustrations or similar presentation methods.
                        <SU>1145</SU>
                        <FTREF/>
                         We considered mandating the use of these 
                        <PRTPAGE P="26071"/>
                        presentation methods. Investors might gain a clearer understanding of the features and risks of variable contracts as a result. We are concerned, however, that mandating a particular presentation method (besides the presentation methods that the form amendments specifically require) could provide less flexibility to registrants to describe variable contracts in the manner they think is most appropriate. Moreover, there could be a risk that mandating the use of certain presentation methods could unintentionally obscure, or not clearly explain, certain variable contract features and risks.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1145</SU>
                             
                            <E T="03">See supra</E>
                             note 597.
                        </P>
                    </FTNT>
                    <P>
                        Also, we are adopting a requirement that the Key Information Table include cross-references to the location in the statutory prospectus where the subject matter is described in greater detail (and that cross-references in electronic versions of the summary prospectus and/or statutory prospectus should link directly to the location in the statutory prospectus where the subject matter is discussed in more detail, or should provide a means of facilitating access to that information through equivalent methods or technologies). As an alternative to this instruction, we considered requiring that, where a topic is summarized in the statutory prospectus and is discussed in more detail elsewhere in the statutory prospectus, the summarized topic must include a cross-reference (and a hyperlink in electronic document versions) to the location in the statutory prospectus where the topic is discussed in more detail. This alternative requirement would make use of the layered disclosure approach that underlies the rulemaking proposal in a manner that could make information in the prospectus more accessible to investors and leverage technology in a way that could further assist investors in navigating the prospectus. We believe, however, that adding additional cross-references and hyperlinks would increase costs for insurers and could lead to greater uncertainty among registrants about where cross-references and hyperlinks are required (
                        <E T="03">i.e.,</E>
                         whether a topic is summarized in one part of the prospectus and then discussed in more detail later could be viewed as a subjective determination). Further, the benefits of cross-references and hyperlinks might be limited, given that rule 498A will require electronic versions of the statutory prospectus to include a table of contents that would allow the reader to move directly between it and the related sections of the document.
                    </P>
                    <HD SOURCE="HD3">7. Requiring All Variable Contracts (Including Eligible Contracts) To Prepare Updated Registration Statements and Deliver Statutory or Summary Prospectuses</HD>
                    <P>
                        Instead of permitting Eligible Contracts to operate under the Commission position, we considered requiring issuers of all contracts to prepare updated registration statements and comply with either the current standard prospectus delivery requirements or the optional summary prospectus regime. In this scenario, investors in Eligible Contracts would receive the statutory prospectus or the optional updating summary prospectuses, while continuing to have access (either upon request or online, under the summary prospectus regime) to financial statements. As explained in detail above, the optional summary prospectus regime, if relied on, provides significant additional benefits for investors in terms of facilitating the review and understanding of available disclosures.
                        <SU>1146</SU>
                        <FTREF/>
                         At the same time, the optional summary prospectus regime also permits insurers to satisfy delivery obligations for the underlying company prospectuses by making those documents available online, which could create a burden for investors who prefer to use those prospectuses when making allocation decisions and who would have been sent those documents as part of the Alternative Disclosures.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1146</SU>
                             
                            <E T="03">See supra</E>
                             Section IV.C.1.a.i.(a).
                        </P>
                    </FTNT>
                    <P>
                        With respect to the impact on insurers, under this alternative, issuers of Eligible Contracts could incur significant costs to update their registration statements under the new form requirements, most of which have not been updated for many years.
                        <SU>1147</SU>
                        <FTREF/>
                         These costs could vary, including based on the period of time since the insurer had last updated the relevant registration statement. In addition, insurers would bear the ongoing costs associated with maintaining an effective registration statement and sending investors documents under the current standard prospectus delivery requirements or the optional summary prospectus regime. We expect these costs would exceed the costs associated with providing investors with the Alternative Disclosures or modernized alternative disclosures particularly when combined with electronic delivery of underlying portfolio company prospectuses.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1147</SU>
                             
                            <E T="03">See supra</E>
                             Section II.E.2.
                        </P>
                    </FTNT>
                    <P>
                        On balance, given the burdens associated with preparing an updated registration statement and compliance with either standard prospectus delivery requirements or the optional summary prospectus regime, Eligible Contracts may operate in the manner discussed above.
                        <SU>1148</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1148</SU>
                             
                            <E T="03">See supra</E>
                             Section II.E.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">8. Alternative Approaches to Discontinued Contracts</HD>
                    <P>
                        The Commission is declining to extend its position to contracts that are not Eligible Contracts. For Eligible Contracts, the Commission position will allow insurers to choose whether to provide Alternative Disclosures or modernized alternative disclosures.
                        <SU>1149</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1149</SU>
                             
                            <E T="03">See supra</E>
                             Section II.E.3. Alternatively, issuers of currently discontinued contracts could choose to begin using the summary prospectus framework.
                        </P>
                    </FTNT>
                    <P>
                        We considered and received comment on two alternative approaches; each alternative approach could have been implemented only on a going forward basis or for all contracts, including Eligible Contracts.
                        <SU>1150</SU>
                        <FTREF/>
                         For Method 1, under which each approach would be applied only on a going forward basis for contracts that become discontinued in the future, we analyze the costs and benefits of each approach relative to the adopted summary prospectus framework. For Method 2, under which each approach would also be applied to Eligible Contracts, we analyze the costs and benefits of each approach relative to the options under Commission position. In addition to these economic impacts to existing contracts, the costs and benefits of these approaches could also affect the development of new variable contracts in the future. For example, to the extent that an approach represents additional costs/cost savings associated with a variable contract relative to the adopted rule, these alternative approaches could result in higher/lower fees and charges for future variable contracts. Similarly, these relative costs and benefits may affect insurers' willingness to develop and offer new variable products.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1150</SU>
                             
                            <E T="03">See supra</E>
                             note 939.
                        </P>
                    </FTNT>
                    <P>
                        For the reasons described above, the Commission is declining to adopt either alternative and believes that it will benefit from further study and data regarding the potential cost savings and other burden reductions under Approach 2.
                        <SU>1151</SU>
                        <FTREF/>
                         We welcome input from the public as we undertake this further study.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1151</SU>
                             
                            <E T="03">See supra</E>
                             Section II.E.4.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">a. Approach 1</HD>
                    <P>
                        Approach 1 would codify existing practices under the Staff Letters with 
                        <PRTPAGE P="26072"/>
                        certain modifications.
                        <SU>1152</SU>
                        <FTREF/>
                         The Commission could have implemented Approach 1 only on a going forward basis (Method 1) or for all contracts, including Eligible Contracts (Method 2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>1152</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.C.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">i. Method 1</HD>
                    <P>New rule 498A and Approach 1 would require generally the same information to be delivered to investors. For example, Approach 1 would require insurers of discontinued contracts to deliver an annual notice to investors that contains information substantially similar to that included in an updating summary prospectus under 498A. In addition, under both frameworks, portfolio company prospectuses and shareholder reports would be delivered to all investors but insurers could satisfy portfolio company prospectus delivery requirements by making the portfolio company prospectuses available online and delivering them to investors upon request. As a result, we do not believe that Approach 1 would have a substantial effect on the costs incurred by insurers associated with preparing and delivering disclosures to investors in contracts that become discontinued in the future.</P>
                    <P>
                        The summary prospectus framework is a layered disclosure regime, however, with a contract's current statutory prospectus (and certain other information) available online and delivered upon request. This additional information would not be available to investors under Approach 1. Unlike the summary prospectus framework, Approach 1 would also allow issuers of certain contracts that become discontinued in the future to cease maintaining an updated registration statement.
                        <SU>1153</SU>
                        <FTREF/>
                         As a result, investors also would not have access to the more detailed information that would be included in an updated registration statement under the summary prospectus framework but not in the materials delivered to investors or available upon request under Approach 1. Under Approach 1 issuers of certain contracts that become discontinued in the future would face lower costs relative to the summary prospectus framework because they would not be required to maintain an updated registration statement for the duration of the contract.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1153</SU>
                             
                            <E T="03">Id.</E>
                        </P>
                    </FTNT>
                    <P>As a further consequence, under Approach 1 the liability provisions available under the federal securities laws would not apply to the same extent as under the current variable contract prospectus delivery regime and under the summary prospectus regime for registrants that choose to rely on rule 498A. The loss of these liability protections represents a potential cost to investors in contracts that may become discontinued in the future.</P>
                    <HD SOURCE="HD3">ii. Method 2</HD>
                    <P>The Commission could also choose to apply Approach 1 not only to future discontinued contracts but to all contracts, including Eligible Contracts. Under the Commission position, insurers of Eligible Contracts may choose whether to provide Alternative Disclosures or modernized alternative disclosures. Issuers of Eligible Contracts who elect to utilize modernized alternative disclosures may provide investors a notice containing information comparable to that in an updating summary prospectus and post the portfolio company prospectuses, statutory prospectus, SAI, and shareholder reports online in lieu of mailing these materials to investors. This is similar to Approach 1 and therefore, where insurers elect to utilize modernized alternative disclosures, we do not believe that investors or insurers in those contracts would realize additional costs or benefits associated with preparing and delivering disclosures under Approach 1.</P>
                    <P>In contrast, issuers of Eligible Contracts who elect to provide Alternative Disclosures under the Commission position would face additional costs under Approach 1 associated with providing an annual notice to investors. This cost may be mitigated by savings on printing and mailing costs resulting from Approach 1's option to provide portfolio company prospectuses and updated financial statements by posting them on a website. However, investors in these contracts would benefit by receiving the additional information included in the annual notice they would be provided under Approach 1 but would not receive as part of the Alternative Disclosures.</P>
                    <HD SOURCE="HD3">b. Approach 2</HD>
                    <P>
                        Approach 2 would require that insurers maintain an updated registration statement, but would allow financial statements to be forward incorporated by reference into the registration statement.
                        <SU>1154</SU>
                        <FTREF/>
                         The Commission could have implemented Approach 2 only on a going forward basis (Method 1) or for all contracts, including Eligible Contracts (Method 2).
                    </P>
                    <FTNT>
                        <P>
                            <SU>1154</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section II.C.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">i. Method 1</HD>
                    <P>Under Approach 2, the documents insurers would prepare and deliver to investors are similar to those that are prepared and delivered in the summary prospectus framework. As a result, we do not believe that Approach 2 would have a substantial effect on the costs incurred by insurers associated with preparing and delivering disclosures to investors in contracts that become discontinued in the future. Like the summary prospectus framework, Approach 2 would require issuers of discontinued contracts to maintain a current registration statement and to make the statutory prospectus and SAI available online. However, Approach 2 would only require insurers to file post-effective amendments to update their registration statements when there are material changes to the offering, and would allow forward incorporation by reference of updated financial statements in the registration statement. This approach could reduce costs for issuers of future discontinued contracts to the extent that it reduced the number of post-effective amendments compared to the summary prospectus framework.</P>
                    <P>For investors in contracts that may become discontinued in the future, the disclosures that would be delivered to them under Approach 2 are similar to those they will receive under the adopted summary prospectus framework. Further, because the summary prospectus framework and Approach 2 would both require insurers to maintain an updated registration statement for the life of the contract, investors in future discontinued contracts under both frameworks would have access to the more detailed information included in the updated registration statement.</P>
                    <HD SOURCE="HD3">ii. Method 2</HD>
                    <P>
                        The Commission could also choose to apply Approach 2 not only to future discontinued contracts but to all contracts, including Eligible Contracts. If the Commission chose to apply Approach 2 to all contracts, insurers issuing Eligible Contracts would likely face additional costs relative to the Commission position. Issuers of Eligible Contracts who choose to provide modernized alternative disclosures under the Commission position would face similar costs associated with preparing and delivering disclosures to investors under Approach 2, but these insurers would incur an additional cost to bring their registration statement up to date. Insurers who choose instead to 
                        <PRTPAGE P="26073"/>
                        provide Alternative Disclosures under the Commission position would similarly incur costs under Approach 2 to bring their registration statement up to date, as well as the additional cost of providing the notice document. However, Approach 2's option to post portfolio company statements and updated financial statements on a website would likely mitigate these additional costs to insurers that would otherwise opt to provide Alternative Disclosures under the Commission position.
                    </P>
                    <P>Under Approach 2, investors in all Eligible Contracts would benefit from the liability protections of the federal securities laws, which they would not receive under either option under the Commission position. Investors who would receive Alternative Disclosures under the Commission position would further benefit from the disclosures provided in the annual notice they would receive under Approach 2.</P>
                    <HD SOURCE="HD1">V. Paperwork Reduction Act</HD>
                    <P>
                        New rule 498A will result in new “collection of information” requirements within the meaning of the Paperwork Reduction Act of 1995 (“PRA”).
                        <SU>1155</SU>
                        <FTREF/>
                         In addition, the new rule and other amendments will impact the collections of information under Form N-3, Form N-4, Form N-6, and Mutual Fund Interactive Data (which will be retitled as “Investment Company Interactive Data”) within the meaning of the PRA.
                        <SU>1156</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1155</SU>
                             44 U.S.C. 3501-3520.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1156</SU>
                             We recently issued a release that, among other things, proposed to retitle the “Mutual Fund Interactive Data” information collection as “Investment Company Interactive Data.” 
                            <E T="03">See</E>
                             Closed-End Offering Reform Release, 
                            <E T="03">supra</E>
                             note 18.
                        </P>
                    </FTNT>
                    <P>
                        The titles for the existing collections of information are: (1) “Form N-3, Registration Statement under the Securities and Investment Co. Acts for Insurance Co. Separate Accounts Issuing Variable Annuity Contracts” (OMB Control No. 3235-0316); (2) “FormN-4, Registration Statement under the Securities and Investment Co. Acts for Insurance Co. Separate Accounts Issuing Variable Annuity Contracts” (OMB Control No. 3235-0318); (3) “FormN-6 under the Investment Company Act of 1940 and the Securities Act of 1933, Registration Statement of Variable Life Insurance Separate Accounts Registered as Unit Investment Trusts” (OMB Control No. 3235-0503); and “Mutual Fund Interactive Data” (OMB Control No. 3235-0642) (re-titled as “Investment Company Interactive Data”). The title for the new collection of information under rule 498A is “Summary Prospectus for Variable Annuity and Variable Life Insurance Contracts.” 
                        <SU>1157</SU>
                        <FTREF/>
                         The Commission is submitting these collections of information to the Office of Management and Budget (“OMB”) for review in accordance with 44 U.S.C. 3507(d) and 5 CFR 1320.11. An agency may not conduct or sponsor, and a person is not required to respond to, a collection of information unless it displays a currently valid control number.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1157</SU>
                             As discussed above, we are adopting minor revisions to Form N-14. 
                            <E T="03">See supra</E>
                             note 587 and accompanying text. However, such changes do not impact the form's existing collection of information (titled “Form N-14, Registration Statement under the Securities Act of 1933” (OMB Control No. 3235-0337)).
                        </P>
                    </FTNT>
                    <P>
                        We published notice soliciting comments on the collection of information requirements in the Proposing Release and submitted the proposed collections of information to OMB for review in accordance with 44 U.S.C. 3507(d) and 5 CFR 1320.11. We received two comments that discussed our estimates of burdens and costs associated with certain collection of information requirements under the proposal.
                        <SU>1158</SU>
                        <FTREF/>
                         We address these comments below, along with a discussion generally of the collection of information burdens and costs associated with new rule 498A and where applicable, the existing collections of information.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1158</SU>
                             
                            <E T="03">See</E>
                             Broadridge Comment Letter; Memorandum from the Division of Investment Management re: May 29, 2019 meeting with representatives of the Committee of Annuity Insurers (including attachments), 
                            <E T="03">available at</E>
                              
                            <E T="03">https://www.sec.gov/comments/s7-23-18/s72318-5604687-185508.pdf</E>
                            . (“CAI Presentation Materials”).
                        </P>
                    </FTNT>
                    <P>The amendments to Forms N-3, N-4, and N-6 update and enhance the required disclosures provided to variable contract investors. For example, the amendments require registrants to summarize certain key information about the contract at the beginning of the prospectus, as well as update the presentation of fee information and require additional information about standard and optional benefits that a contract may offer. They also standardize presentation requirements to make the information more accessible to retail investors, while retaining key elements of the disclosure that is available today.</P>
                    <P>
                        In addition, we are amending Forms N-3, N-4, and N-6, along with certain rules that effectuate the Commission's requirements regarding the use of Inline XBRL format for the submission of certain required disclosures 
                        <SU>1159</SU>
                        <FTREF/>
                         in variable contract statutory prospectuses. These amendments are intended to harness technology to allow investors (directly and through their investment professionals), data aggregators, financial analysts, Commission staff, and other data users to efficiently analyze and compare the available information about variable contracts.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1159</SU>
                             We are amending rules 485 and 497 of Regulation C (OMB Control No. 3235-0074), which describes the procedures to be followed in preparing and filing registration statements with the Commission, and rules 11 and 405 of RegulationS-T (OMB Control No. 3235-0424), which specifies the requirements that govern the electronic submission of documents. The additional collection of information burden that will result from these changes, as well as the burdens that we estimate will result from the amendments to the General Instructions of Forms N-3, N-4, and N-6, are included in our estimates for the “Investment Company Interactive Data” collection of information.
                        </P>
                    </FTNT>
                    <P>New rule 498A permits a person to satisfy its prospectus delivery obligations under the Securities Act for a variable contract by providing a summary prospectus to investors and making the statutory prospectus available online. The rule also will consider a person to have met its prospectus delivery obligations for any portfolio companies associated with a variable contract if these prospectuses are posted online. Pursuant to the rule, registrants using a summary prospectus also are required to send these documents to investors upon request.</P>
                    <P>Finally, the amendments to rule 497 provide the requirements for filing summary prospectuses with the Commission and for submitting information to the Commission in Inline XBRL format. These amendments do not constitute a separate collection of information under rule 497. The burden required by these amendments is part of the collection of information under new rule 498A, and for filings of Interactive Data Files, are part of the “Investment Company Interactive Data” collection of information.</P>
                    <HD SOURCE="HD2">A. Form N-3</HD>
                    <P>Form N-3 is the form used by separate accounts offering variable annuity contracts that are organized as management investment companies to register under the Investment Company Act and/or to register and offer their securities under the Securities Act. Form N-3 contains collection of information requirements. Compliance with the disclosure requirements of Form N-3 is mandatory. Responses to the disclosure requirements are not confidential.</P>
                    <P>
                        Form N-3 generally imposes two types of reporting burdens on investment companies: (1) The burden of preparing and filing the initial registration statement; and (2) the burden of preparing and filing post 
                        <PRTPAGE P="26074"/>
                        effective amendments to a previously effective registration statement. The hour and cost burden estimates for preparing and filing initial registration statements and post-effective amendments on Form N-3 are based on the Commission's experience with the contents of the form. The number of burden hours and cost may vary depending on, among other things, the complexity of the filing and whether preparation of the form is performed by internal staff or outside counsel. We currently estimate for Form N-3 a total of 2,518 internal burden hours, with a total annual external cost burden of $164,144.
                        <SU>1160</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1160</SU>
                             These estimates are included in Form N-3's current information collection, which was approved in July 2019 and reflects the adoption of certain form amendments associated with rule 30e-3 under the Investment Company Act. 
                            <E T="03">See</E>
                             Investment Company Shareholder Reports Release, 
                            <E T="03">supra</E>
                             note 19. 
                        </P>
                        <P> We currently estimate that registrants spend 922.7 internal burden hours per investment option to prepare and file an initial registration statement on Form N-3, and 156.2 internal burden hours per investment option for each post-effective amendment. We also estimate that Form N-3 registrants spend $24,873 in external costs per investment option for each initial filing, and $10,259 per investment option for each post-effective amendment.</P>
                    </FTNT>
                    <P>
                        We are adopting amendments to Form N-3 to update and enhance the disclosures to investors in variable annuity contracts, and to implement the new summary prospectus regime. We are amending certain disclosures that Form N-3 currently requires with respect to the separate account's investment objectives and risks, management of the registrant, investment advisory and other services, portfolio managers, and brokerage allocation and other practices. In addition, amended Form N-3 requires certain new disclosures regarding, among other things: The Key Information Table, an overview of the contract, principal risks, optional benefits, loans, and the Appendix of available investment options. We are also reducing or eliminating certain disclosures currently required by the form, such as the AUV tables.
                        <SU>1161</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1161</SU>
                             
                            <E T="03">See supra</E>
                             Section II.C.2.e.
                        </P>
                    </FTNT>
                    <P>
                        The table below summarizes the estimated adjustments to the Form N-3 collection of information from the proposed amendments,
                        <SU>1162</SU>
                        <FTREF/>
                         the estimated adjustments to the Form N-3 collection of information from the final amendments, and the final PRA estimates for internal and external burdens associated with amended Form N-3:
                    </P>
                    <FTNT>
                        <P>
                            <SU>1162</SU>
                             As part of these estimates, Commission staff estimated that there would be no initial filings and eight post-effective amendments on Form N-3 per year, and further estimated that these filings would be made by five registrants covering an average of three investment options per filing. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section IV.A for more detail regarding the proposed estimates.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="551">
                        <PRTPAGE P="26075"/>
                        <GID>ER01MY20.006</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="450">
                        <PRTPAGE P="26076"/>
                        <GID>ER01MY20.007</GID>
                    </GPH>
                    <HD SOURCE="HD3">Changes to Burden Estimates Resulting From Final Amendments</HD>
                    <P>
                        We did not receive public comment on our proposed PRA estimates for the amendments to Form N-3, which we are adopting largely as proposed. With one exception, we generally believe the modifications to the proposed amendments in the aggregate do not result in changes to our proposed estimates of the effect of the amendments on the current burdens. We believe, however, that registrants will experience a reduction in internal hourly burdens due to the elimination of the requirement to provide AUV tables and are reducing the estimated hourly burden to prepare and file a post-effective amendment by 5 hours per investment option.
                        <SU>1163</SU>
                        <FTREF/>
                         We are also revising our estimates to reflect current figures for the number of Form N-3 registration statements filed annually and updated internal wage rates,
                        <SU>1164</SU>
                        <FTREF/>
                         as set forth in the table above.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1163</SU>
                             We assume that removing the requirement to disclose AUV tables will largely impact the internal burdens associated with post-affective amendments (certain initial filings may provide AUV tables, but the form currently and as amended generally requires AUV tables in all post-effective amendments).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1164</SU>
                             The $269 wage rate reflects current estimates of the blended hourly rate for an in-house compliance attorney ($365) and intermediate accountant ($172), which is derived from SIFMA's Management &amp; Professional Earnings in the Securities Industry 2013 (modified to account for an 1,800-hour work year; multiplied by 5.35 to account for bonuses, firm size, employee benefits and overheard, and adjusted for inflation). 
                        </P>
                        <P>The Proposing Release estimates were based on a blended hourly rate for an in-house compliance attorney and a senior programmer. Because we believe an intermediate accountant is more likely to assist in the preparation of a registration statement than a senior programmer, the wage rate estimate reflects this change in professional positions.</P>
                    </FTNT>
                    <P>
                        <E T="03">Initial registration statements.</E>
                         As proposed, we estimate that the amendments will result in the following changes to the internal hours and external cost burdens:
                    </P>
                    <P>
                        • For disclosures that are not related to the contract's investment options, an additional 1.7 hours per initial registration statement.
                        <SU>1165</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1165</SU>
                             We estimate, as proposed, that the amendments to Form N-3 will increase the burden of preparing an initial registration statement by 5 hours per investment option per filing, which amortized over 3 years equals 1.7 hours annually (5 hours + 0 hours + 0 hours)/3 years = 1.7 hours per year (we assume 0 hours in years 2 and 3 because after year 1, the registrant will prepare and file post effective amendments)). As Commission 
                            <PRTPAGE/>
                            staff estimates that no initial registration statements will be filed on Form N-3 in the next 3 years, we continue to estimate a 0 hour burden for initial registration statement filings.
                        </P>
                    </FTNT>
                    <PRTPAGE P="26077"/>
                    <P>
                        • For disclosures related to the contract's investment options, an additional 2 hours per investment option per initial registration statement.
                        <SU>1166</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1166</SU>
                             We estimate, as proposed, that the amendments to Form N-3 will require an additional 6 hours per investment option per initial filing, which amortized over 3 years equals 2 hours annually on a per investment option basis: (6 hours + 0 hours + 0 hours)/3 years = 2 hours per year. We assume 0 hours in years 2 and 3 because after year 1, the registrant will prepare and file post effective amendments.
                        </P>
                    </FTNT>
                    <P>• We estimate no change to the external cost burden due to the amendments.</P>
                    <P>
                        • Unrelated to the amendments, we estimate an external cost burden of $20,300 per initial registration statement to provide disclosures other than those related to the contract's investment options, and an additional $8,291 per investment option per initial registration statement to provide disclosures that are related to the contract's investment options. This reflects a change in our methodology regarding how to calculate burdens attributable to investment options.
                        <SU>1167</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1167</SU>
                             We currently estimate the external cost to prepare and file an initial registration statement on Form N-3 is $24,873 per investment option. 
                            <E T="03">See supra</E>
                             note 1160. 
                        </P>
                        <P>
                             As discussed in the Proposing Release, in our most recently approved PRA submission, we estimated that a registrant with multiple investment options would experience a burden of complying with the requirements of Form N-3 that is proportional to the number of investment options that the registrant offers. 
                            <E T="03">See supra</E>
                             note 6 at n.777. Since many of the disclosure requirements of Form N-3 do not depend on the number of investment options offered by the registrant, we are revising our approach to estimate an incremental burden per investment option (as opposed to a burden that is proportional to the number of investment options that the registrant offers). Pursuant to this change in methodology, we estimate the cost to prepare and file an initial registration statement on Form N-3 will be $24,873 for disclosures not related to the contract's investment options, and an additional $8,291 per investment option (or 
                            <FR>1/3</FR>
                             of the cost to provide non-investment option-related disclosures) to provide disclosures related to each investment option: $24,873/3 = $8,291. As we estimate no initial registration statements will be filed on Form N-3, we continue to estimate $0 in external costs for initial registration statement filings.
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Post-effective amendments.</E>
                         As proposed, we estimate that the amendments will result in the following changes to the internal hours and external cost burdens:
                    </P>
                    <P>
                        • For disclosures that are not related to the contract's investment options, a one-time burden of 20 hours per registration statement the first time the registration statement is amended and an ongoing burden of an additional 5 hours per registration statement per year thereafter. Amortizing these burdens over a three-year period results in an estimated average annual burden of 10 hours per initial registration statement.
                        <SU>1168</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1168</SU>
                             (20 hours in year 1 + 5 hours in year 2 + 5 hours in year 3)/3 years = 10 hours per year.
                        </P>
                    </FTNT>
                    <P>
                        • For disclosures related to the contract's investment options other than the AUV table requirement, a one-time burden of 6 hours per investment option the first time the registration statement is amended by post-effective amendment. Subsequently, we estimate an ongoing burden of 1.5 hours per investment option per post-effective amendment. Amortizing these burdens over a three-year period results in an estimated average annual burden of 3 hours per investment option to prepare and file a post-effective amendment.
                        <SU>1169</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1169</SU>
                             (6 hours in year 1 + 1.5 hours in year 2 + 1.5 hours in year 3)/3 years = 3 hours per year.
                        </P>
                    </FTNT>
                    <P>• For elimination of the AUV table requirement, we estimate a reduction in the annual hour burden of 5 hours per investment option per year. Adding this reduction to the burden increases discussed in the prior bullet point results in a net reduction of 2 hours per investment option per year for disclosures related to the contract's investment options.</P>
                    <P>• We estimate no change to the external cost burden due to the amendments.</P>
                    <P>
                        • Unrelated to the amendments, we estimate an external cost burden of $10,259 per post-effective amendment to update disclosures not related to investment options, and an additional $3,420 per investment option per post-effective amendment to update disclosures that are related to the contract's investment options. This reflects a change in our methodology regarding how to calculate burdens attributable to investment options.
                        <SU>1170</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1170</SU>
                             
                            <E T="03">See supra</E>
                             note 1167 (regarding change in methodology). We currently estimate $10,259 per investment option for each post-effective amendment. 
                            <E T="03">See supra</E>
                             note 1160.
                        </P>
                    </FTNT>
                    <P>
                        In the aggregate, we estimate the total annual hour burden to comply with amended Form N-3 to be 2,836 hours,
                        <SU>1171</SU>
                        <FTREF/>
                         at an average time cost of $762,884.
                        <SU>1172</SU>
                        <FTREF/>
                         We also estimate the total external cost burden to comply with amended Form N-3 to be $123,114.
                        <SU>1173</SU>
                        <FTREF/>
                         These estimates reflect the change in our methodology for estimating burdens attributable to investment options, the increase in estimated burdens associated with the amendments, the increase in the estimated average number of investment options per Form N-3 registration statement from two to three investment options, and current estimates for the number of post-effective amendments filed annually.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1171</SU>
                             0 initial registration statements + ((156.2 hours (current burden per post-effective amendment) + (10 hours for amendments not related to investment options ÷ 3 investment options) + (3 hours per investment option for amendments related to investment options other than elimination of AUV table requirement)—(5 hours per investment option for elimination of the AUV table requirement)) × 3 investment options per post-effective amendment × 6 post-effective amendments = 2,836 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1172</SU>
                             2,836 hours × $269/hour = $762,884.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1173</SU>
                             0 initial registration statements + ($10,259 per post-effective amendment to update disclosures not related to investment options + ($3,420 per investment option to update disclosures related to investment options × 3 investment options)) × 6 post-effective amendments = $123,114.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">B. Form N-4</HD>
                    <P>Form N-4 is the form used by separate accounts offering variable annuity contracts that are organized as unit investment trusts to register under the Investment Company Act and/or to register and offer their securities under the Securities Act. Form N-4 contains collection of information requirements. Compliance with the disclosure requirements of Form N-4 is mandatory. Responses to the disclosure requirements are not confidential.</P>
                    <P>
                        Form N-4 generally imposes two types of reporting burdens on investment companies: (1) The burden of preparing and filing the initial registration statement; and (2) the burden of preparing and filing post effective amendments to a previously effective registration statement. The hour and cost burden estimates for preparing and filing initial registration statements and post-effective amendments on Form N-4 are based on the Commission's experience with the contents of the form. The number of burden hours and cost may vary depending on, among other things, the complexity of the filing and whether preparation of the form is performed by internal staff or outside counsel. We currently estimate for Form N-4 a total of 271,914 internal burden hours, with a total annual external cost burden of $32,111,916.
                        <SU>1174</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1174</SU>
                             These estimates are included in Form N-4's current information collection, which was approved in July 2019 and reflects the adoption of certain form amendments associated with rule 30e-3 under the Investment Company Act. 
                        </P>
                        <P> We currently estimate that on a per filing basis, registrants spend 278.5 internal burden hours to prepare and file an initial registration statement on Form N-4, and 197.25 internal burden hours for each post-effective amendment. We also estimate that registrants incur $23,013 in external costs for initial filings and $21,813 for post-effective amendments. As discussed below, we are adjusting some of these estimates.</P>
                    </FTNT>
                    <P>
                        We are adopting amendments to Form N-4 to update and enhance the disclosures to investors in variable annuity contracts, and to implement the new summary prospectus regime. We 
                        <PRTPAGE P="26078"/>
                        are amending certain disclosure requirements that Form N-4 currently requires. In addition, amended Form N-4 requires certain new disclosures regarding, among other things: The Key Information Table, an overview of the contract, principal risks, optional benefits, loans, and the Appendix of available portfolio companies. We are also reducing or eliminating certain disclosures currently required by the form, such as the AUV tables.
                    </P>
                    <P>
                        The table below summarizes the estimated adjustments to the Form N-4 collection of information from the proposed amendments,
                        <SU>1175</SU>
                        <FTREF/>
                         the estimated adjustments to the Form N-4 collection of information from the final amendments, and the final PRA estimates for internal and external burdens associated with amended Form N-4:
                    </P>
                    <FTNT>
                        <P>
                            <SU>1175</SU>
                             As part of these estimates, Commission staff estimated that there would be 35 initial filings and 1,326 post-effective amendments on Form N-4 per year. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section IV.B for more detail regarding the proposed estimates.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="592">
                        <PRTPAGE P="26079"/>
                        <GID>ER01MY20.008</GID>
                    </GPH>
                    <HD SOURCE="HD3">Changes to Baseline Burden Estimates</HD>
                    <P>
                        We received one comment regarding our proposed estimates for internal burdens and external costs associated with the current burdens associated with preparing and filing a post-effective amendment.
                        <SU>1176</SU>
                        <FTREF/>
                         The estimates that were submitted were in some respects higher, and in others lower, 
                        <PRTPAGE P="26080"/>
                        than our proposed estimates.
                        <SU>1177</SU>
                        <FTREF/>
                         In light of the commenter's estimates, and because variable annuity contracts registered on Form N-4 today tend to offer greater numbers of portfolio companies and optional benefits than variable annuity contracts offered in the past, we believe that certain of our current estimates may be too low. Therefore, we are adjusting the baseline current estimates (before the effect of the amendments we are adopting) for certain burdens and costs associated with Form N-4,
                        <SU>1178</SU>
                        <FTREF/>
                         as follows:
                    </P>
                    <FTNT>
                        <P>
                            <SU>1176</SU>
                             
                            <E T="03">See</E>
                             CAI Presentation Materials 
                            <E T="03">supra</E>
                             note 1158. These estimates were supplied to illustrate the disparity between the burdens associated with filing a post-effective amendment compared to the reduced burdens for registrants that rely on the Great-West no-action letters. Because only Form N-4 and N-6 filers have received Great-West no-action relief, we assume the commenter's estimates only concern amendments filed on those forms.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1177</SU>
                             
                            <E T="03">See supra</E>
                             notes 6 and 1176. The commenter estimated that “based on information provided by certain members, internal business and legal teams spend approximately 310 hours in connection with the update of a single active registration statement” with associated “soft costs” (internal costs) of $25,000 and “hard costs” described as “outside counsel, auditor, typesetting and mailing,” estimated to be an average of $170,000.” 
                        </P>
                        <P>
                             Our current estimates for Form N-4 are based on previously approved estimates that assume a registrant's in-house staff spends 197.25 internal burden hours to prepare and file a post-effective amendment (for an internal cost of $56,019 per filing based on the $284 wage rate used in the most-recently approved PRA (July 2019)), with external costs (
                            <E T="03">e.g.,</E>
                             outside counsel, independent auditors, consultants) of $21,813 for each filing. 
                            <E T="03">See supra</E>
                             note 1174.
                        </P>
                        <P>
                             We note that the commenter's estimates for external costs include typesetting and printing and mailing, while our estimates for our registration forms do not because the forms do not impose a delivery requirement. The obligation to deliver a prospectus is imposed by Section 5(b)(2) of the Securities Act. 
                            <E T="03">See United States</E>
                             v. 
                            <E T="03">Wunder,</E>
                             919 F.2d 34, 38 (6th Cir. 1990) (“The Paperwork Reduction Act therefore, does not apply to the statutory requirement, but only to the forms themselves.”).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1178</SU>
                             
                            <E T="03">See supra</E>
                             note 1174.
                        </P>
                    </FTNT>
                    <P>
                        • We are increasing our estimate to prepare and file an initial registration statement from 278.5 hours to 800 hours per filing; 
                        <SU>1179</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1179</SU>
                             We are also increasing this estimate for consistency with the currently approved estimates for initial registration statements on Form N-3 (922.7 hours per investment option per filing) and Form N-6 (770.25 hours per filing).
                        </P>
                    </FTNT>
                    <P>• We are increasing our estimate to prepare and file a post-effective amendment from 197.25 hours to 227.25 per filing; and</P>
                    <P>• We are increasing our estimate of the external cost to prepare and file an initial registration statement from $23,013 to $40,000 per filing.</P>
                    <HD SOURCE="HD3">Changes to Burden Estimates Resulting From Final Amendments</HD>
                    <P>
                        With one exception, we generally believe the modifications to the proposed amendments in the aggregate do not result in changes to our proposed estimates of the effect of the amendments on the current burdens. We believe, however, that registrants will experience a reduction in internal hourly burdens due to the elimination of the requirement to provide AUV tables and are reducing the estimated hourly burden to prepare and file a post-effective amendment by 30 hours (reducing the adjusted estimated hourly burden from 227.25 hours to 197.25 hours per filing).
                        <SU>1180</SU>
                        <FTREF/>
                         Our revised estimates also reflect updated data for the number of Form N-4 initial registration statements and post-effective amendments filed annually, and revised internal wage rates,
                        <SU>1181</SU>
                        <FTREF/>
                         as set forth in the table above.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1180</SU>
                             As with Form N-3, we assume that removing the requirement to disclose AUV tables will largely impact the internal burdens associated with post-affective amendments (certain initial filings may provide AUV tables, but the form currently and as amended generally requires AUV tables in all post-effective amendments). 
                            <E T="03">See supra</E>
                             note 1163.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1181</SU>
                             
                            <E T="03">See supra</E>
                             note 1164 (providing revised internal wage rate estimates for purposes of preparing and filing reports on Form N-3, and that apply equally to Form N-4).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Initial registration statements.</E>
                         As proposed, we estimate that the amendments will result in the following changes to the internal hours and external cost burdens:
                    </P>
                    <P>• We estimate that, on a net basis, the amendments to Form N-4 will increase the burden of preparing and filing an initial registration statement by 5 hours per filing. Amortizing this burden over a three-year period results in an estimated average annual burden of 1.7 hours per initial registration statement.</P>
                    <P>• We estimate no change to the external cost burden for these amendments.</P>
                    <P>
                        <E T="03">Post-effective amendments.</E>
                         As proposed, we estimate that the amendments will result in the following changes to the internal hours and external cost burdens:
                    </P>
                    <P>• We estimate a one-time burden of an additional 20 hours per registration statement the first time the registration statement is amended by post-effective amendment following adoption of the amendments. Subsequently, we estimate an ongoing burden of an additional 5 hours per registration statement to prepare and file a post-effective amendment. Amortizing these burdens over a three-year period results in an estimated average annual burden of an additional 10 hours per registration statement to prepare and file a post-effective amendment.</P>
                    <P>• We estimate no change to the external cost burden for these amendments.</P>
                    <P>
                        In the aggregate, we estimate the total annual hour burden to comply with amended Form N-4 to be 300,937 hours,
                        <SU>1182</SU>
                        <FTREF/>
                         at an average time cost of $80,952,053.
                        <SU>1183</SU>
                        <FTREF/>
                         We also estimate the total external cost burden to comply with amended Form N-4 to be $30,342,168.
                        <SU>1184</SU>
                        <FTREF/>
                         These estimates reflect the increase in estimated burdens associated with the amendments, adjustments to certain per filing estimates, and current estimates for the number of filings on Form N-4.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1182</SU>
                             For initial registration statements: 30 initial filings × (as adjusted 800 hours per filing + 1.7 hours under amendments) = 24,051 hours. For post-effective amendments: 1,336 post-effective amendments × (197.25 hours current per filing burden + 10 hours under amendments) = 276,886 hours. 24,051 hours + 276,886 hours = 300,937 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1183</SU>
                             300,937 hours × $269/hour = $80,952,053.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1184</SU>
                             For initial registration statements: 30 initial filings x $40,000 per filing (as adjusted external cost per filing) = $1,200,000. For post-effective amendments: 1,336 post-effective amendments × $21,813 (current external cost per filing) = $29,142,168. $1,200,000 + $29,142,168 = $30,342,168.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">C. Form N-6</HD>
                    <P>Form N-6 is the form used by separate accounts organized as unit investment trusts that offer variable life insurance contracts to register under the Investment Company Act and/or to register and offer their securities under the Securities Act. Form N-6 contains collection of information requirements. Compliance with the disclosure requirements of Form N-6 is mandatory. Responses to the disclosure requirements are not confidential.</P>
                    <P>
                        Form N-6 generally imposes two types of reporting burdens on investment companies: (1) The burden of preparing and filing the initial registration statement; and (2) the burden of preparing and filing post-effective amendments to a previously effective registration statement. The hour and cost burden estimates for preparing and filing initial registration statements and post-effective amendments on Form N-6 are based on the Commission's experience with the contents of the form. The number of burden hours and cost may vary depending on, among other things, the complexity of the filing and whether preparation of the form is performed by internal staff or outside counsel. We currently estimate for Form N-6 a total of 31,987 internal burden hours, with a total annual external cost burden of $3,816,692.
                        <SU>1185</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1185</SU>
                             Form N-6's current information collection, which was approved in July 2019, reflects the adoption of certain form amendments associated with rule 30e-3 under the Investment Company Act.
                        </P>
                        <P> We currently estimate that on a per filing basis, registrants spend 770.25 internal burden hours to prepare and file an initial registration statement on Form N-6, and 67.5 internal burden hours for each post-effective amendment. We also estimate that Form N-6 registrants spend $26,169 in external costs per initial filing, and $9,493 per post-effective amendment. As discussed below, we are adjusting some of these estimates.</P>
                    </FTNT>
                    <PRTPAGE P="26081"/>
                    <P>We are adopting amendments to Form N-6 to update and enhance the disclosures to investors in variable life insurance contracts, and to implement the new summary prospectus regime. We are amending certain disclosures that Form N-6 currently requires. In addition, amended Form N-6 requires certain new disclosures regarding, among other things: The Key Information Table, an overview of the contract, principal risks, optional benefits, loans, lapse, and the Appendix of available portfolio companies. We are also reducing certain disclosures currently required by the form.</P>
                    <P>
                        The table below summarizes the estimated adjustments to the Form N-6 collection of information from the proposed amendments,
                        <SU>1186</SU>
                        <FTREF/>
                         the estimated adjustments to the Form N-6 collection of information from the final amendments, and the final PRA estimates for internal and external burdens associated with amended Form N-6:
                    </P>
                    <FTNT>
                        <P>
                            <SU>1186</SU>
                             As part of these estimates, Commission staff estimated that there would be eight initial filings and 380 post-effective amendments on Form N-6 per year. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section IV.C for more detail regarding the proposed estimates.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="615">
                        <PRTPAGE P="26082"/>
                        <GID>ER01MY20.009</GID>
                    </GPH>
                    <HD SOURCE="HD3">Changes to Baseline Burden Estimates</HD>
                    <P>
                        We did not receive public comment on our PRA estimates for the amendments to Form N-6, which we are adopting largely as proposed. However, in light of the comment we received regarding estimated burdens associated with preparing and filing a post-effective amendment on Form N-4,
                        <SU>1187</SU>
                        <FTREF/>
                         and because variable life insurance 
                        <PRTPAGE P="26083"/>
                        contracts registered on Form N-6 today tend to offer greater numbers of portfolio companies and optional benefits than variable life insurance contracts offered in the past, we believe that certain of our estimates may be too low. Therefore, we are adjusting the baseline current estimates (before the effect of the amendments we are adopting) for certain burdens and costs associated with Form N-6,
                        <SU>1188</SU>
                        <FTREF/>
                         as follows:
                    </P>
                    <FTNT>
                        <P>
                            <SU>1187</SU>
                             
                            <E T="03">See supra</E>
                             notes 1176-1177 and accompanying text.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1188</SU>
                             
                            <E T="03">See supra</E>
                             note 1185.
                        </P>
                    </FTNT>
                    <P>
                        • We are increasing our estimate to prepare and file a post-effective amendment from 67.5 hours to 150 hours per filing;
                        <SU>1189</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1189</SU>
                             Due to differences in the products and the respective form requirements associated with each, we estimate the burden hours associated with preparing a post-effective amendment for a registrant on Form N-6 to be approximately 
                            <FR>2/3</FR>
                             of the burden hours associated with preparing a post-effective amendment for a registrant on Form N-4. As discussed above, we have revised our baseline estimate of the burdens associated with preparing a post-effective amendment for a registrant on Form N-4 to 227.5 hours. 
                            <E T="03">See</E>
                             Section V.B 
                            <E T="03">supra.</E>
                        </P>
                    </FTNT>
                    <P>
                        • We are increasing our estimate of the external cost to prepare and file an initial registration statement from $26,169 to $40,000 per filing; 
                        <SU>1190</SU>
                        <FTREF/>
                         and
                    </P>
                    <FTNT>
                        <P>
                            <SU>1190</SU>
                             We estimate the external costs to prepare and file an initial registration statement on Form N-6 to be roughly equivalent to those associated with preparing and filing an initial registration statement on Form N-4. As discussed above, we have increased our baseline estimate of the external costs associated with preparing and filing an initial registration statement on Form N-4 to $40,000 per filing. 
                            <E T="03">See</E>
                             Section V.B 
                            <E T="03">supra.</E>
                        </P>
                    </FTNT>
                    <P>
                        • We are increasing our estimate of the external cost to prepare and file a post-effective amendment from $9,493 to $20,000 per filing.
                        <SU>1191</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1191</SU>
                             We are increasing this estimate to be roughly equivalent to the same burden associated with preparing and filing a post-effective amendment on Form N-4. 
                            <E T="03">See</E>
                             Section V.B 
                            <E T="03">supra.</E>
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Changes to Burden Estimates Resulting From Final Amendments</HD>
                    <P>
                        We believe that the modifications to the proposed amendments in the aggregate do not result in changes to our proposed estimates of the effect of the amendments on the current burdens. Our revised estimates, however, reflect updated data for the number of Form N-6 initial registration statements and post-effective amendments filed annually, and revised internal wage rates,
                        <SU>1192</SU>
                        <FTREF/>
                         as set forth in the table above.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1192</SU>
                             
                            <E T="03">See supra</E>
                             note 1164 (providing revised internal wage rate estimates for purposes of preparing and filing reports on Form N-3, and that apply equally to Form N-6).
                        </P>
                    </FTNT>
                    <P>
                        <E T="03">Initial registration statements.</E>
                         As proposed, we estimate that the amendments will result in the following changes to the internal hours and external cost burdens:
                    </P>
                    <P>• We estimate that, on a net basis, the amendments to Form N-6 will increase the burden of preparing and filing an initial registration statement by 4 hours per filing. Amortizing this burden over a three-year period results in an estimated average annual burden of 1 hour per initial registration statement.</P>
                    <P>• We estimate no change to the external cost burden for these amendments.</P>
                    <P>
                        <E T="03">Post-effective amendments.</E>
                         As proposed, we estimate that the amendments will result in the following changes to the internal hours and external cost burdens:
                    </P>
                    <P>• We estimate a one-time burden of an additional 15 hours per registration statement the first time the registration statement is amended by post-effective amendment following adoption of the amendments. Subsequently, we estimate an ongoing burden of an additional 4 hours per registration statement to prepare and file a post-effective amendment. Amortizing these burdens over a three-year period results in an estimated average annual burden of an additional 8 hours per registration statement to prepare and file a post-effective amendment.</P>
                    <P>• We estimate no change to the external cost burden for these amendments.</P>
                    <P>
                        In the aggregate, we estimate the total annual hour burden to comply with amended Form N-6 to be 65,123 hours,
                        <SU>1193</SU>
                        <FTREF/>
                         at an annual time cost of $17,518,087.
                        <SU>1194</SU>
                        <FTREF/>
                         We also estimate the total external cost burden to comply with amended Form N-6 to be $7,840,000.
                        <SU>1195</SU>
                        <FTREF/>
                         These estimates reflect the increase in estimated burdens associated with the amendments, adjustments to certain per filing estimates, and current estimates for the annual number of filings on Form N-6.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1193</SU>
                             For initial registration statements: 7 initial filings × (770.25 hours current burden + 1 hour under amendments) = 5,399 hours. For post-effective amendments: 378 post-effective amendments × (150 hours (as adjusted per filing) + 8 hours under amendments) = 59,724 hours. 5,399 + 59,724 = 65,123 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1194</SU>
                             65,123 hours × $269/hour = $17,518,087.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1195</SU>
                             For initial registration statements: 7 initial filings x $40,000 (as adjusted external cost per filing) = $280,000. For post-effective amendments: 378 post-effective amendments × $20,000 (as adjusted external cost per filing) = $7,560,000. $280,000 + $7,560,000 = $7,840,000.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">D. Investment Company Interactive Data</HD>
                    <P>
                        Generally as proposed,
                        <SU>1196</SU>
                        <FTREF/>
                         we are amending the General Instructions of Forms N-3, N-4, and N-6, rules 485 and 497 under the Securities Act, and rules under Regulation S-T,
                        <SU>1197</SU>
                        <FTREF/>
                         to require the use of Inline XBRL format for the submission of certain required disclosures in variable contract statutory prospectuses. Specifically, registrants will submit the following information in Inline XBRL format in registration statements or post-effective amendments regarding contracts being sold to new investors, as well as in forms of prospectuses filed pursuant to rule 497(c) or 497(e) under the Securities Act for such contracts that include information that varies from the registration statement:
                    </P>
                    <FTNT>
                        <P>
                            <SU>1196</SU>
                             
                            <E T="03">See supra</E>
                             Section II.D for a discussion on how the adopted amendments differ from the proposal.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1197</SU>
                             
                            <E T="03">See supra</E>
                             note 1159.
                        </P>
                    </FTNT>
                    <P>• Form N-3 registrants: information provided in response to Items 2, 4, 5, 11, 18, and 19 of Form N-3;</P>
                    <P>• Form N-4 registrants: information provided in response to Items 2, 4, 5, 10 and 17 of Form N-4; and</P>
                    <P>• Form N-6 registrants: information provided in response to Items 2, 4, 5, 10, 11 and 18 of Form N-6.</P>
                    <P>The title of the collection of information affected by these amendments is “Mutual Fund Interactive Data,” which we are re-titling as “Investment Company Interactive Data.” Compliance with these disclosure requirements is mandatory, and responses are not confidential.</P>
                    <P>
                        The amendments generally impose two types of reporting burdens on variable contracts being sold to new investors: (1) The burden of submitting certain information in Inline XBRL to the Commission in registration statements or post-effective amendments filed on Form N-3, Form N-4, and Form N-6; and (2) the burden of submitting certain information in Inline XBRL to the Commission in forms of prospectuses filed pursuant to rule 497(c) or 497(e) under the Securities Act that include information that varies from the registration statement. We currently estimate a total annual hour burden of 178,803 hours for this collection of information, and a total annual external cost burden of $10,000,647.
                        <SU>1198</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1198</SU>
                             These estimates are referenced in the most-recent information collection submission, reflecting the Commission's 2018 adoption of amendments to require the use of Inline XBRL format for the submission of mutual fund risk/return summary information. 
                            <E T="03">See</E>
                             Inline XBRL Adopting Release, 
                            <E T="03">supra</E>
                             note 892.
                        </P>
                    </FTNT>
                    <P>
                        The tables below summarize the proposed estimates included in the Proposing Release 
                        <SU>1199</SU>
                        <FTREF/>
                         and the final PRA estimates for internal and external 
                        <PRTPAGE P="26084"/>
                        burdens associated with the structured data requirements for Forms N-3, N-4, and N-6.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1199</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section IV.D for more detail regarding the proposed estimates.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="601">
                        <GID>ER01MY20.010</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="369">
                        <PRTPAGE P="26085"/>
                        <GID>ER01MY20.011</GID>
                    </GPH>
                    <P>
                        We did not receive public comment on our proposed PRA estimates for the burdens and costs associated with requiring variable contract registrants to use Inline XBRL to tag certain information in the specified variable contract filings. We continue to estimate the same burdens and costs associated with structured data requirements as proposed.
                        <SU>1200</SU>
                        <FTREF/>
                         As reflected in the table above, we are revising our estimates to reflect current figures for the number of registration statements and rule 497 filings annually filed on Forms N-3, N-4, and N-6, and updated internal wage rates.
                        <SU>1201</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1200</SU>
                             Although in a change from the proposal contracts not being sold to new investors are excluded from the Inline XBRL requirement, for purposes of these estimates we are assuming on a conservative basis that all contracts are subject to the requirement.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1201</SU>
                             The $348 wage rate reflects current estimates of the blended hourly rate for an in-house compliance attorney ($365) and senior programmer ($331), which is derived from SIFMA's Management &amp; Professional Earnings in the Securities Industry 2013 (modified to account for an 1,800 hour work year; multiplied by 5.35 to account for bonuses, firm size, employee benefits and overheard; and adjusted for inflation).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Internal Hour Burden</HD>
                    <P>
                        We estimate, as proposed, that registrants that file on Forms N-3, N-4, and N-6 will require approximately 18 burden hours of in-house personnel time to tag and submit the required disclosure information in Inline XBRL format for each post-effective amendment 
                        <SU>1202</SU>
                        <FTREF/>
                         in the first year, and the same task in subsequent years will require approximately 12 hours for each post-effective amendment.
                        <SU>1203</SU>
                        <FTREF/>
                         With respect to Form N-3 registrants, we estimate an additional burden of 2 hours per investment option to tag and submit the required disclosure information for each post-effective amendment. Therefore, we estimate the average annual burden over a three-year period for each post-effective amendment filed on Form N-3 will be 20 hours,
                        <SU>1204</SU>
                        <FTREF/>
                         and for those filed on Forms N-4 and N-6, 14 hours.
                        <SU>1205</SU>
                        <FTREF/>
                         We further estimate that the burden for each rule 497 filing will be 25% of that, or 3.5 hours per response.
                        <SU>1206</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1202</SU>
                             We are not including estimates for Form N-3 initial registration statements, as none have been filed in the past three years.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1203</SU>
                             Our estimates are based on our prior experience with Inline XBRL. 
                            <E T="03">See, e.g.,</E>
                             Inline XBRL Adopting Release, 
                            <E T="03">supra</E>
                             note 892. We are largely following the same approach to estimating hourly burdens for variable contracts as in the context of mutual funds in the Inline XBRL Adopting Release.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1204</SU>
                             (18 hours for the first submission + 12 hours for the second submission + 12 hours for the third submission)/3 years) + (2 hours per investment option × 3 investment options) = 20 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1205</SU>
                             (18 hours for the first submission + 12 hours for the second submission + 12 hours for the third submission)/3 years = 14 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1206</SU>
                             Because rule 497 filings are typically 1-3 pages in length, we estimate the burden will be only 25% of the burden associated with tagging the relevant disclosures in a full registration statement filing.
                        </P>
                    </FTNT>
                    <P>
                        We also estimate, as proposed, a weighted burden average of approximately 3 responses per year per registrant to file initial and post-effective registration statements and rule 497 filings, based on weighting the burden for each rule 497 filing as 25% of the burden of a post-effective amendment filing, averaging the burden for each form equally, and estimating (based on a survey by Commission staff of filings made pursuant to rule 497) that 75% of rule 497 filings by 
                        <PRTPAGE P="26086"/>
                        registrants on each form will contain data that would be required to be submitting in Inline XBRL format.
                        <SU>1207</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1207</SU>
                             For Form N-3, we estimate a burden of 1.6 responses per year. This estimate is based on the following calculation: ((0 initial registration statements + 6 post-effective amendments) + (18 rule 497 filings × 75% of which will contain data that will need to be tagged × 25% weighted burden))/6 Form N-3 registrants = approximately 1.6 responses per year per registrant.
                        </P>
                        <P>For Form N-4, we estimate a burden of 4.9 responses per year. This estimate is based on the following calculation: ((30 initial registration statements + 1,336 post-effective amendments) + (3,896 rule 497 filings × 75% of which will contain data that will need to be tagged × 25% weighted burden))/426 Form N-4 registrants = approximately 4.9 responses per year per registrant.</P>
                        <P> For Form N-6, we estimate a burden of 2.3 responses per year. This estimate is based on the following calculation: ((7 initial registration statements + 378 post-effective amendments) + (1,130 rule 497 filings × 75% of which will contain data that will need to be tagged × 25% weighted burden))/244 Form N-6 registrants = approximately 2.4 responses per year per registrant.</P>
                        <P>Overall, we estimate approximately 3 responses per year. This estimate is based upon the following calculation: (1.6 responses per N-3 registrant + 4.9 responses per N-4 registrant + 2.4 responses per N-6 registrant)/3 = 3 responses per year.</P>
                    </FTNT>
                    <P>
                        As reflected in the table above, we estimate that in the aggregate, adoption of the Inline XBRL requirements will result in 360 burden hours annually for Form N-3 registrants, with a collective internal cost burden of $125,280, to tag and submit the required Form N-3 disclosure information in Inline XBRL.
                        <SU>1208</SU>
                        <FTREF/>
                         We estimate 17,892 burden hours annually for Form N-4 registrants (with an internal cost burden of $6,226,416),
                        <SU>1209</SU>
                        <FTREF/>
                         and 10,248 burden hours annually for Form N-6 registrants (with an internal cost burden of $3,566,304) to tag and submit the required disclosures in Inline XBRL.
                        <SU>1210</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1208</SU>
                             6 Form N-3 registrants × 3 responses per year per registrant × (14 hours per registrant + (2 hours per investment option × 3 investment options per registrant)) = 360 burden hours/year. The internal time cost equivalent is calculated by multiplying the total hour burden (360 hours) by the estimated hourly wage of $348 (updated to reflect inflation) = $125,280.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1209</SU>
                             426 Form N-4 registrants × 3 responses per year per registrant × 14 hours per registrant = 17,892 burden hours/year. The internal time cost equivalent of is calculated by multiplying the total hour burden (17,892 hours) by the estimated hourly wage of $348 = $6,226,416.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1210</SU>
                             244 Form N-6 registrants × 3 responses per year per registrant × 14 hours per registrant = 10,248 burden hours/year. The internal time cost equivalent is calculated by multiplying the total hour burden (10,248 hours) by the estimated hourly wage of $348 = $3,566,304.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">External Cost Burden</HD>
                    <P>
                        Compliance with the Inline XBRL requirements is expected to entail certain external costs, such as for software and/or the services of consultants and filing agents. For Form N-4 and Form N-6 registrants, we estimate, as proposed, an external cost burden of $900 per registrant for the cost of goods and services purchased to comply with the proposed Inline XBRL requirements.
                        <SU>1211</SU>
                        <FTREF/>
                         For Form N-3 registrants, we estimate, as proposed, an additional cost of $300 per investment option for the cost of goods and services purchased to comply with the Inline XBRL requirements for an estimated external cost burden of $1,800 per registrant.
                        <SU>1212</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1211</SU>
                             This estimate is based on the estimated average external cost burden associated with the Inline XBRL preparation expenses for mutual funds and ETFs. 
                            <E T="03">See</E>
                             Inline XBRL Adopting Release, 
                            <E T="03">supra</E>
                             note 892.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1212</SU>
                             $900 per registrant + (3 investment options per registrant x $300 per investment option) = $1,800 per Form N-3 registrant.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Aggregate Burdens for Form N-3, N-4, and N-6 Registrants</HD>
                    <P>
                        We estimate that the new Inline XBRL requirements for Form N-3, N-4, and N-6 registrants will result in 28,500 internal burden hours annually,
                        <SU>1213</SU>
                        <FTREF/>
                         with a collective internal time cost of approximately $9,918,000.
                        <SU>1214</SU>
                        <FTREF/>
                         We therefore estimate the aggregate total hour burden for the collection of information to be 207,303 hours as a result of the amendments.
                        <SU>1215</SU>
                        <FTREF/>
                         We estimate the aggregate external cost burden under the new Inline XBRL requirements for Form N-3, N-4, and N-6 registrants to be approximately $613,800.
                        <SU>1216</SU>
                        <FTREF/>
                         We therefore estimate the aggregate total external cost burden for the collection of information will be $10,614,447 as a result of the final amendments.
                        <SU>1217</SU>
                        <FTREF/>
                         These estimates include the additional internal burdens and external costs associated with the final amendments that will require variable contracts to use Inline XBRL to tag certain specified disclosures in their registration statements and rule 497 filings.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1213</SU>
                             360 burden hours for Form N-3 registrants + 17,892 burden hours for Form N-4 registrants + 10,248 burden hours for Form N-6 registrants = 28,500 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1214</SU>
                             28,500 hours × $348/hour = $9,918,000.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1215</SU>
                             178,803 hours (current internal burden estimate for Mutual Fund Interactive Data (retitled as Investment Company Interactive Data)) + 28,500 burden hours due to new Inline XBRL requirements for variable contracts = 207,303 total burden hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1216</SU>
                             (6 Form N-3 registrants × ($900 per registrant + ($300 per investment option × 3 investment options))) + (426 Form N-4 registrants × $900 per registrant) + (244 Form N-6 registrants × $900 per registrant) = $613,800.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1217</SU>
                             $10,000,647 (current external cost estimate for Mutual Fund Interactive Data (retitled as Investment Company Interactive Data)) + $613,800 external costs due to new Inline XBRL requirements for variable contracts = $10,614,447.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD2">E. Rule 498A</HD>
                    <P>
                        New rule 498A contains collection of information requirements. The likely respondents to this information collection are variable annuity and variable life insurance separate accounts registered or registering with the Commission.
                        <SU>1218</SU>
                        <FTREF/>
                         Under rule 498A, use of the summary prospectus is voluntary, but the rule's requirements are mandatory for variable annuity and variable life insurance separate accounts that elect to send or give a summary prospectus in reliance upon rule 498A. The information provided under rule 498A will not be kept confidential.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1218</SU>
                             Rule 498A can be broadly relied upon by any person to satisfy prospectus delivery obligations under Section 5(b)(2) under the Securities Act for a variable contract or portfolio company. However, we expect the hour and cost burdens of the rule (
                            <E T="03">i.e.,</E>
                             to create and file initial and updating summary prospectuses and to make certain documents available online and to distribute them upon request) will generally be borne by registrants. We base this expectation in part on the fact that our amendments require prospectuses and summary prospectuses to include the website address where the documents required to be posted online are located, and contact information to call or email to obtain paper copies of those documents, and we expect registrants to list their own website and their own contact information to satisfy these requirements, as opposed to directing investors to various financial intermediaries who may be involved in distributing those contracts.
                        </P>
                    </FTNT>
                    <P>
                        The summary prospectus is voluntary, so the percentage of variable annuity and variable life insurance separate accounts that will choose to utilize it is uncertain. Given this uncertainty, we have assumed that 90% of registrants will choose to use a summary prospectus under rule 498A.
                        <SU>1219</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1219</SU>
                             Given expressed industry support for layered disclosure with summary prospectuses, our estimate that approximately 93% of mutual funds currently use summary prospectuses (
                            <E T="03">see supra</E>
                             note 21), and our anticipation that the rule will provide costs savings to insurers, we believe it is appropriate to assume that 90% of insurers will choose to use summary prospectuses. This differs from the estimate of 95% in the Proposing Release which was based on available data at the time. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section IV.E.
                        </P>
                    </FTNT>
                    <P>
                        The table below summarizes the proposed estimates included in the Proposing Release 
                        <SU>1220</SU>
                        <FTREF/>
                         and the final PRA estimates for internal and external burdens associated with rule 498A for Forms N-3, N-4, and N-6:
                    </P>
                    <FTNT>
                        <P>
                            <SU>1220</SU>
                             
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section IV.E for more detail regarding the proposed estimates.
                        </P>
                    </FTNT>
                    <GPH SPAN="3" DEEP="431">
                        <PRTPAGE P="26087"/>
                        <GID>ER01MY20.012</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="474">
                        <PRTPAGE P="26088"/>
                        <GID>ER01MY20.013</GID>
                    </GPH>
                    <GPH SPAN="3" DEEP="406">
                        <PRTPAGE P="26089"/>
                        <GID>ER01MY20.014</GID>
                    </GPH>
                    <P>
                        The only public
                        <FTREF/>
                         comment we received regarding our PRA estimates for proposed rule 498A discussed estimated external costs associated with printing and mailing initial and summary prospectuses pursuant to the proposed rule.
                        <SU>1223</SU>
                        <FTREF/>
                         As discussed below, in response to this comment, we are adjusting our estimates for external costs. In all other respects, we generally believe the modifications to the proposed rule in the aggregate do not result in changes to our proposed estimates of the burdens associated with the rule unrelated to printing and mailing the summary prospectuses. Therefore, we are not otherwise adjusting our proposed estimates, except to reflect estimates for printing and mailing costs, and revised estimates for the number of variable contract registrants and internal wage rates.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1221</SU>
                             The Proposing Release included an aggregate estimate of 17,359 hours, which reflected a mathematical error. The table includes the corrected calculation based on the estimates in the Proposing Release.
                        </P>
                        <P>
                            <SU>1222</SU>
                             The Proposing Release included an aggregate estimated time cost equivalent of $5,565,971, which reflected a mathematical error relating to the estimated total annual burden hours. The table includes the corrected calculation based on the estimates in the Proposing Release.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1223</SU>
                             
                            <E T="03">See</E>
                             Broadridge Comment Letter.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Preparation of Initial Summary Prospectus and Updating Summary Prospectus</HD>
                    <HD SOURCE="HD3">Internal Hour Burden</HD>
                    <P>
                        We did not receive any comments on our proposed estimates associated with the internal burdens to prepare and file initial and updating summary prospectuses. We continue to estimate that for registrants that choose to rely upon rule 498A, a one-time collective burden of 40 hours per registration statement to prepare and file both a new initial summary prospectus and a new updating summary prospectus for offerings on Forms N-4 or N-6.
                        <SU>1224</SU>
                        <FTREF/>
                         In addition, we estimate an ongoing collective burden of 10 hours per registration statement during each subsequent year for the registrant to prepare and file updates of the initial summary prospectus and updating summary prospectus for offerings on Forms N-4 or N-6. For offerings on Form N-3, we estimate a one-time collective burden of 40 hours per registration statement to prepare and file both a new initial summary prospectus and a new updating summary prospectus, plus a further burden of 12 hours per contract investment option. Subsequently, we estimate an ongoing collective burden of 10 hours per registration statement that would be 
                        <PRTPAGE P="26090"/>
                        incurred each following year to prepare and file updates of summary prospectuses, plus a further burden of 3 hours per investment option. As previously discussed, we estimate that each registration statement filed on Form N-3 will include three investment options.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1224</SU>
                             We are aware that more than one prospectus may be filed as part of a registration statement, but we do not have data regarding how many registration statements currently include more than one prospectus. For purposes of this analysis we assume one prospectus is filed per registration statement.
                        </P>
                    </FTNT>
                    <P>
                        Because the PRA estimates represent the average burden over a three year period, we estimate, as proposed, the average annual hour burden per registration statement to prepare and file initial and updating summary prospectuses to be 20 hours for filings on Form N-4 or N-6,
                        <SU>1225</SU>
                        <FTREF/>
                         and 38 hours for filings on Form N-3.
                        <SU>1226</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1225</SU>
                             ((40 hours in year 1) + (10 hours in year 2) + (10 hours in year 3))/3 years = 20 hours per year.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1226</SU>
                             (((40 hours + (12 hours per investment option × 3 investment options) in year 1) + (10 hours + (3 hours per investment option × 3 investment options in year 2) + (10 hours + (3 hours per investment option × 3 investment options) in year 3))/3 years = 38 hours per year.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">External Cost Burden</HD>
                    <P>Registrants may also bear external costs to prepare and update the initial and updating summary prospectuses, such as the services of independent auditors and outside counsel. However, any external costs, such as for outside counsel and auditors, that may be associated with preparing and updating the initial summary prospectus as an exhibit to a registration statement will be reflected in the external costs associated with those registration statements.</P>
                    <P>For registrants that choose to rely upon rule 498A, we continue to estimate a one-time collective external cost burden of $10,000 per registration statement to prepare both a new initial summary prospectus and a new updating summary prospectus for offerings on Forms N-4 or N-6. In addition, we estimate an ongoing collective burden of $2,500 per registration statement during each subsequent year for the registrant to prepare updates of the initial summary prospectus and updating summary prospectus for offerings on Forms N-4 or N-6. For offerings on Form N-3, we estimate a one-time collective burden of $10,000 per registration statement to prepare and file both a new initial summary prospectus and a new updating summary prospectus, plus a further burden of $3,000 per contract investment option. Subsequently, we estimate an ongoing collective burden of $2,500 per registration statement during each following year to prepare and file updates of summary prospectuses, plus a further burden of $750 per investment option. As discussed above, we estimate that each registration statement filed on Form N-3 will include three investment options.</P>
                    <P>
                        Because the PRA estimates represent the average burden over a three-year period, we estimate that the average annual cost burden to prepare and file initial and updating summary prospectuses will be $5,000 per filing on Forms N-4 and N-6.
                        <SU>1227</SU>
                        <FTREF/>
                         For Form N-3, we estimate the average annual cost burden per registration statement to prepare and update initial and updating summary prospectuses will be $9,500.
                        <SU>1228</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1227</SU>
                             (($10,000 in year 1) + ($2,500 in year 2) + ($2,500 in year 3))/3 years = $5,000 per year.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1228</SU>
                             ((($10,000 to prepare new initial and updating summary prospectuses + ($3,000 per investment option × 3 investment options) in year 1) + ($2,500 + ($750 per investment option × 3 investment options)) in year 2) + ($2,500 + ($750 per investment option × 3 investment options) in year 3)/3 = $9,500 per year.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Aggregate Burdens for Preparing and Filing Summary Prospectuses</HD>
                    <P>
                        As discussed above, in light of our consideration of a comment received on our printing and mailing estimates, we have revised our estimate of related external costs which was $3,469,875 in the proposal. We now estimate the aggregate annual hour burden to prepare and file initial and updating summary prospectuses for offerings on Forms N-3, N-4, and N-6 will be 12,265 hours,
                        <SU>1229</SU>
                        <FTREF/>
                         at an internal cost equivalent of $3,299,285.
                        <SU>1230</SU>
                        <FTREF/>
                         We also estimate the aggregate annual external costs associated with preparing and filing summary prospectuses to be $3,066,300.
                        <SU>1231</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1229</SU>
                             This estimate, which assumes 90% reliance on the rule, is based on the following: ((38 hours × 6 registrants on Form N-3 = 228) + (20 hours × 426 registrants on Form N-4 = 8,520) + (20 hours × 244 registrants on Form N-6 = 4,880)) × 90% = 12,265 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1230</SU>
                             12,265 hours × $269 per hour = $3,299,285.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1231</SU>
                             (($9,500 × 6 registrants on Form N-3 = $57,000) + ($5,000 × 426 registrants on Form N-4 = $2,130,000) + ($5,000 × 244 registrants on Form N-6 = $1,220,000)) × 90% = $3,066,300.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Online Availability of Contract Statutory Prospectus and Certain Other Documents Relating to the Contract</HD>
                    <P>
                        Registrants that choose to rely on rule 498A are required to make certain documents relating to the contract available online, including a variable contract's initial summary prospectus, updating summary prospectus, statutory prospectus, and SAI for contracts registered on Forms N-3, N-4, or N-6, and the contract's most recent annual and semi-annual reports to shareholders under rule 30e-1 in the case of a variable annuity contract registered under Form N-3. We received no comments on this aspect of the proposal, and continue to estimate, as proposed, the average burden to comply with the website posting requirements to be 2 hours per set of documents associated with a single registration statement, both in the first year and annually thereafter.
                        <SU>1232</SU>
                        <FTREF/>
                         Registrants must also provide these documents upon request. We estimate, as proposed, that the average annual costs associated with printing and mailing these documents upon request to be collectively $500 for all specified contract documents associated with a single registrant.
                        <SU>1233</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1232</SU>
                             Separate account registrants are generally larger entities, and therefore, based on our experience with these registrants, we assume that all separate account registrants already have their own website and will not experience any burdens associated with developing a website.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1233</SU>
                             Because we do not have specific data regarding cost of printing and mailing the documents that must be provided on request, for purposes of our analysis we continue to estimate, as proposed, $500 per year to collectively print and mail upon request all of the specified contract documents associated with a single registrant. Investors could also request to receive these documents electronically. We estimate that there will be negligible external costs associated with emailing electronic copies of these documents.
                        </P>
                    </FTNT>
                    <P>
                        In total, we estimate the annual burden to comply with the website posting requirements of the rule for documents relating to variable contracts will be 1,217 hours,
                        <SU>1234</SU>
                        <FTREF/>
                         at an internal cost equivalent of $301,816.
                        <SU>1235</SU>
                        <FTREF/>
                         We also estimate the aggregate annual external costs associated with printing and mailing these documents upon request to be $304,200.
                        <SU>1236</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1234</SU>
                             This estimate, which assumes 90% reliance on the rule, is based on the following: 2 hours per registrant × (6 registrants on Form N-3 + 426 registrants on Form N-4 + 244 registrants on Form N-6) × 90% = 1,217 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1235</SU>
                             1,217 hours × $248 per hour = $301,816.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1236</SU>
                             $500 per registrant × (6 registrants on Form N-3 + 426 registrants on Form N-4 + 244 registrants on Form N-6) × 90% = $304,200.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Online Availability of Portfolio Company Statutory Prospectuses and Certain Other Documents Relating to Portfolio Companies</HD>
                    <P>
                        Registrants on Forms N-4 and N-6 that choose to rely on the new delivery option for portfolio company prospectuses are also required to post online the portfolio company's summary prospectus, statutory prospectus, SAI, and most recent annual and semi-annual shareholder reports.
                        <SU>1237</SU>
                        <FTREF/>
                         We received no comments 
                        <PRTPAGE P="26091"/>
                        on this aspect of the proposal. Accordingly, we estimate, as proposed, the average burden to comply with the website posting requirements to be 2 hours per set of documents associated with a single registration statement, both in the first year and annually thereafter. Because registrants may incur external costs in connection with the requirement to provide these documents upon investor request, we estimate, as proposed, the average annual costs associated with printing and mailing these documents upon request to be collectively $500 for all specified portfolio company documents associated with a single registrant.
                        <SU>1238</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1237</SU>
                             The obligation to post these documents online will fall upon the party that has the prospectus delivery obligation for the portfolio company prospectus. For purposes of this PRA analysis, we assume that delivery of portfolio company prospectuses will be done by registrants, rather than portfolio companies or financial intermediaries such as broker-dealers. In some situations, portfolio company documents may 
                            <PRTPAGE/>
                            already be posted online, such as in the case of portfolio companies that already use summary prospectuses and therefore are subject to the document posting requirements of rule 498. However, for purposes of this PRA, we still assume that the registrant will bear the burden of posting those documents since we expect the registrant will repost those documents to make them available on a single website. 
                            <E T="03">See supra</E>
                             note 1218.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1238</SU>
                             As previously noted, investors could also request to receive these documents electronically. We estimate that there will be negligible external costs associated with emailing electronic copies of these documents.
                        </P>
                    </FTNT>
                    <P>
                        In total, we estimate the annual burden to comply with the website posting requirements of the rule for documents relating to portfolio companies will be 1,206 hours,
                        <SU>1239</SU>
                        <FTREF/>
                         at an internal cost equivalent of $299,088.
                        <SU>1240</SU>
                        <FTREF/>
                         We estimate that the aggregate annual external costs associated with printing and mailing these documents upon request will be $301,500.
                        <SU>1241</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1239</SU>
                             This estimate, which assumes 90% reliance on the rule, is based on the following: 2 hours per registrant × (426 registrants on Form N-4 + 244 registrants on Form N-6) × 90% = 1,206 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1240</SU>
                             1,206 hours × $248/hour = $299,088.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1241</SU>
                             This estimate, which assumes 90% reliance on the rule, is based on the following: $500 per registrant × (426 registrants on Form N-4 + 244 registrants on Form N-6) × 90% = $301,500. For purposes of this PRA analysis and based upon our experience, we assume the burden of emailing these documents will be outsourced to third-party service providers and therefore included within these external cost estimates.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Printing and Mailing Summary Prospectuses</HD>
                    <P>
                        In the Proposing Release, the Commission did not estimate any costs associated with printing and mailing the initial and updating summary prospectuses. In response to the Commission's general request for comments on our PRA estimates, one commenter provided an estimate of $8 million for total costs to print and mail initial and updating summary prospectuses annually.
                        <SU>1242</SU>
                        <FTREF/>
                         We received no other comments in this regard. Based on the commenter's methodology (updated to reflect new estimates for new and existing contracts, which the commenter used as the basis for estimating the number of summary prospectuses delivered each year), we estimate the external cost for registrants to print and mail the summary prospectuses to be $10,038,200 annually.
                        <SU>1243</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1242</SU>
                             
                            <E T="03">See</E>
                             Broadridge Comment Letter. Because this commenter's estimates assumed the inclusion of portfolio company prospectuses, it appears to only contemplate the costs associated summary prospectuses for Forms N-4 and N-6 (Form N-3 does not offer underlying portfolio companies).
                        </P>
                        <P>
                             The commenter's figures, which rely on estimates in the Economic Analysis section of the Proposing Release for the number of new and existing contracts likely to use the summary prospectus option, 
                            <E T="03">see supra</E>
                             note 6, n.698 and accompanying text, assume that 700,000 initial summary prospectuses and 13 million updating summary prospectuses will be printed and mailed annually, with an estimated unit cost of $1.20 (first-class) for each initial summary prospectus, and $0.55 (bulk rate) for each updating summary prospectus.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1243</SU>
                             The commenter's estimates assume that each new and existing contract is a proxy for a single new and existing investor, which conflicts with our understanding that each contract may have many investors (new and existing). However, lacking other specific data upon which to estimate printing and mailing costs associated with summary prospectuses, we apply the commenter's methodology for purposes of this PRA analysis (updated to reflect revised estimates for the number of initial and existing contracts likely to use a summary prospectus). 
                            <E T="03">See supra</E>
                             note 1077 and accompanying text. Calculated as follows: Initial summary prospectuses ($1.20 unit cost × 986,000 new contracts (initial mailings)) = $1,183,200) + updating summary prospectuses ($0.55 unit cost × 16.1 million existing contracts (annual updates)) = $8,855,000) = $10,038,200 combined.
                        </P>
                    </FTNT>
                    <HD SOURCE="HD3">Aggregate Total Burdens Associated With Rule 498A</HD>
                    <P>
                        We estimate the aggregate total annual hour burden for registrants under rule 498A to be 14,688 hours,
                        <SU>1244</SU>
                        <FTREF/>
                         at an internal time cost equivalent of $3,900,189 
                        <SU>1245</SU>
                        <FTREF/>
                         which reflects a decrease from the proposed estimates due to revised estimates for the number of variable contract registrants and revised estimates of the percentage of insurers that will choose to use summary prospectuses. We also estimate the total external cost to be $12,706,380, which reflects an increase over the proposed estimate due to the inclusion of costs associated with the printing and mailing of summary prospectuses.
                        <SU>1246</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1244</SU>
                             This estimate, which assumes 90% reliance on the rule, is based on the following: 12,265 hours to prepare and update summary prospectuses + 1,217 hours for online posting of contract documents + 1,206 hours for online posting of portfolio company documents = 14,688 hours.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1245</SU>
                             This estimate, which assumes 90% reliance on the rule, is based on the following: $3,299,285 to prepare and update summary prospectuses + $301,816 for online posting of contract documents + $315,704 for online posting of portfolio company documents = $3,900,189. Due to rounding, this estimate differs slightly from the corresponding number posted in the table above ($3,900,193).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1246</SU>
                             This estimate, which assumes 90% reliance on the rule, is based on the following: ($3,407,000 to prepare and update summary prospectuses + $338,000 for online posting of contract documents + $335,000 for online posting of portfolio company documents + $10,038,200 to annually print and mail all summary prospectuses) × 90% = $12,706,380 (total external costs for rule 498A).
                        </P>
                    </FTNT>
                    <HD SOURCE="HD1">VI. Regulatory Flexibility Act Certification</HD>
                    <P>
                        Pursuant to 5 U.S.C. 605(b), we hereby certify that rule 498A under the Securities Act and amendments to Forms N-3, N-4, N-6, and N-14 under the Securities Act and the Investment Company Act, as adopted, will not have a significant economic impact on a substantial number of small entities.
                        <SU>1247</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1247</SU>
                             We also certified that the proposed rule and proposed form amendments would not have a significant economic impact on a substantial number of small entities. 
                            <E T="03">See</E>
                             Proposing Release, 
                            <E T="03">supra</E>
                             note 6, at Section V. We received no comments on that certification. As discussed below, we are also adopting minor amendments to Form N-14 in response to a comment letter.
                        </P>
                    </FTNT>
                    <P>We are adopting rule 498A under the Securities Act pursuant to authority set forth in Sections 5, 6, 7, 10, 19, and 28 of the Securities Act [15 U.S.C. 77e, 77f, 77g, 77j, 77s, and 77z-3] and Sections 8, 24(a), 24(g), 30, and 38 of the Investment Company Act [15 U.S.C. 80a-8, 80a-24(a), 80a-24(g), 80a-29, and 80a-37]. Rule 498A provides a new option that permits a person to satisfy its variable annuity and variable life insurance contract prospectus delivery obligations under the Securities Act by providing a summary prospectus to investors.</P>
                    <P>
                        A person will have the option of satisfying its prospectus delivery obligations for variable contracts under Section 5(b)(2) of the Securities Act by: (1) Sending or giving to new investors key information contained in a variable contract statutory prospectus in the form of an initial summary prospectus; (2) sending or giving to existing investors each year a brief description of certain changes to the contract, and a subset of the information in the initial summary prospectus, in the form of an updating summary prospectus; and (3) providing the statutory prospectus and other materials online. Rule 498A requires a registrant (or the financial intermediary distributing the variable contact) to send the variable contract statutory prospectus and other materials to the investor in paper or by email upon request. Additionally, the rule permits satisfaction of any portfolio company prospectus delivery obligations by posting the portfolio company summary and statutory prospectuses online at the website 
                        <PRTPAGE P="26092"/>
                        address specified on the variable contract summary prospectus.
                        <SU>1248</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1248</SU>
                             This option does not apply to Form N-3 registrants, which do not have underlying portfolio companies due to a single-tier investment company structure. 
                        </P>
                        <P>
                             The obligation to post these documents online will fall upon the party that has the prospectus delivery obligation for the portfolio company prospectus. For purposes of this Regulatory Flexibility Act analysis, we assume that delivery of portfolio company prospectuses will be done by registrants, rather than portfolio companies or financial intermediaries such as broker-dealers. 
                            <E T="03">See supra</E>
                             note 1237 (making the same assumption for purposes of the Paperwork Reduction Act analysis).
                        </P>
                    </FTNT>
                    <P>Investors will also be able to request and receive those documents in paper or electronically at no cost. No variable contract separate accounts will be required to send or give a summary prospectus.</P>
                    <P>We are also adopting amendments to Forms N-3, N-4, N-6, and N-14 pursuant to authority set forth in Sections 5, 6, 7, 10, and 19(a) of the Securities Act [15 U.S.C. 77e, 77f, 77g, 77j, and 77s(a)] and Sections 8, 24(a), 24(g), 30, and 38 of the Investment Company Act [15 U.S.C. 80a-8, 80a-24(a), 80a-24(g), 80a-29, and 80a-37]. The amendments to Forms N-3, N-4, and N-6 are intended to update and enhance the disclosures to investors in variable annuity and variable life insurance contracts, and to implement the proposed summary prospectus framework.</P>
                    <P>
                        Specifically, the amendments to Forms N-3, N-4, and N-6 add new disclosures requiring, among other things, an overview of the contract, key information, consolidated risk disclosures, a list of the available portfolio companies with expense and performance information, and information about standard and optional benefits that a contract may offer. The amendments also standardize presentation requirements across registration statement forms to make the information more accessible to retail investors. We are also requiring variable contracts to use the Inline XBRL format for the submission of certain required disclosures in the variable contract statutory prospectus.
                        <SU>1249</SU>
                        <FTREF/>
                         All insurance company separate accounts offering variable annuity and variable life insurance contracts will be subject to the new disclosure and reporting requirements, regardless of size. In addition, the amendments to Form N-14 provide that a portfolio company prospectus whose delivery obligations were satisfied via new rule 498A(j) may be incorporated by reference into a filing on Form N-14 without being sent to investors, so long as that portfolio company was listed in the variable contract summary prospectus Appendix at the time the disclosures required by Form N-14 were delivered to investors.
                        <SU>1250</SU>
                        <FTREF/>
                    </P>
                    <FTNT>
                        <P>
                            <SU>1249</SU>
                             
                            <E T="03">See supra</E>
                             Section II.D.
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1250</SU>
                             
                            <E T="03">See supra</E>
                             Section II.B.2.d.
                        </P>
                    </FTNT>
                    <P>
                        Generally, an investment company is a small entity if, together with other investment companies in the same group of related investment companies, it has net assets of $50 million or less as of the end of its most recent fiscal year.
                        <SU>1251</SU>
                        <FTREF/>
                         The analysis is slightly different for insurance company separate accounts. Because state law generally treats separate account assets as the property of the sponsoring insurance company, rule 0-10 aggregates each separate account's assets with the assets of the sponsoring insurance company, together with assets held in other sponsored separate accounts.
                        <SU>1252</SU>
                        <FTREF/>
                         As a result, the Commission expects few, if any, separate accounts to be treated as small entities.
                    </P>
                    <FTNT>
                        <P>
                            <SU>1251</SU>
                             17 CFR 270.0-10(a) (rule 0-10(a)).
                        </P>
                    </FTNT>
                    <FTNT>
                        <P>
                            <SU>1252</SU>
                             Rule 0-10(b).
                        </P>
                    </FTNT>
                    <P>For this reason, we believe rule 498A and the amendments to Forms N-3, N-4, N-6, and N-14, as adopted, will not have a significant economic impact on a substantial number of small entities.</P>
                    <HD SOURCE="HD1">VII. Statutory Authority</HD>
                    <P>
                        We are adopting the rule and form amendments contained in this document under the authority set forth in the Securities Act, particularly, Sections 10, 19, and 28 thereof [15 U.S.C. 
                        <E T="03">77a et seq.</E>
                        ], the Exchange Act, particularly, Section 23 thereof [15 U.S.C. 78a 
                        <E T="03">et seq.</E>
                        ], the Investment Company Act, particularly, Sections 8, 30, and 38 thereof [15 U.S.C. 80a 
                        <E T="03">et seq.</E>
                        ], and 44 U.S.C. 3506, 3507.
                    </P>
                    <LSTSUB>
                        <HD SOURCE="HED">List of Subjects</HD>
                        <CFR>17 CFR Part 200</CFR>
                        <P>Administrative practice and procedure, Organization and functions (Government agencies).</P>
                        <CFR>17 CFR Parts 230, 270, and 274</CFR>
                        <P>Investment companies, Reporting and recordkeeping requirements, Securities.</P>
                        <CFR>17 CFR Part 232</CFR>
                        <P>Administrative practice and procedure, Reporting and recordkeeping requirements, Securities.</P>
                        <CFR>17 CFR Parts 239 and 240</CFR>
                        <P>Reporting and recordkeeping requirements, Securities.</P>
                    </LSTSUB>
                    <HD SOURCE="HD1">Text of Rule and Form Amendments</HD>
                    <P>For reasons set forth in the preamble, title 17, chapter II of the Code of Federal Regulations is amended as follows:</P>
                    <PART>
                        <HD SOURCE="HED">PART 200—ORGANIZATION; CONDUCT AND ETHICS; AND INFORMATION AND REQUESTS</HD>
                        <SUBPART>
                            <HD SOURCE="HED">Subpart N—Commission Information Collection Requirements Under the Paperwork Reduction Act: OMB Control Numbers</HD>
                        </SUBPART>
                    </PART>
                    <REGTEXT TITLE="17" PART="200">
                        <AMDPAR>1. The authority citation for subpart N of part 200 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>44 U.S.C. 3506; 44 U.S.C. 3507.</P>
                        </AUTH>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="200">
                        <AMDPAR>2. Amend § 200.800 in the table in paragraph (b) by adding an entry in numerical order by part and section number for “Rule 498A” to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 200.800 </SECTNO>
                            <SUBJECT> OMB control numbers assigned pursuant to the Paperwork Reduction Act.</SUBJECT>
                            <STARS/>
                            <P>(b) * * *</P>
                            <GPOTABLE COLS="3" OPTS="L1,tp0,i1" CDEF="s25,15,15">
                                <TTITLE> </TTITLE>
                                <BOXHD>
                                    <CHED H="1">Information collection requirement</CHED>
                                    <CHED H="1">
                                        17 CFR part or 
                                        <LI>section where </LI>
                                        <LI>identified </LI>
                                        <LI>and described</LI>
                                    </CHED>
                                    <CHED H="1">
                                        Current OMB 
                                        <LI>control No.</LI>
                                    </CHED>
                                </BOXHD>
                                <ROW>
                                    <ENT I="22"> </ENT>
                                </ROW>
                                <ROW>
                                    <ENT I="28">*         *         *         *         *         *         *</ENT>
                                </ROW>
                                <ROW>
                                    <ENT I="01">Rule 498A</ENT>
                                    <ENT>230.498A</ENT>
                                    <ENT>3235-0765</ENT>
                                </ROW>
                                <ROW>
                                    <ENT I="22"> </ENT>
                                </ROW>
                                <ROW>
                                    <ENT I="28">*         *         *         *         *         *         *</ENT>
                                </ROW>
                            </GPOTABLE>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <PRTPAGE P="26093"/>
                        <HD SOURCE="HED">PART 230—GENERAL RULES AND REGULATIONS, SECURITIES ACT OF 1933</HD>
                    </PART>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>3. The authority citation for part 230 continues to read, in part, as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P>
                                 15 U.S.C. 77b, 77b note, 77c, 77d, 77f, 77g, 77h, 77j, 77r, 77s, 77z-3, 77sss, 78c, 78d, 78j, 78
                                <E T="03">l,</E>
                                 78m, 78n, 78
                                <E T="03">o,</E>
                                 78
                                <E T="03">o</E>
                                -7 note, 78t, 78w, 78
                                <E T="03">ll</E>
                                (d), 78mm, 80a-8, 80a-24, 80a-28, 80a-29, 80a-30, and 80a-37, and Public Law 112-106, sec. 201(a), sec. 401, 126 Stat. 313 (2012), unless otherwise noted.
                            </P>
                        </AUTH>
                        <EXTRACT>
                            <STARS/>
                            <P>Sections 230.400 to 230.499 issued under secs. 6, 8, 10, 19, 48 Stat. 78, 79, 81, and 85, as amended (15 U.S.C. 77f, 77h, 77j, 77s).</P>
                            <STARS/>
                        </EXTRACT>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>4. Amend § 230.159A by revising paragraph (a)(2) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.159A </SECTNO>
                            <SUBJECT> Certain definitions for purposes of Section 12(a)(2) of the Act.</SUBJECT>
                            <P>(a) * * *</P>
                            <P>
                                (2) Any free writing prospectus as defined in § 230.405 (Rule 405) relating to the offering prepared by or on behalf of the issuer or used or referred to by the issuer and, in the case of an issuer that is an open-end management company registered under the Investment Company Act of 1940 (15 U.S.C. 80a-1 
                                <E T="03">et seq.</E>
                                ) or a separate account (as defined in Section 2(a)(14) of the Securities Act) (15 U.S.C. 77b(a)(14)) registered under the Investment Company Act of 1940 on §§ 239.17a and 274.11b of this chapter (Form N-3), §§ 239.17b and 274.11c of this chapter (Form N-4), or §§ 239.17c and 274.11d of this chapter (Form N-6), any summary prospectus relating to the offering provided pursuant to § 230.498 (Rule 498) or § 230.498A (Rule 498A), respectively;
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>5. Amend § 230.431 by revising the introductory text to paragraph (a) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.431 </SECTNO>
                            <SUBJECT> Summary prospectuses.</SUBJECT>
                            <P>
                                (a) A summary prospectus prepared and filed (except a summary prospectus filed by an open-end management investment company registered under the Investment Company Act of 1940 (15 U.S.C. 80a-1 
                                <E T="03">et seq.</E>
                                ) or a separate account (as defined in section 2(a)(14) of the Securities Act (15 U.S.C. 77b(a)(14)) registered under the Investment Company Act of 1940 on §§ 239.17a and 274.11b of this chapter (Form N-3), §§ 239.17b and 274.11c of this chapter (Form N-4), or §§ 239.17c and 274.11d of this chapter (Form N-6) as part of a registration statement in accordance with this section shall be deemed to be a prospectus permitted under section 10(b) of the Act (15 U.S.C. 77j(b)) for the purposes of section 5(b)(1) of the Act (15 U.S.C. 77e(b)(1)) if the form used for registration of the securities to be offered provides for the use of a summary prospectus and the following conditions are met:
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>6. Amend § 230.482 by revising paragraph (a) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.482 </SECTNO>
                            <SUBJECT> Advertising by an investment company as satisfying requirements of section 10.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Scope of rule.</E>
                                 This section applies to an advertisement or other sales material (
                                <E T="03">advertisement</E>
                                ) with respect to securities of an investment company registered under the Investment Company Act of 1940 (15 U.S.C. 80a-1 
                                <E T="03">et seq.</E>
                                ) (
                                <E T="03">1940 Act</E>
                                ), or a business development company, that is selling or proposing to sell its securities pursuant to a registration statement that has been filed under the Act. This section does not apply to an advertisement that is excepted from the definition of prospectus by section 2(a)(10) of the Act (15 U.S.C. 77b(a)(10)), § 230.498(d), or § 230.498A(g) or (j)(2), or to a summary prospectus under § 230.498 or § 230.498A. An advertisement that complies with this section, which may include information the substance of which is not included in the prospectus specified in section 10(a) of the Act (15 U.S.C 77j(a)), will be deemed to be a prospectus under section 10(b) of the Act (15 U.S.C. 77j(b)) for the purposes of section 5(b)(1) of the Act (15 U.S.C. 77e(b)(1)).
                            </P>
                            <NOTE>
                                <HD SOURCE="HED">Note 1 to paragraph (a): </HD>
                                <P>The fact that an advertisement complies with this section does not relieve the investment company, underwriter, or dealer of any obligations with respect to the advertisement under the antifraud provisions of the Federal securities laws. For guidance about factors to be weighed in determining whether statements, representations, illustrations, and descriptions contained in investment company advertisements are misleading, see § 230.156. In addition, an advertisement that complies with this section is subject to the legibility requirements of § 230.420.</P>
                            </NOTE>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>7. Amend § 230.485 by revising paragraph (c)(3) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.485</SECTNO>
                            <SUBJECT>Effective date of post-effective amendments filed by certain registered investment companies.</SUBJECT>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>(3) A registrant's ability to file a post-effective amendment, other than an amendment filed solely for purposes of submitting an Interactive Data File, under paragraph (b) of this section is automatically suspended if a registrant fails to submit any Interactive Data File as required by General Instruction C.3.(g) of §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), or General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6). A suspension under this paragraph (c)(3) shall become effective at such time as the registrant fails to submit an Interactive Data File as required by General Instruction C.3.(g) of Form N-1A, or General Instruction C.3.(h) of Form N-3, General Instruction C.3.(h) of Form N-4, or General Instruction C.3.(h) of Form N-6. Any such suspension, so long as it is in effect, shall apply to any post-effective amendment that is filed after the suspension becomes effective, but shall not apply to any post-effective amendment that was filed before the suspension became effective. Any suspension shall apply only to the ability to file a post-effective amendment pursuant to paragraph (b) of this section and shall not otherwise affect any post-effective amendment. Any suspension under this paragraph (c)(3) shall terminate as soon as a registrant has submitted the Interactive Data File as required by General Instruction C.3.(g) of Form N-1A, General Instruction C.3.(h) of Form N-3, General Instruction C.3.(h) of Form N-4, or General Instruction C.3.(h) of Form N-6.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>8. Revise § 230.496 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.496 </SECTNO>
                            <SUBJECT>Contents of prospectus and statement of additional information used after nine months.</SUBJECT>
                            <P>In the case of a registration statement filed on Form N-1A (§§ 239.15A and 274.11A of this chapter), Form N-2 (§§ 239.14 and 274.11a-1 of this chapter), Form N-3 (§§ 239.17a and 274.11b of this chapter), Form N-4 (§§ 239.17b and 274.11c of this chapter), or Form N-6 (§§ 239.17c and 274.11d of this chapter), there may be omitted from any prospectus or Statement of Additional Information used more than nine months after the effective date of the registration statement any information previously required to be contained in the prospectus or the Statement of Additional Information insofar as later information covering the same subjects, including the latest available certified financial statements, as of a date not more than 16 months prior to the use of the prospectus or the Statement of Additional Information is contained therein.</P>
                            <NOTE>
                                <PRTPAGE P="26094"/>
                                <HD SOURCE="HED">Note 1 to § 230.496:</HD>
                                <P> For a discussion of the effectiveness of a registration statement relating to certain discontinued contracts subject to a Commission position as of July 1, 2020, see Investment Company Release No. 33814 (March 11, 2020). </P>
                            </NOTE>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>9. Amend § 230.497 by revising paragraphs (c), (e), and (k) and removing the parenthetical authority at the end of the section to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.497 </SECTNO>
                            <SUBJECT>Filing of investment company prospectuses—number of copies.</SUBJECT>
                            <STARS/>
                            <P>(c) For investment companies filing on §§ 239.15A and 274.11A of this chapter (Form N-1A), §§ 239.14 and 274.11a-1 of this chapter (Form N-2), §§ 239.17a and 274.11b of this chapter (Form N-3), §§ 239.17b and 274.11c of this chapter (Form N-4), or §§ 239.17c and 274.11d of this chapter (Form N-6), within five days after the effective date of a registration statement or the commencement of a public offering after the effective date of a registration statement, whichever occurs later, 10 copies of each form of prospectus and form of Statement of Additional Information used after the effective date in connection with such offering shall be filed with the Commission in the exact form in which it was used. Investment companies filing on Forms N-1A, N-3, N-4, or N-6 must, if applicable pursuant to General Instruction C.3.(g) of Form N-1A, General Instruction C.3.(h) of Form N-3, General Instruction C.3.(h) of Form N-4, or General Instruction C.3.(h) of Form N-6, submit an Interactive Data File (as defined in § 232.11 of this chapter).</P>
                            <STARS/>
                            <P>(e) For investment companies filing on §§ 239.15A and 274.11A of this chapter (Form N-1A), §§ 239.14 and 274.11a-1 of this chapter (Form N-2), §§ 239.17a and 274.11b of this chapter (Form N-3), §§ 239.17b and 274.11c of this chapter (Form N-4), or §§ 239.17c and 274.11d of this chapter (Form N-6), after the effective date of a registration statement, no prospectus that purports to comply with Section 10 of the Act (15 U.S.C. 77j) or Statement of Additional Information that varies from any form of prospectus or form of Statement of Additional Information filed pursuant to paragraph (c) of this section shall be used until five copies thereof have been filed with, or mailed for filing to the Commission. Investment companies filing on Forms N-1A, N-3, N-4, or N-6 must, if applicable pursuant to General Instruction C.3.(g) of Form N-1A, General Instruction C.3.(h) of Form N-3, General Instruction C.3.(h) of Form N-4, or General Instruction C.3.(h) of Form N-6, submit an Interactive Data File (as defined in § 232.11 of this chapter).</P>
                            <STARS/>
                            <P>(k) This paragraph (k), and not the other provisions of this section, shall govern the filing of summary prospectuses under §§ 230.498 and 230.498A. Each definitive form of a summary prospectus under §§ 230.498 and 230.498A shall be filed with the Commission no later than the date that it is first used. </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>10. Amend § 230.498 by revising paragraph (c)(2) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.498 </SECTNO>
                            <SUBJECT>Summary Prospectuses for open-end management investment companies.</SUBJECT>
                            <STARS/>
                            <P>(c) * * *</P>
                            <P>(2) The Summary Prospectus is not bound together with any materials, except that a Summary Prospectus for a Fund that is available as an investment option in a variable annuity or variable life insurance contract may be bound together with the Statutory Prospectus for the contract (or a summary prospectus for the contract provided under § 230.498A) and Summary Prospectuses and Statutory Prospectuses for other investment options available in the contract, provided that:</P>
                            <P>(i) All of the Funds to which the Summary Prospectuses and Statutory Prospectuses that are bound together relate are available to the person to whom such documents are sent or given; and</P>
                            <P>(ii) A table of contents identifying each Summary Prospectus, Statutory Prospectus, and summary prospectus under § 230.498A that is bound together, and the page number on which it is found, is included at the beginning or immediately following a cover page of the bound materials;</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>11. Add § 230.498A to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 230.498A </SECTNO>
                            <SUBJECT>Summary Prospectuses for separate accounts offering variable annuity and variable life insurance contracts.</SUBJECT>
                            <P>
                                (a) 
                                <E T="03">Definitions.</E>
                                 For purposes of this section:
                            </P>
                            <P>
                                <E T="03">Class</E>
                                 means a class of a Contract that varies principally with respect to distribution-related fees and expenses.
                            </P>
                            <P>
                                <E T="03">Contract</E>
                                 means a Variable Annuity Contract or a Variable Life Insurance Contract as defined in this section, respectively.
                            </P>
                            <P>
                                <E T="03">Depositor</E>
                                 means the person primarily responsible for the organization of the Registrant and the person, other than the trustee or custodian, who has continuing functions or responsibilities with respect to the administration of the affairs of the Registrant. “Depositor” includes the sponsoring insurance company that establishes and maintains the Registrant.
                            </P>
                            <P>
                                <E T="03">Initial Summary Prospectus</E>
                                 means the initial summary prospectus described in paragraph (b) of this section.
                            </P>
                            <P>
                                <E T="03">Investment Option</E>
                                 means any portfolio of investments in which a Registrant on Form N-3 invests and which may be selected as an option by the investor.
                            </P>
                            <P>
                                <E T="03">Portfolio Company</E>
                                 means any company in which a Registrant on Form N-4 or Form N-6 invests and which may be selected as an option by the investor.
                            </P>
                            <P>
                                <E T="03">Portfolio Company Prospectus</E>
                                 means the Statutory Prospectus of a Portfolio Company and a summary prospectus of a Portfolio Company permitted by § 230.498.
                            </P>
                            <P>
                                <E T="03">Registrant</E>
                                 means a separate account (as defined in section 2(a)(14) of the Securities Act (15 U.S.C. 77b(a)(14)) that has an effective registration statement on §§ 239.17a and 274.11b of this chapter (Form N-3), §§ 239.17b and 274.11c of this chapter (Form N-4), or §§ 239.17c and 274.11d of this chapter (Form N-6) and that has a current prospectus that satisfies the requirements of section 10(a) of the Act (15 U.S.C. 77j(a)).
                            </P>
                            <P>
                                <E T="03">Statement of Additional Information</E>
                                 means the statement of additional information required by Part B of Form N-1A, Form N-3, Form N-4, or Form N-6.
                            </P>
                            <P>
                                <E T="03">Statutory Prospectus</E>
                                 means a prospectus that satisfies the requirements of section 10(a) of the Act (15 U.S.C. 77j(a)).
                            </P>
                            <P>
                                <E T="03">Summary Prospectus</E>
                                 refers to both the Initial Summary Prospectus and the Updating Summary Prospectus.
                            </P>
                            <P>
                                <E T="03">Updating Summary Prospectus</E>
                                 means the updating summary prospectus described in paragraph (c) of this section.
                            </P>
                            <P>
                                <E T="03">Variable Annuity Contract</E>
                                 means any accumulation contract or annuity contract, any portion thereof, or any unit of interest or participation therein pursuant to which the value of the contract, either during an accumulation period or after annuitization, or both, may vary with the investment performance of any separate account.
                            </P>
                            <P>
                                <E T="03">Variable Life Insurance Contract</E>
                                 means a life insurance contract that provides for death benefits and cash values that may vary with the investment performance of any separate account.
                            </P>
                            <P>
                                (b) 
                                <E T="03">General requirements for Initial Summary Prospectus.</E>
                                 An Initial Summary Prospectus that complies with 
                                <PRTPAGE P="26095"/>
                                this paragraph (b) will be deemed to be a prospectus that is authorized under section 10(b) of the Act (15 U.S.C. 77j(b)) and section 24(g) of the Investment Company Act (15 U.S.C. 80a-24(g)) for the purposes of section 5(b)(1) of the Act (15 U.S.C. 77e(b)(1)).
                            </P>
                            <P>
                                (1) 
                                <E T="03">Scope of Initial Summary Prospectus.</E>
                                 An Initial Summary Prospectus may only describe a single Contract (but may describe more than one Class of the Contract) currently offered by the Registrant under the Statutory Prospectus to which the Initial Summary Prospectus relates.
                            </P>
                            <P>
                                (2) 
                                <E T="03">Cover page or beginning of Initial Summary Prospectus.</E>
                                 Include on the front cover page or the beginning of the Initial Summary Prospectus:
                            </P>
                            <P>(i) The Depositor's name;</P>
                            <P>(ii) The name of the Contract, and the Class or Classes if any, to which the Initial Summary Prospectus relates;</P>
                            <P>(iii) A statement identifying the document as a “Summary Prospectus for New Investors”;</P>
                            <P>(iv) The approximate date of the first use of the Initial Summary Prospectus;</P>
                            <P>(v) The following legend:</P>
                            <P>This Summary Prospectus summarizes key features of the [Contract].</P>
                            <P>Before you invest, you should also review the prospectus for the [Contract], which contains more information about the [Contract's] features, benefits, and risks. You can find this document and other information about the [Contract] online at [___]. You can also obtain this information at no cost by calling[____] or by sending an email requestto [___].</P>
                            <P>You may cancel your [Contract] within 10 days of receiving it without paying fees or penalties. In some states, this cancellation period may be longer. Upon cancellation, you will receive either a full refund of the amount you paid with your application or your total contract value. You should review the prospectus, or consult with your investment professional, for additional information about the specific cancellation terms that apply.</P>
                            <P>
                                Additional information about certain investment products, including [variable annuities/variable life insurance contracts], has been prepared by the Securities and Exchange Commission's staff and is available at 
                                <E T="03">Investor.gov.</E>
                            </P>
                            <P>(A) A Registrant may modify the legend so long as the modified legend contains comparable information.</P>
                            <P>(B) The legend must provide a website address, other than the address of the Commission's electronic filing system; toll-free telephone number; and email address that investors can use to obtain the Statutory Prospectus and other materials, request other information about the Contract, and make investor inquiries. The website address must be specific enough to lead investors directly to the Statutory Prospectus and other materials that are required to be accessible under paragraph (h)(1) of this section, rather than to the home page or other section of the website on which the materials are posted. The website could be a central site with prominent links to each document. The legend may indicate, if applicable, that the Statutory Prospectus and other information are available from a financial intermediary (such as a broker-dealer) through which the Contract may be purchased or sold. If a Fund relies on § 270.30e-3 of this chapter to transmit a report, the legend must also include the website address required by § 270.30e-3(c)(1)(iii) of this chapter if different from the website address required by this paragraph (b)(2)(v)(B).</P>
                            <P>(C) The paragraph of the legend regarding cancellation of the Contract may be omitted if not applicable. If this paragraph is included in the legend, the paragraph must be presented in a manner reasonably calculated to draw investor attention to that paragraph.</P>
                            <P>(D) The legend may include instructions describing how a shareholder can elect to receive prospectuses or other documents and communications by electronic delivery.</P>
                            <P>(E) The legend for a Contract registered on Form N-3 shall include a statement to the following effect, if applicable:</P>
                            <P>Beginning on [date], as permitted by regulations adopted by the Securities and Exchange Commission, paper copies of [the Registrant's] shareholder reports will no longer be sent by mail, unless you specifically request paper copies of the reports from [the Registrant] [or from your financial intermediary, such as a broker-dealer or bank]. Instead, the reports will be made available on a website, and you will be notified by mail each time a report is posted and provided with a website link to access the report.</P>
                            <P>If you already elected to receive shareholder reports electronically, you will not be affected by this change and you need not take any action. You may elect to receive shareholder reports and other communications from [the Registrant] [or your financial intermediary] electronically by [insert instructions].</P>
                            <P>You may elect to receive all future reports in paper free of charge. You can inform [the Registrant] [or your financial intermediary] that you wish to continue receiving paper copies of your shareholder reports by [insert instructions]. Your election to receive reports in paper will apply to all [funds] held with [the fund complex/your financial intermediary].</P>
                            <P>(F) The legend for a Contract registered on Form N-4 or N-6 shall include a statement to the following effect, if applicable:</P>
                            <P>Beginning on [date], as permitted by regulations adopted by the Securities and Exchange Commission, paper copies of the shareholder reports for [Portfolio Companies available under your Contract] will no longer be sent by mail, unless you specifically request paper copies of the reports from [the Registrant] [or from your financial intermediary, such as a broker-dealer or bank]. Instead, the reports will be made available on a website, and you will be notified by mail each time a report is posted and provided with a website link to access the report.</P>
                            <P>If you already elected to receive shareholder reports electronically, you will not be affected by this change and you need not take any action. You may elect to receive shareholder reports and other communications from [the Portfolio Companies] [or your financial intermediary] electronically by [insert instructions].</P>
                            <P>You may elect to receive all future reports in paper free of charge. You can inform [the Registrant] [or your financial intermediary] that you wish to continue receiving paper copies of your shareholder reports by [insert instructions]. Your election to receive reports in paper will apply to all portfolio companies [available under your Contract].</P>
                            <P>
                                (3) 
                                <E T="03">Back cover page or last page of Initial Summary Prospectus.</E>
                                 (i) If a Registrant incorporates any information by reference into the Summary Prospectus, include a legend identifying the type of document (
                                <E T="03">e.g.,</E>
                                 Statutory Prospectus) from which the information is incorporated and the date of the document. If a Registrant incorporates by reference a part of a document, the legend must clearly identify the part by page, paragraph, caption, or otherwise. If information is incorporated from a source other than the Statutory Prospectus, the legend must explain that the incorporated information may be obtained, free of charge, in the same manner as the Statutory Prospectus.
                            </P>
                            <P>
                                (ii) Include on the bottom of the back cover page or the last page of the Initial Summary Prospectus the EDGAR contract identifier for the contract in type size smaller than that generally used in the prospectus (
                                <E T="03">e.g.,</E>
                                 8-point modern type).
                                <PRTPAGE P="26096"/>
                            </P>
                            <P>
                                (4) 
                                <E T="03">Table of contents.</E>
                                 An Initial Summary Prospectus may include a table of contents meeting the requirements of § 230.481(c).
                            </P>
                            <P>
                                (5) 
                                <E T="03">Contents of Initial Summary Prospectus.</E>
                                 An Initial Summary Prospectus must contain the information required by this paragraph (b)(5) with respect to the applicable registration form, and only the information required by this paragraph (b)(5), in the order provided in paragraphs (b)(5)(i) through (ix) of this section.
                            </P>
                            <P>(i) Under the heading “Important Information You Should Consider About the [Contract],” the information required by Item 2 of Form N-3, Item 2 of Form N-4, or Item 2 of Form N-6.</P>
                            <P>(ii) Under the heading “Overview of the [Contract],” the information required by Item 3 of Form N-3, Item 3 of Form N-4, or Item 3 of Form N-6.</P>
                            <P>(iii) Under the heading “Standard Death Benefits,” the information required by Item 10(a) of Form N-6.</P>
                            <P>(iv) Under the heading “Benefits Available Under the [Contract],” the information required by Item 11(a) of Form N-3 or Item 10(a) of Form N-4. Under the heading “Other Benefits Available Under the [Contract],” the information required by Item 11(a) of Form N-6.</P>
                            <P>(v) Under the heading “Buying the [Contract],” the information required by Item 12(a) of Form N-3, Item 11(a) of Form N-4, or Item 9(a) through (c) of Form N-6.</P>
                            <P>(vi) Under the heading “How Your [Contract] Can Lapse,” the information required by Item 14(a) through (c) of Form N-6.</P>
                            <P>(vii) Under the heading “Making Withdrawals: Accessing the Money in Your [Contract],” the information required by Item 13(a) of Form N-3, Item 12(a) of Form N-4, or Item 12(a) of Form N-6.</P>
                            <P>(viii) Under the heading “Additional Information About Fees,” the information required by Item 4 of Form N-3, Item 4 of Form N-4, or Item 4 of Form N-6.</P>
                            <P>(ix) Under the heading “Appendix: [Portfolio Companies] Available Under the Contract,” include as an appendix the information required by Item 18 of Form N-3, Item 17 of Form N-4, or Item 18 of Form N-6. Alternatively, an Initial Summary Prospectus for a Contract registered on Form N-3 may include the information required by Item 19 of Form N-3 under the heading “Additional Information About Investment Options Available Under the Contract.”</P>
                            <P>
                                (c) 
                                <E T="03">General requirements for Updating Summary Prospectus.</E>
                                 An Updating Summary Prospectus that complies with this paragraph (c) will be deemed to be a prospectus that is authorized under section 10(b) of the Act (15 U.S.C. 77j(b)) and section 24(g) of the Investment Company Act (15 U.S.C. 80a-24(g)) for the purposes of section 5(b)(1) of the Act (15 U.S.C. 77e(b)(1)).
                            </P>
                            <P>
                                (1) 
                                <E T="03">Use of Updating Summary Prospectus.</E>
                                 A Registrant may only use an Updating Summary Prospectus if the Registrant uses an Initial Summary Prospectus for each currently offered Contract described under the Statutory Prospectus to which the Updating Summary Prospectus relates.
                            </P>
                            <P>
                                (2) 
                                <E T="03">Scope of Updating Summary Prospectus.</E>
                                 An Updating Summary Prospectus may describe one or more Contracts (and more than one Class) described under the Statutory Prospectus to which the Updating Summary Prospectus relates.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Cover page or beginning of Updating Summary Prospectus.</E>
                                 Include on the front cover page or at the beginning of the Updating Summary Prospectus:
                            </P>
                            <P>(i) The Depositor's name;</P>
                            <P>(ii) The name of the Contract(s) and the Class or Classes, if any, to which the Updating Summary Prospectus relates;</P>
                            <P>(iii) A statement identifying the document as an “Updating Summary Prospectus”;</P>
                            <P>(iv) The approximate date of the first use of the Updating Summary Prospectus; and</P>
                            <P>(v)(A) The following legend, which must meet the requirements of paragraphs (b)(2)(v)(A), (B), and (D) of this section, as applicable:</P>
                            <P>The prospectus for the [Contract] contains more information about the [Contract], including its features, benefits, and risks. You can find the current prospectus and other information about the [Contract] online at [___]. You can also obtain this information at no cost by calling[____] or by sending an email requestto [___].</P>
                            <P>
                                Additional information about certain investment products, including [variable annuities/variable life insurance contracts], has been prepared by the Securities and Exchange Commission's staff and is available at 
                                <E T="03">Investor.gov.</E>
                            </P>
                            <P>(B) The legend required by paragraphs (b)(2)(v)(E) and (F) of this section, as applicable.</P>
                            <P>
                                (4) 
                                <E T="03">Back cover page or last page of Updating Summary Prospectus.</E>
                                 Include on the bottom of the back cover page or the last page of the Updating Summary Prospectus:
                            </P>
                            <P>(i) The legend required by paragraph (b)(3)(i) of this section; and</P>
                            <P>
                                (ii) The EDGAR contract identifier(s) for each contract in type size smaller than that generally used in the prospectus (
                                <E T="03">e.g.,</E>
                                 8-point modern type).
                            </P>
                            <P>
                                (5) 
                                <E T="03">Table of contents.</E>
                                 An Updating Summary Prospectus may include a table of contents meeting the requirements of § 230.481(c).
                            </P>
                            <P>
                                (6) 
                                <E T="03">Contents of Updating Summary Prospectus.</E>
                                 An Updating Summary Prospectus must contain the information required by this paragraph (c)(6) with respect to the applicable registration form, in the order provided in paragraphs (c)(6)(i) through (iv) of this section.
                            </P>
                            <P>(i) If any changes have been made with respect to the Contract after the date of the most recent Updating Summary Prospectus or Statutory Prospectus that was sent or given to investors with respect to the availability of Investment Options (for Registrants on Form N-3) or Portfolio Companies (for Registrants on Forms N-4 and N-6) under the Contract, or the disclosure that the Registrant included in response to Item 2 (Key Information), Item 3 (Overview of the Contract), Item 4 (Fee Table), Item 11 (Benefits Available Under the Contract), Item 12 (Purchases and Contract Value), or Item 13 (Surrenders and Withdrawals) of Form N-3; Item 2 (Key Information), Item 3 (Overview of the Contract), Item 4 (Fee Table), Item 10 (Benefits Available Under the Contract), Item 11 (Purchases and Contract Value), or Item 12 (Surrenders and Withdrawals) of Form N-4; and Item 2 (Key Information), Item 3 (Overview of the Contract), Item 4 (Fee Table), Item 9 (Premiums), Item 10 (Standard Death Benefits), Item 11 (Other Benefits Available Under the Contract), Item 12 (Surrenders and Withdrawals), or Item 14 (Lapse and Reinstatement) of Form N-6, include the following as applicable, under the heading “Updated Information About Your [Contract]”:</P>
                            <P>(A) The following legend: “The information in this Updating Summary Prospectus is a summary of certain [Contract] features that have changed since the Updating Summary Prospectus dated [date]. This may not reflect all of the changes that have occurred since you entered into your [Contract].”</P>
                            <P>(B) As applicable, provide a concise description of each change specified in paragraph (c)(6)(i) of this section. Provide enough detail to allow investors to understand the change and how it will affect investors, including indicating whether the change only applies to certain Contracts described in the Updating Summary Prospectus.</P>
                            <P>
                                (ii) In addition to the changes specified in paragraph (c)(6)(i) of this 
                                <PRTPAGE P="26097"/>
                                section, a Registrant may provide a concise description of any other information relevant to the Contract within the time period that paragraph (c)(6)(i) of this section specifies, under the heading “Updated Information About Your [Contract].” Any additional information included pursuant to this paragraph (c)(6)(ii) should not, by its nature, quantity, or manner of presentation, obscure or impede understanding of the information that paragraph (c)(6)(i) of this section requires.
                            </P>
                            <P>(iii) Under the heading “Important Information You Should Consider About the [Contract],” provide the information required by Item 2 of Form N-3, Item 2 of Form N-4, or Item 2 of Form N-6.</P>
                            <P>(iv) Under the heading “Appendix: [Portfolio Companies/Investment Options] Available Under the [Contract],” include as an appendix the information required by Item 18 of Form N-3, Item 17 of Form N-4, or Item 18 of Form N-6. Alternatively, an Updating Summary Prospectus for a Contract registered on Form N-3 may include, under the heading “Additional Information About [Investment Options] Available Under the [Contract],” the information required by Item 19 of Form N-3.</P>
                            <P>
                                (d) 
                                <E T="03">Incorporation by reference into a Summary Prospectus.</E>
                                 (1) Except as provided by paragraph (d)(2) of this section, information may not be incorporated by reference into a Summary Prospectus. Information that is incorporated by reference into a Summary Prospectus in accordance with paragraph (d)(2) of this section need not be sent or given with the Summary Prospectus.
                            </P>
                            <P>(2) A Registrant may incorporate by reference into a Summary Prospectus any or all of the information contained in the Registrant's Statutory Prospectus and Statement of Additional Information, and any information from the Registrant's reports under § 270.30e-1 of this chapter that the Registrant has incorporated by reference into the Registrant's Statutory Prospectus, provided that:</P>
                            <P>(i) The conditions of paragraphs (b)(2)(v)(B), (c)(3)(v), and (h) of this section are met;</P>
                            <P>(ii) A Registrant may not incorporate by reference into a Summary Prospectus information that paragraphs (b) and (c) of this section require to be included in an Initial Summary Prospectus or Updating Summary Prospectus, respectively; and</P>
                            <P>(iii) Information that is permitted to be incorporated by reference into the Summary Prospectus may be incorporated by reference into the Summary Prospectus only by reference to the specific document that contains the information, not by reference to another document that incorporates such information by reference.</P>
                            <P>(3) For purposes of § 230.159 of this chapter, information is conveyed to a person not later than the time that a Summary Prospectus is received by the person if the information is incorporated by reference into the Summary Prospectus in accordance with paragraph (d)(2) of this section.</P>
                            <P>
                                (e) 
                                <E T="03">Terms used in the Summary Prospectus.</E>
                                 Define special terms used in the Initial Summary Prospectus and Updating Summary Prospectus using any presentation style that clearly conveys their meaning to investors, such as the use of a glossary or list of definitions.
                            </P>
                            <P>
                                (f) 
                                <E T="03">Transfer of the Contract security.</E>
                                 Any obligation under section 5(b)(2) of the Act (15 U.S.C. 77e(b)(2)) to have a Statutory Prospectus precede or accompany the carrying or delivery of a Contract security in an offering registered on Form N-3, Form N-4, or Form N-6 is satisfied if:
                            </P>
                            <P>(1) A Summary Prospectus is sent or given no later than the time of the carrying or delivery of the Contract security (an Initial Summary Prospectus in the case of a purchase of a new Contract, or an Updating Summary Prospectus in the case of additional purchase payments in an existing Contract);</P>
                            <P>(2) The Summary Prospectus is not bound together with any materials except Portfolio Company Prospectuses for Portfolio Companies available as investment options under the Contract, provided that:</P>
                            <P>(i) All of the Portfolio Companies are available as investment options to the person to whom such documents are sent or given; and</P>
                            <P>(ii) A table of contents identifying each Portfolio Company Prospectus that is bound together, and the page number on which each document is found, is included at the beginning or immediately following a cover page of the bound materials.</P>
                            <P>(3) The Summary Prospectus that is sent or given satisfies the requirements of paragraph (b) or (c) of this section, as applicable, at the time of the carrying or delivery of the Contract security; and</P>
                            <P>(4) The conditions set forth in paragraph (h) of this section are satisfied.</P>
                            <P>
                                (g) 
                                <E T="03">Sending communications.</E>
                                 A communication relating to an offering registered on Form N-3, Form N-4, or Form N-6 sent or given after the effective date of a Contract's registration statement (other than a prospectus permitted or required under section 10 of the Act) shall not be deemed a prospectus under section 2(a)(10) of the Act (15 U.S.C. 77b(a)(10)) if:
                            </P>
                            <P>(1) It is proved that prior to or at the same time with such communication a Summary Prospectus was sent or given to the person to whom the communication was made;</P>
                            <P>(2) The Summary Prospectus is not bound together with any materials, except as permitted by paragraph (f)(2) of this section;</P>
                            <P>(3) The Summary Prospectus that was sent or given satisfies the requirements of paragraph (b) or (c) of this section, as applicable, at the time of such communication; and</P>
                            <P>(4) The conditions set forth in paragraph (h) of this section are satisfied.</P>
                            <P>
                                (h) 
                                <E T="03">Availability of the Statutory Prospectus and certain other documents.</E>
                                 (1) The current Initial Summary Prospectus, Updating Summary Prospectus, Statutory Prospectus, Statement of Additional Information, and in the case of a Registrant on Form N-3, the Registrant's most recent annual and semi-annual reports to shareholders under § 270.30e-1, are publicly accessible, free of charge, at the website address specified on the cover page or beginning of the Summary Prospectuses, on or before the time that the Summary Prospectuses are sent or given and current versions of those documents remain on the website through the date that is at least 90 days after:
                            </P>
                            <P>(i) In the case of reliance on paragraph (f) of this section, the date that the Contract security is carried or delivered; or</P>
                            <P>(ii) In the case of reliance on paragraph (g) of this section, the date that the communication is sent or given.</P>
                            <P>(2) The materials that are accessible in accordance with paragraph (h)(1) of this section must be presented on the website in a format, or formats, that:</P>
                            <P>(i) Are human-readable and capable of being printed on paper in human-readable format;</P>
                            <P>
                                (ii) Permit persons accessing the Statutory Prospectus or Statement of Additional Information for the Contract to move directly back and forth between each section heading in a table of contents of such document and the section of the document referenced in that section heading; provided that, in the case of the Statutory Prospectus, the table of contents is either required by § 230.481(c) or contains the same section headings as the table of contents required by § 230.481(c); and
                                <PRTPAGE P="26098"/>
                            </P>
                            <P>(iii) Permit persons accessing a Summary Prospectus to move directly back and forth between:</P>
                            <P>(A) Each section of the Summary Prospectus and any section of the Statutory Prospectus and Contract Statement of Additional Information that provides additional detail concerning that section of the Summary Prospectus; or</P>
                            <P>(B) Links located at both the beginning and end of the Summary Prospectus, or that remain continuously visible to persons accessing the Summary Prospectus, and tables of contents of both the Statutory Prospectus and the Contract Statement of Additional Information that meet the requirements of paragraph (h)(2)(ii) of this section.</P>
                            <P>
                                (iv) Permit persons accessing the Summary Prospectus to view the definition of each special term used in the Summary Prospectus (as required by paragraph (e) of this section) upon command (
                                <E T="03">e.g.,</E>
                                 by moving or “hovering” the computer's pointer or mouse over the term, or selecting the term on a mobile device); or permits persons accessing the Contract Summary Prospectus to move directly back and forth between each special term and the corresponding entry in any glossary or list of definitions in the Contract Summary Prospectus (as described in paragraph (e) of this section).
                            </P>
                            <P>(3) Persons accessing the materials specified in paragraph (h)(1) of this section must be able to permanently retain, free of charge, an electronic version of such materials in a format, or formats, that meet each of the requirements of paragraphs (h)(2)(i) and (ii) of this section.</P>
                            <P>(4) The conditions set forth in paragraphs (h)(1) through (3) of this section shall be deemed to be met, notwithstanding the fact that the materials specified in paragraph (h)(1) of this section are not available for a time in the manner required by paragraphs (h)(1) through (3) of this section, provided that:</P>
                            <P>(i) The Registrant has reasonable procedures in place to ensure that the specified materials are available in the manner required by paragraphs (h)(1) through (3) of this section; and</P>
                            <P>(ii) The Registrant takes prompt action to ensure that the specified documents become available in the manner required by paragraphs (h) through (3) of this section, as soon as practicable following the earlier of the time at which it knows or reasonably should have known that the documents are not available in the manner required by paragraphs (h)(1) through (3) of this section.</P>
                            <P>
                                (i) 
                                <E T="03">Other requirements</E>
                                —(1) 
                                <E T="03">Delivery upon request.</E>
                                 If paragraph (f) or (g) of this section is relied on with respect to a Contract, the Registrant (or a financial intermediary through which the Contract may be purchased) must send, at no cost to the requestor and by U.S. first class mail or other reasonably prompt means, a paper copy of the Contract Statutory Prospectus, Contract Statement of Additional Information, and in the case of a Registrant on Form N-3, the Registrant's most recent annual and semi-annual reports to shareholders under § 270.30e-1 of this chapter, to any person requesting such a copy within three business days after receiving a request for a paper copy. If paragraph (f) or (g) of this section is relied on with respect to a Contract, the Registrant (or a financial intermediary through which Contract may be purchased) must send, at no cost to the requestor, and by email, an electronic copy of any of the documents listed in this paragraph (i)(1) to any person requesting a copy of such document within three business days after receiving a request for an electronic copy. The requirement to send an electronic copy of a document may be satisfied by sending a direct link to the online document; provided that a current version of the document is directly accessible through the link from the time that the email is sent through the date that is six months after the date that the email is sent and the email explains both how long the link will remain useable and that, if the recipient desires to retain a copy of the document, he or she should access and save the document.
                            </P>
                            <P>
                                (2) 
                                <E T="03">Greater prominence.</E>
                                 If paragraph (f) or (g) of this section is relied on with respect to a Contract, the Summary Prospectus shall be given greater prominence than any materials that accompany the Summary Prospectus.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Convenient for reading and printing.</E>
                                 If paragraph (f) or (g) of this section is relied on with respect to a Contract:
                            </P>
                            <P>(i) The materials that are accessible in accordance with paragraph (h)(1) of this section must be presented on the website in a format, or formats, that are convenient for both reading online and printing on paper; and</P>
                            <P>(ii) Persons accessing the materials that are accessible in accordance with paragraph (h)(1) of this section must be able to permanently retain, free of charge, an electronic version of such materials in a format, or formats, that are convenient for both reading online and printing on paper.</P>
                            <P>
                                (4) 
                                <E T="03">Website addresses.</E>
                                 If paragraph (f) or (g) of this section is relied on with respect to a Contract, any website address that is included in an electronic version of the Summary Prospectus must include an active hyperlink or provide another means of facilitating access through equivalent methods or technologies that lead directly to the relevant website address. This paragraph (i)(4) does not apply to electronic versions of a Summary Prospectus that are filed on the EDGAR system.
                            </P>
                            <P>
                                (5) 
                                <E T="03">Compliance with this paragraph (i) not a condition to reliance on paragraph (f) or (g) of this section.</E>
                                 Compliance with this paragraph (i) is not a condition to the ability to rely on paragraph (f) or (g) of this section with respect to a Contract, and failure to comply with this paragraph (i) does not negate the ability to rely on paragraph (f) or (g) of this section.
                            </P>
                            <P>
                                (j) 
                                <E T="03">Portfolio Company Prospectuses</E>
                                —(1) 
                                <E T="03">Transfer of the Portfolio Company security.</E>
                                 Any obligation under section 5(b)(2) of the Act to have a Statutory Prospectus precede or accompany the carrying or delivery of a Portfolio Company security is satisfied if, and information contained in the documents referenced in paragraph (j)(1)(ii) of this section is conveyed for purposes of § 230.159 when:
                            </P>
                            <P>(i) An Initial Summary Prospectus is used for each currently offered Contract described under the related registration statement;</P>
                            <P>(ii) A summary prospectus is used for the Portfolio Company (if the Portfolio Company is registered on Form N-1A); and</P>
                            <P>(iii) The current summary prospectus, Statutory Prospectus, Statement of Additional Information, and most recent annual and semi-annual reports to shareholders under § 270.30e-1 of this chapter for the Portfolio Company are publicly accessible, free of charge, at the same website address referenced in paragraph (h)(1) of this section, and are accessible under the conditions set forth in paragraphs (h)(1), (h)(2)(i) and (ii), and (h)(3) and (4) of this section, with respect to the availability of documents relating to the Contract.</P>
                            <P>
                                (2) 
                                <E T="03">Communications.</E>
                                 Any communication relating to a Portfolio Company (other than a prospectus permitted or required under section 10 of the Act) shall not be deemed a prospectus under section 2(a)(10) of the Act (15 U.S.C. 77b(a)(10)) if the conditions set forth in paragraph (j)(1) of this section are satisfied.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Other requirements.</E>
                                 The materials referenced in paragraph (j)(1)(iii) of this section must be delivered upon request, 
                                <PRTPAGE P="26099"/>
                                presented, and able to be retained under the conditions set forth in paragraphs (i)(1) and (3) of this section. Compliance with this paragraph (j)(3) is not a condition to the ability to rely on paragraph (j)(1) or (2) of this section, and failure to comply with this paragraph (j)(3) does not negate the ability to rely on paragraph (j)(1) or (2) of this section.
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 230.498A </SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="230">
                        <AMDPAR>12. Effective January 1, 2022, § 230.498A is further amended by:</AMDPAR>
                        <AMDPAR>a. Removing paragraphs (b)(2)(v)(E) and (F); and</AMDPAR>
                        <AMDPAR>b. Removing and reserving paragraph (c)(3)(v)(B).</AMDPAR>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 232—REGULATION S-T—GENERAL RULES AND REGULATIONS FOR ELECTRONIC FILINGS</HD>
                    </PART>
                    <REGTEXT TITLE="17" PART="232">
                        <AMDPAR>13. The authority citation for part 232 continues to read, in part, as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>
                                15 U.S.C. 77c, 77f, 77g, 77h, 77j, 77s(a), 77z-3, 77sss(a), 78c(b), 78
                                <E T="03">l,</E>
                                 78m, 78n, 78
                                <E T="03">o</E>
                                (d), 78w(a), 78
                                <E T="03">ll,</E>
                                 80a-6(c), 80a-8, 80a-29, 80a-30, 80a-37, 7201 
                                <E T="03">et seq.,</E>
                                 and 18 U.S.C. 1350, unless otherwise noted.
                            </P>
                        </AUTH>
                        <STARS/>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="232">
                        <AMDPAR>14. Amend § 232.11 by revising the definition of “Related Official Filing” to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 232.11 </SECTNO>
                            <SUBJECT> Definition of terms used in part 232.</SUBJECT>
                            <STARS/>
                            <P>
                                <E T="03">Related Official Filing.</E>
                                 The term 
                                <E T="03">Related Official Filing</E>
                                 means the ASCII or HTML format part of the official filing with which all or part of an Interactive Data File appears as an exhibit or, in the case of a filing on §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), and General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6), the ASCII or HTML format part of an official filing that contains the information to which an Interactive Data File corresponds.
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="232">
                        <AMDPAR>15. Amend § 232.405 by:</AMDPAR>
                        <AMDPAR>a. Revising the introductory text and paragraphs (a)(2), (a)(3)(i) introductory text, (a)(3)(ii), and (a)(4);</AMDPAR>
                        <AMDPAR>b. Adding a heading for paragraph (b);</AMDPAR>
                        <AMDPAR>c. Revising paragraphs (b)(1) introductory text and (b)(2); and</AMDPAR>
                        <AMDPAR>d. Redesignating the Note to § 232.405 as Note 2 to § 232.405 and revising the newly redesignated note.</AMDPAR>
                        <P>The revisions and addition read as follows:</P>
                        <SECTION>
                            <SECTNO>§ 232.405 </SECTNO>
                            <SUBJECT> Interactive Data File submissions.</SUBJECT>
                            <P>This section applies to electronic filers that submit Interactive Data Files. Section 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K), paragraph (101) of Part II—Information Not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10), paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form F-20), paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F), paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K), General Instruction C.3.(g) of §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), and General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6) specify when electronic filers are required or permitted to submit an Interactive Data File (as defined in § 232.11), as further described in the note to this section. This section imposes content, format, and submission requirements for an Interactive Data File, but does not change the substantive content requirements for the financial and other disclosures in the Related Official Filing (as defined in § 232.11).</P>
                            <P>(a) * * *</P>
                            <P>(2) Be submitted only by an electronic filer either required or permitted to submit an Interactive Data File as specified by § 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K), paragraph (101) of Part II—Information Not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10), paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form 20-F), paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F), paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K), General Instruction C.3.(g) of §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), or General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6), as applicable;</P>
                            <P>(3) * * *</P>
                            <P>
                                (i) If the electronic filer is neither an open-end management investment company registered under the Investment Company Act of 1940 (15 U.S.C. 80a 
                                <E T="03">et seq.</E>
                                ) nor a separate account (as defined in section 2(a)(14) of the Securities Act) (15 U.S.C. 77b(a)(14)) registered under the Investment Company Act of 1940 (15 U.S.C. 80a 
                                <E T="03">et seq.</E>
                                ), and is not within one of the categories specified in paragraph (f)(1)(i) of this section, as partly embedded into a filing with the remainder simultaneously submitted as an exhibit to:
                            </P>
                            <STARS/>
                            <P>
                                (ii) If the electronic filer is either an open-end management investment company registered under the Investment Company Act of 1940 (15 U.S.C. 80a 
                                <E T="03">et seq.</E>
                                ) or a separate account (as defined in section 2(a)(14) of the Securities Act) registered under the Investment Company Act of 1940 (15 U.S.C. 80a 
                                <E T="03">et seq.</E>
                                ), and is not within one of the categories specified in paragraph (f)(1)(ii) of this section, as partly embedded into a filing with the remainder simultaneously submitted as an exhibit to a filing that contains the disclosure this section requires to be tagged; and
                            </P>
                            <P>(4) Be submitted in accordance with the EDGAR Filer Manual and, as applicable, either § 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K), paragraph (101) of Part II—Information Not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10), paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form 20-F), paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F), paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K), General Instruction C.3.(g) of §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), or General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6).</P>
                            <P>
                                (b) 
                                <E T="03">Content—categories of information presented.</E>
                                 (1) If the electronic filer is neither an open-end management investment company registered under the Investment Company Act of 1940 nor a separate account (as defined in section 2(a)(14) of the Securities Act) registered under the Investment Company Act of 1940 (15 U.S.C. 80a 
                                <E T="03">et seq.</E>
                                ), an Interactive Data File must consist of only a complete set of information for all periods required to be presented in the corresponding data in the Related Official Filing, no more and no less, from all of the following categories:
                            </P>
                            <STARS/>
                            <PRTPAGE P="26100"/>
                            <P>
                                (2) If the electronic filer is either an open-end management investment company registered under the Investment Company Act of 1940 or a separate account (as defined in section 2(a)(14) of the Securities Act) registered under the Investment Company Act of 1940 (15 U.S.C. 80a 
                                <E T="03">et seq.</E>
                                ), an Interactive Data File must consist of only a complete set of information for all periods required to be presented in the corresponding data in the Related Official Filing, no more and no less, from the information set forth in:
                            </P>
                            <P>(i) Items 2, 3, and 4 of §§ 239.15A and 274.11A of this chapter (Form N-1A);</P>
                            <P>(ii) Items 2, 4, 5, 11, 18 and 19 of §§ 239.17a and 274.11b of this chapter (Form N-3);</P>
                            <P>(iii) Items 2, 4, 5, 10, and 17 of §§ 239.17b and 274.11c of this chapter (Form N-4); or</P>
                            <P>(iv) Items 2, 4, 5, 10, 11 and 18 §§ 239.17c and 274.11d of this chapter (Form N-6) as applicable.</P>
                            <STARS/>
                            <NOTE>
                                <HD SOURCE="HED">Note 2 to § 232.405: </HD>
                                <P>
                                    Section 229.601(b)(101) of this chapter (Item 601(b)(101) of Regulation S-K) specifies the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to § 239.11 of this chapter (Form S-1), § 239.13 of this chapter (Form S-3), § 239.25 of this chapter (Form S-4), § 239.18 of this chapter (Form S-11), § 239.31 of this chapter (Form F-1), § 239.33 of this chapter (Form F-3), § 239.34 of this chapter (Form F-4), § 249.310 of this chapter (Form 10-K), § 249.308a of this chapter (Form 10-Q), and § 249.308 of this chapter (Form 8-K). Paragraph (101) of Part II—Information not Required to be Delivered to Offerees or Purchasers of § 239.40 of this chapter (Form F-10) specifies the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to Form F-10. Paragraph 101 of the Instructions as to Exhibits of § 249.220f of this chapter (Form 20-F) specifies the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to Form 20-F. Paragraph B.(15) of the General Instructions to § 249.240f of this chapter (Form 40-F) and Paragraph C.(6) of the General Instructions to § 249.306 of this chapter (Form 6-K) specify the circumstances under which an Interactive Data File must be submitted and the circumstances under which it is permitted to be submitted, with respect to § 249.240f of this chapter (Form 40-F) and § 249.306 of this chapter (Form 6-K). Section 229.601(b)(101) (Item 601(b)(101) of Regulation S-K), paragraph (101) of Part II—Information not Required to be Delivered to Offerees or Purchasers of Form F-10, paragraph 101 of the Instructions as to Exhibits of Form 20-F, paragraph B.(15) of the General Instructions to Form 40-F, and paragraph C.(6) of the General Instructions to Form 6-K all prohibit submission of an Interactive Data File by an issuer that prepares its financial statements in accordance with 17 CFR 210.6-01 through 210.6-10 (Article 6 of Regulation S-X). For an issuer that is an open-end management investment company or separate account registered under the Investment Company Act of 1940 (15 U.S.C. 80a 
                                    <E T="03">et seq.</E>
                                    ), General Instruction C.3.(g) §§ 239.15A and 274.11A of this chapter (Form N-1A), General Instruction C.3.(h) of §§ 239.17a and 274.11b of this chapter (Form N-3), General Instruction C.3.(h) of §§ 239.17b and 274.11c of this chapter (Form N-4), or General Instruction C.3.(h) of §§ 239.17c and 274.11d of this chapter (Form N-6), as applicable, specifies the circumstances under which an Interactive Data File must be submitted.
                                </P>
                            </NOTE>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 239—FORMS PRESCRIBED UNDER THE SECURITIES ACT OF 1933</HD>
                    </PART>
                    <REGTEXT TITLE="17" PART="239">
                        <AMDPAR>16. The authority citation for part 239 continues to read, in part, as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P>
                                15 U.S.C. 77c, 77f, 77g, 77h, 77j, 77s, 77z-2, 77z-3, 77sss, 78c, 78
                                <E T="03">l,</E>
                                 78m,78n, 78
                                <E T="03">o</E>
                                (d), 78
                                <E T="03">o</E>
                                -7 note, 78u-5, 78w(a), 78
                                <E T="03">ll,</E>
                                 78mm, 80a-2(a), 80a-3, 80a-8, 80a-9, 80a-10, 80a-13, 80a-24, 80a-26, 80a-29, 80a-30, and 80a-37; and sec. 107, Pub. L. 112-106, 126 Stat. 312, unless otherwise noted.
                            </P>
                        </AUTH>
                        <STARS/>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 239.15 </SECTNO>
                        <SUBJECT>[Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="239">
                        <AMDPAR>17. Remove and reserve § 239.15.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="239">
                        <AMDPAR>18. Amend Form N-14 (referenced in § 239.23) by:</AMDPAR>
                        <AMDPAR>a. In General Instruction G, revising the second sentence;</AMDPAR>
                        <AMDPAR>b. In Item 3, replacing the phrase “Items 2, 4(a) through (c), and 5 through 14 of Form N-3” with “Items 2 through 3, 5 through 16, and 18 of Form N-3”;</AMDPAR>
                        <AMDPAR>c. In Item 12(a), replacing the phrase “Items 15 through 23 of Form N-3” with “Items 20 through 26 of Form N-3”; and</AMDPAR>
                        <AMDPAR>d. In Item 13(a), replacing the phrase “Items 15 through 23 of Form N-3” with “Items 20 through 26 of Form N-3”.</AMDPAR>
                        <P>The revisions to General Instruction G read as follows:</P>
                        <NOTE>
                            <HD SOURCE="HED">Note: </HD>
                            <P> The text of Form N-14 does not, and this amendment will not, appear in the Code of Federal Regulations.</P>
                        </NOTE>
                    </REGTEXT>
                    <GPH SPAN="3" DEEP="405">
                        <PRTPAGE P="26101"/>
                        <GID>ER01MY20.015</GID>
                    </GPH>
                    <PART>
                        <HD SOURCE="HED">PART 240—GENERAL RULES AND REGULATIONS, SECURITIES EXCHANGE ACT OF 1934</HD>
                    </PART>
                    <REGTEXT TITLE="17" PART="240">
                        <AMDPAR>19. The general authority citation for part 240 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority: </HD>
                            <P>
                                15 U.S.C. 77c, 77d, 77g, 77j, 77s, 77z-2, 77z-3, 77eee, 77ggg, 77nnn, 77sss, 77ttt, 78c, 78c-3, 78c-5, 78d, 78e, 78f, 78g, 78i, 78j, 78j-1, 78k, 78k-1, 78
                                <E T="03">l,</E>
                                 78m, 78n, 78n-1, 78
                                <E T="03">o,</E>
                                 78
                                <E T="03">o</E>
                                -4, 78
                                <E T="03">o</E>
                                -10, 78p, 78q, 78q-1, 78s, 78u-5, 78w, 78x, 78
                                <E T="03">ll,</E>
                                 78mm, 80a-20, 80a-23, 80a-29, 80a-37, 80b-3, 80b-4, 80b-11, and 7201 
                                <E T="03">et seq.;</E>
                                 and 8302; 7 U.S.C. 2(c)(2)(E); 12 U.S.C. 5221(e)(3); 18 U.S.C. 1350; Public Law 111-203, 939A, 124 Stat. 1376 (2010); and Pub. L. 112-106, secs. 503 and 602, 126 Stat. 326 (2012), unless otherwise noted.
                            </P>
                        </AUTH>
                        <STARS/>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="240">
                        <AMDPAR>20. Amend § 240.14a-16 by revising paragraph (f)(2)(iii) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 240.14a-16 </SECTNO>
                            <SUBJECT>Internet availability of proxy materials.</SUBJECT>
                            <STARS/>
                            <P>(f) * * *</P>
                            <P>(2) * * *</P>
                            <P>
                                (iii) In the case of an investment company registered under the Investment Company Act of 1940, the company's prospectus, a summary prospectus that satisfies the requirements of § 230.498(b) or § 230.498A(b) or (c) of this chapter, a Notice under § 270.30e-3 of this chapter, or a report that is required to be transmitted to stockholders by section 30(e) of the Investment Company Act (15 U.S.C. 80a-29(e)) and its implementing regulations (
                                <E T="03">e.g.,</E>
                                 §§ 270.30e-1 and 270.30e-2 of this chapter); and
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 240.14a-101 </SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="240">
                        <AMDPAR>21. Amend § 240.14a-101 by removing the phrase “Item 3 of Form N-3” and adding in its place “Item 4 of Form N-3” in paragraph (a)(3)(iv) of Item 22.</AMDPAR>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 270—RULES AND REGULATIONS, INVESTMENT COMPANY ACT OF 1940</HD>
                    </PART>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>22. The authority citation for part 270 is amended by removing the sectional authority for § 270.6e-3(T) and adding a sectional authority for § 270.6e-3 in numerical order to read, in part, as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P>
                                15 U.S.C. 80a-1 
                                <E T="03">et seq.,</E>
                                 80a-34(d), 80a-37, 80a-39, and Pub. L. 111-203, sec. 939A, 124 Stat. 1376 (2010), unless otherwise noted.
                            </P>
                        </AUTH>
                        <STARS/>
                    </REGTEXT>
                    <EXTRACT>
                        <P>Section 270.6e-3 is also issued under 15 U.S.C. 80a-5(e).</P>
                        <STARS/>
                    </EXTRACT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>23. Amend § 270.0-1 by revising paragraph (e) introductory text and paragraph (e)(2) to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.0-1 </SECTNO>
                            <SUBJECT>Definition of terms used in this part.</SUBJECT>
                            <STARS/>
                            <PRTPAGE P="26102"/>
                            <P>(e) Definition of separate account and conditions for availability of exemption under §§ 270.6c-6, 270.6c-7, 270.6c-8, 270.11a-2, 270.14a-2, 270.15a-3, 270.16a-1, 270.22c-1, 270.22d-2, 270.22e-1, 270.26a-1, 270.27i-1, and 270.32a-2 (Rules 6c-6, 6c-7, 6c-8, 11a-2, 14a-2, 15a-3, 16a-1, 22c-1, 22d-2, 22e-1, 26a-1, 27i-1, and 32a-2).</P>
                            <STARS/>
                            <P>(2) As conditions to the availability of exemptive Rules 6c-6, 6c-7, 6c-8, 11a-2, 14a-2, 15a-3, 16a-1, 22c-1, 22d-2, 22e-1, 26a-1, 27i-1, and 32a-2, the separate account shall be legally segregated, the assets of the separate account shall, at the time during the year that adjustments in the reserves are made, have a value at least equal to the reserves and other contract liabilities with respect to such account, and at all other times, shall have a value approximately equal to or in excess of such reserves and liabilities; and that portion of such assets having a value equal to, or approximately equal to, such reserves and contract liabilities shall not be chargeable with liabilities arising out of any other business which the insurance company may conduct.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>24. Amend § 270.6c-7 by revising the introductory text and removing the parenthetical authority at the end of the section to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.6c-7 </SECTNO>
                            <SUBJECT>Exemptions from certain provisions of sections 22(e) and 27 for registered separate accounts offering variable annuity contracts to participants in the Texas Optional Retirement Program.</SUBJECT>
                            <P>
                                A registered separate account, and any depositor of or underwriter for such account, shall be exempt from the provisions of sections 22(e), 27(i)(2)(A), and 27(d) of the Act (15 U.S.C. 80a-22(e), 80a-27(i)(2)(A), and 80a-27(d), respectively) with respect to any variable annuity contract participating in such account to the extent necessary to permit compliance with the Texas Optional Retirement Program (“Program”), 
                                <E T="03">Provided,</E>
                                 That the separate, account, depositor, or underwriter for such account:
                            </P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>25. Amend § 270.6c-8 by revising paragraphs (b) and (c) and removing the parenthetical authority at the end of the section to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.6c-8 </SECTNO>
                            <SUBJECT>Exemptions for registered separate accounts to impose a deferred sales load and to deduct certain administrative charges.</SUBJECT>
                            <STARS/>
                            <P>(b) A registered separate account, and any depositor of or principal underwriter for such account, shall be exempt from the provisions of sections 22(c) and 27(i)(2)(A) of the Act (15 U.S.C. 80a-22(c) and 80a-27(i)(2)(A), respectively) and § 270.22c-1 (Rule 22c-1) to the extent necessary to permit them to impose a deferred sales load on any variable annuity contract participating in such account; provided that the terms of any offer to exchange another contract for the contract are in compliance with the requirements of paragraph (d) or (e) of § 270.11a-2 (Rule 11a-2).</P>
                            <P>(c) A registered separate account, and any depositor of or principal underwriter for such account, shall be exempt from sections 22(c) and 27(i)(2)(A) of the Act (15 U.S.C. 80a-22(c) and 80a-27(i)(2)(A), respectively) and § 270.22c-1 (Rule 22c-1) to the extent necessary to permit them to deduct from the value of any variable annuity contract participating in such account, upon total redemption of the contract prior to the last day of the year, the full annual fee for administrative services that otherwise would have been deducted on that date.</P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>26. Revise § 270.6e-2 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.6e-2 </SECTNO>
                            <SUBJECT>Exemptions for certain variable life insurance separate accounts.</SUBJECT>
                            <P>(a) A separate account, and the investment adviser, principal underwriter and depositor of such separate account, shall, except for the exemptions provided in paragraph (b) of this section, be subject to all provisions of the Act and this part as though such separate account were a registered investment company issuing periodic payment plan certificates if:</P>
                            <P>(1) Such separate account is established and maintained by a life insurance company pursuant to the insurance laws or code of:</P>
                            <P>(i) Any state or territory of the United States or the District of Columbia; or</P>
                            <P>(ii) Canada or any province thereof, if it complies to the extent necessary with § 270.7d-1 (Rule 7d-1) under the Act;</P>
                            <P>(2) The assets of the separate account are derived solely from the sale of variable life insurance contracts as defined in paragraph (c) of this section, and advances made by the life insurance company which established and maintains the separate account (“life insurer”) in connection with the operation of such separate account;</P>
                            <P>(3) The separate account is not used for variable annuity contracts or for funds corresponding to dividend accumulations or other contract liabilities not involving life contingencies;</P>
                            <P>(4) The income, gains and losses, whether or not realized, from assets allocated to such separate account, are, in accordance with the applicable variable life insurance contract, credited to or charged against such account without regard to other income, gains or losses of the life insurer;</P>
                            <P>(5) The separate account is legally segregated, and that portion of its assets having a value equal to, or approximately equal to, the reserves and other contract liabilities with respect to such separate account are not chargeable with liabilities arising out of any other business that the life insurer may conduct;</P>
                            <P>(6) The assets of the separate account have, at each time during the year that adjustments in the reserves are made, a value at least equal to the reserves and other contract liabilities with respect to such separate account, and at all other times, except pursuant to an order of the Commission, have a value approximately equal to or in excess of such reserves and liabilities; and</P>
                            <P>(7) The investment adviser of the separate account is registered under the Investment Advisers Act of 1940.</P>
                            <P>(b) If a separate account meets the requirements of paragraph (a) of this section, then such separate account and the other persons described in paragraph (a) of this section shall be exempt from the provisions of the Act as follows:</P>
                            <P>(1) Section 7 (15 U.S.C. 80a-7).</P>
                            <P>(2) Section 8 (15 U.S.C. 80a-8) to the extent that:</P>
                            <P>(i) For purposes of paragraph (a) of section 8, the separate account shall file with the Commission a notification on § 274.301 of this chapter (Form N-6EI-1) which identifies such separate account; and</P>
                            <P>(ii) For purposes of paragraph (b) of section 8, the separate account shall file with the Commission a form to be designated by the Commission within 90 days after filing the notification on Form N-6EI-1; provided, however, that if the fiscal year of the separate account ends within this 90 day period the form may be filed within ninety days after the end of such fiscal year.</P>
                            <P>(3) Section 9 (15 U.S.C. 80a-9) to the extent that:</P>
                            <P>(i) The eligibility restrictions of section 9(a) shall not be applicable to those persons who are officers, directors and employees of the life insurer or its affiliates who do not participate directly in the management or administration of the separate account or in the sale of variable life insurance contracts funded by such separate account; and</P>
                            <P>
                                (ii) A life insurer shall be ineligible pursuant to paragraph (3) of section 9(a) to serve as investment adviser, depositor of or principal underwriter for a variable life insurance separate account only if 
                                <PRTPAGE P="26103"/>
                                an affiliated person of such life insurer, ineligible by reason of paragraph (1) or (2) of section 9(a), participates directly in the management or administration of the separate account or in the sale of variable life insurance contracts funded by such separate account.
                            </P>
                            <P>(4) Section 13(a) (15 U.S.C. 80a-13(a)) to the extent that:</P>
                            <P>(i) An insurance regulatory authority may require pursuant to insurance law or regulation that the separate account make (or refrain from making) certain investments which would result in changes in the subclassification or investment policies of the separate account;</P>
                            <P>(ii) Changes in the investment policy of the separate account initiated by contractholders or the board of directors of the separate account may be disapproved by the life insurer, provided that such disapproval is reasonable and is based upon a determination by the life insurer in good faith that:</P>
                            <P>(A) Such change would be contrary to state law; or</P>
                            <P>(B) Such change would be inconsistent with the investment objectives of the separate account or would result in the purchase of securities for the separate account which vary from the general quality and nature of investments and investment techniques utilized by other separate accounts of the life insurer or of an affiliated life insurance company, which separate accounts have investment objectives similar to the separate account; and</P>
                            <P>(iii) Any action taken in accordance with paragraph (b)(4)(i) or (ii) of this section and the reasons therefor shall be disclosed in the proxy statement for the next meeting of variable life insurance contractholders of the separate account.</P>
                            <P>(5) Section 14(a) (15 U.S.C. 80a-14(a)).</P>
                            <P>(6)(i) Section 15(a) (15 U.S.C. 80a-15(a)) to the extent this section requires that the initial written contract pursuant to which the investment adviser serves or acts shall have been approved by the vote of a majority of the outstanding voting securities of the registered company; provided that:</P>
                            <P>(A) Such investment adviser is selected and a written contract is entered into before the effective date of the registration statement under the Securities Act of 1933, as amended, for variable life insurance contracts which are funded by the separate account, and that the terms of the contract are fully disclosed in such registration statement; and</P>
                            <P>(B) A written contract is submitted to a vote of variable life insurance contractholders at their first meeting after the effective date of the registration statement under the Securities Act of 1933, as amended, on condition that such meeting shall take place within one year after such effective date, unless the time for the holding of such meeting shall be extended by the Commission upon written request for good cause shown; and</P>
                            <P>(ii) Sections 15(a), (b) and (c) (15 U.S.C. 80a-15(a), (b), and (c)) to the extent that:</P>
                            <P>(A) An insurance regulatory authority may disapprove pursuant to insurance law or regulation any contract between the separate account and an investment adviser or principal underwriter;</P>
                            <P>(B) Changes in the principal underwriter for the separate account initiated by contractholders or the board of directors of the separate account may be disapproved by the life insurer; provided that such disapproval is reasonable;</P>
                            <P>(C) Changes in the investment adviser of the separate account initiated by contractholders or the board of directors of the separate account may be disapproved by the life insurer; provided that such disapproval is reasonable and is based upon a determination by the life insurer in good faith that:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The rate of the proposed investment advisory fee will exceed the maximum rate that is permitted to be charged against the assets of the separate account for such services as specified by any variable life insurance contract funded by such separate account; or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The proposed investment adviser may be expected to employ investment techniques which vary from the general techniques utilized by the current investment adviser to the separate account, or advise the purchase or sale of securities which would be inconsistent with the investment objectives of the separate account, or which would vary from the quality and nature of investments made by other separate accounts of the life insurer or of an affiliated life insurance company, which separate accounts have investment objectives similar to the separate account; and
                            </P>
                            <P>(D) Any action taken in accordance with paragraph (b)(6)(ii)(A), (B), or (C) of this section and the reasons therefor shall be disclosed in the proxy statement for the next meeting of variable life insurance contractholders of the separate account.</P>
                            <P>(7) Section 16(a) (15 U.S.C. 80a-16(a)) to the extent that:</P>
                            <P>(i) Persons serving as directors of the separate account prior to the first meeting of such account's variable life insurance contractholders are exempt from the requirement of section 16(a) that such persons be elected by the holders of outstanding voting securities of such account at an annual or special meeting called for that purpose; provided that:</P>
                            <P>(A) Such persons have been appointed directors of such account by the life insurer before the effective date of the registration statement under the Securities Act of 1933, as amended, for variable life insurance contracts which are funded by the separate account and are identified in such registration statement (or are replacements appointed by the life insurer for any such persons who have become unable to serve as directors); and</P>
                            <P>(B) An election of directors for such account shall be held at the first meeting of variable life insurance contractholders after the effective date of the registration statement under the Securities Act of 1933, as amended, relating to contracts funded by such account, which meeting shall take place within one year after such effective date, unless the time for holding such meeting shall be extended by the Commission upon written request for good cause shown; and</P>
                            <P>(ii) A member of the board of directors of such separate account may be disapproved or removed by the appropriate insurance regulatory authority if such person is ineligible to serve as a director of the separate account pursuant to insurance law or regulation of the jurisdiction in which the life insurer is domiciled.</P>
                            <P>(8) Section 17(f) (15 U.S.C. 80a-17(f)) to the extent that the securities and similar investments of the separate account may be maintained in the custody of the life insurer or an insurance company which is an affiliated person of such life insurer; provided that:</P>
                            <P>(i) The securities and similar investments allocated to such separate account are clearly identified as to ownership by such account, and such securities and similar investments are maintained in the vault of an insurance company which meets the qualifications set forth in paragraph (b)(8)(ii) of this section, and whose procedures and activities with respect to such safekeeping function are supervised by the insurance regulatory authorities of the jurisdiction in which the securities and similar investments will be held;</P>
                            <P>
                                (ii) The insurance company maintaining such investments must file with an insurance regulatory authority of a State or territory of the United States or the District of Columbia an 
                                <PRTPAGE P="26104"/>
                                annual statement of its financial condition in the form prescribed by the National Association of Insurance Commissioners, must be subject to supervision and inspection by such authority and must be examined periodically as to its financial condition and other affairs by such authority, must hold the securities and similar investments of the separate account in its vault, which vault must be equivalent to that of a bank which is a member of the Federal Reserve System, and must have a combined capital and surplus, if a stock company, or an unassigned surplus, if a mutual company, of not less than $1,000,000 as set forth in its most recent annual statement filed with such authority;
                            </P>
                            <P>(iii) Access to such securities and similar investments shall be limited to employees of or agents authorized by the Commission, representatives of insurance regulatory authorities, independent public accountants for the separate account, accountants for the life insurer and to no more than 20 persons authorized pursuant to a resolution of the board of directors of the separate account, which persons shall be directors of the separate account, officers and responsible employees of the life insurer or officers and responsible employees of the affiliated insurance company in whose vault such investments are maintained (if applicable), and access to such securities and similar investments shall be had only by two or more such persons jointly, at least one of whom shall be a director of the separate account or officer of the life insurer;</P>
                            <P>(iv) The requirement in paragraph (b)(8)(i) of this section that the securities and similar investments of the separate account be maintained in the vault of a qualified insurance company shall not apply to securities deposited with insurance regulatory authorities or deposited in a system for the central handling of securities established by a national securities exchange or national securities association registered with the Commission under the Securities Exchange Act of 1934, as amended, or such person as may be permitted by the Commission, or to securities on loan which are collateralized to the extent of their full market value, or to securities hypothecated, pledged, or placed in escrow for the account of such separate account in connection with a loan or other transaction authorized by specific resolution of the board of directors of the separate account, or to securities in transit in connection with the sale, exchange, redemption, maturity or conversion, the exercise of warrants or rights, assents to changes in terms of the securities, or to other transactions necessary or appropriate in the ordinary course of business relating to the management of securities;</P>
                            <P>(v) Each person when depositing such securities or similar investments in or withdrawing them from the depository or when ordering their withdrawal and delivery from the custody of the life insurer or affiliated insurance company, shall sign a notation in respect of such deposit, withdrawal or order which shall show:</P>
                            <P>(A) The date and time of the deposit, withdrawal, or order;</P>
                            <P>(B) The title and amount of the securities or other investments deposited, withdrawn or ordered to be withdrawn, and an identification thereof by certificate numbers or otherwise;</P>
                            <P>(C) The manner of acquisition of the securities or similar investments deposited or the purpose for which they have been withdrawn, or ordered to be withdrawn; and</P>
                            <P>(D) If withdrawn and delivered to another person the name of such person. Such notation shall be transmitted promptly to an officer or director of the separate account or the life insurer designated by the board of directors of the separate account who shall not be a person designated for the purpose of paragraph (b)(8)(iii) of this section. Such notation shall be on serially numbered forms and shall be preserved for at least one year;</P>
                            <P>(vi) Such securities and similar investments shall be verified by complete examination by an independent public accountant retained by the separate account at least three times during each fiscal year, at least two of which shall be chosen by such accountant without prior notice to such separate account. A certificate of such accountant stating that he has made an examination of such securities and investments and describing the nature and extent of the examination shall be transmitted to the Commission by the accountant promptly after each examination; and</P>
                            <P>(vii) Securities and similar investments of a separate account maintained with a bank or other company whose functions and physical facilities are supervised by Federal or state authorities pursuant to any arrangement whereby the directors, officers, employees or agents of the separate account or the life insurer are authorized or permitted to withdraw such investments upon their mere receipt are deemed to be in the custody of the life insurer and shall be exempt from the requirements of section 17(f) so long as the arrangement complies with all provisions of paragraph (b)(8) of this section, except that such securities will be maintained in the vault of a bank or other company rather than the vault of an insurance company.</P>
                            <P>(9) Section 18(i) (15 U.S.C. 80a-18(i)) to the extent that:</P>
                            <P>(i) For the purposes of any section of the Act which provides for the vote of securityholders on matters relating to the investment company:</P>
                            <P>(A) Variable life insurance contractholders shall have one vote for each $100 of cash value funded by the separate account, with fractional votes allocated for amounts less than $100;</P>
                            <P>(B) The life insurer shall have one vote for each $100 of assets of the separate account not otherwise attributable to contractholders pursuant to paragraph (b)(9)(i)(A) of this section, with fractional votes allocated for amounts less than $100; provided that after the commencement of sales of variable life insurance contracts funded by the separate account, the life insurer shall cast its votes for and against each matter which may be voted upon by contractholders in the same proportion as the votes cast by contractholders; and</P>
                            <P>(C) The number of votes to be allocated shall be determined as of a record date not more than 90 days prior to any meeting at which such vote is held; provided that if a quorum is not present at the meeting, the meeting may be adjourned for up to 60 days without fixing a new record date; and</P>
                            <P>(ii) The requirement of this section that every share of stock issued by a registered management investment company (except a common-law trust of the character described in section 16(c)) shall be a voting stock and have equal voting rights with every other outstanding voting stock shall not be deemed to be violated by actions specifically permitted by any provision of this section.</P>
                            <P>(10) Section 19 (15 U.S.C. 80a-19) to the extent that the provisions of this section shall not be applicable to any dividend or similar distribution paid or payable pursuant to provisions of participating variable life insurance contracts.</P>
                            <P>(11) Sections 22(d), 22(e), and 27(i)(2)(A) (15 U.S.C. 80a-22(d), 80a-22(e), and 80a-27(i)(2)(A), respectively) and § 270.22c-1 (Rule 22c-1) promulgated under section 22(c) to the extent:</P>
                            <P>
                                (i) That the amount payable on death and the cash surrender value of each variable life insurance contract shall be determined on each day during which the New York Stock Exchange is open for trading, not less frequently than once daily as of the time of the close of 
                                <PRTPAGE P="26105"/>
                                trading on such exchange; provided that the amount payable on death need not be determined more than once each contract month if such determination does not reduce the participation of the contract in the investment experience of the separate account; provided further, however, that if the net valuation premium for such contract is transferred at least annually, then the amount payable on death need be determined only when such net premium is transferred; and
                            </P>
                            <P>(ii) Necessary for compliance with this section or with insurance laws and regulations and established administrative procedures of the life insurer with respect to issuance, transfer and redemption procedures for variable life insurance contracts funded by the separate account including, but not limited to, premium rate structure and premium processing, insurance underwriting standards, and the particular benefit afforded by the contract; provided, however, that any procedure or action shall be reasonable, fair and not discriminatory to the interests of the affected contractholder and to all other holders of contracts of the same class or series funded by the separate account; and, further provided that any such action shall be disclosed in the form required to be filed by the separate account with the Commission pursuant to paragraph (b)(2)(ii) of this section.</P>
                            <P>(12) Section 27(i)(2)(A) (15 U.S.C. 80a-27(i)(A)), to the extent that such sections require that the variable life insurance contract be redeemable or provide for a refund in cash; provided that such contract provides for election by the contractholder of a cash surrender value or certain non-forfeiture and settlement options which are required or permitted by the insurance law or regulation of the jurisdiction in which the contract is offered; and further provided that unless required by the insurance law or regulation of the jurisdiction in which the contract is offered or unless elected by the contractholder, such contract shall not provide for the automatic imposition of any option, including, but not limited to, an automatic premium loan, which would involve the accrual or payment of an interest or similar charge;</P>
                            <P>(13) Section 32(a)(2) (15 U.S.C. 80a-31(a)(2)); provided that:</P>
                            <P>(i) The independent public accountant is selected before the effective date of the registration statement under the Securities Act of 1933, as amended, for variable life insurance contracts which are funded by the separate account, and the identity of such accountant is disclosed in such registration statement; and</P>
                            <P>(ii) The selection of such accountant is submitted for ratification or rejection to variable life insurance contractholders at their first meeting after the effective date of the registration statement under the Securities Act of 1933, as amended, on condition that such meeting shall take place within one year after such effective date, unless the time for the holding of such meeting shall be extended by the Commission upon written request for good cause shown.</P>
                            <P>(14) If the separate account is organized as a unit investment trust, all the assets of which consist of the shares of one or more registered management investment companies which offer their shares exclusively to variable life insurance separate accounts of the life insurer or of any affiliated life insurance company:</P>
                            <P>(i) The eligibility restrictions of section 9(a) (15 U.S.C. 80a-9(a)) shall not be applicable to those persons who are officers, directors, and employees of the life insurer or its affiliates who do not participate directly in the management or administration of any registered management investment company described in paragraph (b)(14) introductory text;</P>
                            <P>(ii) The life insurer shall be ineligible pursuant to paragraph (3) of section 9(a) to serve as investment adviser of or principal underwriter for any registered management investment company described in paragraph (b)(14) of this section only if an affiliated person of such life insurer, ineligible by reason of paragraph (1) or (2) of section 9(a), participates in the management or administration of such company;</P>
                            <P>(iii) The life insurer may vote shares of the registered management investment companies held by the separate account without regard to instructions from contractholders of the separate account if such instructions would require such shares to be voted:</P>
                            <P>(A) To cause such companies to make (or refrain from making) certain investments which would result in changes in the sub-classification or investment objectives of such companies or to approve or disapprove any contract between such companies and an investment adviser when required to do so by an insurance regulatory authority subject to the provisions of paragraphs (b)(4)(i) and (b)(6)(ii)(A) of this section; or</P>
                            <P>(B) In favor of changes in investment objectives, investment adviser of or principal underwriter for such companies subject to the provisions of paragraphs (b)(4)(ii) and (b)(6)(ii)(B) and (C) of this section;</P>
                            <P>(iv) Any action taken in accordance with paragraph (b)(14)(iii)(A) or (B) of this section and the reasons therefor shall be disclosed in the next report to contractholders made pursuant to section 30(e) (15 U.S.C. 80a-29(e)) and § 270.30e-2 (Rule 30e-2);</P>
                            <P>(v) Any registered management investment company established by the insurer and described in paragraph (b)(14) of this section shall be exempt from section 14(a); and</P>
                            <P>(vi) Any registered management investment company established by the insurer and described in paragraph (b)(14) of this section shall be exempt from sections 15(a), 16(a), and 32(a)(2) (15 U.S.C. 80a-15(a), 80-16(a), and 80-31(a)(2), respectively), to the extent prescribed by paragraphs (b)(6)(i), (b)(7)(i), and (b)(13) of this section, provided that such company complies with the conditions set forth in those paragraphs as if it were a separate account.</P>
                            <P>
                                (c) When used in this section, 
                                <E T="03">variable life insurance contract</E>
                                 means a contract of life insurance, subject to regulation under the insurance laws or code of every jurisdiction in which it is offered, funded by a separate account of a life insurer, which contract, so long as premium payments are duly paid in accordance with its terms, provides for:
                            </P>
                            <P>(1) A death benefit and cash surrender value which vary to reflect the investment experience of the separate account;</P>
                            <P>(2) An initial stated dollar amount of death benefit, and payment of a death benefit guaranteed by the life insurer to be at least equal to such stated amount; and</P>
                            <P>(3) Assumption of the mortality and expense risks thereunder by the life insurer for which a charge against the assets of the separate account may be assessed. Such charge shall be disclosed in the prospectus and shall not be less than fifty per centum of the maximum charge for risk assumption as disclosed in the prospectus and as provided for in the contract.</P>
                        </SECTION>
                        <SECTION>
                            <SECTNO>§ 270.6e-3(T)</SECTNO>
                            <SUBJECT> [Redesignated as § 270.6e-3 and Amended]</SUBJECT>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>27. Redesignate § 270.6e-3(T) as § 270.6e-3 and revise newly redesignated § 270.6e-3 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.6e-3</SECTNO>
                            <SUBJECT>Exemptions for flexible premium variable life insurance separate accounts.</SUBJECT>
                            <P>
                                (a) A separate account, and its investment adviser, principal underwriter and depositor, shall, except 
                                <PRTPAGE P="26106"/>
                                as provided in paragraph (b) of this section, comply with all provisions of the Investment Company Act of 1940 (15 U.S.C. 80a-1 
                                <E T="03">et seq.</E>
                                ) and this part that apply to a registered investment company issuing periodic payment plan certificates if:
                            </P>
                            <P>(1) It is a separate account within the meaning of section 2(a)(37) of the Act (15 U.S.C. 80a-2(a)(37)) and is established and maintained by a life insurance company pursuant to the insurance laws or code of:</P>
                            <P>(i) Any state or territory of the United States or the District of Columbia; or</P>
                            <P>(ii) Canada or any province thereof, if it complies with § 270.7d-1 (Rule 7d-1) under the Act (the “life insurer”);</P>
                            <P>(2) The assets of the separate account are derived solely from:</P>
                            <P>(i) The sale of flexible premium variable life insurance contracts (“flexible contracts”) as defined in paragraph (c)(1) of this section;</P>
                            <P>(ii) The sale of scheduled premium variable life insurance contracts (“scheduled contracts”) as defined in paragraph (c) of § 270.6e-2 (Rule 6e-2) under the Act;</P>
                            <P>(iii) Funds corresponding to dividend accumulations with respect to such contracts; and</P>
                            <P>(iv) Advances made by the life insurer in connection with the operation of such separate account;</P>
                            <P>(3) The separate account is not used for variable annuity contracts or other contract liabilities not involving life contingencies;</P>
                            <P>(4) The separate account is legally segregated, and that part of its assets with a value approximately equal to the reserves and other contract liabilities for such separate account are not chargeable with liabilities arising from any other business of the life insurer;</P>
                            <P>(5) The value of the assets of the separate account, each time adjustments in the reserves are made, is at least equal to the reserves and other contract liabilities of the separate account, and at all other times approximately equals or exceeds the reserves and liabilities; and</P>
                            <P>
                                (6) The investment adviser of the separate account is registered under the Investment Advisers Act of 1940 (15 U.S.C. 80b-1 
                                <E T="03">et seq.</E>
                                ).
                            </P>
                            <P>(b) A separate account that meets the requirements of paragraph (a) of this section, and its investment adviser, principal underwriter and depositor shall be exempt with respect to flexible contracts funded by the separate account from the following provisions of the Act:</P>
                            <P>(1) Subject to section 26(f) of the Act, in connection with any sales charge deducted under the flexible contract, the separate account and other persons shall be exempt from sections 12(b), 22(c), and 27(i)(2)(A) (15 U.S.C. 80a-12(b), 80-22(c), and 80a-27(i)(2)(A), respectively) of the Act, and §§ 270.12b-1 (Rule 12b-1) and 270.22c-1 (Rule 22c-1) under the Act.</P>
                            <P>(2) Section 7 (15 U.S.C. 80a-7).</P>
                            <P>(3) Section 8 (15 U.S.C. 80a-8), to the extent that:</P>
                            <P>(i) For purposes of paragraph (a) of section 8, the separate account filed with the Commission a notification on § 274.301 of this chapter (Form N-6EI-1) which identifies the separate account; and</P>
                            <P>(ii) For purposes of paragraph (b) of section 8, the separate account shall file with the Commission the form designated by the Commission within ninety days after filing the notification on Form N-6EI-1; provided, however, that if the fiscal year of the separate account end within this ninety day period, the form may be filed within ninety days after the end of such fiscal year.</P>
                            <P>(4) Section 9 (15 U.S.C. 80a-9), to the extent that:</P>
                            <P>(i) The eligibility restrictions of section 9(a) shall not apply to persons who are officers, directors or employees of the life insurer or its affiliates and who do not participate directly in the management or administration of the separate account or in the sale of flexible contracts; and</P>
                            <P>(ii) A life insurer shall be ineligible under paragraph (3) of section 9(a) to serve as investment adviser, depositor of or principal underwriter for the separate account only if an affiliated person of such life insurer, ineligible by reason of paragraphs (1) or (2) of section 9(a), participates directly in the management or administration of the separate account or in the sale of flexible contracts.</P>
                            <P>(5) Section 13(a) (15 U.S.C. 80a-13(a)), to the extent that:</P>
                            <P>(i) An insurance regulatory authority may require pursuant to insurance law or regulation that the separate account make (or refrain from making) certain investments which would result in changes in the subclassification or investment policies of the separate account;</P>
                            <P>(ii) Changes in the investment policy of the separate account initiated by its contractholders or board of directors may be disapproved by the life insurer, if the disapproval is reasonable and is based on a good faith determination by the life insurer that:</P>
                            <P>(A) The change would violate state law; or</P>
                            <P>(B) The change would not be consistent with the investment objectives of the separate account or would result in the purchase of securities for the separate account which vary from the general quality and nature of investments and investment techniques used by other separate accounts of the life insurer or of an affiliated life insurance company with similar investment objectives; and</P>
                            <P>(iii) Any action described in paragraph (b)(5)(i) or (ii) of this section and the reasons for it shall be disclosed in the next communication to contractholders, but in no case, later than twelve months from the date of such action.</P>
                            <P>(6) Section 14(a) (15 U.S.C. 80a-14(a)).</P>
                            <P>(7)(i) Section 15(a) (15 U.S.C. 80a-15(a)), to the extent it requires that the initial written contract with the investment adviser shall have been approved by the vote of a majority of the outstanding voting securities of the registered investment company; provided that:</P>
                            <P>(A) The investment adviser is selected and a written contract is entered into before the effective date of the 1933 Act registration statement for flexible contracts, and that the terms of the contract are fully disclosed in the registration statement; and</P>
                            <P>(B) A written contract is submitted to a vote of contractholders at their first meeting and within one year after the effective date of the 1933 Act registration statement, unless the Commission upon written request and for good cause shown extends the time for the holding of such meeting; and</P>
                            <P>(ii) Sections 15(a), (b), and (c), to the extent that:</P>
                            <P>(A) An insurance regulatory authority may disapprove pursuant to insurance law or regulation any contract between the separate account and an investment adviser or principal underwriter;</P>
                            <P>(B) Changes in the principal underwriter for the separate account initiated by contractholders or the board of directors of the separate account may be disapproved by the life insurer; provided that such disapproval is reasonable;</P>
                            <P>(C) Changes in the investment adviser of the separate account initiated by contractholders or the board of directors of the separate account may be disapproved by the life insurer; provided that such disapproval is reasonable and is based on a good faith determination by the life insurer that:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) The proposed investment advisory fee will exceed the maximum rate specified in any flexible contract that may be charged against the assets of the separate account for such services; or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) The proposed investment adviser may be expected to employ investment 
                                <PRTPAGE P="26107"/>
                                techniques which vary from the general techniques used by the current investment adviser to the separate account, or advise the purchase or sale of securities which would not be consistent with the investment objectives of the separate account, or which would vary from the quality and nature of investments made by other separate accounts with similar investment objectives of the life insurer or an affiliated life insurance company; and
                            </P>
                            <P>(D) Any action described in paragraph (b)(7)(ii)(A), (B), or (C) of this section and the reasons for it shall be disclosed in the next communication to contractholders, but in no case, later than twelve months from the date of such action.</P>
                            <P>(8) Section 16(a) (15 U.S.C. 80a-16(a)), to the extent that:</P>
                            <P>(i) Directors of the separate account serving before the first meeting of the account's contractholders are exempt from the requirement of section 16(a) that they be elected by the holders of outstanding voting securities of the account at an annual or special meeting called for that purpose; provided that:</P>
                            <P>(A) Such persons were appointed directors of the account by the life insurer before the effective date of the 1933 Act registration statement for flexible contracts and are identified in the registration statement (or are replacements appointed by the life insurer for any such persons who have become unable to serve as directors); and</P>
                            <P>(B) An election of directors for the account is held at the first meeting of contractholders and within one year after the effective date of the 1933 Act registration statement for flexible contracts, unless the time for holding the meeting is extended by the Commission upon written request and for good cause shown; and</P>
                            <P>(ii) A member of the board of directors of the separate account may be disapproved or removed by an insurance regulatory authority if the person is not eligible to be a director of the separate account under the law of the life insurer's domicile.</P>
                            <P>(9) Section 17(f) (15 U.S.C. 80a-17(f)), to the extent that the securities and similar investments of a separate account organized as a management investment company may be maintained in the custody of the life insurer or of an affiliated life insurance company; provided that:</P>
                            <P>(i) The securities and similar investments allocated to the separate account are clearly identified as owned by the account, and the securities and similar investments are kept in the vault of an insurance company which meets the qualifications in paragraph (b)(9)(ii) of this section, and whose safekeeping function is supervised by the insurance regulatory authorities of the jurisdiction in which the securities and similar investments will be held;</P>
                            <P>(ii) The insurance company maintaining such investments must file with an insurance regulatory authority of a state or territory of the United States or the District of Columbia an annual statement of its financial condition in the form prescribed by the National Association of Insurance Commissioners, must be subject to supervision and inspection by such authority and must be examined periodically as to its financial condition and other affairs by such authority, must hold the securities and similar investments of the separate account in its vault, which vault must be equivalent to that of a bank which is a member of the Federal Reserve System, and must have a combined capital and surplus, if a stock company, or an unassigned surplus, if a mutual company, of not less than $1,000,000 as set forth in its most recent annual statement filed with such authority;</P>
                            <P>(iii) Access to such securities and similar investments shall be limited to employees of the Commission, representatives of insurance regulatory authorities, independent public accountants retained by the separate account (or on its behalf by the life insurer), accountants for the life insurer, and to no more than 20 persons authorized by a resolution of the board of directors of the separate account, which persons shall be directors of the separate account, officers and responsible employees of the life insurer or officers and responsible employees of the affiliated life insurance company in whose vault the investments are kept (if applicable), and access to such securities and similar investments shall be had only by two or more such persons jointly, at least one of whom shall be a director of the separate account or officer of the life insurer;</P>
                            <P>(iv) The requirement in paragraph (b)(9)(i) of this section that the securities and similar investments of the separate account be maintained in the vault of a qualified insurance company shall not apply to securities deposited with insurance regulatory authorities or deposited in accordance with any rule under section 17(f), or to securities on loan which are collateralized to the extent of their full market value, or to securities hypothecated, pledged, or placed in escrow for the account of such separate account in connection with a loan or other transaction authorized by specific resolution of the board of directors of the separate account, or to securities in transit in connection with the sale, exchange, redemption, maturity or conversion, the exercise of warrants or rights, assents to changes in terms of the securities, or to other transactions necessary or appropriate in the ordinary course of business relating to the management of securities;</P>
                            <P>(v) Each person when depositing such securities or similar investments in or withdrawing them from the depository or when ordering their withdrawal and delivery from the custody of the life insurer or affiliated life insurance company, shall sign a notation showing:</P>
                            <P>(A) The date and time of the deposit, withdrawal or order;</P>
                            <P>(B) The title and amount of the securities or other investments deposited, withdrawn or ordered to be withdrawn, and an identification thereof by certificate numbers or otherwise;</P>
                            <P>(C) The manner of acquisition of the securities or similar investments deposited or the purpose for which they have been withdrawn, or ordered to be withdrawn; and</P>
                            <P>(D) If withdrawn and delivered to another person, the name of such person. The notation shall be sent promptly to an officer or director of the separate account or the life insurer designated by the board of directors of the separate account who is not himself permitted to have access to the securities or investments under paragraph (b)(9)(iii) of this section. The notation shall be on serially numbered forms and shall be kept for at least one year;</P>
                            <P>(vi) The securities and similar investments shall be verified by complete examination by an independent public accountant retained by the separate account (or on its behalf by the life insurer) at least three times each fiscal year, at least two of which shall be chosen by the accountant without prior notice to the separate account. A certificate of the accountant stating that he has made an examination of such securities and investments and describing the nature and extent of the examination shall be sent to the Commission by the accountant promptly after each examination; and</P>
                            <P>
                                (vii) Securities and similar investments of a separate account maintained with a bank or other company whose functions and physical facilities are supervised by Federal or state authorities under any arrangement whereby the directors, officers, employees or agents of the separate account or the life insurer are authorized or permitted to withdraw 
                                <PRTPAGE P="26108"/>
                                such investments upon their mere receipt are deemed to be in the custody of the life insurer and shall be exempt from the requirements of section 17(f) so long as the arrangement complies with all provisions of paragraph (b)(9) of this section, except that such securities will be maintained in the vault of a bank or other company rather than the vault of an insurance company.
                            </P>
                            <P>(10) Section 18(i) (15 U.S.C. 80a-18(i)), to the extent that:</P>
                            <P>(i) For the purposes of any section of the Act which provides for the vote of securityholders on matters relating to the investment company:</P>
                            <P>(A) Flexible contractholders shall have one vote for each $100 of cash value funded by the separate account, with fractional votes allocated for amounts less than $100;</P>
                            <P>(B) The life insurer shall have one vote for each $100 of assets of the separate account not otherwise attributable to contractholders under paragraph (b)(10)(i)(A) of this section, with fractional votes allocated for amounts less than $100; provided that after the commencement of sales of flexible contracts, the life insurer shall cast its votes for and against each matter which may be voted upon by contractholders in the same proportion as the votes cast by contractholders; and</P>
                            <P>(C) The number of votes to be allocated shall be determined as of a record date not more than 90 days before any meeting at which such vote is held; provided that if a quorum is not present at the meeting, the meeting may be adjourned for up to 60 days without fixing a new record date; and</P>
                            <P>(ii) The requirement of section 18(i) that every share of stock issued by a registered management investment company (except a common-law trust of the character described in section 16(c) (15 U.S.C. 80a-16(c))) shall be a voting stock and have equal voting rights with every other outstanding voting stock shall not be deemed to be violated by actions specifically permitted by any provisions of this section.</P>
                            <P>(11) Section 19 (15 U.S.C. 80a-19), to the extent that the provisions of this section shall not apply to any dividend or similar distribution paid or payable under provisions of participating flexible contracts.</P>
                            <P>(12) Sections 22(c), 22(d), 22(e) and 27(i)(2)(A) (15 U.S.C. 80a-22(c)), 80a-22(d), 80a-22(e), and 80a-27(i)(2)(A), respectively) and § 270.22c-1 (Rule 22c-1) to the extent:</P>
                            <P>(i) The cash value of each flexible contract shall be computed in accordance with Rule 22c-1(b); provided, however, that where actual computation is not necessary for the operation of a particular contract, then the cash value of that contract must only be capable of computation; and provided further that to the extent the calculation of the cash value reflects deductions for the cost of insurance and other insurance benefits or administrative expenses and fees or sales charges, such deductions need only be made at such times as specified in the contract or as necessary for compliance with insurance laws and regulations;</P>
                            <P>(ii) The death benefit, unless required by insurance laws and regulations, shall be computed on any day that the investment experience of the separate account would affect the death benefit under the terms of the contract provided that such terms are reasonable, fair, and nondiscriminatory; and</P>
                            <P>(iii) Necessary to comply with this section or with insurance laws and regulations and established administrative procedures of the life insurer for issuance, increases in or additions of insurance benefits, transfer and redemption of flexible contracts, including, but not limited to, premium rate structure and premium processing, insurance underwriting standards, and the particular benefit afforded by the contract; provided, however, that any procedure or action shall be reasonable, fair, and not discriminatory to the interests of the affected contractholders and to all other holders of contracts of the same class or series funded by the separate account; and provided further that any such action shall be disclosed in the form filed by the separate account with the Commission under paragraph (b)(3)(ii) of this section.</P>
                            <P>(13) Sections 27(i)(2)(A) and 22(c) (15 U.S.C. 80a-27(i)(2)(A) and 80a-22(c)) and § 270.22c-1 (Rule 22c-1), to the extent that:</P>
                            <P>(i) Such sections require that the flexible contract be redeemable or provide for a refund in cash; provided that the contract provides for election by the contractholder of a cash surrender value or certain non-forfeiture and settlement options which are required or permitted by the insurance law or regulation of the jurisdiction in which the contract is offered; and provided further that unless required by the insurance law or regulation of the jurisdiction in which the contract is offered or unless elected by the contractholder, the contract shall not provide for the automatic imposition of any option, including, but not limited to, an automatic premium loan, which would involve the accrual or payment of an interest or similar charge.</P>
                            <P>(ii) Notwithstanding the provisions of paragraph (b)(13)(i) of this section, if the amounts available under the contract to pay the charges due under the contract on any contract processing day are less than such charges due, the contract may provide that the cash surrender value shall be applied to purchase a non-forfeiture option specified by the life insurer in such contract; provided that the contract also provides that Contract processing days occur not less frequently than monthly.</P>
                            <P>(iii) Subject to section 26(f) (15 U.S.C. 80a-26(f)), sales charges and administrative expenses or fees may be deducted upon redemption.</P>
                            <P>(14) Section 32(a)(2) (15 U.S.C. 80a-31(a)(2)); provided that:</P>
                            <P>(i) The independent public accountant is selected before the effective date of the 1933 Act registration statement for flexible contracts, and the identity of the accountant is disclosed in the registration statement; and</P>
                            <P>(ii) The selection of the accountant is submitted for ratification or rejection to flexible contractholders at their first meeting and within one year after the effective date of the 1933 Act registration statement for flexible contracts, unless the time for holding the meeting is extended by order of the Commission.</P>
                            <P>
                                (15) If the separate account is organized as a unit investment trust, all the assets of which consist of the shares of one or more registered management investment companies which offer their shares exclusively to separate accounts of the life insurer, or of any affiliated life insurance company, offering either scheduled contracts or flexible contracts, or both; or which also offer their shares to variable annuity separate accounts of the life insurer or of an affiliated life insurance company, or which offer their shares to any such life insurance company in consideration solely for advances made by the life insurer in connection with the operation of the separate account; provided that the board of directors of each investment company, constituted with a majority of disinterested directors, will monitor such company for the existence of any material irreconcilable conflict between the interests of variable annuity contractholders and scheduled or flexible contractholders investing in such company; the life insurer agrees that it will be responsible for reporting any potential or existing conflicts to the directors; and if a conflict arises, the life insurer will, at its own cost, remedy such conflict up to and including establishing a new registered management investment company and segregating the assets underlying the 
                                <PRTPAGE P="26109"/>
                                variable annuity contracts and the scheduled or flexible contracts; then:
                            </P>
                            <P>(i) The eligibility restrictions of section 9(a) shall not apply to those persons who are officers, directors or employees of the life insurer or its affiliates who do not participate directly in the management or administration of any registered management investment company described in paragraph (b)(15) of this section;</P>
                            <P>(ii) The life insurer shall be ineligible under paragraph (3) of section 9(a) to serve as investment adviser of or principal underwriter for any registered management investment company described in paragraph (b)(15) of this section only if an affiliated person of such life insurer, ineligible by reason of paragraphs (1) or (2) of section 9(a), participates in the management or administration of such company;</P>
                            <P>(iii) For purposes of any section of the Act which provides for the vote of securityholders on matters relating to the separate account or the underlying registered investment company, the voting provisions of paragraphs (b)(10)(i) and (ii) of this section apply; provided that:</P>
                            <P>(A) The life insurer may vote shares of the registered management investment companies held by the separate account without regard to instructions from contractholders of the separate account if such instructions would require such shares to be voted:</P>
                            <P>
                                (
                                <E T="03">1</E>
                                ) To cause such companies to make (or refrain from making) certain investments which would result in changes in the sub-classification or investment objectives of such companies or to approve or disapprove any contract between such companies and an investment adviser when required to do so by an insurance regulatory authority subject to the provisions of paragraphs (b)(5)(i) and (b)(7)(ii)(A) of this section; or
                            </P>
                            <P>
                                (
                                <E T="03">2</E>
                                ) In favor of changes in investment objectives, investment adviser of or principal underwriter for such companies subject to the provisions of paragraphs (b)(5)(ii) and (b)(7)(ii)(B) and (C) of this section;
                            </P>
                            <P>
                                (B) Any action taken in accordance with paragraph (b)(15)(iii)(A)(
                                <E T="03">1</E>
                                ) or (
                                <E T="03">2</E>
                                ) of this section and the reasons therefor shall be disclosed in the next report contractholders made under section 30(e) (15 U.S.C. 80a-29(e)) and § 270.30e-2 (Rule 30e-2);
                            </P>
                            <P>(iv) Any registered management investment company established by the life insurer and described in paragraph (b)(15) of this section shall be exempt from section 14(a); and</P>
                            <P>(v) Any registered management investment company established by the life insurer and described in paragraph (b)(14) of this section shall be exempt from sections 15(a), 16(a), and 32(a)(2) (15 U.S.C. 80a-15(a), 80-16(a), and 80-31(a)(2), respectively), to the extent prescribed by paragraphs (b)(7)(i), (b)(8)(i), and (b)(14) of this section; provided that the company complies with the conditions set forth in paragraphs (b)(7)(i), (b)(8)(i), and (b)(14) of this section as if it were a separate account.</P>
                            <P>(c) When used in this section:</P>
                            <P>
                                (1) 
                                <E T="03">Flexible premium variable life insurance contract</E>
                                 means a contract of life insurance, subject to regulation under the insurance laws or code of every jurisdiction in which it is offered, funded by a separate account of a life insurer, which contract provides for:
                            </P>
                            <P>(i) Premium payments which are not fixed by the life insurer as to both timing and amount; provided, however, that the life insurer may fix the timing and minimum amount of premium payments for the first two contract periods following issuance of the contract or of an increase in or addition of insurance benefits, and may prescribe a reasonable minimum amount for any additional premium payment;</P>
                            <P>(ii) A death benefit the amount or duration of which may vary to reflect the investment experience of the separate account;</P>
                            <P>(iii) A cash value which varies to reflect the investment experience of the separate account; and</P>
                            <P>(iv) There is a reasonable expectation that subsequent premium payments will be made.</P>
                            <P>
                                (2) 
                                <E T="03">Contract period</E>
                                 means the period from a contract issue or anniversary date to the earlier of the next following anniversary date (or, if later, the last day of any grace period commencing before such next following anniversary date) or the termination date of the contract.
                            </P>
                            <P>
                                (3) 
                                <E T="03">Cash value</E>
                                 means the amount that would be available in cash upon voluntary termination of a contract by its owner before it becomes payable by death or maturity, without regard to any charges that may be assessed upon such termination and before deduction of any outstanding contract loan.
                            </P>
                            <P>
                                (4) 
                                <E T="03">Cash surrender value</E>
                                 means the amount available in cash upon voluntary termination of a contract by its owner before it becomes payable by death or maturity, after any charges assessed in connection with the termination have been deducted and before deduction of any outstanding contract loan.
                            </P>
                            <P>
                                (5) 
                                <E T="03">Contract processing day</E>
                                 means any day on which charges under the contract are deducted from the separate account.
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.8b-1 </SECTNO>
                        <SUBJECT>[Amended]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>28. Amend § 270.8b-1 by removing “270.8b-32” everywhere it appears and adding “270.8b-31” in its place.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>29. Amend § 270.11a-2 by revising paragraphs (c) and (d) and removing the parenthetical authority at the end of the section to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.11a-2 </SECTNO>
                            <SUBJECT>Offers of exchange by certain registered separate accounts or others the terms of which do not require prior Commission approval.</SUBJECT>
                            <STARS/>
                            <P>(c) If the offering account imposes a front-end sales load on the acquired security, then such sales load shall be a percentage that is no greater than the excess of the rate of the front-end sales load otherwise applicable to that security over the rate of any front-end sales load previously paid on the exchanged security.</P>
                            <P>(d) If the offering account imposes a deferred sales load on the acquired security and the exchanged security was also subject to a deferred sales load, then any deferred sales load imposed on the acquired security shall be calculated as if:</P>
                            <P>(1) The holder of the acquired security had been the holder of that security from the date on which he became the holder of the exchanged security; and</P>
                            <P>(2) Purchase payments made for the exchanged security had been made for the acquired security on the date on which they were made for the exchanged security.</P>
                            <STARS/>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>30. Revise § 270.14a-2 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.14a-2 </SECTNO>
                            <SUBJECT>Exemption from section 14(a) of the Act for certain registered separate accounts and their principal underwriters.</SUBJECT>
                            <P>(a) A registered separate account, and any principal underwriter for such account, shall be exempt from section 14(a) of the Act (15 U.S.C. 80a-14(a)) with respect to a public offering of variable annuity contracts participating in such account.</P>
                            <P>(b) Any registered management investment company which has as a promoter an insurance company and which offers its securities to separate accounts of such insurance company that offer variable annuity contracts and are registered under the Act as unit investment trusts (“trust accounts”), and any principal underwriter for such investment company, shall be exempt from section 14(a) with respect to such offering and to the offering of such securities to trust accounts of other insurance companies.</P>
                            <P>
                                (c) Any registered management investment company exempt from 
                                <PRTPAGE P="26110"/>
                                section 14(a) of the Act pursuant to paragraph (b) of this section shall be exempt from sections 15(a), 16(a), and 32(a)(2) of the Act (15 U.S.C. 80a-15(a), 80a-16(a), and 80a-31(a)(2)), to the extent prescribed in §§ 270.15a-3, 270.16a-1, and 270.32a-2 (Rules 15a-3, 16a-1, and 32a-2 under the Act), provided that such investment company complies with the conditions set forth in Rules 15a-3, 16a-1, and 32a-2 as if it were a separate account.
                            </P>
                        </SECTION>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>31. Revise § 270.26a-1 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.26a-1 </SECTNO>
                            <SUBJECT>Payment of administrative fees to the depositor or principal underwriter of a unit investment trust; exemptive relief for separate accounts.</SUBJECT>
                            <P>For purposes of section 26(a)(2)(C) of the Act, payment of a fee to the depositor of or a principal underwriter for a registered unit investment trust, or to any affiliated person or agent of such depositor or underwriter (collectively, “depositor”), for bookkeeping or other administrative services provided to the trust shall be allowed the custodian or trustee (“trustee”) as an expense, provided that such fee is an amount not greater than the expenses, without profit:</P>
                            <P>(a) Actually paid by such depositor directly attributable to the services provided; and</P>
                            <P>(b) Increased by the services provided directly by such depositor, as determined in accordance with generally accepted accounting principles consistently applied.</P>
                        </SECTION>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.26a-2</SECTNO>
                        <SUBJECT> [Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>32. Remove § 270.26a-2.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27a-1</SECTNO>
                        <SUBJECT> [Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>33. Remove § 270.27a-1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27a-2</SECTNO>
                        <SUBJECT> [Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>34. Remove § 270.27a-2.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27a-3</SECTNO>
                        <SUBJECT> [Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>35. Remove § 270.27a-3.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27c-1 </SECTNO>
                        <SUBJECT>[Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>36. Remove and reserve § 270.27c-1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27d-2 </SECTNO>
                        <SUBJECT>[Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>37. Remove and reserve § 270.27d-2.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27e-1 </SECTNO>
                        <SUBJECT>[Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>38. Remove and reserve § 270.27e-1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27f-1</SECTNO>
                        <SUBJECT> [Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>39. Remove and reserve § 270.27f-1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27g-1</SECTNO>
                        <SUBJECT> [Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>40. Remove and reserve § 270.27g-1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 270.27h-1 </SECTNO>
                        <SUBJECT>[Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>41. Remove and reserve § 270.27h-1.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="270">
                        <AMDPAR>42. Add § 270.27i-1 to read as follows:</AMDPAR>
                        <SECTION>
                            <SECTNO>§ 270.27i-1 </SECTNO>
                            <SUBJECT>Exemption from Section 27(i)(2)(A) of the Act during annuity payment period of variable annuity contracts participating in certain registered separate accounts.</SUBJECT>
                            <P>A registered separate account, and any depositor of or underwriter for such account, shall, during the annuity payment period of variable annuity contracts participating in such account, be exempt from the requirement of paragraph (1) of section 27(i)(2)(A) of the Act that a periodic payment plan certificate be a redeemable security.</P>
                        </SECTION>
                    </REGTEXT>
                    <PART>
                        <HD SOURCE="HED">PART 274—FORMS PRESCRIBED UNDER THE INVESTMENT COMPANY ACT OF 1940</HD>
                    </PART>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>43. The general authority citation for part 274 continues to read as follows:</AMDPAR>
                        <AUTH>
                            <HD SOURCE="HED">Authority:</HD>
                            <P>
                                 15 U.S.C. 77f, 77g, 77h, 77j, 77s, 78c(b), 78
                                <E T="03">l,</E>
                                 78m, 78n, 78o(d), 80a-8, 80a-24, 80a-26, 80a-29, and Pub. L. 111-203, sec. 939A, 124 Stat. 1376 (2010), unless otherwise noted.
                            </P>
                        </AUTH>
                        <STARS/>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 274.11 </SECTNO>
                        <SUBJECT>[Removed and Reserved]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>44. Remove and reserve § 274.11.</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>45. Revise Form N-3 (referenced in §§ 239.17a and 274.11b) to read as follows:</AMDPAR>
                        <NOTE>
                            <HD SOURCE="HED">Note: </HD>
                            <P>The text of Form N-3 will not appear in the Code of Federal Regulations.</P>
                        </NOTE>
                        <GPH SPAN="3" DEEP="638">
                            <PRTPAGE P="26111"/>
                            <GID>ER01MY20.016</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="629">
                            <PRTPAGE P="26112"/>
                            <GID>ER01MY20.017</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="617">
                            <PRTPAGE P="26113"/>
                            <GID>ER01MY20.018</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="607">
                            <PRTPAGE P="26114"/>
                            <GID>ER01MY20.019</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="638">
                            <PRTPAGE P="26115"/>
                            <GID>ER01MY20.020</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="633">
                            <PRTPAGE P="26116"/>
                            <GID>ER01MY20.021</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="634">
                            <PRTPAGE P="26117"/>
                            <GID>ER01MY20.022</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="638">
                            <PRTPAGE P="26118"/>
                            <GID>ER01MY20.023</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="631">
                            <PRTPAGE P="26119"/>
                            <GID>ER01MY20.024</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="606">
                            <PRTPAGE P="26120"/>
                            <GID>ER01MY20.025</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="633">
                            <PRTPAGE P="26121"/>
                            <GID>ER01MY20.026</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="628">
                            <PRTPAGE P="26122"/>
                            <GID>ER01MY20.027</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="634">
                            <PRTPAGE P="26123"/>
                            <GID>ER01MY20.028</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="609">
                            <PRTPAGE P="26124"/>
                            <GID>ER01MY20.029</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="630">
                            <PRTPAGE P="26125"/>
                            <GID>ER01MY20.030</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="633">
                            <PRTPAGE P="26126"/>
                            <GID>ER01MY20.031</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="588">
                            <PRTPAGE P="26127"/>
                            <GID>ER01MY20.032</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="628">
                            <PRTPAGE P="26128"/>
                            <GID>ER01MY20.033</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26129"/>
                            <GID>ER01MY20.034</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="631">
                            <PRTPAGE P="26130"/>
                            <GID>ER01MY20.035</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26131"/>
                            <GID>ER01MY20.036</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="607">
                            <PRTPAGE P="26132"/>
                            <GID>ER01MY20.037</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="615">
                            <PRTPAGE P="26133"/>
                            <GID>ER01MY20.038</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="637">
                            <PRTPAGE P="26134"/>
                            <GID>ER01MY20.039</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26135"/>
                            <GID>ER01MY20.040</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="595">
                            <PRTPAGE P="26136"/>
                            <GID>ER01MY20.041</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="632">
                            <PRTPAGE P="26137"/>
                            <GID>ER01MY20.042</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26138"/>
                            <GID>ER01MY20.043</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26139"/>
                            <GID>ER01MY20.044</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26140"/>
                            <GID>ER01MY20.045</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="630">
                            <PRTPAGE P="26141"/>
                            <GID>ER01MY20.046</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="630">
                            <PRTPAGE P="26142"/>
                            <GID>ER01MY20.047</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="538">
                            <PRTPAGE P="26143"/>
                            <GID>ER01MY20.048</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="618">
                            <PRTPAGE P="26144"/>
                            <GID>ER01MY20.049</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26145"/>
                            <GID>ER01MY20.050</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26146"/>
                            <GID>ER01MY20.051</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26147"/>
                            <GID>ER01MY20.052</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26148"/>
                            <GID>ER01MY20.053</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="629">
                            <PRTPAGE P="26149"/>
                            <GID>ER01MY20.054</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26150"/>
                            <GID>ER01MY20.055</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26151"/>
                            <GID>ER01MY20.056</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26152"/>
                            <GID>ER01MY20.057</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26153"/>
                            <GID>ER01MY20.058</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26154"/>
                            <GID>ER01MY20.059</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26155"/>
                            <GID>ER01MY20.060</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26156"/>
                            <GID>ER01MY20.061</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26157"/>
                            <GID>ER01MY20.062</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26158"/>
                            <GID>ER01MY20.063</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26159"/>
                            <GID>ER01MY20.064</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26160"/>
                            <GID>ER01MY20.065</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26161"/>
                            <GID>ER01MY20.066</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26162"/>
                            <GID>ER01MY20.067</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26163"/>
                            <GID>ER01MY20.068</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26164"/>
                            <GID>ER01MY20.069</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26165"/>
                            <GID>ER01MY20.070</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26166"/>
                            <GID>ER01MY20.071</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26167"/>
                            <GID>ER01MY20.072</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26168"/>
                            <GID>ER01MY20.073</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26169"/>
                            <GID>ER01MY20.074</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26170"/>
                            <GID>ER01MY20.075</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26171"/>
                            <GID>ER01MY20.076</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="611">
                            <PRTPAGE P="26172"/>
                            <GID>ER01MY20.077</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="623">
                            <PRTPAGE P="26173"/>
                            <GID>ER01MY20.078</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26174"/>
                            <GID>ER01MY20.079</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26175"/>
                            <GID>ER01MY20.080</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26176"/>
                            <GID>ER01MY20.081</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26177"/>
                            <GID>ER01MY20.082</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26178"/>
                            <GID>ER01MY20.083</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26179"/>
                            <GID>ER01MY20.084</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26180"/>
                            <GID>ER01MY20.085</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26181"/>
                            <GID>ER01MY20.086</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26182"/>
                            <GID>ER01MY20.087</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26183"/>
                            <GID>ER01MY20.088</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26184"/>
                            <GID>ER01MY20.089</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26185"/>
                            <GID>ER01MY20.090</GID>
                        </GPH>
                          
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26186"/>
                            <GID>ER01MY20.091</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26187"/>
                            <GID>ER01MY20.092</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26188"/>
                            <GID>ER01MY20.093</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26189"/>
                            <GID>ER01MY20.094</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26190"/>
                            <GID>ER01MY20.095</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26191"/>
                            <GID>ER01MY20.096</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26192"/>
                            <GID>ER01MY20.097</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26193"/>
                            <GID>ER01MY20.098</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26194"/>
                            <GID>ER01MY20.099</GID>
                        </GPH>
                          
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26195"/>
                            <GID>ER01MY20.100</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26196"/>
                            <GID>ER01MY20.101</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26197"/>
                            <GID>ER01MY20.102</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26198"/>
                            <GID>ER01MY20.103</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26199"/>
                            <GID>ER01MY20.104</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26200"/>
                            <GID>ER01MY20.105</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26201"/>
                            <GID>ER01MY20.106</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26202"/>
                            <GID>ER01MY20.107</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26203"/>
                            <GID>ER01MY20.108</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="430">
                            <PRTPAGE P="26204"/>
                            <GID>ER01MY20.109</GID>
                        </GPH>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>46. Effective January 1, 2022, Form N-3 (referenced in §§ 239.17a and 274.11b) is further amended by:</AMDPAR>
                        <AMDPAR> a. In Item 1, removing paragraph (a)(11); and</AMDPAR>
                        <AMDPAR> b. In Item 31(a), removing Instruction 4(f).</AMDPAR>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>47. Revise Form N-4 (referenced in §§ 239.17b and 274.11c) to read as follows:</AMDPAR>
                        <NOTE>
                            <HD SOURCE="HED">Note:</HD>
                            <P>The text of Form N-4 will not appear in the Code of Federal Regulations.</P>
                        </NOTE>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26205"/>
                            <GID>ER01MY20.111</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26206"/>
                            <GID>ER01MY20.112</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26207"/>
                            <GID>ER01MY20.113</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26208"/>
                            <GID>ER01MY20.114</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26209"/>
                            <GID>ER01MY20.115</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26210"/>
                            <GID>ER01MY20.116</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26211"/>
                            <GID>ER01MY20.117</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26212"/>
                            <GID>ER01MY20.118</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26213"/>
                            <GID>ER01MY20.119</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26214"/>
                            <GID>ER01MY20.120</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26215"/>
                            <GID>ER01MY20.121</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26216"/>
                            <GID>ER01MY20.122</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26217"/>
                            <GID>ER01MY20.123</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26218"/>
                            <GID>ER01MY20.124</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26219"/>
                            <GID>ER01MY20.125</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26220"/>
                            <GID>ER01MY20.126</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26221"/>
                            <GID>ER01MY20.127</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26222"/>
                            <GID>ER01MY20.128</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26223"/>
                            <GID>ER01MY20.129</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26224"/>
                            <GID>ER01MY20.130</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26225"/>
                            <GID>ER01MY20.131</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26226"/>
                            <GID>ER01MY20.132</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26227"/>
                            <GID>ER01MY20.133</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26228"/>
                            <GID>ER01MY20.134</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26229"/>
                            <GID>ER01MY20.135</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26230"/>
                            <GID>ER01MY20.136</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26231"/>
                            <GID>ER01MY20.137</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26232"/>
                            <GID>ER01MY20.138</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26233"/>
                            <GID>ER01MY20.139</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26234"/>
                            <GID>ER01MY20.140</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26235"/>
                            <GID>ER01MY20.141</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26236"/>
                            <GID>ER01MY20.142</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26237"/>
                            <GID>ER01MY20.143</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26238"/>
                            <GID>ER01MY20.144</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26239"/>
                            <GID>ER01MY20.145</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26240"/>
                            <GID>ER01MY20.146</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26241"/>
                            <GID>ER01MY20.147</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26242"/>
                            <GID>ER01MY20.148</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26243"/>
                            <GID>ER01MY20.149</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26244"/>
                            <GID>ER01MY20.150</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26245"/>
                            <GID>ER01MY20.151</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26246"/>
                            <GID>ER01MY20.152</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26247"/>
                            <GID>ER01MY20.153</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26248"/>
                            <GID>ER01MY20.154</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26249"/>
                            <GID>ER01MY20.155</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26250"/>
                            <GID>ER01MY20.156</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26251"/>
                            <GID>ER01MY20.157</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26252"/>
                            <GID>ER01MY20.158</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26253"/>
                            <GID>ER01MY20.159</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26254"/>
                            <GID>ER01MY20.160</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26255"/>
                            <GID>ER01MY20.161</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="300">
                            <PRTPAGE P="26256"/>
                            <GID>ER01MY20.162</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26257"/>
                            <GID>ER01MY20.164</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26258"/>
                            <GID>ER01MY20.165</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26259"/>
                            <GID>ER01MY20.166</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26260"/>
                            <GID>ER01MY20.167</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26261"/>
                            <GID>ER01MY20.168</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26262"/>
                            <GID>ER01MY20.169</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26263"/>
                            <GID>ER01MY20.170</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26264"/>
                            <GID>ER01MY20.171</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26265"/>
                            <GID>ER01MY20.172</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26266"/>
                            <GID>ER01MY20.173</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26267"/>
                            <GID>ER01MY20.174</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26268"/>
                            <GID>ER01MY20.175</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26269"/>
                            <GID>ER01MY20.176</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26270"/>
                            <GID>ER01MY20.177</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="562">
                            <PRTPAGE P="26271"/>
                            <GID>ER01MY20.178</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26272"/>
                            <GID>ER01MY20.179</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26273"/>
                            <GID>ER01MY20.180</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26274"/>
                            <GID>ER01MY20.181</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26275"/>
                            <GID>ER01MY20.182</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26276"/>
                            <GID>ER01MY20.183</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26277"/>
                            <GID>ER01MY20.184</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26278"/>
                            <GID>ER01MY20.185</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26279"/>
                            <GID>ER01MY20.186</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26280"/>
                            <GID>ER01MY20.187</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26281"/>
                            <GID>ER01MY20.188</GID>
                        </GPH>
                          
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26282"/>
                            <GID>ER01MY20.189</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26283"/>
                            <GID>ER01MY20.190</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26284"/>
                            <GID>ER01MY20.191</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26285"/>
                            <GID>ER01MY20.192</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26286"/>
                            <GID>ER01MY20.193</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26287"/>
                            <GID>ER01MY20.194</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26288"/>
                            <GID>ER01MY20.195</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26289"/>
                            <GID>ER01MY20.196</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="638">
                              
                            <PRTPAGE P="26290"/>
                            <GID>ER01MY20.197</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26291"/>
                            <GID>ER01MY20.198</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26292"/>
                            <GID>ER01MY20.199</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26293"/>
                            <GID>ER01MY20.200</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26294"/>
                            <GID>ER01MY20.201</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26295"/>
                            <GID>ER01MY20.202</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26296"/>
                            <GID>ER01MY20.203</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26297"/>
                            <GID>ER01MY20.204</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26298"/>
                            <GID>ER01MY20.205</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26299"/>
                            <GID>ER01MY20.206</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26300"/>
                            <GID>ER01MY20.207</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26301"/>
                            <GID>ER01MY20.208</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26302"/>
                            <GID>ER01MY20.209</GID>
                        </GPH>
                            
                        <GPH SPAN="3" DEEP="640">
                              
                            <PRTPAGE P="26303"/>
                            <GID>ER01MY20.210</GID>
                        </GPH>
                          
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26304"/>
                            <GID>ER01MY20.211</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26305"/>
                            <GID>ER01MY20.212</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26306"/>
                            <GID>ER01MY20.213</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="633">
                            <PRTPAGE P="26307"/>
                            <GID>ER01MY20.214</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="640">
                            <PRTPAGE P="26308"/>
                            <GID>ER01MY20.215</GID>
                        </GPH>
                        <GPH SPAN="3" DEEP="96">
                            <PRTPAGE P="26309"/>
                            <GID>ER01MY20.216</GID>
                        </GPH>
                    </REGTEXT>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>50. Effective January 1, 2022, Form N-6 (referenced in §§ 239.17c and 274.11d) is amended by removing paragraph (a)(9) of Item 1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 274.127e-1</SECTNO>
                        <SUBJECT>[Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>51. Remove § 274.127e-1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 274.127f-1</SECTNO>
                        <SUBJECT>[Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>52. Remove § 274.127f-1.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 274.302 </SECTNO>
                        <SUBJECT>[Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>53. Remove § 274.302.</AMDPAR>
                    </REGTEXT>
                    <SECTION>
                        <SECTNO>§ 274.303 </SECTNO>
                        <SUBJECT>[Removed]</SUBJECT>
                    </SECTION>
                    <REGTEXT TITLE="17" PART="274">
                        <AMDPAR>54. Remove § 274.303.</AMDPAR>
                    </REGTEXT>
                    <SIG>
                        <P>By the Commission.</P>
                        <DATED>Dated: March 11, 2020.</DATED>
                        <NAME>Vanessa A. Countryman,</NAME>
                        <TITLE>Secretary.</TITLE>
                    </SIG>
                </SUPLINF>
                <FRDOC>[FR Doc. 2020-05526 Filed 4-30-20; 8:45 am]</FRDOC>
                <BILCOD> BILLING CODE 8011-01-P</BILCOD>
            </RULE>
        </RULES>
    </NEWPART>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Presidential Documents</UNITNAME>
    <NEWPART>
        <PTITLE>
            <PRTPAGE P="26311"/>
            <PARTNO>Part V</PARTNO>
            <PRES>The President</PRES>
            <EXECORDR>Executive Order 13917—Delegating Authority Under the Defense Production Act With Respect to Food Supply Chain Resources During the National Emergency Caused by the Outbreak of COVID-19</EXECORDR>
            <EXECORDR>Executive Order 13918—Establishment of the Interagency Labor Committee for Monitoring and Enforcement Under Section 711 of the United States-Mexico-Canada Agreement Implementation Act</EXECORDR>
            <MEMO>Memorandum of April 28, 2020—Providing Continued Federal Support for Governors' Use of the National Guard To Respond to COVID-19 and To Facilitate Economic Recovery</MEMO>
        </PTITLE>
        <PRESDOCS>
            <PRESDOCU>
                <EXECORD>
                    <TITLE3>Title 3—</TITLE3>
                    <PRES>
                        The President
                        <PRTPAGE P="26313"/>
                    </PRES>
                    <EXECORDR>Executive Order 13917 of April 28, 2020</EXECORDR>
                    <HD SOURCE="HED">Delegating Authority Under the Defense Production Act With Respect to Food Supply Chain Resources During the National Emergency Caused by the Outbreak of COVID-19</HD>
                    <FP>
                        By the authority vested in me as President by the Constitution and the laws of the United States of America, including the Defense Production Act of 1950, as amended (50 U.S.C. 4501 
                        <E T="03">et seq.</E>
                        ) (the “Act”), and section 301 of title 3, United States Code, it is hereby ordered as follows:
                    </FP>
                    <FP>
                        <E T="04">Section 1</E>
                        . 
                        <E T="03">Policy.</E>
                         The 2019 novel (new) coronavirus known as SARS-CoV-2, the virus causing outbreaks of the disease COVID-19, has significantly disrupted the lives of Americans. In Proclamation 9994 of March 13, 2020 (Declaring a National Emergency Concerning the Novel Coronavirus Disease (COVID-19) Outbreak), I declared that the COVID-19 outbreak in the United States constituted a national emergency, beginning March 1, 2020. Since then, the American people have united behind a policy of mitigation strategies, including social distancing, to flatten the curve of infections and reduce the spread of COVID-19. The COVID-19 outbreak and these necessary mitigation measures have taken a dramatic toll on the United States economy and critical infrastructure.
                    </FP>
                    <FP>It is important that processors of beef, pork, and poultry (“meat and poultry”) in the food supply chain continue operating and fulfilling orders to ensure a continued supply of protein for Americans. However, outbreaks of COVID-19 among workers at some processing facilities have led to the reduction in some of those facilities' production capacity. In addition, recent actions in some States have led to the complete closure of some large processing facilities. Such actions may differ from or be inconsistent with interim guidance recently issued by the Centers for Disease Control and Prevention (CDC) of the Department of Health and Human Services and the Occupational Safety and Health Administration (OSHA) of the Department of Labor entitled “Meat and Poultry Processing Workers and Employers” providing for the safe operation of such facilities.</FP>
                    <FP>Such closures threaten the continued functioning of the national meat and poultry supply chain, undermining critical infrastructure during the national emergency. Given the high volume of meat and poultry processed by many facilities, any unnecessary closures can quickly have a large effect on the food supply chain. For example, closure of a single large beef processing facility can result in the loss of over 10 million individual servings of beef in a single day. Similarly, under established supply chains, closure of a single meat or poultry processing facility can severely disrupt the supply of protein to an entire grocery store chain.</FP>
                    <FP>
                        Accordingly, I find that meat and poultry in the food supply chain meet the criteria specified in section 101(b) of the Act (50 U.S.C. 4511(b)). Under the delegation of authority provided in this order, the Secretary of Agriculture shall take all appropriate action under that section to ensure that meat and poultry processors continue operations consistent with the guidance for their operations jointly issued by the CDC and OSHA. Under the delegation of authority provided in this order, the Secretary of Agriculture may identify additional specific food supply chain resources that meet the criteria of section 101(b).
                        <PRTPAGE P="26314"/>
                    </FP>
                    <FP>
                        <E T="04">Sec. 2</E>
                        . 
                        <E T="03">Ensuring the Continued Supply of Meat and Poultry.</E>
                         (a) Notwithstanding Executive Order 13603 of March 16, 2012 (National Defense Resources Preparedness), the authority of the President to require performance of contracts or orders (other than contracts of employment) to promote the national defense over performance of any other contracts or orders, to allocate materials, services, and facilities as deemed necessary or appropriate to promote the national defense, and to implement the Act in subchapter III of chapter 55 of title 50, United States Code (50 U.S.C. 4554, 4555, 4556, 4559, 4560), is delegated to the Secretary of Agriculture with respect to food supply chain resources, including meat and poultry, during the national emergency caused by the outbreak of COVID-19 within the United States.
                    </FP>
                    <P>(b) The Secretary of Agriculture shall use the authority under section 101 of the Act, in consultation with the heads of such other executive departments and agencies as he deems appropriate, to determine the proper nationwide priorities and allocation of all the materials, services, and facilities necessary to ensure the continued supply of meat and poultry, consistent with the guidance for the operations of meat and poultry processing facilities jointly issued by the CDC and OSHA.</P>
                    <P>(c) The Secretary of Agriculture shall issue such orders and adopt and revise appropriate rules and regulations as may be necessary to implement this order.</P>
                    <FP>
                        <E T="04">Sec. 3</E>
                        . 
                        <E T="03">General Provisions.</E>
                         (a) Nothing in this order shall be construed to impair or otherwise affect:
                    </FP>
                    <FP SOURCE="FP1">(i) the authority granted by law to an executive department or agency, or the head thereof; or</FP>
                    <FP SOURCE="FP1">(ii) the functions of the Director of the Office of Management and Budget relating to budgetary, administrative, or legislative proposals.</FP>
                    <P>(b) This order shall be implemented consistent with applicable law and subject to the availability of appropriations.</P>
                    <P>(c) This order is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.</P>
                    <GPH SPAN="1" DEEP="80" HTYPE="RIGHT">
                        <GID>Trump.EPS</GID>
                    </GPH>
                    <PSIG> </PSIG>
                    <PLACE>THE WHITE HOUSE,</PLACE>
                    <DATE>April 28, 2020.</DATE>
                    <FRDOC>[FR Doc. 2020-09536 </FRDOC>
                    <FILED>Filed 4-30-20; 11:15 am]</FILED>
                    <BILCOD>Billing code 3295-F0-P</BILCOD>
                </EXECORD>
            </PRESDOCU>
        </PRESDOCS>
    </NEWPART>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Presidential Documents</UNITNAME>
    <PRESDOC>
        <PRESDOCU>
            <EXECORD>
                <PRTPAGE P="26315"/>
                <EXECORDR>Executive Order 13918 of April 28, 2020</EXECORDR>
                <HD SOURCE="HED">Establishment of the Interagency Labor Committee for Monitoring and Enforcement Under Section 711 of the United States-Mexico-Canada Agreement Implementation Act</HD>
                <FP>By the authority vested in me as President by the Constitution and the laws of the United States of America, including section 301 of title 3, United States Code, and section 711 of the United States-Mexico-Canada Agreement Implementation Act (Act) (Public Law 116-113), it is hereby ordered as follows:</FP>
                <FP>
                    <E T="04">Section 1</E>
                    . 
                    <E T="03">Establishment of the Interagency Labor Committee for Monitoring and Enforcement.</E>
                     The Interagency Labor Committee for Monitoring and Enforcement (Committee) is hereby established to coordinate the efforts of the United States to monitor the implementation and maintenance of the labor obligations of Canada and Mexico, to monitor the implementation and maintenance of Mexico's labor reform, and to recommend enforcement actions with respect to Canada or Mexico, as provided for in section 715 of the Act.
                </FP>
                <FP>
                    <E T="04">Sec. 2</E>
                    . 
                    <E T="03">Membership.</E>
                     The Committee shall be co-chaired by the United States Trade Representative and the Secretary of Labor, and shall include representatives of the Department of State, the Department of the Treasury, the Department of Agriculture, the Department of Commerce, the Department of Homeland Security, and the United States Agency for International Development. The Co-Chairs may invite representatives from other executive departments or agencies, as appropriate, to participate as members or observers. Each executive department, agency, and component represented on the Committee shall ensure that the necessary staff are available to assist their respective representatives in performing the responsibilities of the Committee. The Committee, by consensus, may designate members to assist it in carrying out the functions described in the Act.
                </FP>
                <FP>
                    <E T="04">Sec. 3</E>
                    . 
                    <E T="03">Committee Decision-Making.</E>
                     The Committee shall endeavor to make any decision on an action or determination under sections 712 through 719 of the Act by consensus, which shall be deemed to exist where no member objects to the proposed action or determination.
                </FP>
                <FP>
                    <E T="04">Sec. 4</E>
                    . 
                    <E T="03">Funding.</E>
                     Each executive department and agency participating in the Committee shall bear its own expenses incurred in connection with the Committee's functions described in sections 711 through 719 of the Act. The Department of Labor will provide funding for the hotline required under section 717 of the Act.
                </FP>
                <FP>
                    <E T="04">Sec. 5</E>
                    . 
                    <E T="03">General Provisions.</E>
                     (a) Nothing in this order shall be construed to impair or otherwise affect:
                </FP>
                <FP SOURCE="FP1">(i) the authority granted by law to an executive department or agency, or the head thereof; or</FP>
                <FP SOURCE="FP1">(ii) the functions of the Director of the Office of Management and Budget relating to budgetary, administrative, or legislative proposals.</FP>
                <P>(b) This order shall be implemented consistent with applicable law and subject to the availability of appropriations.</P>
                <PRTPAGE P="26316"/>
                <P>(c) This order is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.</P>
                <GPH SPAN="1" DEEP="80" HTYPE="RIGHT">
                    <GID>Trump.EPS</GID>
                </GPH>
                <PSIG> </PSIG>
                <PLACE>THE WHITE HOUSE,</PLACE>
                <DATE>April 28, 2020.</DATE>
                <FRDOC>[FR Doc. 2020-09537 </FRDOC>
                <FILED>Filed 4-30-20; 11:15 am]</FILED>
                <BILCOD>Billing code 3295-F0-P</BILCOD>
            </EXECORD>
        </PRESDOCU>
    </PRESDOC>
    <VOL>85</VOL>
    <NO>85</NO>
    <DATE>Friday, May 1, 2020</DATE>
    <UNITNAME>Presidential Documents</UNITNAME>
    <PRESDOC>
        <PRESDOCU>
            <PRMEMO>
                <PRTPAGE P="26317"/>
                <MEMO>Memorandum of April 28, 2020</MEMO>
                <HD SOURCE="HED">Providing Continued Federal Support for Governors' Use of the National Guard To Respond to COVID-19 and To Facilitate Economic Recovery</HD>
                <HD SOURCE="HED">Memorandum for the Secretary of Defense [and] the Secretary of Homeland Security</HD>
                <FP>By the authority vested in me as President by the Constitution and the laws of the United States of America, including the Robert T. Stafford Disaster Relief and Emergency Assistance Act, 42 U.S.C. 5121-5207 (the “Stafford Act”), and section 502 of title 32, United States Code, it is hereby ordered as follows:</FP>
                <FP>
                    <E T="04">Section 1</E>
                    . 
                    <E T="03">Policy.</E>
                     It is the policy of the United States to take measures to assist State Governors under the Stafford Act in their responses to all threats and hazards to the American people in their respective States. On March 13, 2020, I declared a national emergency recognizing the threat that COVID-19, the disease caused by the novel (new) coronavirus known as SARS-CoV-2 (“the virus”), and the virus poses to the Nation's healthcare systems. I also determined that same day that the COVID-19 outbreak constituted an emergency, of nationwide scope, pursuant to section 501(b) of the Stafford Act (42 U.S.C. 5191(b)). Considering the profound and unique public health risks posed by the ongoing outbreak of COVID-19, the need for close cooperation and mutual assistance between the Federal Government and the States is greater than at any time in recent history. This need remains as the United States continues to battle the public health threat posed by the virus, while transitioning to a period of increased economic activity and recovery in those areas of the Nation where the threat posed by the virus has been sufficiently mitigated. To provide maximum support to the Governor of the State of North Dakota as he makes decisions about the responses required to address local conditions in his jurisdiction with respect to combatting the threat posed by the virus and, where appropriate, facilitating its economic recovery, I am taking the actions set forth in sections 2, 3, and 4 of this memorandum:
                </FP>
                <FP>
                    <E T="04">Sec. 2</E>
                    . 
                    <E T="03">One Hundred Percent Federal Cost Share.</E>
                     To maximize assistance to the Governor of the State of North Dakota to facilitate Federal support with respect to the use of National Guard units under State control, I am directing the Federal Emergency Management Agency (FEMA) of the Department of Homeland Security to fund 100 percent of the emergency assistance activities associated with preventing, mitigating, and responding to the threat to public health and safety posed by the virus that North Dakota undertakes using its National Guard forces, as authorized by sections 403 (42 U.S.C. 5170b) and 503 (42 U.S.C. 5193) of the Stafford Act.
                </FP>
                <FP>
                    <E T="04">Sec. 3</E>
                    . 
                    <E T="03">Support of Operations or Missions to Prevent and Respond to the Spread of COVID-19.</E>
                     I am directing the Secretary of Defense, to the maximum extent feasible and consistent with mission requirements (including geographic proximity), to request pursuant to 32 U.S.C. 502(f) that the Governor of the State of North Dakota order National Guard forces to perform duty to fulfill mission assignments, on a fully reimbursable basis, that FEMA issues to the Department of Defense for the purpose of supporting State and local emergency assistance efforts under the Stafford Act.
                    <PRTPAGE P="26318"/>
                </FP>
                <FP>
                    <E T="04">Sec. 4</E>
                    . 
                    <E T="03">Termination and Extension.</E>
                     The 100 percent Federal cost share for the State of North Dakota's use of National Guard forces authorized pursuant to this memorandum shall extend to, and shall be available for orders of any length authorizing duty through, May 31, 2020.
                </FP>
                <FP>
                    <E T="04">Sec. 5</E>
                    . 
                    <E T="03">General Provisions.</E>
                     (a) Nothing in this memorandum shall be construed to impair or otherwise affect:
                </FP>
                <FP SOURCE="FP1">(i) the authority granted by law to an executive department or agency, or the head thereof; or</FP>
                <FP SOURCE="FP1">(ii) the functions of the Director of the Office of Management and Budget relating to budgetary, administrative, or legislative proposals.</FP>
                <P>(b) This memorandum shall be implemented consistent with applicable law and subject to the availability of appropriations.</P>
                <P>(c) This memorandum is not intended to, and does not, create any right or benefit, substantive or procedural, enforceable at law or in equity by any party against the United States, its departments, agencies, or entities, its officers, employees, or agents, or any other person.</P>
                <P>
                    (d) The Secretary of Defense is authorized and directed to publish this memorandum in the 
                    <E T="03">Federal Register.</E>
                </P>
                <GPH SPAN="1" DEEP="80" HTYPE="RIGHT">
                    <GID>Trump.EPS</GID>
                </GPH>
                <PSIG> </PSIG>
                <PLACE>THE WHITE HOUSE,</PLACE>
                <DATE>Washington, April 28, 2020</DATE>
                <FRDOC>[FR Doc. 2020-09540 </FRDOC>
                <FILED>Filed 4-30-20; 11:15 am]</FILED>
                <BILCOD>Billing code 5001-06-P</BILCOD>
            </PRMEMO>
        </PRESDOCU>
    </PRESDOC>
</FEDREG>
