21st Century Cures Act Overview For States - ONC

Transcription

21st Century Cures Act Overview for StatesSIM State Educational Session 1An Overview of the 21st Century Cures Act for StatesGenevieve Morris, Principal Deputy National Coordinator for Health IT, ONCElise Sweeny Anthony, JD, Director, Office of Policy, ONCJanuary 8, 2018

Goals for These Learning Sessions1. What does the Cures Act say?Not seeking to interpret the Cures Act, but extracting important languageassociated with key topics of potential interest to states. Use this information toplan your own activities and understand how the Cures Act may have an impacton your projects.2. Who is responsible for each action?The Cures Act usually identifies the party responsible for completing each of theactions it identifies, often in collaboration with others. Use this information as abasis for who to monitor in order to keep abreast of progress, and how best toparticipate in public forums, if any.3. When is each action due?The Cures Act usually identifies dates by which progress is due. Use thisinformation in planning your own activities, and for a general sense of thetimeline for Cures Act activities.An Overview of the 21st Century Cures Act for States2

Goal for Today An overview of What, Who, and When for each of the topic areas ofTitle IV of the Cures Act, which focuses on Delivery» An introduction to the contents of the Cures Act of interest to states,identifying what it is to accomplish and ONC’s role» Future sessions will provide more detail on individual topics Key outcome» Begin to think about how to apply outcomes of the Cures Act to your owninitiativesFor details of the 21st Century Cures Act, seeSummary: -bill/34Full Text: 4publ255.pdfAn Overview of the 21st Century Cures Act for States3

History of the 21st Century Cures Act01/06/2015Introduced in House01/07/2015Passed/agreed to in House10/06/2015Passed/agreed to in Senate: Passed Senate with an amendment11/30/2016House actions: House agreed with an amendment to the Agreed to12/07/2016Senate actions: Senate agreed to the House amendment to the Senateamendment12/08/2016Presented to President12/13/2016Signed by President and became Public LawAn Overview of the 21st Century Cures Act for States4

21st Century Cures ActTitle IV – DELIVERYSec. 4001. Assisting doctors and hospitals in improving quality of care for patients.Sec. 4002. Transparent reporting on usability, security, and functionality.Sec. 4003. Interoperability.Sec. 4004. Information blocking.Sec. 4005. Leveraging electronic health records to improve patient care.Sec. 4006. Empowering patients and improving patient access to their electronichealth information.Sec. 4007. GAO study on patient matching.Sec. 4008. GAO study on patient access to health information.Sec. 4009. Improving Medicare local coverage determinations.Sec. 4010. Medicare pharmaceutical and technology ombudsman.Sec. 4011. Medicare site-of-service price transparency.Sec. 4012. Telehealth services in Medicare.An Overview of the 21st Century Cures Act for States5

Section 4001Assisting doctors and hospitals in improving quality of care for patients4001(a) Amends the HITECH Act to require HHS to establish a goal, develop astrategy, and make recommendations to reduce regulatory or administrativeburdens relating to the use of EHRs4001(b) ONC must encourage, keep, or recognize the certification of health IT for usein medical specialtiesHHS must adopt certification criteria to support health IT for pediatrics, andbegin certification soon after4001(c) HHS must publish attestation statistics for the Medicare and Medicaid EHRIncentive Programs to Health Information Technology Advisory CommitteeAn Overview of the 21st Century Cures Act for States6

Section 4002Transparent reporting on usability, security, and functionality4002(a) Requires HHS through notice and comment rulemaking to require, as acondition of certification and maintenance of certification, that the HITdeveloper or entity “does not take any action that constitutes informationblocking” (as defined in Section 3022(a) of the Public Health Service Act, asamended), or “any other action that may inhibit the appropriate exchange,access, and use of electronic health information”4002(b) A health care provider whose adopted health IT is decertified is exemptedfrom the application of a payment adjustment4002(c) HHS must support the convening of stakeholders to develop reportingcriteriaAn Overview of the 21st Century Cures Act for States7

Section 4003Interoperability4003(a) Defines Interoperability as:The term ‘interoperability’, with respect to health information technology,means such health information technology that—A. enables the secure exchange of electronic health information with, anduse of electronic health information from, other health informationtechnology without special effort on the part of the user;B. allows for complete access, exchange, and use of all electronicallyaccessible health information for authorized use under applicable State orFederal law; andC. does not constitute information blocking as defined in section 3022(a) ofthe PHSA as amended.An Overview of the 21st Century Cures Act for States8

