Copyright Scottsdale Institute All Rights Reserved.

Transcription

1 Copyright Scottsdale Institute All Rights Reserved. No part of this document may be reproduced or shared with anyone outside of your organization without prior written consent from the author(s). You may contact us at / (763)

2 MIPS Information Blocking: Attestation Requirements December 6, 2017

3 Agenda Introductions Background & History of Information Blocking CMS Fact Sheet Specifics Strategies for Implementation and Documentation Top 5 Things to Do Right Now Questions / Discussion What we won t cover today. Basics of MIPS MIPS Scoring MIPS Timelines 3

4 Introductions

5 Introductions Dr. Dan Golder Principal Advisor Larry Katzovitz Senior Advisor Jason Fortin Senior Advisor 5

6 Background and History of Information Blocking

7 History of Information Blocking Information blocking has received a considerable amount of attention of late from the federal government. Began receiving widespread attention in 2015 after a report to Congress from ONC. based on the evidence and knowledge available, it is apparent that some health care providers and health IT developers are knowingly interfering with the exchange or use of electronic health information in ways that limit its availability and use to improve health and health care Report to Congress on Health Information Blocking, April 2015 Source: 7

8 History of Information Blocking (cont.) MACRA, which was enacted in April 2015, also included language pertaining to the concept of information blocking. PREVENTING BLOCKING THE SHARING OF INFORMATION. (A) FOR MEANINGFUL USE EHR PROFESSIONALS. Section 1848(o)(2)(A)(ii) of the Social Security Act (42 U.S.C. 1395w 4(o)(2)(A)(ii)) is amended by inserting before the period at the end the following:, and the professional demonstrates (through a process specified by the Secretary, such as the use of an attestation) that the professional has not knowingly and willfully taken action (such as to disable functionality) to limit or restrict the compatibility or interoperability of the certified EHR technology. 8

9 History of Information Blocking (cont.) CMS fleshed out details of the information blocking requirements in the original QPP Final Rule. Per the Quality Payment Final Rule from November 2016, eligible clinicians are required to attest to three statements pertaining to information blocking and HIE. Goal is to provide substantial assurance not only that certified EHR technology was connected in accordance with applicable standards during the relevant EHR reporting period, but that the health care provider acted in good faith to implement and use the certified EHR technology in a manner that supported and did not interfere with the electronic exchange of health information among health care providers and with patients to improve quality and promote care coordination. 9

10 More on Information Blocking Information blocking was further defined in the 21 st Century Cures Act, which was signed into law on December 13, st Century Cures Act Bipartisan law passed overwhelmingly by the Senate (94-5) and House (392-26) Includes provisions related to: Health Information Technology (HIT) Biomedical research Approval of new drugs and medical devices Mental health and substance abuse 10

11 21 st Century Cures Act: Definition of Information Blocking INFORMATION BLOCKING is defined as a practice that except as required by law or specified by [HHS], is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information. Examples: Implementing HIT in nonstandard ways that are likely to substantially increase the complexity or burden of accessing, exchanging, or using electronic health information. Implementing HIT in ways that are likely to: Restrict the access, exchange, or use of electronic health information with respect to exporting complete information sets or in transitioning between HIT systems; or Lead to fraud, waste, or abuse, or impede innovations and advancements in health information access, exchange, and use. 11

12 21 st Century Cures Act: Enhancements to EHR Certification The 21 st Century Cures Act adds new conditions of EHR certification related to interoperability and data exchange. As a condition of certification, EHR developers will need to: Attest that they do not engage in information blocking. Publish application programming interfaces (APIs) that allow health information to be accessed, exchanged, and used without special effort. Ensure the real world use of the technology has been successfully tested for interoperability. Details to be fleshed out by HHS via the rulemaking process. 12

13 21 st Century Cures Act: Penalties for Information Blocking Any developer, network, exchange, or provider found guilty of information blocking will be subject to penalties. Claims of information blocking will be investigated by the GAO. Penalties if found guilty: EHR developers, networks, and/or exchanges: fines up to $1,000,000 per violation Provider organizations: subject to appropriate disincentives Note: although providers can be found guilty of information blocking, they cannot be penalized for the failure of developers. 13

14 CMS Fact Sheet Specifics

