WIXLIB

Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and RegulationsB. Health IT and Opioid Use DisorderPrevention and Treatment—Request forInformationVII. Conditions and Maintenance ofCertification Requirements for Health ITDevelopersA. ImplementationB. Provisions1. Information Blocking2. Assurancesa. Full Compliance and UnrestrictedImplementation of Certification CriteriaCapabilitiesb. Certification to the ‘‘Electronic HealthInformation Export’’ Criterionc. Records and Information Retentiond. Trusted Exchange Framework and theCommon Agreement—Request forInformation3. Communicationsa. Background and Purposeb. Condition of Certification Requirementsc. Maintenance of CertificationRequirements4. Application Programming Interfacesa. Statutory Interpretation and API PolicyPrinciplesb. API Standards and ImplementationSpecificationsc. Standardized API for Patient andPopulation Servicesd. API Condition of CertificationRequirementse. API Maintenance of CertificationRequirements5. Real World Testinga. Unit of Analysis at which TestingRequirements Applyb. Applicability of Real World TestingCondition and Maintenance ofCertification Requirementsc. Testing Plans, Methods, and ResultsReportingd. Submission Datese. Real World Testing Pilot Yearf. Health IT Modules Certified But Not YetDeployedg. Standards Version Advancement Process(SVAP)h. Updating Already Certified Health ITLeveraging SVAP Flexibilityi. Health IT Modules Presented forCertification Leveraging SVAPFlexibilityj. Requirements Associated With AllHealth IT Modules Certified LeveragingSVAP Flexibilityk. Advanced Version Approval for SVAPl. Real World Testing Principles of ProperConduct for ONC-ACBsm. Health IT Module Certification &Certification to Newer Versions ofCertain Standards6. Attestations7. EHR Reporting Criteria SubmissionC. ComplianceD. Enforcement1. ONC Direct Review of the Conditionsand Maintenance of CertificationRequirements2. Review and Enforcement Only by ONC3. Review Processesa. Initiating Review and Health ITDeveloper Noticeb. Relationship With ONC-ACBs and ONCATLsVerDate Sep 11 201409:23 May 01, 2020Jkt 250001c. Records Accessd. Corrective Actione. Certification Ban and Terminationf. Appealg. Suspensionh. Proposed Termination4. Public Listing of Certification Ban andTerminations5. Effect on Existing Program Requirementsand Processes6. Coordination With the Office ofInspector General7. Applicability of Conditions andMaintenance of CertificationRequirements for Self-DevelopersVIII. Information BlockingA. Statutory BasisB. Legislative Background and PolicyConsiderations1. Purpose of the Information BlockingProvision2. Policy Considerations and Approach toInformation Blocking3. General Comments RegardingInformation Blocking ExceptionsC. Relevant Statutory Terms and Provisions1. ‘‘Required by Law’’2. Health Care Providers, Health ITDevelopers, Exchanges, and Networksa. Health Care Providersb. Health IT Developers of Certified HealthITc. Health Information Networks and HealthInformation Exchanges3. Electronic Health Information4. Price Information—Request forInformation5. Interests Promoted by the InformationBlocking Provisiona. Access, Exchange, and Use of EHIb. Interoperability Elements6. Practices That May Implicate theInformation Blocking Provisiona. Prevention, Material Discouragement,and Other Interferenceb. Likelihood of Interferencec. Examples of Practices Likely to InterfereWith Access, Exchange, or Use of EHI7. Applicability of Exceptionsa. Reasonable and Necessary Activitiesb. Treatment of Different Types of Actorsc. Establishing That Activities andPractices Meet the Conditions of anExceptionD. Exceptions to the Information BlockingDefinition1. Exceptions That Involve not FulfillingRequests To Access, Exchange, or UseEHIa. Preventing Harm Exception—When willan actor’s practice that is likely tointerfere with the access, exchange, oruse of EHI in order to prevent harm notbe considered information blocking?b. Privacy Exception—When will an actor’spractice of not fulfilling a request toaccess, exchange, or use EHI in order toprotect an individual’s privacy not beconsidered information blocking?c. Security Exception—When will anactor’s practice that is likely to interferewith the access, exchange, or use of EHIin order to protect the security of EHI notbe considered information blocking?d. Infeasibility Exception—When will anactor’s practice of not fulfilling a requestPO 00000Frm 00003Fmt 4701Sfmt 470025643to access, exchange, or use EHI due tothe infeasibility of the request not beconsidered information blocking?e. Health IT Performance Exception—When will an actor’s practice that isimplemented to maintain or improvehealth IT performance and that is likelyto interfere with the access, exchange, oruse of EHI not be considered informationblocking?2. Exceptions That Involve Procedures forFulfilling Requests To Access, Exchange,or Use EHIa. Content and Manner Exception—Whenwill an actor’s practice of limiting thecontent of its response to or the mannerin which it fulfills a request to access,exchange, or use EHI not be consideredinformation blocking?b. Fees Exception—When will an actor’spractice of charging fees for accessing,exchanging, or using EHI not beconsidered information blocking?c. Licensing Exception—When will anactor’s practice to licenseinteroperability elements in order forEHI to be accessed, exchanged, or usednot be considered information blocking?E. Additional Exceptions—Request forInformation1. Exception for Complying With CommonAgreement for Trusted Exchange2. New ExceptionsF. Complaint ProcessG. Disincentives for Health CareProviders—Request for InformationIX. Registries Request for InformationX. Patient Matching Request for InformationXI. Incorporation by ReferenceXII. Collection of Information RequirementsA. ONC–ACBsB. Health IT DevelopersXIII. Regulatory Impact AnalysisA. Statement of NeedB. Alternatives ConsideredC. Overall Impact1. Executive Orders 12866 and 13563—Regulatory Planning and ReviewAnalysis2. Executive Order 13771—ReducingRegulation and Controlling RegulatoryCostsa. Costs and Benefitsb. Accounting Statement and Table3. Regulatory Flexibility Act4. Executive Order 13132—Federalism5. Unfunded Mandates Reform Act of 1995Regulation TextI. Executive SummaryA. Purpose of Regulatory ActionONC is responsible for theimplementation of key provisions inTitle IV of the 21st Century Cures Act(Cures Act) that are designed to advanceinteroperability; support the access,exchange, and use of electronic healthinformation (EHI); and addressoccurrences of information blocking.This final rule implements certainprovisions of the Cures Act, includingConditions and Maintenance ofCertification requirements for healthinformation technology (health IT)E:\FR\FM\01MYR3.SGM01MYR3