Trusted Exchange Framework and Common Agreement21st Century Cures Act - Section 4003(b)“Not later than 6 months after the date of enactment of the 21st Century Cures Act, the National Coordinatorshall convene appropriate public and private stakeholders to develop or support a trusted exchangeframework for trust policies and practices and for a common agreement for exchange between healthinformation networks. The common agreement may include—“(I) a common method for authenticating trusted health information network participants;“(II) a common set of rules for trusted exchange;“(III) organizational and operational policies to enable the exchange of health information amongnetworks, including minimum conditions for such exchange to occur; and“(IV) a process for filing and adjudicating noncompliance with the terms of the common agreement.”21st Century Cures Act - Section 4003(c)“Not later than 1 year after convening stakeholders the National Coordinator shall publish on its publicInternet website, and in the Federal register, the trusted exchange framework and common agreementdeveloped or supported under paragraph B ”9

Format of the Draft Trusted ExchangeFrameworkPart A—Principles for Trusted ExchangeGeneral principles that provide guardrails to engender trust betweenHealth Information Networks (HINs). Six (6) categories:» Principle 1 - Standardization: Adhere to industry and federallyrecognized standards, policies, best practices, and procedures.» Principle 2 - Transparency: Conduct all exchange openly andtransparently.» Principle 3 - Cooperation and Non-Discrimination:Collaborate with stakeholders across the continuum of care toexchange electronic health information, even when a stakeholdermay be a business competitor.» Principle 4 - Security and Patient Safety: Exchangeelectronic health information securely and in a mannerthat promotes patient safety and ensures data integrity.» Principle 5 - Access: Ensure that patients andtheir caregivers have easy access to their electronichealth information.» Principle 6 - Data-driven Accountability: Exchangemultiple records at one time to enable identificationand trending of data to lower the cost of care andimprove the health of the population.Part B—Minimum Required Terms andConditions for Trusted ExchangeA minimum set of terms and conditions for the purpose ofensuring that common practices are in place and requiredof all participants who participate in the Trusted ExchangeFramework, including:» Common authentication processes of trusted healthinformation network participants;» A common set of rules for trusted exchange;» A minimum core set of organizational and operationalpolicies to enable the exchange of electronic healthinformation among networks.10

Need for the Trusted Exchange Framework – ComplexityCURRENT PROLIFERATIONOF AGREEMENTSMany organizations have to joinmultiple Health InformationNetworks (HINs), and the HINs donot share data with each other.Trusted exchange must besimplified in order to scale.Each line color on the map representsa different network. There are wellover 100 networks in the U.S.11

Need for the Trusted Exchange Framework – CostsCosts to healthcare providers due to lack ofTrusted Exchange FrameworkHealthcare organizations are currently burdened withcreating many costly, point-to-point interfaces betweenorganizations.The Trusted Exchange Framework will significantly reduce theneed for individual interfaces, which are costly, complex tocreate and maintain, and an inefficient use of provider andhealth IT developer resources.Proliferation ofInteroperabilityMethodsBased on a pilot survey ofroughly 70 hospitals:Few hospitals used only one interoperability method. A majority of hospitals required threeor more methods About three in 10 used five or more methodsRated their own Interoperability as 63% Not or a little bit interoperable17% Somewhat interoperable19% Largely or Fully interoperable

