21st Century Cures - Information Blocking Exceptions

The 21st Century Cures Act includes provisions to promote health information interoperability and to prohibit information blocking. In this video I'll review the 8 exceptions providers, health IT developers of certified IT, HINs and HIEs may use for this rule.

Video:

Video Transcript:

Hi there, I’m Drae the host and founder of the Draegan Network. Welcome to this week's video.

I want to continue the conversation around something we started last week which is the topic of information blocking. On today's video I am going to focus on the exceptions that are in place. If you missed the last video there's a new information blocking rule that was put in place and became effective on April 5th of 2021 as part of the 21st Century Cures Act. Section 4004 of that Act states that information blocking is any practice that is interfering with access, use or exchange of electronic health information. It applies to care providers, to health IT developers of certified health IT, to health information networks (HINs) and to health information exchanges (HIEs).

[00:48] As part of that 21st Century Cures Act, commonly referred to simply as the Cures Act, there are eight (8) exceptions to the information blocking rule. Today let's chat about what those 8 exceptions are. They fall into two different categories:

• the first category involves exceptions for not fulfilling the requests; and,
• the second category is for procedural exceptions when fulfilling requests.

The first exception is the preventing harm exception. It will not be considered information blocking if there is reasonable belief that providing the information is going to cause harm for a patient or a person that's involved in the request. With each of these exceptions there are conditions that are applied. For the preventing harm exception the first condition is there needs to be a belief that it will cause substantial harm. (So, that substantial term is relevant here.) The next one is that the exception, or invoking the exception, cannot be broader than is necessary. Using this exception must also satisfy one or more of each of these areas:

• the type of risk
• the type of harm, and
• the implementation basis.

The other big condition is if a preventing harm exception is cited as the reason for not providing information, then the patient has the right to review that decision.

[02:08] The next one is the privacy exception and this one involves the actor, or the entity who is holding the information, failing to fulfill the request to protect an individual's privacy. It must meet at least one of the conditions that I've outlined here:

• if there are certain preconditions that have been established by the entity who's holding the information prior to allowing the access, exchange, or use
• if the health IT developer or certified health IT is not an entity that's governed by the HIPAA privacy legislation. If they fall outside of that then that is another exception. The next one is,
• if there is a denial of the request for reasons that are set out in the Cures Act. And the final one is
• to respect the patient's privacy wishes. If a patient has put in a request not to share information that must be respected and that falls under the privacy exception.

[03:01] The security exception is focused on protecting the security of the EHI within the entity or the holding entities systems. With this one, where you'll find exceptions is that the practice must be directly related to safeguarding the confidentiality, the integrity, and the availability of that EHI. It must be tailored to specific security risks. It can't just be broad and generalized to say “I think it's a security risk if I share.” And it needs to be implemented in a consistent and non-discriminatory matter. It can't be arbitrarily implemented when there is an exception being identified as a security exception. There needs to be consistent parameters and it needs to be applied sort of uniformly each time it's applied.

[03:47] The infeasibility exception is really where it's just simply not feasible to provide that information. It needs to meet one of the following conditions:

• it needs to be the result of an uncontrollable event,
• it needs to be the result of segmentation where data is in different places and it's impossible to sort of pull it together, or
• it needs to be infeasible under other circumstances.

There has to be some defined parameter circumstances that are set which indicate why it's not feasible at that time. Or to manage and fulfill that particular request, if the entity is claiming an exception due to infeasibility, then there needs to be a written response that's provided indicating why and what the reason is within 10 days of the request being received.

[04:32] The final exception in this category for not fulfilling a request to access, exchange, or use EHI is the health IT performance exception. If this exception is utilized then it needs to be implemented for no longer than is necessary. It can't be extended duration periods. It needs to be focused on a certain amount of time. It needs to be implemented consistently and in a non-discriminatory manner. It also must meet some additional conditions if the unavailability is initiated by the certified health IT developer, HIN or HIE. (E.g., instances like a down time.) There are certain parameters and additional conditions that apply for things like that.

[05:15] The next three (3) exceptions fall under the procedural category when fulfilling requests. The first exception that we've got listed here is content and manner exception. From a content perspective, the content conditions that are in place, as I mentioned in last week's video (which I will link to below), is between April 5th of 2021 and October 6th of 2022 the minimum data set that needs to be adhered to or disclosed in a request for access, exchange, or use is that USCDI v1. That is the minimum content condition that is in place. After October 6th of 2022, EHI that's identified in § 171.102 is going to be the minimum data set that's required. That is the content component. The manner exception can be utilized if there needs to be an alternative method of providing the information because the entity is unable to reach an agreement with the requester, or for some reason the standard manner is not technically feasible. Depending on who the requester is, there needs to be an agreement on how the information would be shared. It needs to be shared in a standard way and if you can't do that there is a manner exception.

[06:28] The next one is a fees exception. First off it is not going to be considered information blocking if fees are charged. A health entity or health data holder can actually charge fees for access, for use, or exchange of that information. So a couple things with this one. There's a lot of parameters on what fees can be charged, where they can be applied, how they can be applied and that type of thing so I'm not going to go into that. But the fees exception needs to be utilized when there is objective and verifiable criteria. It needs to be uniformly applied. Again, there has to be consistent, non-discriminatory application of the fees exception. You can't just claim a fees exception for having procedural changes here and there. They need to be uniform across the board. You also can't fail to provide the information or restrict or alter the provision of that information based on fees or based on the fee exception. If that fee is determined to be opportunistic or if it is interfering with the access, exchange, or use of the EHI.

[07:30] The last one is the licensing exception. This really applies more to a larger request for data and not necessarily for the provision of care or patient directing data; but information that is being requested for the purposes of licensing. Say between health IT (certified health IT applications) or between payers and provider entities. Things like that. It's the larger sort of context. With the licensing exception, the conditions that are in play here is that licensing negotiation needs to begin within 10 business days of requests being made; and there needs to be an agreement made within a 30 business day period. If that agreement can't be made, then you would of course look to some of the other exceptions to see if they would apply in that particular situation. The licensing conditions that need to be negotiated within that period are:

• the scope of rights,
• the reasonable royalty that would be required (if there's royalties on the information being provided),
• non-discriminatory terms (what are the rules of the road if you will),
• collateral terms that would be in place should something occur, as well as
• a non-disclosure agreement if that's applicable for the situation.

[08:46] Again, all of these apply to HIPAA covered entities, so the protection of privacy and the security of the data is absolutely first and forefront.  It is not an exchange of data sort of willy-nilly anyone who wants it can get it and the information blocking is just saying that you have to give it out. That's definitely not the case here. Those are the eight exceptions in the two categories. We will see over the next several years how many times the exceptions are invoked and whether this is something that is going to be revisited. With the rule just coming into place April 5th of this year, we haven't seen a lot of these exception requests come through yet. We haven't really seen this play out but we'll certainly keep an eye on it.

If you found the information helpful in this week's video, as always don't forget to hit that like button. If you haven't subscribed to the channel, go ahead and do that now. I'm going to put those few links that I mentioned in the comments below and I will see you again next week!

Links:

Last week's video

Cures Act

Draegan Network