25644Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulationsdevelopers, the voluntary certificationof health IT for use by pediatric healthproviders, and reasonable and necessaryactivities that do not constituteinformation blocking. The final rule alsoimplements parts of section 4006(a) ofthe Cures Act to support patients’ accessto their EHI in a form convenient forpatients, such as making a patient’s EHImore electronically accessible throughthe adoption of standards andcertification criteria and theimplementation of information blockingpolicies that support patient electronicaccess to their health information at nocost. Additionally, the final rulemodifies the 2015 Edition health ITcertification criteria and ONC Health ITCertification Program (Program) in otherways to advance interoperability,enhance health IT certification, andreduce burden and costs.In addition to fulfilling the CuresAct’s requirements, the final rulecontributes to fulfilling Executive Order(E.O.) 13813. The President issued E.O.13813 on October 12, 2017, to promotehealth care choice and competitionacross the United States. Section 1(c) ofthe E.O., in relevant part, states thatgovernment rules affecting the UnitedStates health care system should reinject competition into health caremarkets by lowering barriers to entryand preventing abuses of market power.Section 1(c) also states that governmentrules should improve access to and thequality of information that Americansneed to make informed health caredecisions. For example, as mentionedabove, the final rule establishesapplication programming interface (API)requirements, including for patients’access to their health informationwithout special effort. The APIapproach also supports health careproviders’ independence to choose the‘‘provider-facing’’ third-party servicesthey want to use to interact with thecertified API technology they haveacquired. In addition, the final ruleprovides the Secretary of Health andHuman Services’ (Secretary)interpretation of the informationblocking definition as established in theCures Act and the application of theinformation blocking provision byidentifying reasonable and necessaryactivities that would not constituteinformation blocking. Many of theseactivities focus on improving patientand health care provider access to EHIand promoting competition.VerDate Sep 11 201409:23 May 01, 2020Jkt 250001B. Summary of Major Provisions andClarifications1. Deregulatory Actions for PreviousRulemakingsSince the inception of the Program,we have aimed to implement andadminister the Program in the leastburdensome manner that supports ourpolicy goals. Throughout the years, wehave worked to improve the Programwith a focus on ways to reduce burden,offer flexibility to both developers andproviders, and support innovation. Thisapproach has been consistent with theprinciples of E.O. 13563 on ImprovingRegulation and Regulatory Review(February 2, 2011), which instructsagencies to ‘‘periodically review itsexisting significant regulations anddetermine whether any such regulationsshould be modified, streamlined,expanded, or repealed so as to make theagency’s regulatory program moreeffective or less burdensome inachieving the regulatory objectives.’’ Tothat end, we have historically, wherefeasible and appropriate, takenmeasures to reduce burden within theProgram and make the Program moreeffective, flexible, and streamlined.We reviewed and evaluated existingregulations and identified ways toadministratively reduce burden andimplement deregulatory actions throughguidance. In this final rule, we havefinalized new deregulatory actions thatwill reduce burden for health ITdevelopers, providers, and otherstakeholders. We have finalized fivederegulatory actions in section III.B: (1)Removal of a requirement to conductrandomized surveillance on a setpercentage of certified products,allowing ONC-Authorized CertificationBodies (ONC–ACBs) more flexibility toidentify the right approach forsurveillance actions; (2) removal of the2014 Edition from the Code of FederalRegulations (CFR); (3) removal of theONC-Approved Accreditor (ONC–AA)from the Program; (4) removal of certain2015 Edition certification criteria; and(5) removal of certain Programrequirements. We have not finalized asixth deregulatory action we proposed,related to recognition of the Food andDrug Administration (FDA) SoftwarePrecertification Program, as commentsand the early stage of development ofthe FDA program indicate finalizationwould be premature at this time.2. Updates to the 2015 EditionCertification CriteriaThis final rule updates the 2015Edition to remove several certificationcriteria. It also updates somecertification criteria to reflect standardPO 00000Frm 00004Fmt 4701Sfmt 4700and implementation specificationupdates. In consideration of publiccomments, the final rule adds only twonew technical certification criteria andtwo new attestation-structured privacyand security certification criteria.a. Adoption of the United States CoreData for Interoperability (USCDI) as aStandardWe noted in the Proposed Rule that,as part of continued efforts to ensure theavailability of a minimum baseline ofdata classes that could be commonlyavailable for interoperable exchange,ONC adopted the 2015 Edition‘‘Common Clinical Data Set’’ (CCDS)definition and used the CCDS shorthandin several certification criteria.However, the CCDS definition alsobegan to be used colloquially for manydifferent purposes. As the CCDSdefinition’s relevance grew outside of itsregulatory context, it was often viewedas a ceiling to the industry’s collectivedata set for access, exchange, and use.In addition, we noted in the NPRM thatas we continue to move toward valuebased care, the inclusion of additionaldata classes beyond the CCDS would benecessary. In order to advanceinteroperability, we proposed to removethe CCDS definition and its referencesfrom the 2015 Edition and replace itwith the ‘‘United States Core Data forInteroperability 1’’ (USCDI). Weproposed to adopt the USCDI as astandard, naming USCDI Version 1(USCDI v1) in § 170.213 andincorporating it by reference in§ 170.299. The USCDI standard wouldestablish a set of data classes andconstituent data elements required tosupport interoperability nationwide. Toachieve the goals set forth in the CuresAct, we indicated that we intended toestablish and follow a predictable,transparent, and collaborative process toexpand the USCDI, including providingstakeholders with the opportunity tocomment on the USCDI’s expansion. Wealso noted that once the USCDI isadopted by the Secretary in regulation,health IT developers would be allowedto take advantage of a new proposedflexibility we called the ‘‘StandardsVersion Advancement Process’’ (SVAP)(see 84 FR 7497 through 7500, see alsosection VII.B.5 of this final rule). Inorder to advance interoperability, wehave finalized the adoption of theUSCDI standard. Because the USCDI isadopted as a standard and the SVAP isfinalized, the SVAP will allow adeveloper to voluntarily have theirproducts certified to newer, NationalCoordinator approved versions of the1 01MYR3

Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and RegulationsUSCDI in the future without waiting forrulemaking to update the version of theUSCDI listed in the regulations.b. Electronic PrescribingWe have finalized an update to theelectronic prescribing National Councilfor Prescription Drug Programs (NCPDP)SCRIPT standard in 45 CFR 170.205(b)from NCPDP SCRIPT standard version10.6 to NCPDP SCRIPT standard version2017071 for the electronic prescribingcertification criterion (§ 170.315(b)(3)).ONC and the Centers for Medicare &Medicaid Services (CMS) havehistorically maintained aligned e-Rxand medication history (MH) standardsto ensure that the current standard forcertification to the electronicprescribing criterion supports use of thecurrent Part D e-Rx and MH standards.This helps advance alignment withCMS’ program standards.In a final rule published April 16,2018, CMS finalized its update of itsPart D standards to NCPDP SCRIPTstandard version 2017071 for e-Rx andMH, effective January 1, 2020 (83 FR16440). In addition to continuing toreference the transactions previouslyincluded in § 170.315(b)(3), and inkeeping with CMS’ final rule, we haveadopted all of the additional NCPDPSCRIPT standard version 2017071transactions that CMS adopted in 42CFR 423.160(b)(2)(iv). Furthermore, wehave adopted the same electronic PriorAuthorization (ePA) request andresponse transactions supported byNCPDP SCRIPT standard 2017071proposed by CMS in the MedicareProgram; Secure Electronic PriorAuthorization for Medicare Part Dproposed rule (84 FR 28450). Someadopted transactions are required todemonstrate conformance to theupdated § 170.315(b)(3) criterion, whileother transactions are optional.c. Clinical Quality Measures—ReportIn this final rule, we have removedthe Health Level 7 (HL7 ) QualityReporting Document Architecture(QRDA) standard requirements in the2015 Edition ‘‘Clinical QualityMeasures—report’’ criterion in§ 170.315(c)(3) and, in their place,required Health IT Modules to supportthe CMS QRDA Implementation Guide(IGs).2 This will help reduce the burdenfor health IT developers and removecertification requirements that do notsupport quality reporting for CMSprograms.2 cument-architecture.VerDate Sep 11 201409:23 May 01, 2020Jkt 250001d. Electronic Health Information (EHI)ExportWe proposed to adopt a new 2015Edition certification criterion, referredto as ‘‘EHI export’’ in § 170.315(b)(10) inthe Proposed Rule. The criterion’sproposed conformance requirementswere intended to provide a means toexport the entire EHI a certified healthIT product produced and electronicallymanaged to support two contexts: (1)Single patient EHI export and (2) forpatient EHI export when a health careprovider is switching health IT systems.The proposals did not require theexported data to be in a specificstandardized format. Rather, weproposed to require that such an exportbe in a computable, electronic formatmade available via a publicly accessiblehyperlink. We noted that thistransparency would facilitate thesubsequent interpretation and use of theexported information.We have finalized the criterion withmodifications in response to publiccomment. We have refined the scope ofdata a Health IT Module certified to§ 170.315(b)(10) must export, andaligned the criterion to the definition ofEHI we finalized in § 170.102 and§ 171.102. The finalized criterionrequires a certified Health IT Module toelectronically export all of the EHI, asdefined in § 171.102, that can be storedat the time of certification by theproduct, of which the Health IT Moduleis a part. We finalized the 2015 EditionCures Update ‘‘EHI export’’ criterion in§ 170.315(b)(10) but did not finalize itsinclusion in the 2015 Edition BaseElectronic Health Record (EHR)definition, as proposed. Our intentionwith this criterion, in combination withother criteria set forth in this final rule,is to advance the interoperability ofhealth IT as defined in section 4003 theCures Act, including the ‘‘completeaccess, exchange, and use of allelectronically accessible healthinformation.’’e. Application Programming Interfaces(APIs)We have adopted a new APIcertification criterion in§ 170.315(g)(10) to replace the‘‘application access—data categoryrequest’’ certification criterion(§ 170.315(g)(8)), and added it to theupdated 2015 Edition Base EHRdefinition. This new ‘‘standardized APIfor patient and population services’’certification criterion focuses onsupporting two types of API-enabledservices: (1) Services for which a singlepatient’s data is the focus and (2)services for which multiple patients’PO 00000Frm 00005Fmt 4701Sfmt 470025645data are the focus. The API certificationcriterion requires the use of the HealthLevel 7 (HL7 ) Fast HealthcareInteroperability Resources (FHIR )standard Release 4 and referencesseveral standards and implementationspecifications adopted in § 170.213 and§ 170.215 to support standardizationand interoperability. This certificationcriterion will align industry effortsaround FHIR Release 4 and advanceinteroperability of API-enabled ‘‘read’’services for single and multiple patients.f. Privacy and Security TransparencyAttestationsWe have adopted two new privacyand security certification criteriarequiring transparency attestations fromdevelopers of certified health IT as partof the updated 2015 Edition privacy andsecurity certification framework. Theattestations will serve to identifywhether or not certified health ITsupports encrypting authenticationcredentials and/or multi-factorauthentication (MFA). While thesecriteria provide increased transparency,they do not require new development orimplementation to take place. As part ofONC’s ongoing commitment to advancetransparency about certified health ITproducts, ONC will list the developers’attestation responses on the CertifiedHealth IT Product List (CHPL).g. Security Tags and ConsentManagementIn the 2015 Edition final rule (80 FR62646, Oct. 16, 2015), we adopted two‘‘data segmentation for privacy’’ (DS4P)certification criteria, one for creating asummary record according to the DS4Pstandard (§ 170.315(b)(7)) and one forreceiving a summary record accordingto the DS4P standard (§ 170.315(b)(8)).Certification to these 2015 Edition DS4Pcriteria only required security tagging ofConsolidated-Clinical DocumentArchitecture (C–CDA) documents at thedocument level. As noted in the 2015Edition final rule (80 FR 62646),certification to these criteria is notlinked to meeting the Certified EHRTechnology definition (CEHRT) used inCMS programs.Since the 2015 Edition final rule, thehealth care industry has engaged inadditional field testing andimplementation of the DS4P standard.Stakeholders also shared with ONC—through public forums, listeningsessions, and correspondence—thatonly tagging C–CDA documents at thedocument level did not permitproviders the flexibility to address morecomplex use cases for representingpatient privacy preferences. Based onpublic comment, in this final rule, weE:\FR\FM\01MYR3.SGM01MYR3