Goals of the Draft Trusted Exchange FrameworkGOAL 1Build on and extendexisting work doneby the industryGOAL 2Provide a single“on-ramp” tointeroperability for allGOAL 3Be scalable tosupport theentire nationGOAL 4Build a competitivemarket allowing allto compete ondata servicesGOAL 5Achieve long-termsustainabilityThe Draft TrustedExchange Frameworkrecognizes and buildsupon the significant workdone by the industry overthe last few years tobroaden the exchange ofdata, build trustframeworks, and developparticipation agreementsthat enable providers toexchange data acrossorganizational boundaries.The Draft Trusted ExchangeFramework provides a single“on-ramp” to allow all typesof healthcare stakeholders tojoin any health informationnetwork they choose and beable to participate innationwide exchangeregardless of what health ITdeveloper they use, healthinformation exchange ornetwork they contract with, orwhere the patients’ recordsare located.The Draft TrustedExchange Framework aimsto scale interoperabilitynationwide bothtechnologically andprocedurally, by defining afloor, which will enablestakeholders to access,exchange, and userelevant electronic healthinformation acrossdisparate networks andsharing arrangements.Easing the flow of datawill allow new andinnovative technologiesto enter the marketand build competitive,invaluable services thatmake use of the data.By providing a single “onramp” to nationwideinteroperability while alsoallowing for variationaround a broader set of usecases, the Draft TrustedExchange Frameworkensures the long-termsustainability of itsparticipants and end-users.13

Stakeholders who can use the Trusted Exchange FrameworkHEALTH INFORMATION NETWORKSFEDERAL AGENCIESFederal, state, tribal, andlocal governmentsINDIVIDUALSPatients, caregivers,authorized representatives,and family members serving ina non-professional rolePROVIDERSProfessional care providers whodeliver care across the continuum, notlimited to but including ambulatory,inpatient, long-term and post-acutecare (LTPAC), emergency medicalservices (EMS), behavioral health, andhome and community based servicesPUBLIC HEALTHPublic and private organizations andagencies working collectively to prevent,promote and protect the health ofcommunities by supporting effortsaround essential public health servicesPAYERSPrivate payers, employers, andpublic payers that pay forprograms like Medicare,Medicaid, and TRICARETECHNOLOGY DEVELOPERSOrganizations that provide health IT capabilities,including but not limited to electronic health records,health information exchange (HIE) technology,analytics products, laboratory information systems,personal health records, Qualified Clinical DataRegistries (QCDRs), registries, pharmacy systems,mobile technology, and other technology thatprovides health IT capabilities and services14

Trusted Exchange Framework Benefits for HINsFor Qualified HINs and HINs the Trusted Exchange Framework will:Give HINs and their participants access to more data on thepatients they currently serve. This will enhance care coordination and care delivery use cases.The Trusted Exchange Framework ensures that there is no limitationto the aggregation of data that is exchanged among Participants. This will allow organizations, including Health IT Developers,HINs, Qualified Clinical Data Registries (QCDRs), and otherregistries to use the Trusted Exchange Framework to obtainclinical data from providers and provide analytics services. (Notethat appropriate BAs must be in place between the healthcareprovider and analytics provider.)15

Trusted Exchange Framework Benefits for ProvidersFor Health Systems and Ambulatory Providers theTrusted Exchange Framework will:Enable them to join one network and have access to data on thepatients they serve regardless of where the patient went for care. This enables safer, more effective care, and better carecoordination.Enable them to eliminate one off and point-to –point interfaces This will allow providers and health systems to more easily workwith third parties, such as analytics products, care coordinationservices, HINs, Qualified Clinical Data Registries (QCDRs), andother registries. (Note that appropriate BAs must be in placebetween the healthcare provider and analytics provider.)16

Trusted Exchange Framework Benefits for PatientsFor Patients and Their Caregivers, theTrusted Exchange Framework will:Enable them to find all of their health information from acrossthe care continuum, even if they don’t remember the name ofthe provider they saw. This enables patients and their caregivers to participate intheir care and manage their health information.17

Recognized Coordinating Entity (RCE)Recognized Coordinating EntityThe RCE is the entity selected by ONC that will enterinto agreements with HINs that qualify and elect tobecome Qualified HINs in order to impose, at aminimum, the requirements of the CommonAgreement set forth herein on the Qualified HINsand administer such requirements on an ongoingbasis as described herein.The RCE will act as a governance body that will operationalize the Trusted Exchange Framework byincorporating it into a single, all-encompassing Common Agreement to which Qualified HINs will agree toabide. In its capacity as a governance body, the RCE will be expected to monitor Qualified HINscompliance with the final TEFCA and take actions to remediate non-conformity and non-compliance byQualified HINs, up to and including the removal of a Qualified HIN from the final TEFCA and subsequentreporting of its removal to ONC.The RCE will also be expected to work collaboratively with stakeholders from across the industry to buildand implement new use cases that can use the final TEFCA as their foundation, and appropriately updatethe TEFCA over time to account for new technologies, policies, and use cases.18

