How can an Actor/covered entity provider comply with both the Information Blocking Rule & HIPAA when access to EHI/PHI needs to be denied based on harm that arises from corrupted data?
- Delay access to EHI/PHI instead of denying access completely.
- Have a licensed health care professional confirm the denial of access due to data issues.
- Adopt a standing policy “signed off” by a licensed health care professional permitting denials of access in pre-identified scenarios involving data issues.
The Information Blocking (IB) Rule is intended to work in sync with HIPAA, including the “right of access” granted to patients with regard to their own protected health information (PHI). However, as I continue to analyze how to implement the various standards that overlap between these two regulations, questions about how to thread the needle on seemingly conflicting provisions continues to come up. Today, I take a closer look at the difference between HIPAA’s “right of access” as compared to the Preventing Harm Exception found in the IB Rule. Specifically, this post considers how a covered entity may be permitted – under HIPAA — to either delay or deny the release of EHI/PHI to a patient who is requesting access when data is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason.
The HIPAA Privacy Rule’s “right of access” standards are set forth in 45 C.F.R. §164.524. Generally, HIPAA affords a patient with a right of access to inspect and obtain a copy of his/her PHI maintained in a designated record set. This right of access may be denied only under certain circumstances, which are separated into “unreviewable” and “reviewable” denials. Unreviewable denials are very limited in scope (e.g., psychotherapy notes; information complied in reasonable anticipation of civil, criminal, or administrative action; PHI created in the course of research etc.) (for a full list of the limited PHI which falls within unreviewable denials, see 45 C.F.R. §164.524(a)(1) & (a)(2)). Furthermore, unreviewable denials are carved out of the Preventing Harm Exception and instead are treated under the IB Rule’s Privacy Exception. Specifically, Privacy Sub-Exception (e) permits an Actor/covered entity to deny access to an individual requesting EHI/PHI if HIPAA’s provisions governing unreviewable denials are followed. However, reviewable denials under HIPAA are a different story.
With respect to reviewable denials, a covered entity may deny an individual access to his/her PHI only if a health care professional has determined, in the exercise of professional judgement, that access to such PHI is reasonably likely to “endanger the life or physical safety” of the individual or another person. Any such denial is subject to a review process, if requested by the individual, but can be overturned only by another licensed health care professional. Therefore, here, the only mechanism available to potentially deny an individual access to his/her PHI when requested is a determination by a health care professional. Not so under the IB Rule’s Preventing Harm Exception.
The Preventing Harm Exception is found at 45 C.F.R. §171.201. Under this exception, an Actor (which includes covered entity health care providers) are permitted to “interfere with” (e.g., deny) a request for access to EHI in order to “prevent harm” if the Actor has a reasonable belief that the interference/denial of access would substantially reduce a risk of harm to the individual or another natural person that would otherwise occur if the requested EHI is allowed to be accessed, exchanged, or used. When an individual is requesting access to EHI himself/herself, the type of harm that must be present is one that is reasonably likely to “endanger the life or physical safety” of the individual or another person. So far, so good. As intended by ONC, this tracks the same type of “harm” that is required to deny an individual access under HIPAA. However, under the IB Rule the risk of such harm may be determined either by a licensed health care professional (same as HIPAA) OR “arise from data that is known or reasonably suspected to be misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason.” Yet, as I just laid out above, HIPAA does not have an analogous mechanism to permit a covered entity to deny access based on harm that arises out of data – hence, the rub.
So, the question becomes how can an Actor/covered entity comply with both the IB Rule and HIPAA when it needs to deny an individual access to her/his EHI/PHI based on harm that arises from data? Here are the options I see:
1. Delay access instead of denying access completely. If data is misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason but the issue can be corrected, then an Actor/covered entity would be permitted to delay providing the requested EHI/PHI to the individual until the data can be corrected. This is allowed under both the IB Rule’s Preventing Harm Exception and HIPAA. In fact, the Preventing Harm Exception requires that an Actor not interfere with access to EHI in any manner that is “broader than necessary.” Therefore, even though the Preventing Harm Exception would potentially allow for an outright denial of access to EHI for data issues that meet the requisite harm threshold (i.e., danger to life or physical safety of patient or another person), if the data is correctable and corrected, an Actor would be expected to fulfill the individual’s request for access at that point in time. Similarly, under HIPAA, a covered entity has up to 30 days to act on a request for access received from the individual. Even though HHS has made it clear in its slew of Resolution Agreements and elsewhere that a covered entity may not to take up to 30 days to respond to a request of access if it can be fulfilled sooner, when there is a legitimate reason to delay access – i.e., because data has been corrupted and needs to be corrected – a covered entity may do so. If more than 30 days is needed to correct the data, then the covered entity need only provide the individual with a written statement of the reasons for the delay and the date by which the covered entity will complete its action on the request. See 45 C.F.R. 164.524(b)(2)(ii)(A). On a practical level, this option will likely be the most common one used. Therefore, an organization should confirm that its P&Ps track this option accordingly.
2. Have a licensed health care professional confirm the denial of access due to data issues. If data is misidentified or mismatched, corrupt due to technical failure, or erroneous for another reason but cannot be corrected, then a covered entity looking to fully deny an individual access to his/her own EHI/PHI being requested would need to have such decision confirmed by a health care professional. This would allow the covered entity to satisfy HIPAA’s denial of access requirements, as well as those under the Preventing Harm Exception. As discussed above, unlike the IB Rule’s Preventing Harm Exception, the HIPAA Privacy Rule does not provide a separate mechanism which would allow a covered entity to completely deny an individual access to her/his PHI solely based on data issues unless a health care professional has made a determination in her/his professional judgement that it would pose a “danger to life or physical safety of patient or another person.” The good news is that a covered entity may continue to use the “less stringent” standard under HIPAA which allows any licensed health care professional to make such a determination (note: since this determination is needed only to satisfy HIPAA’s requirements, the IB Rule’s requirement that there be a “patient-practitioner relationship” does not need to be satisfied). Therefore, a covered entity looking to fully deny a patient request for access to EHI/PHI that is based on uncorrectable data may do so by implementing such a process accordingly.
3. Adopt a standing policy “signed off” by a health care professional permitting denials of access in pre-identified scenarios involving data issues. As an alternative to the preceding option, a covered entity could consider developing a policy that lays out specific scenarios involving potential data issues (i.e., misidentified/mismatched; corrupt; erroneous) and conclude – based on the professional judgement of such health care professional – that it is reasonably likely to “endanger the life or physical safety” of the patient or another person, and should not be provided to the patient in such situations. Since HIPAA does not expressly require “individualized determinations” (i.e., on a case-by-case basis), the policy-approach is easier to implement on an organization-wide basis than option #2 which involves having a health care professional confirm denials each time any such data-issue arises.
In a few weeks, I will be offering a 1-hour Webinar exclusively on how to operationalize the Preventing Harm Exception — if you are interested in registration details, email me at helen@legalhie.com.
__________________
Subscribe HERE to Legal HIE’s compliance library to gain access to sample policies, documents and tools for compliance with the Information Blocking Rule. Review our Table of Contents here.
