The Gang Explains Information Blocking: Part III
The Part that’s actually about Information Blocking
Welcome back, readers. Hopefully, you enjoyed a Thanksgiving respite after reading the previous articles on HIPAA and Meaningful Use leading us up to the present. Understanding those foundational policies will make your life a lot easier when trying to untangle the web of myriad and overlapping pieces that have sprouted from the most recent piece of health technology legislation enacted by Congress: the 21st Century Cures Act. I would console you that we are almost done, but alas, that is not our fate. The ONC Cures Final Rule (of course, including editorial commentary) is a whopping 353,998 words and over 300 pages. So all in all, this is somewhat of the abbreviated (and hopefully more fun/consumable) version.
The Cures Act
In 2016, Congress passed the 21st Century Cures Act. Like HIPAA before it, the bulk was not dedicated to the reasons we’re talking about it (health technology and infrastructure regulatory changes), but actually for research and drug development. It was aimed to help bring drugs and medical devices to market quicker. It also notably exempted medical software from FDA jurisdiction, a huge boon for EHRs, lab systems, and basically the bulk of digital health.
But luckily for you and I, dear readers, it also had a section (“Title IV - Delivery”) that quite clearly, yet succinctly, deals with the topics we have been discussing in this series: a comprehensive national network of exchange and patient access to their data. It also calls out a net new concept that has interplay at all three levels: information blocking.
With this in mind, the various governmental departments in play then did their beautiful bureaucratic alchemy, turning legislation into regulation. What’s somewhat confusing is that the Cures Act was spun out in several different directions, with different deadlines and different maturities:
After some iteration, the parts that deal with patient access, information blocking, and registry stuff became the ONC Cures Act Final Rule in 2020. I personally wish they had been more creative with the naming to differentiate the law from the rule, as the rule made by ONC is inherently narrower than the Act.
Separate and notably untethered from the ONC Cures Rule, the ONC developed drafts for the Trusted Exchange Framework and Common Agreement, which deal with the national framework for interoperability
The CMS, while not explicitly called out in the legislation, was not to be left behind and used the vision set out in the Cures Act as a reason to create the CMS Interoperability and Patient Access Rule and the subsequent CMS Interoperability and Prior Authorization Proposed Rule.
So let’s dig into what our civil servants designed and how they improve or change the situation for each of the three domains.
Information Blocking
At face value, the concept of information blocking seems truly wild. Tasked with ensuring that “...developers not engage in information blocking, which is preventing, discouraging, or interfering with the access, exchange, or use of information”, for better or worse, the ONC opted for breadth over precision in their rule-making, including a variety of actors and actions in extremely high-level language.
In regards to who (actors), it covers:
Health IT developer of certified health IT
Health information networks and health information exchanges
Health care provider
Notably, it does not regulate health IT developers of non-certified health, payers, or patients. However, as participants, these entities do benefit from the rule in regards to accessing data from regulated actors. Regardless, holy smokes, that’s a lot of healthcare.
In regards to how (actions), it covers any practice by those actors that is likely to interfere with access, exchange, or use of electronic health information (EHI), aside from breaking the law or several exceptions the ONC has devised.
Lastly in regards to what (content), it covers the aforementioned Electronic Health Information, which sounds simple on paper but then becomes shockingly obtuse as soon as you read the formal definition:
Electronic health information (EHI) means electronic protected health information as defined in 45 CFR 160.103 to the extent that it would be included in a designated record set as defined in 45 CFR 164.501, regardless of whether the group of records are used or maintained by or for a covered entity as defined in 45 CFR 160.103, but EHI shall not include:
(1) Psychotherapy notes as defined in 45 CFR 164.501; or
(2) Information compiled in reasonable anticipation of, or for use in, a civil, criminal, or administrative action or proceeding.
Luckily, the comments here say it much more clearly:
"Put simply, the EHI definition represents the same ePHI that a patient would have the right to request a copy of pursuant to the HIPAA Privacy Rule."
Put it all together and you get a diagram like this:
So if you’re one of the defined actors, almost all work that you do deals with EHI in some fashion, putting you at risk of information blocking if you’re not careful:
If you developed certified health IT and have other health products that have EHI but forget to allow equal and fair access to outside developers to your API program, you’re at risk of information blocking
If you’re a provider and want to discuss a patient’s HIV test results with them prior to releasing them to a portal, you’re at risk of information blocking
If you’re a health information exchange and haven’t figured out how to give patients access to their data when they request, you’re at risk of information blocking
Because of its breadth, waving the information blocking flag has been a rallying cry across disparate groups who don’t actually all want the same access or information. At any hiccup or roadblock that may occur as they participate in the healthcare economy, they feel frustration and resort to a cry of information blocking. They are sometimes justified, but are more often than not truly mistaken in what the information blocking provisions in Cures enable due to the inherent ambiguity of its broad language. The information blocking provisions reinforce and reinvigorate the existing HIPAA roles and rights, but it does not redefine them.
The main reason for that misunderstanding is failing to parse the exceptions that ONC defined: specific situations by the actors above that do not constitute information blocking. ONC bucketed these into two categories: exceptions that define situations when an actor is okay to not exchange information and exceptions that define how an actor could exchange information.
The first category of exceptions is interesting, but honestly, most are fairly straightforward and innocuous. I don’t know that many people would object to actors not releasing information in the event it would cause patient harm, violate state or federal privacy or security laws, or mean that system upgrades could never take place.
The second category, though, really is where the breadth of information blocking starts to get limited, and “Content and Manner Exception” is worth a deeper study.
Content Condition: Establishes the content an actor must provide in response to a request to access, exchange, or use EHI in order to satisfy the exception.
1. Up to 24 months after the publication date of the Cures Act Final Rule, an actor must respond to a request to access, exchange, or use EHI with, at a minimum, the EHI identified by the data elements represented in the United States Core Data for Interoperability (USCDI) standard.
2. On and after 24 months after the publication date of the Cures Act Final Rule, an actor must respond to a request to access, exchange, or use EHI with EHI as defined in § 171.102.
Manner Condition: Establishes the manner in which an actor must fulfill a request to access, exchange, or use EHI in order to satisfy this exception.
§ An actor may need to fulfill a request in an alternative manner when the actor is:
o Technically unable to fulfill the request in any manner requested; or
o Cannot reach agreeable terms with the requestor to fulfill the request.
§ If an actor fulfills a request in an alternative manner, such fulfillment must comply with the order of priority described in the manner condition and must satisfy the Fees Exception and Licensing Exception, as applicable.
Holy shit, what a gaping, cavernous hole in the broad, humongous blanket that the information blocking provisions represent. What does this mean and how did it happen? Let’s find out, intrepid reader.
Let’s start with the content part. Taking a step back and mincing no words - when these proposed rules first dropped, hospitals and EHRs freaked the fuck out. The idea of developing the mechanisms to electronically release the full set of EHI on the original timelines proposed was scary to them and they commented as much.
So ONC, in its infinite generosity, came up with a compromise:
Information blocking requirements would still come into effect, on April 5, 2021 (delayed from October 2020 due to COVID)
However, EHI’s definition would be constrained just to the United States Core Data for Interoperability (USCDI), a subset of core data that is basically just a souped-up Common Clinical Data Set (see the last article for a refresher), until Oct 6, 2022
After Oct 6, 2022, all EHI is included in the definition
This delay, while a compromise, was actually pretty hardline compared to what most commenters (HCOs, EHRs, etc) on the proposed rule wanted. Beyond that, there’s a subtle art and beauty to the way they architected it if you look closely. By constraining to USCDI subset first, which is well defined in FHIR, it incentivizes EHRs and HCOs to build the capabilities to meet the export criteria in FHIR, which may mean that the more comprehensive EHI exports are more FHIR forward than they would otherwise be. We can still expect a bunch of random CSVs or other file formats, as that’s allowed, but there’s hope with this approach that a lot of data will be FHIR native.
As wild as that provision is, the manner one is the absolute moneymaker that everyone ignores. To understand this one, let’s use an example. Suppose you’ve received care at Dr. Brendan Keeler’s Fun Fun Adventure Clinic and want to request your records under your HIPAA Right to Access. You are eccentric (you’re reading this newsletter, so highly likely) and decide that handwritten records delivered by carrier pigeon are the best manner by which to receive that. You request that from my Fun Fun Clinic.
At that point, I have two options under the Cures Final Rule:
I can respond in the manner requested. In this case, I can actually charge you a fee outside of the Fees Exception (i.e. charge you whatever I want), which sorta makes sense - carrier pigeons are expensive, and likely my clinic has not exercised that particular communication muscle recently. (Note: this is not an invitation to make some trendy NYC carrier pigeon startup)
Alternatively, I can say “no, I’m technically unable to fulfill the request, carrier pigeons went out of vogue around World War II and are low-key a form of animal exploitation, so let’s do something different.”
If I opt to prevent animal harm (and fairly high cost to you and I), I then need to offer a method supported in Part 170. In that case, I’m almost certainly going to offer it via the FHIR APIs required in the Cures Final Rule EHR Certification updates (more to come here), a standard export of a CDA (hello, Meaningful Use 3), or some other method I actually support (even a CSV!). However, if I choose to fulfill in this alternative manner, I must use the Fees Exception - which means that fees for business associate or covered entity requests must be priced related to the actor's costs and patient-initiated requests cannot be charged a fee.
All of this is pretty reasonable! Unsurprisingly, though, this is not actually about carrier pigeons. There are an infinite variety of other possible technical methods by which a patient could conceivably request their information: by letter, by fax, by smoke signal, by HL7v2 over HTTPS, by CDA over XDS, by FHIR… the list goes on. We see this pretty commonly already for groups trying to request over existing health information exchanges or networks and asserting Patient Request as their purpose of use. The ONC actually lists multiple similar examples in the Rule. As well-intentioned and reasonable as that is, health systems have every legal ground to reject that under this provision.
Beyond that, many in the industry also forget that the concepts of HIPAA still set the fundamental rules of engagement and spend no time overlaying the information blocking provisions on their HIPAA-defined role and rules. Information blocking requirements do not reinvent HIPAA; they serves as a brute force, a last resort cudgel to pummel those who would resist the principles that HIPAA outlined.
I might be lambasted for this, but... to be completely frank, I have problems with the information blocking provisions. They represent excellent regulatory policy when judged solely on intent but, taken more practically, miss on advancing our national posture. They don’t fundamentally change a whole lot, given the exceptions, and really just reinforces HIPAA rights that already existed. They’re broad and unprescriptive to such an extent that it will be subject to chronic misunderstanding. It’s fodder for lawyers to fight and argue. Lastly and most importantly, it’s a blunt weapon many will wield, but the punishment will hurt the weak more than the strong. Epic, Cerner, or Kaiser have the resources to prepare properly and also to withstand an infraction or two if they make a mistake or are attacked. But smaller practices or vendors do not have the same resources and that same penalty may likely kill them.
I think the issue is that people so desperately want these information blocking requirements to be the solution to their most pressing problems that they mentally contort it to match whatever they need. Healthcare is, unfortunately, painful for everyone and HIPAA’s promises are still not fulfilled - covered entities still don’t have the full picture of their patients, business associates die on the vine trying to do the jobs they promise to their customers, and patients still can’t get their information.
The fact of the matter, though, is that the information blocking requirements don’t solve those problems, by and large. Far more important and impactful to fixing many of those problems are the prescriptive capabilities that are defined in the Cures Final Rule (the EHR Certification Requirement updates) and in the Cures Act-adjacent CMS regulation. In the interest of dividing things nicely, we’ll pick that up next week in Part IV (the last of this series).
To summarize some key points before we depart:
The 21st Century Cures Act, a piece of legislation, led to the ONC Cures Final Rule (a piece of regulation), but also to TEFCA, as well as two related pieces of regulation by the CMS - the CMS Interoperability and Patient Access Rule and the CMS Interoperability and Prior Authorization Proposed Rule.
ONC Cures had sections related to information blocking, but also to EHR certification criteria updates.
Information blocking is an extremely broad provision preventing, discouraging, or interfering with the access, exchange, or use of information and applies specifically to providers, developers of certified health technology, and health information exchanges.
The Content and Manner Exception, as well as other defined exceptions, reduces the surface area of information blocking by giving actors some reasonable flexibility in terms of the manner they support to give the patient their data.
Information blocking provisions are not a panacea for all of the struggles for integration and interoperability that exist today.
Huge shout out (again) to the squad of friends, colleagues, and Good Samaritans who contributed by editing this article - Colin Keeler (check out Atai if you think mental health could be transformed by psychedelic compounds), Garrett Rhodes (Redox is dope and their new payer offerings are sweet), Samir Jain (serial health tech legend, currently of RubiconMD), Ed Manzi (former law student building something new in-home medical equipment), Matthew Fisher (actual lawyer at Carium, a virtual care platform company, and host of Healthcare de Jure), and Joshua Schwartz (PM at Commure). It takes a village to navigate the legal norms we impose upon ourselves as a society, so appreciate their help.