Recognized Coordinating Entity (RCE)2018SelectionProcess for Recognizing EntityONC will release an open, competitive FundingOpportunity Announcement (FOA) in spring 2018to award a single multi-year CooperativeAgreement to a private sector organization orentity. The RCE will need to have experience withbuilding multi-stakeholder collaborations andimplementing governance principles in order to beeligible to apply for the Cooperative Agreement.Expectations for EntityONC will work with the RCE to incorporate the Trusted Exchange Framework into a single CommonAgreement to which Qualified HINs and their participants voluntarily agree to adhere.The RCE will have oversight, enforcement, and governance responsibilities for each of the QualifiedHINs who voluntarily adopt the final TEFCA.19

Structure of a Qualified Health Information NetworkA Qualified HIN (QHIN) is a network of organizations working together to share data. QHINs will connect directlyto each other to ensure interoperability between the networks they represent.A Connectivity Broker is a service provided by a Qualified HIN that provides all of the following functions withrespect to all Permitted Purposes: master patient index (federated or centralized); Record Locator Service;Broadcast and Directed Queries, and eHI return to an authorized requesting Qualified HIN.A Participant is a person or entity that participates in the QHIN. Participants connect to each other through theQHIN, and they access organizations not included in their QHIN through QHIN-to-QHIN connectivity. Participantscan be HINs, EHR vendors, and other types of organizations.An End User is an individual or organization using the services of a Participant to send and/or receive electronichealth info.20.

How Will the Trusted Exchange Framework Work?RCE provides oversight andgovernance for Qualified HINS.Qualified HINs connect directly to eachother to serve as the core fornationwide interoperability.QHINs connect via connectivity brokersEach Qualified HIN represents a varietyof networks and participants that theyconnect together, serving a wide rangeof end users.21

Qualified HIN Requirements ClarificationsINCLUDED A minimum floor in the areas wherethere is currently variation betweenHINs that causes a lack ofinteroperability.NOT INCLUDED Obligation to respond to broadcast ordirected queries for all the PermittedPurposes outlined in the TrustedExchange Framework.Qualified HINs must exchange all ofthe data specified in the USCDI to theextent such data is then available andhas been requested.Base set of expectations for howQualified Health InformationNetworks connect with each other. A full end-to-end agreement thatwould be a net new agreement.T RU ST E DE XCH A NG EFRA MEWO RKCO NT ENTSNo expectation that every HIN willserve same constituents or use casesi.e. no requirement that QualifiedHINs initiate broadcast or directedqueries for all of the PermittedPurposes outlined in the TrustedExchange Framework.Not dictating internal technology orinfrastructure requirements.No limitation on additionalagreements to support uses casesother than Broadcast Query andDirected Query for the TrustedExchange Framework specifiedpermitted purposes.22

Permitted Purposes23

Supported Use CasesBroadcast QuerySending a request for a patient’s Electronic Health Information (EHI) to allQualified HINs to have data returned from all organizations who have it.Supports situations where it is unknown who may have electronic healthinformation about a patient.Directed QuerySending a targeted request for a patient’s Electronic Health Information(EHI) to a specific organization(s).Supports situations where you want specific Electronic Health Information(EHI) about a patient, for example data from a particular specialist.Population Level DataQuerying and retrieving Electronic Health Information (EHI) aboutmultiple patients in a single query.Supports population health services, such as quality measurement, riskanalysis, and other analytics.24

US Core Data for Interoperability (USCDI) Glide PathThe /draft-uscdi.pdf)establishes a minimum set of dataclasses that are required to beinteroperable nationwide and isdesigned to be expanded in aniterative and predictable way overtime. Data classes listed in theUSCDI are represented in atechnically agnostic manner.1. USCDI v1— Required—CCDS plusClinical Notes and Provenance2. Candidate Data Classes—Underconsideration for USCDI v23. Emerging Data Classes– Beginevaluating for candidate statusU.S. CORE DATA FOR INTEROPERABILITYUSCDI v1REQUIREDCandidateData ClassesUNDER CONSIDERATIONEmergingData ClassesBEGIN EVALUATING