25646Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulationshave changed the names of the twocurrent 2015 Edition DS4P criteria toSecurity tags—Summary of Care (send)and Security tags—Summary of Care(receive). We also updated therequirements for these criteria tosupport security tagging at thedocument, section, and entry levels.This change better reflects the purposeof these criteria and enables adopters tosupport a more granular approach tosecurity tagging clinical documents forexchange.In finalizing this more granularapproach for security taggingConsolidated Clinical DocumentArchitecture (C–CDA) documents, wenote that we do not specify rules orrequirements for the disposition oftagged data or any requirements onhealth care providers related to datasegmentation for privacy. The use casesfor which health IT certified to thesecriteria might be implemented would bedriven by other applicable Federal,State, local, or tribal law and are outsidethe scope of the certification criteria. Werecognize that the tagging of documentsis not a fully automated segmentation ofthe record but rather a first,technological step or tool to supporthealth IT developers implementingtechnology solutions for health careproviders to replace burdensomemanual processes for tagging sensitiveinformation.We also proposed to adopt a new2015 Edition certification criterion,‘‘consent management for APIs’’ in§ 170.315(g)(11), to support datasegmentation and consent managementthrough an API in accordance with theConsent Implementation Guide (IG).However, in response to comments, wehave chosen not to finalize our proposalfor this criterion at this time.3. Modifications to the ONC Health ITCertification ProgramIn this final rule, we have finalizedcorrections to the 2015 Edition privacyand security certification framework (80FR 62705) and relevant regulatoryprovisions. We also have finalizedcorrections to the relevant currentCertification Companion Guides (CCGs).We have adopted new and revisedPrinciples of Proper Conduct (PoPC) forONC–ACBs. We have finalizedclarification that the records retentionprovision includes the ‘‘life of theedition’’ as well as three years after theretirement of an edition related to thecertification of Complete EHRs andHealth IT Modules. We also havefinalized revisions to the PoPC in§ 170.523(h) to clarify the basis forcertification, including to permit acertification decision to be based on anVerDate Sep 11 201409:23 May 01, 2020Jkt 250001evaluation conducted by the ONC–ACBfor Health IT Modules’ compliance withcertificati

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