The exceptions you should ask an EMR vendor about are Fees, Manner, Licensing, Infeasibility, and Health IT Performance — because those are the four or five that turn into line items, restrictions, and outages in your actual contract. The other exceptions (Preventing Harm, Privacy, Security, Protecting Care Access, and TEFCA Manner) matter clinically and legally, but they rarely determine what you pay or what you can do with your own data. Ask a vendor which exceptions they rely on, and you learn more about your future than any demo will tell you.
The short answer
Information blocking rules are usually pitched to practices as a compliance burden. Treat them instead as a buying tool. The regulation defines a small, closed list of circumstances in which an actor may lawfully interfere with access, exchange, or use of electronic health information. Every fee your vendor charges for data access, every restriction on getting your records out, and every "we can't do that" has to fit inside one of them — or it fits nowhere. That gives you a structured way to interrogate vendor behavior instead of arguing about fairness.
What information blocking actually is
Information blocking, established under the 21st Century Cures Act, refers to practices likely to interfere with the access, exchange, or use of electronic health information, except as required by law or covered by an exception. The regulations are codified at 45 CFR Part 171 and apply to "actors" — health care providers, health IT developers of certified health IT, health information networks, and health information exchanges.
Two consequences for a buyer. Your EMR vendor is an actor if it develops certified health IT, so its conduct toward you is regulated, not merely commercial. And you are an actor too, as a health care provider — so the exceptions also govern how you respond to patient and third-party requests once the system is live.
The ten exceptions, in plain terms
Part 171 organizes the exceptions into groups. Exceptions that involve not fulfilling requests sit in Subpart B; exceptions that involve procedures for fulfilling requests sit in Subpart C; and TEFCA-related practices sit in Subpart D.
| Exception | Citation | What it covers |
|---|---|---|
| Preventing Harm | § 171.201 | Interference intended to prevent harm to a patient or another person. |
| Privacy | § 171.202 | Not fulfilling a request in order to protect an individual's privacy. |
| Security | § 171.203 | Interference to protect the security of electronic health information. |
| Infeasibility | § 171.204 | Not fulfilling a request because it is infeasible under defined conditions. |
| Health IT Performance | § 171.205 | Practices implemented to maintain or improve health IT performance — maintenance, in other words. |
| Protecting Care Access | § 171.206 | Interference to reduce potential exposure to legal action. |
| Manner | § 171.301 | Limiting the manner in which a request is fulfilled. |
| Fees | § 171.302 | Charging fees for accessing, exchanging, or using electronic health information. |
| Licensing | § 171.303 | Licensing interoperability elements needed to access or use the information. |
| TEFCA Manner | § 171.403 | Limiting fulfillment of a request to exchange via TEFCA only. |
Each exception has conditions that must be met. An actor cannot invoke "Security" as a general excuse; it must satisfy the specific requirements the regulation attaches to that exception. That specificity is what makes the list useful in a negotiation.
The Fees exception is where your money is
When a vendor tells you that an interface costs money, that an API connection carries a per-transaction charge, or that a full data extract at termination is a professional-services engagement, they are — whether they say so or not — operating in the territory of the Fees exception at § 171.302. The exception permits fees, subject to conditions. It does not permit any fee a vendor feels like charging.
So ask directly, and ask in writing:
- What fees would you charge us to access, export, or exchange our own electronic health information, in any scenario, including termination?
- Which exception do you rely on for each of those fees?
- How is each fee calculated, and on what basis?
- Are any of those fees waived if we remain a customer, and charged if we leave?
The Manner exception is where your options are
The Manner exception at § 171.301 addresses limiting how a request gets fulfilled. In vendor terms, this is the difference between "yes, you can have your data" and "yes, you can have your data as a 40,000-page PDF." Both are technically a yes. Only one is useful.
When you evaluate portability, do not accept a yes/no answer. Specify the manner you need — standards-based API access, a structured bulk export, a documented database schema — and ask whether the vendor will fulfil requests that way, at what price, and what happens if you ask for something they would rather not provide. The Manner and Fees exceptions interact: a vendor that cannot reach agreement on the manner requested has different obligations than one that simply refuses.
Infeasibility and Health IT Performance
Two exceptions are worth understanding because they are the ones most likely to be invoked at you, casually, in an email.
Infeasibility (§ 171.204) permits not fulfilling a request that is infeasible under the conditions the regulation specifies. Note what it requires: the actor must demonstrate, through a contemporaneous written record or other documentation, its consistent and non-discriminatory consideration of the factors that led to the infeasibility determination. "We can't do that" is not an infeasibility finding. A documented, consistent, non-discriminatory determination is. If a vendor tells you something is infeasible, it is entirely fair to ask what their documentation of that determination says.
Health IT Performance (§ 171.205) covers practices implemented to maintain or improve performance — which is to say, maintenance windows and upgrades. This is the exception under which a system can be taken offline. It is legitimate. It is also the one to keep in view when you negotiate maintenance windows and downtime notice in the contract, because the regulation permitting an outage says nothing about whether that outage is scheduled at 2pm on a Tuesday.
How to use this during diligence
- Send the exception list to the vendor before the demo. Ask which ones their standard practices rely on. An evasive answer is itself the finding.
- Convert every "no" into an exception question. When something is refused, ask which exception applies and what conditions they have satisfied.
- Get all fees enumerated in writing, pre-signature — especially export and termination fees.
- Ask what Manner they will fulfil a bulk export in: format, standard, timeline, cost.
- Put it in the contract. If a vendor will genuinely not charge you to leave with your data, that costs them nothing to warrant.
If you think you are being blocked
ONC operates a formal channel for information blocking claims, and anyone can submit one. Separately, if a certified product does not do what its certification says it does, ONC runs a complaint process for certified health IT — a different channel, worth knowing which one fits your problem. Knowing both exist changes the character of a conversation about export fees, and it is far better to have that conversation while you still have leverage.
The takeaway
Most practices meet information blocking as a compliance chore after go-live. Meet it earlier and it becomes leverage. The exceptions are a closed list; a vendor's fees and refusals either fit inside them or they do not. Ask which exception applies, ask what conditions have been satisfied, and get the answers before you sign — because the day you want your data out is the day you have the least bargaining power you will ever have.
Common questions
How many information blocking exceptions are there?
Ten. Six address not fulfilling requests (Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance, Protecting Care Access), three address procedures for fulfilling requests (Manner, Fees, Licensing), and one addresses TEFCA-only exchange (TEFCA Manner).
Can an EMR vendor charge us to export our own data?
Possibly, but only within the conditions of the Fees exception at 45 CFR 171.302. Fees are not automatically permitted simply because they appear in a contract. Ask which exception the vendor relies on and how the fee is calculated, before you sign.
Is my practice an information blocking actor too?
Yes. Health care providers are actors under the rule, alongside health IT developers of certified health IT, health information networks, and health information exchanges. The exceptions govern your conduct as well as your vendor's.
What does the Manner exception actually mean for a buyer?
It governs how a request gets fulfilled, not whether. It is why a vendor can say yes to a data request and still hand you something unusable. Specify the manner you need, in the contract.
Common questions
How many information blocking exceptions are there?
Ten. Six address not fulfilling requests (Preventing Harm, Privacy, Security, Infeasibility, Health IT Performance, Protecting Care Access), three address procedures for fulfilling requests (Manner, Fees, Licensing), and one addresses TEFCA-only exchange (TEFCA Manner).
Can an EMR vendor charge us to export our own data?
Possibly, but only within the conditions of the Fees exception at 45 CFR 171.302. Fees are not automatically permitted simply because they appear in a contract. Ask which exception the vendor relies on and how the fee is calculated, before you sign.
Is my practice an information blocking actor too?
Yes. Health care providers are actors under the rule, alongside health IT developers of certified health IT, health information networks, and health information exchanges. The exceptions govern your conduct as well as your vendor's.
What does the Manner exception actually mean for a buyer?
It governs how a request gets fulfilled, not whether. It is why a vendor can say yes to a data request and still hand you something unusable. Specify the manner you need, in the contract.