Expansion of US Core Data for Interoperability (USCDI)As the USCDI expands, Qualified HINs and their Participants will berequired to upgrade their technology to support the data specified inthe USCDI.

Privacy/Security: Identity ProofingIdentity proofing is the process of verifying a person is who they claim to be. TheTrusted Exchange Framework requires identity proofing (referred to as the IdentityAssurance Level (IAL) in SP 800-63A).End Users and Participants Each Qualified HINshall require proof of identity for Participantsand participating End Users at a minimum ofIAL2 prior to issuance of credentials.IAL ndividuals Each Qualified HIN shall require its End Usersand Participants to proof the identity for Individuals at aminimum of IAL2 prior to issuance of credentials.Individuals must provide strong evidence of their identity.DESCRIPTION One (1) piece of SUPERIOR or STRONG evidence; OR Two (2) pieces of STRONG evidence; OR One (1) piece of STRONG evidence plus two (2) pieces of ADEQUATE evidence Each piece of evidence must be validated with a process able to achieve the same strength as the evidence presented. Validation against a third-party data service SHALL only be used for one piece of presented identity evidence. The Credential Service Provider (CSP) SHALL confirm address of record through validation of the address contained on anysupplied, valid piece of identity evidence.* Full IAL2 requirements can be found at www.nist.gov.27

Privacy/Security: Identity Proofing - EXCEPTIONSQualified HINs, Participants, or End Users are responsible forproofing Individuals at the IAL2 level, HOWEVER:Trusted Referee and Authoritative Source:In instances where the individual enrolling cannotmeet the identity evidence requirements specified,organization staff may act as a trusted referee,allowing them to use personal knowledge of theidentity of patients when enrolling patients assubscribers to assist in identity proofing the enrollee.Antecedent Event: Staff may also act as authoritativesources by using knowledge of the identity of theindividuals (e.g., physical comparison to legalphotographic identification cards such as driver’slicenses or passports, or employee or schoolidentification badges) collected during anantecedent, in-person registration event.For example, IAL2 identity proofing for an Individualcan be accomplished by two of the following:1.Physical comparison to legal photographic identificationcards such as driver’s licenses or passports, or employee orschool identification badges,2.Comparison to information from an insurance card that hasbeen validated with the issuer, e.g., in an eligibility checkwithin two days of the proofing event, and3.Comparison to information from an electronic health record(EHR) containing information entered from prior encounters.28

Privacy/Security: AuthenticationDigital authentication is the process of establishing confidence in a remote user identitycommunicating electronically to an information system. NIST draft SP 800-63B refers to the level ofassurance in authentication as the Authenticator Assurance Level (AAL). Federal Assurance Level (FAL)refers to the strength of an assertion in a federated environment, used to communicateauthentication and attribute information (if applicable) to a relying party (RP).Each Qualified HIN shall authenticate End Users, Participants, and Individuals at a minimum of AAL2, andprovide support for at least FAL2 or, alternatively, FAL3.Connecting to a Qualified HIN or one of its Participant will require two-factor authentication. A list ofacceptable second factors (in addition to a username and password) can be found athttps://pages.nist.gov/800-63-3/sp800-63b/sec4 aal.html.29

Section 4003Interoperability (continued)4003(c) HHS must establish an index of digital contact information for healthprofessionals, health facilities, and others to encourage the exchange ofhealth information4003(e) Replaces the Health IT Policy Committee and the Health IT StandardsCommittee with the Health IT Advisory Committee (HITAC)The ONC must periodically convene the HITAC to report on priority uses ofhealth IT and standards and implementation specifications that support theimplementation of a health information technology infrastructure thatadvances the electronic access, exchange, and use of health information.An Overview of the 21st Century Cures Act for States30

Section 4004Information blockingRecall that 4002(a) Requires HHS through notice and comment rulemaking to require, as acondition of certification and maintenance of certification, that the HITdeveloper or entity “does not take any action that constitutes informationblocking”4004“(1) The term ‘information blocking’ means a practice that—“(A) except as required by law or specified by the Secretary pursuant to rulemakingunder paragraph (3), is likely to interfere with, prevent, or materially discourageaccess, exchange, or use of electronic health information; and“(B) (i) if conducted by a health information technology developer, exchange, ornetwork, such developer, exchange, or network knows, or should know, thatsuch practice is likely to interfere with, prevent, or materially discourage theaccess, exchange, or use of electronic health information; or(ii) if conducted by a health care provider, such provider knows that suchpractice is unreasonable and is likely to interfere with, prevent, or materiallydiscourage access, exchange, or use of electronic health information.”An Overview of the 21st Century Cures Act for States31

