How to Get a Patient's Health Record in 2026
You'd think I'd tell you about APIs or tools. The key is in understanding legal coverage.
A patient asks an app to pull their medication list from your system. Whether that request succeeds quickly, cleanly, and without an extra fee is now a federal compliance question. The 21st Century Cures Act made data sharing the default and banned information blocking, and after years of light enforcement, regulators have started to act.
This is a practical guide for developers, product teams, and health systems who need to treat the Cures Act as something to build for, not just read about. We’ll cover what the law requires, who’s actually on the hook, the exceptions, the penalties, where enforcement stands right now, and what all of it means for a FHIR implementation.
The throughline is simple: under this law, sharing electronic health information is the default. Withholding it is the exception you have to justify.
What the 21st Century Cures Act is
The 21st Century Cures Act is a US federal law, signed in December 2016, that made sharing electronic health information (EHI) the expected norm in healthcare and prohibited information blocking.
Most of the law deals with medical research and drug approval. The part that matters for health IT is narrower: a set of interoperability and data-access provisions, implemented by ONC (now operating as the Assistant Secretary for Technology Policy, ASTP/ONC) and CMS, that push two things. First, certified health IT has to expose data through standardized APIs. Second, “actors” can’t interfere with the access, exchange, or use of EHI without a valid reason.
The information blocking rules took effect in April 2021, initially scoped to a core data set. Since October 6, 2022, they apply to all EHI, which is most of the practical scope teams deal with today.
That’s the umbrella. The rest of this guide is the parts you’ll actually be measured against.
What information blocking actually means
Information blocking is any practice by a covered actor that is likely to interfere with the access, exchange, or use of EHI, unless the practice is required by law or covered by a specific exception.
It sounds broad because it is. The rule targets conduct, not intent, and a lot of risk hides in routine product and operational decisions:
- How hard it is to export data
- What you charge for API access
- Whether a patient can pull their data into an app of their choice
- Whether requests sit in a queue or get answered on time
One nuance worth knowing: the law sets different knowledge standards depending on who you are. Developers, HIEs, and HINs are held to whether they knew or should have known a practice was likely to interfere with EHI. Providers are held to a “knowingly” standard. In practice, that means vendors carry the heavier burden.
Who counts as an “actor”
Under the ONC Cures Act Final Rule, the information blocking rules apply to three types of actors:
- Healthcare providers: hospitals, clinicians, and the broad set of roles directly involved in patient care.
- Health IT developers of certified health IT: anyone with at least one product certified under the ONC Health IT Certification Program. This includes companies that resell or offer certified modules, not just the original developer.
- Health information networks and health information exchanges (HINs/HIEs): the entities that move data between organizations.
Two details trip teams up. If you’re a certified health IT developer, the rules apply across your entire business and product line, including products that aren’t themselves certified. And the law isn’t tied to certified technology when it comes to EHI itself: the prohibition on blocking applies to EHI no matter what system holds it.
Which actor you are determines both your obligations and your penalties, so it’s worth being precise about where you sit.
The information blocking exceptions
If a practice meets one of the regulatory exceptions, it isn’t information blocking. The exceptions are voluntary and give actors a defined safe harbor when there’s a legitimate reason to limit how EHI is shared.
ONC currently recognizes ten exceptions, grouped into three categories.
Exceptions that involve not fulfilling a request to access, exchange, or use EHI:
- Preventing Harm: limiting access to avoid a real risk of harm to a patient or another person.
- Privacy: withholding EHI to comply with privacy law or a patient’s own preferences.
- Security: measures that protect EHI from unauthorized or unsafe access.
- Infeasibility: cases where fulfilling a request genuinely isn’t possible.
- Health IT Performance: short-term steps to keep systems running, like maintenance windows.
- Protecting Care Access: limited circumstances tied to protecting access to lawful care.
Exceptions that involve the procedures for fulfilling a request:
- Licensing: licensing interoperability elements on reasonable terms.
- Fees: charging fees that are reasonable and cost-based, rather than using price as a barrier.
- Manner: flexibility in how and in what format you deliver EHI when the exact requested manner isn’t feasible.
Exceptions that involve TEFCA participation:
- TEFCA Manner: limiting fulfillment to exchange via TEFCA under specific conditions.
A few things to keep in mind, because this is where the stale explainers get it wrong. The exception set isn’t frozen. The original Cures Act Final Rule had eight; later HTI rulemaking added and refined others, which is how the current count reached ten across three categories. And it’s still moving: the HTI-5 proposed rule, published December 29, 2025 (comments closed February 27, 2026), proposes removing the TEFCA Manner exception entirely and tightening the Manner and Infeasibility exceptions. If finalized as proposed, the count drops to nine. Recent ONC guidance has also narrowed how the Fees and Manner exceptions can be used. For instance, signaling that conditioning EHI access on revenue-sharing arrangements generally won’t satisfy the Fees exception.
Treat the exceptions as a moving target. The names and structure above are the stable core, but check 45 CFR Part 171 and the current ONC fact sheets before you rely on a specific exception in production.
Penalties and disincentives
Penalties depend entirely on which kind of actor you are.
Developers, HINs, and HIEs face civil monetary penalties of up to $1 million per violation, investigated by the HHS Office of Inspector General (OIG). On top of that, ASTP/ONC can terminate the certification of an implicated product or ban a developer from the certification program altogether. For a vendor, losing certification can be a bigger threat than the fine.
Providers don’t face civil monetary penalties. Instead, they face “disincentives” administered through CMS programs: reduced scoring under the Medicare Promoting Interoperability Program for hospitals and critical access hospitals, MIPS impacts for eligible clinicians, and consequences for Medicare Shared Savings Program ACOs.
The headline number gets attention, but the quieter costs matter too: lost certification, stalled deals, and public listing of findings all carry weight in a market where buyers increasingly screen for this.
Where enforcement stands in 2026
This is the part most existing articles miss, and it’s the part that changed the stakes.
For several years the rules existed but enforcement was effectively theoretical. That’s no longer true. Here’s the timeline that matters:
- September 1, 2023: Civil monetary penalties for developers, HINs, and HIEs took effect.
- July 31, 2024: Disincentives for providers took effect, with Medicare Shared Savings Program disincentives following on January 1, 2025.
- September 3-4, 2025: HHS issued a press release and a joint OIG/ASTP enforcement alert announcing active, resourced enforcement and encouraging complaints.
- December 29, 2025: ASTP/ONC published the HTI-5 proposed rule, tightening definitions and exceptions.
- February 11, 2026: ASTP/ONC announced it had begun issuing notices of potential non-conformity to certain certified EHR developers, citing API performance, interoperability, and potential information blocking.
That last point is the signal worth internalizing, regulators aren’t only waiting on complaints anymore; they’re testing compliance against real-world interoperability performance. The complaint portal has also been busy, with well over a thousand complaints filed since it opened. The direction of travel is clear, and it’s toward more scrutiny, not less.
So if you’re asking whether the Cures Act is still in effect and whether enforcement is real: yes on both, and more so than at any point since the law passed.
(The enforcement timeline above is drawn from public HHS, OIG, and ASTP/ONC announcements and legal-industry analysis, not from any single internal source. Dates and rule status can shift, so verify against the current ONC and OIG pages before acting on specifics.)
What it means for your FHIR / API implementation
Most of the compliance conversation eventually lands on your APIs, because that’s where blocking is easiest to spot and hardest to excuse.
In practical terms, the rules expect certified systems to expose data through standardized FHIR APIs, support patient access so individuals can connect approved third-party apps, and avoid putting artificial friction in the way of automated access. The February 2026 non-conformity notices were specifically about API performance and interoperability, which tells you where attention is going.
A few places teams actually run into trouble:
- Slow or unreliable automated access. Delays that look operational can read as interference once someone files a complaint.
- Fees that aren’t clearly cost-based. The Fees exception is narrowing, and revenue-share style arrangements are under scrutiny.
- “We only support our own manner of access.” The Manner exception requires reasonable fulfillment in an alternative format when the requested one isn’t feasible, not a flat refusal.
- Export that technically exists but is unusable. If getting data out is painful enough, that itself can be the problem.
A concrete example makes the line clearer. Say a third-party app requests a patient’s medications through your patient-access API. Compliant looks like: the app authenticates via a standard OAuth flow, your API returns the data as FHIR MedicationRequest resources within a reasonable time, and no extra fee or approval step gates the patient’s own data. Blocking looks like: the request only works through a proprietary integration you charge for, responses lag badly under normal load, or the patient is told to use your portal instead of the app they chose. Same data, same request. The difference is entirely in how you built and priced the path.
This is where building on open standards pays off. SMART on FHIR gives apps a standard, stable path for authorization and launch, which is most of what patient and third-party access requires. Designing around FHIR resources and clean data models from the start means the access paths the rule expects are part of your architecture, not something you bolt on under enforcement pressure.
This is the work Medblocks focuses on: helping teams build standards-based, Cures-ready systems on FHIR and openEHR without the lock-in that gets vendors into trouble in the first place.
The bottom line
The 21st Century Cures Act reset the default in health IT. Sharing electronic health information is expected; withholding it is the exception you have to defend, and the list of acceptable defenses is getting shorter. Enforcement is no longer a someday problem.
The practical move is the same whether you’re a vendor, a developer, or a health system: audit your own access, exchange, and fee practices now, against the current rules, rather than after a complaint lands. The teams that built on open standards are the ones least likely to be surprised.
This article is general information about health IT regulation, not legal advice. Compliance turns on specific facts and current rules, so check 45 CFR Part 171 and the ONC and OIG guidance, or talk to counsel, before making decisions.
P.S. Need help with a specific FHIR or interoperability implementation? Book a call and we’ll talk through it.
Related articles
View all
Karolinska Tip2Toe: Structured Rare-Disease Phenotyping with SMART on openEHR
This project breakdown looks at how we built Tip2Toe, a rare disease phenotyping application for Karolinska University Hospital.
The Data Warehouse is openEHR's Strongest Use Case Right Now
Why openEHR works better as a silver layer in your data warehouse than as a CDR, and what that means for clinical data at scale.
