MIPS Information Blocking: Attestation Requirements
This past Thursday (10/26/17) CMS released a “Fact Sheet” detailing their specification that all Eligible Clinicians (ECs) attesting for MIPS will be required to attest that they are not “Information Blocking” when submitting their MIPS scores.
Today, we’ll discuss the implications of this requirement, and offer strategies for providers to help mitigate any current and future risk associated with this CMS mandate.
Information Blocking – History
Information Blocking is defined as a practice that is likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information. Much of the current regulatory focus surrounding information blocking stems from the 21st Century Cures Act of 2016 (12/13/16), which specifies blocking rules that would apply to HIT developers, exchanges or networks, and health care providers, along with penalties for information blocking that can be levied for up to $1,000,000 per violation. This framework for enforcement would then be administered via other regulatory efforts, including MIPS and MACRA.
MIPS Information Blocking Requirements
All MIPS Eligible Clinicians who report on the advancing care information category will be required to attest to three separate statements on Information Blocking, beginning in 2017.
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 21st Century Cures Act, which notes that providers will not be penalized for failures of HIT developers.
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.
This statement focuses on how CEHRT has been implemented. Providers are asked to confirm they took reasonable steps to implement:
– Corresponding Technologies
– 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.
CMS also clarifies Statement 2, offering this additional explanatory language:
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
Given the “to be clear” statement from 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. 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
All responses should be time and date stamped and archived
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.
This statement 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. They 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.
Again, 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, with all correspondence time and date stamped and archived.
“Act in Good Faith”
One additional specification from CMS is that providers must “act in good faith” when implementing and using CEHRT to exchange electronic health information. This includes working with developers to ensure technology is used correctly and is connected, and ensuring that policies and workflows are enabled and do not restrict CEHRT functionality in any way.
The implication here is that if interoperability features are available from a software developer, then providers must implement and use those features–in other words, if it’s available in the software, you have to use it. This means that providers need to understand all available software features, and must stay current with software updates and patches, enabling and using new interoperability features when they become available.
Summary: Five Recommendations
1. Become familiar with the Information Blocking requirements, read the CMS Fact Sheet, and email any clarifying questions to QPP@cms.hhs.gov. Additional information can also be found on CMS’ QPP website: qpp.cms.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.