Section 4004, continuedInformation blocking4004“(3) RULEMAKING.—The Secretary, through rulemaking, shall identifyreasonable and necessary activities that do not constitute informationblocking for purposes of paragraph (1).”Any individual or entity described in subparagraphs (A) or (C) (e.g. adeveloper, exchange, or network) may be penalized for engaging ininformation blocking, up to 1M per violation.Providers determined by the Inspector General to have committedinformation blocking shall be referred to the appropriate agency to besubject to appropriate disincentives using authorities under applicableFederal law, as the Secretary sets forth through notice and commentrulemaking.An Overview of the 21st Century Cures Act for States32

Section 4005Leveraging electronic health records to improve patient care4005(a) To be certified, EHR must be capable of transmitting to and receiving fromdata registries certified by the ONC4005(c) HHS must report on best practices and current trends provided by patientsafety organizations to improve the integration of health IT into clinicalpracticeAn Overview of the 21st Century Cures Act for States33

Section 4006Empowering patients and improving patient access to their electronic healthinformation4006(a) HHS must(1) Encourage partnerships between health information exchanges andothers to offer patients access to their electronic health information;(2) Educate providers on leveraging health information exchanges(3) Issue guidance to health information exchanges on best practices, and(4) Promote policies to facilitate patient communication with providersONC and OCR shall promote patient access to health information in aconvenient form, without burdening the health care provider involvedOCR, in consultation with ONC, shall provide education for individuals onaccessing and exchanging personal health informationThe ONC may require health IT certification criteria support certain patientaccess componentsAn Overview of the 21st Century Cures Act for States34

Sections 4007 and 40084007GAO study on patient matching4008GAO study on patient access to health informationAn Overview of the 21st Century Cures Act for States35

What We Learned Today - 11.The primary activities called for in Title IV of the 21st Century Cures Act2.Who is responsible for each activity and ONC’s role3.When states may expect to see each activity initiated or completed, andwhen to watch for progress reportsPlus a bit more about the Trusted Exchange Framework and CommonAgreement in Section 4003(b)An Overview of the 21st Century Cures Act for States36

What We Learned Today - 2 This session focused on Delivery provisions in Title IV Other sections may also be of interest to statesFor example:TITLE XII – MEDICAID MENTAL HEALTH COVERAGESec. 12006. Electronic visit verification system required for personal care servicesand home health care services under MedicaidAn Overview of the 21st Century Cures Act for States37

What’s Next?Future educational webinars, FAQs, white papers, and case studies mayinclude a focus on specific topics in the Cures Act, such as:1. Trusted Exchange Framework and Common Agreement2. Information Blocking3. Reducing Administrative Burden4. Prioritization of Interoperability Standards5. Patient Access6. Patient Matching7. Provider DirectoriesAn Overview of the 21st Century Cures Act for States38

Questions?An Overview of the 21st Century Cures Act for States39

Draft Trusted Exchange Framework Resources TEFCA webpage: rustedexchange-framework-and-common-agreement Blog post: operability Draft Framework: trusted-exchange-framework.pdf Guidance: -guide.pdf USCDI: -uscdi.pdfAn Overview of the 21st Century Cures Act for States40

Webinar Recording A recording of the January 8, 2018 2-3 pm EST webinar is available 254321306804226?assets true» GoTo Webinar will ask for an email entry to access the recordingAn Overview of the 21st Century Cures Act for States41

Thank you for attendingCONTACT YOUR ONC SME FOR MOREINFORMATION, OR TO SUGGEST PRIORITIES FORFUTURE SESSIONSONC Contact: Genevieve.Morris@hhs.govElise.Anthony@hhs.govONC SIM Contact: Rim@a-cunning-plan.com@ONC HealthITHHSONC

History of the 21st Century Cures Act 01/06/2015 Introduced in House 01/07/2015 Passed/agreed to in House . 10/06/2015 Passed/agreed to in Senate: Passed Senate with an amendment