15 CMS Fact Sheet Released Thursday, October 26, 2017 Details CMS specifics regarding the Prevention of Information Blocking Attestation Three separate statements to which each provider (Eligible Clinician) must attest To prevent actions that block the exchange of health information, the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) and the Quality Payment Program final rule with comment period require MIPS eligible clinicians to show that they have not knowingly and willfully limited or restricted the compatibility or interoperability of their certified electronic health record (EHR) technology. MIPS eligible clinicians show that they are meeting this requirement by attesting to three statements about how they implement and use certified EHR technology (CEHRT). Together, these three statements are referred to as the Prevention of Information Blocking Attestation. 15

16 Scope All MIPS Eligible Clinicians (ECs) Eligible Clinicians for 2017: Physicians Physician Assistants Nurse Practitioners Certified Registered Nurse Anesthetists Clinical Nurse Specialists Different from Eligible Providers (EPs) from Meaningful Use who report on the Advancing Care Information (ACI) performance category Which should be almost all ECs, unless ACI does not apply to their scope of practice. 16

17 Statement 1 A MIPS eligible clinician must attest that they did not knowingly and willfully take action (such as to disable functionality) to limit or restrict the compatibility or interoperability of CEHRT. The key phrase here is knowingly and willfully take action. This is consistent with other sections of the fact sheet where providers are given some leeway if information blocks occurs and a provider did not know, or could not be expected to know the technology or cause. It s also consistent with the 21 st Century Cures Act, which notes that providers will not be penalized for failures of HIT developers. 17

18 Statement 2 A MIPS eligible clinician must attest that they implemented technologies, standards, policies, practices, and agreements reasonably calculated to ensure, to the greatest extent practicable and permitted by law, that the CEHRT was, at all relevant times. 1. Connected in accordance with applicable law; 2. Compliant with all standards applicable to the exchange of information, including the standards, implementation specifications, and certification criteria adopted at 45 CFR Part 170; 3. Implemented in a manner that allowed for timely access by patients to their electronic health information (including the ability to view, download, and transmit this information); and 4. Implemented in a manner that allowed for the timely, secure, and trusted bi-directional exchange of structured electronic health information with other health care providers (as defined by 42 U.S.C. 300jj(3)), including unaffiliated providers, and with disparate CEHRT and health IT vendors. 18

19 Statement 2: Discussion Focuses on how CEHRT has been implemented. Providers are asked to confirm they took reasonable steps to implement: Corresponding Technologies Standards Policies Practices Agreements to enable the use of CEHRT and not restrict appropriate access to or use of your CEHRT s information. While no documentation is required by CMS, we encourage providers to consider developing and documenting standards and policies (specifically addressing each of the above) for their practice in order to confirm their intention to share information, and then to archive this information for possible future audit. 19

20 Statement 2: Discussion Examples of inappropriate Information Blocking implementation practices provided by CMS: Implementing or configuring CEHRT so access to certain types of data elements or to the structure of the data is limited. Implementing CEHRT in ways that limit the people or entities that can access and exchange information, or the types of technologies they can use. 20

21 Statement 2: Discussion CMS clarifies: We do not expect you to have any special technical skills or to personally deal with the technical details of implementing your health IT. We also do not expect you to have direct knowledge of all the matters described in Statement 2. We do expect that you take reasonable steps to ensure that you can attest that you meet the conditions described in Statement 2. To be clear, you should inform health IT developers, implementers, and others who are responsible for implementing and configuring your CEHRT of the requirements. Also, you should get adequate assurances from them that your CEHRT was connected: To meet the standards and laws that apply In a way that enables you to show you have not knowingly and willfully restricted its compatibility or interoperability 21

22 Statement 2: Discussion This is a curious clarification from CMS. If providers are not expected to have direct knowledge, yet they must attest that the conditions of Statement 2 have been met. While no documentation is required by CMS, we encourage providers to write (and archive) letters sent to their EHR developers / implementers: 1. Informing them of CMS requirements. 2. Obtain assurances that the software as implemented was connected to meet all of the standards and laws that apply. 3. Obtain assurances that the software was connected in a way that enables the provider to demonstrate they have not knowingly and willfully restricted its compatibility or interoperability. 4. All responses should be time and date stamped and archived. (Get it in writing.) 22

23 Statement 2: Discussion CMS stance seems to be that the providers don t have to know the technical details (the how ), yet CMS is expecting providers to be holding EHR developers accountable for ensuring their software is not configured to support information blocking. EHR developers may balk at providing such potentially legally binding documentation. Most EHR developers will be aware of this clarification from CMS, and will likely have prepared documentation for providers. Providers must be insistent, as they are the ones attesting. Even if vendors do not reply, providers should document the date / time / content of their inquiry. 23

24 Statement 3 A MIPS eligible clinician must attest that they responded in good faith and in a timely manner to requests to retrieve or exchange electronic health information, including from patients, health care providers (as defined by 42 U.S.C. 300jj(3)), and other persons, regardless of the requestor s affiliation or technology vendor. 24

25 Statement 3: Discussion Focuses on the use of CEHRT. By attesting to this statement, providers are confirming that they acted in good faith to use CEHRT to support the appropriate exchange and use of electronic health information. Must take reasonable steps to respond to requests for access or exchange of information when it is appropriate, and not discriminate because of the requestor's affiliation, technology vendor, or other characteristics. While no documentation is required by CMS, we encourage providers to document policies and procedures for granting access, and to formally respond in writing to all requestors, including the provider s intention to share information. Correspondence should be time and date stamped. 25

26 Statement 3: Discussion Information can be restricted if it is needed for reasonable purposes. Software upgrades (downtime) Patient safety Provers are not responsible for restricting exchange that they could not have reasonable controlled. Technical Legal Practice Constraints CMS Examples: System downtime Security threat Sensitive test results (e.g. HIV) Protection of a patient s health or well-being (based on a provider s relationship with their patient and their best clinical judgment) 26

27 Strategies for Implementation and Documentation

28 Impact Only affects ACI component. 25% of MIPS composite score Can still score on the other components of MIPS. Quality Improvement Activities Cost beginning in 2018* Can still avoid payment adjustments (penalties) by successfully completing the other components of MIPS. Composite score of 3 for 2017 Composite score of 15 for 2018 Maximum available score without attestation is 75. Still eligible for Eligible Performance Bonus ($500M in 2017 & 2018) * Cost has been weighted to zero for

29 Individuals vs. Groups If reporting as a group, the information blocking attestation by the group applies to all MIPS eligible clinicians within the group. Risk to the group if any member ECs do not comply entire group will be considered to be information blocking. 29

30 Requirements Must Act in Good Faith when implementing and using CEHRT to exchange electronic health information. Includes working with developers to ensure technology is used correctly and is connected. Must ensure policies and workflows are enabled and do not restrict CEHRT functionality in any way. IMPLICATION If it s in the software, you have to use it. Providers need to understand all software features and ensure interoperability capabilities are enabled. Providers must stay current with software updates and patches, and must enable new interoperability features when available. 30

31 Circumstances Beyond a Clinician s Control CMS will consider individual circumstances that may result in limiting the exchange and use of electronic health information, including: Your practice or organization size; How much technology you have; and What your CEHRT can do. What the attestation does not do: Assume how much you know about technology. Hold you responsible for outcomes you cannot reasonably influence or control. 31

32 Documentation Required CMS says no documentation is required to attest: You do not have to give us any documentation to show you have acted in good faith to: Implement and use your CEHRT to support the appropriate exchange of electronic health information. Not block information. What may be required in the event of an audit? 32

33 Other ACI Requirements In addition to the information blocking attestation, CMS reiterates its other requirements to receive and ACI score: Use CEHRT. Submit a performance period. Attest to work in good faith with an ONC direct review, if you get a request to assist in an ONC direct review. Meet all the base score measure requirements. Also CMS states: You can also choose to attest to work in good faith with an ONC ACB surveillance of your health information technology if it is certified under the ONC Health IT Certification Program. You have this option if you get a request for surveillance. 33

34 Direct Review Focus on safety. Framework for ONC to directly review certified health IT if there is a reasonable belief that: Certified health IT may present a serious risk to public health or safety. Review of certified health IT could present practical challenges for ONC-Authorized Certification Bodies (ACBs). The Direct Review is complementary to surveillance conducted by ONC-ACBs. 34

35 The Top 5 Things to Do Right Now

36 Top 5 Things to Do Right Now 1. Become familiar with the Information Blocking requirements, read the CMS Fact Sheet, and any clarifying questions to QPP@cms.hhs.gov. 2. Develop written practice policies and standards confirming ECs / practice s intentions to share information, and how requests for information sharing will be handled. 3. Write to EHR developers / implementers, documenting: 1. CMS requirements 2. All standards and laws have been met 3. Software was implemented so that providers can demonstrate it is not blocking information sharing 4. Document all requests for information sharing from external entities, and the practice s formal response. 5. Time and date stamp all documentation and correspondence and file in case of future CMS or other audit requests (audit preparation). 36

37 Questions / Discussion