EHI access requests moving through the ONC Cures Act compliance gate under 45 CFR Part 171
Every request to access, exchange, or use electronic health information — from a patient's portal download, a referring provider's query, or a health information exchange's bulk pull — is a legally meaningful event under the ONC Cures Act Final Rule. The moment a request lands, the clock on "reasonable and necessary" behavior starts running.
The information blocking regulation applies to three actor types: health care providers, developers of certified health IT, and health information networks/exchanges (HINs/HIEs). A "request" can take many forms in this simulator's queue — a patient using a portal or a third-party app under their direction, a treating provider querying for continuity of care, a payer requesting records for care coordination, or an HIE pulling records on behalf of a participant.
Since October 6, 2022, the scope of covered electronic health information (EHI) expanded from the narrow USCDI data set to the full designated record set definition drawn from HIPAA — meaning nearly any EHI held in an electronic form by an actor is potentially subject to the request.
Each incoming ticket in the queue therefore represents a real legal event: a countdown against the statutory expectation of "as soon as practicable" begins the instant the request is receivable by the actor's system, not when a staff member gets around to looking at it.
Information blocking is defined as a practice by an actor that is likely to interfere with access, exchange, or use of EHI — unless the actor satisfies the requirements of one of the eight recognized exceptions. Intent matters for providers (a "knows" standard) but not for health IT developers and HINs/HIEs, who are held to a stricter "knows or should know" standard.
In a real health system, requests do not arrive evenly. Portal registrations spike after outreach campaigns; HIE bulk queries batch overnight; release-of-information (ROI) teams triage by hand when automated FHIR APIs are unavailable or a manual medical-records request form is used instead.
When intake volume outpaces processing capacity, a backlog forms — visually, tickets stack up on the left side of the compliance gate in this simulator, exactly as an ROI department's queue would build during a staffing shortage or an EHR outage. A backlog is not itself information blocking, but a backlog that is never cleared, or that systematically grows for certain request types (e.g., third-party app data requests), is exactly the pattern OIG and ONC/ASTP investigators look for as circumstantial evidence of a blocking practice.
The response-time-policy slider in this simulator controls how aggressively your organization's internal SLA processes the queue — a longer allowed window produces a visibly larger, slower-draining backlog.
It helps to contrast two overlapping but distinct obligations. HIPAA's Right of Access rule (45 CFR 164.524) requires covered entities to provide individuals access to their records generally within 30 calendar days, with one permissible 30-day extension for good cause — a 60-day outer boundary that predates the Cures Act by two decades.
Information blocking regulation does not replace that timeline; it layers a stricter, EHI-specific, technology-forward expectation on top of it. Where certified health IT and interoperable exchange are available, "as soon as practicable" is understood by ONC/ASTP guidance to mean same-day or near-real-time release for electronic requests — not the 30-to-60-day HIPAA ceiling.
An organization that hides behind the HIPAA 30-day window for a request that its certified EHR could fulfill electronically within minutes is exactly the scenario the information blocking provisions were written to eliminate.
Not fulfilling a request, or fulfilling it on delay, is not automatically information blocking. ONC/ASTP defined eight exceptions that, when their conditions are met exactly, mean a practice that interferes with access, exchange, or use will not be treated as information blocking. Exceptions are affirmative defenses — the actor bears the burden of showing every condition was satisfied.
ONC organized the eight exceptions into two conceptual families. The first family covers exceptions that involve not fulfilling a request at all: Preventing Harm, Privacy, Security, Infeasibility, and Health IT Performance. These apply when an actor reasonably and narrowly determines that satisfying the request as asked would cause harm, violate a privacy law, create a security risk, be technically or practically infeasible, or would require taking health IT temporarily offline for maintenance.
The second family covers exceptions that involve the procedures for fulfilling a request rather than refusing it outright: Content and Manner, Fees, and Licensing. These let an actor limit the content it provides or the manner (e.g., API vs. fax) it uses, charge certain permitted fees, or license interoperability elements on reasonable, non-discriminatory terms — provided each exception's detailed conditions are satisfied.
Every exception has multiple sub-conditions defined in the regulatory text; satisfying the general label of an exception (e.g., "this seems like a privacy issue") is not sufficient — the actor must meet every element, and document that it did.
The exception-invocation-rate slider in this simulator controls how often staff cite one of the eight exceptions when declining or delaying a request. A healthy invocation rate reflects genuine, well-documented determinations — for example, correctly withholding psychotherapy notes under a state-law-aligned Privacy exception, or delaying release during a scheduled system upgrade under Health IT Performance.
But auditors read invocation patterns statistically. A rate that is unusually high, concentrated on one requester type (e.g., disproportionately invoked against competing HIEs or third-party patient apps), or invoked without a documented individualized determination is itself a red flag — it suggests exceptions are being used as a blanket policy rather than a case-by-case defense, which fails the "reasonable and no broader than necessary" test embedded in nearly every exception.
Conversely, an invocation rate near zero in an organization that regularly declines or delays requests suggests those declines are simply undocumented information blocking with no defense asserted at all.
An exception only protects a specific practice if every element of that exception's conditions is met for that specific request. Exceptions are not a general license to be cautious — the Preventing Harm exception, for instance, requires a reasonable belief the practice will substantially reduce a risk of harm, that the practice is no broader than necessary, and that it satisfies at least one of several defined harm-avoidance conditions.
Because every exception is an affirmative defense, the practical difference between "delayed, but exception-covered" (amber in this simulator) and "blocked, non-compliant" (red) is almost entirely about what was written down at the time of the decision, not about the underlying facts.
Well-run compliance programs pair each exception invocation with a structured record: which exception, which sub-condition, who made the determination, what individualized facts supported it, and how the practice was kept no broader than necessary. Weak programs apply exceptions as a verbal policy ("we always hold records for X days") with no per-request record — which collapses the defense the moment ONC/ASTP or OIG asks for evidence.
This is why Stage 4 of this simulator — audit trail and attestation logging — is inseparable from exception handling: an exception invoked but never logged is, from an enforcement perspective, functionally identical to no exception having been invoked at all.
| Product | Indication | Trial Design | Key Result |
|---|---|---|---|
| Preventing Harm | Not fulfilling | Reasonable belief the practice will substantially reduce a risk of harm to a patient or another person | |
| Privacy | Not fulfilling | Practice is required to comply with a precondition under state/federal privacy law (e.g., substance-use records, minors) | |
| Security | Not fulfilling | Practice is directly related to safeguarding EHI confidentiality, integrity, and availability | |
| Infeasibility | Not fulfilling | Actor cannot fulfill the request due to circumstances outside its control (uncontrollable events, segmentation limits) | |
| Health IT Performance | Not fulfilling | Practice is implemented to maintain or improve health IT performance, limited to reasonable maintenance windows | |
| Content & Manner | Procedures | Actor limits the content of its response or the manner of fulfillment when the preferred manner cannot be used | |
| Fees | Procedures | Reasonable, cost-based fees may be charged if broadly non-discriminatory and not designed to interfere with access | |
| Licensing | Procedures | Interoperability elements may be licensed on reasonable, non-discriminatory terms |
The compliance gate is where the abstract regulatory standard becomes an operational number. Each ticket carries an elapsed-time clock; the gate compares that clock against your organization's internal response-time policy and against the regulatory backdrop of "as soon as practicable," then routes the ticket to a compliant, delayed-but-excepted, or blocked outcome as it exits.
Unlike HIPAA's explicit 30-day (plus 30-day extension) ceiling, the information blocking regulation deliberately does not specify a fixed number of hours or days that always satisfies "as soon as practicable." ONC/ASTP guidance and FAQs instead evaluate timeliness contextually: what technology was available, what the request channel was (real-time API vs. manual fax), and whether any delay reflects an actual, documented exception rather than routine friction.
This simulator's response-time-policy slider stands in for an organization's internal SLA — the number of hours leadership has decided is operationally acceptable. Setting that slider high (e.g., 48–72 hours) does not, by itself, violate the rule, but it steadily narrows the gap between "our policy says this is fine" and "a regulator asks why an EHR capable of instant FHIR responses took three days."
Organizations that rely on certified health IT with FHIR-based patient access APIs are increasingly expected to release records same-day or faster for electronic requests; a policy pegged to the old fax-and-mail era invites scrutiny even if no single request individually looks egregious.
Every ticket that exits the compliance gate lands in one of three states, matching this simulator's color coding:
• Green — compliant: released within a time frame consistent with the policy and with "as soon as practicable," no exception needed • Amber — delayed but exception-covered: the request took longer than the ideal window, but a specific, documented exception (see Stage 2) legitimately justified the delay • Red — non-compliant / blocked: the request exceeded the acceptable window with no valid exception on record — the pattern most likely to be scored as information blocking
A healthy compliance posture is not "zero delays" — some delays are legitimate and expected. A healthy posture is a high green share, a modest and well-documented amber share, and a red share trending toward zero over time, with remediation applied whenever red tickets appear.
A single blocked ticket rarely triggers enforcement on its own. What draws regulatory attention is a pattern: a consistently high red rate, a red rate concentrated against a specific requester category (e.g., competing health systems or third-party apps), or a red rate that does not improve after a prior complaint or audit finding.
Watch the left side of the gate in this simulator. When the response-time-policy slider is pushed toward the slow end, the intake queue drains more slowly than it fills, and tickets visibly stack into a backlog before they ever reach evaluation.
Backlog size is a leading indicator of future red outcomes: every ticket sitting in the stack is accumulating elapsed time, and the longer it waits, the more likely it crosses the gate already past the compliant window, forcing it into amber-if-excepted or red-if-not. Organizations that monitor backlog depth in near real time — rather than only auditing completed requests after the fact — catch compliance risk before it becomes an enforceable pattern rather than after.
A compliant decision that is never recorded is, from a regulator's point of view, indistinguishable from no decision at all. Certified health IT is required to generate detailed audit logs of EHI access events, and those logs — plus periodic attestations — form the evidentiary backbone an organization relies on if ONC/ASTP or OIG ever asks it to demonstrate compliance.
Under the ONC Health IT Certification Program, certified health IT modules must implement audit logging capabilities defined largely under the §170.315(d) privacy-and-security criteria family. In practice, every meaningful EHI event — a record accessed, exported, transmitted via API, or a request declined and why — should generate a timestamped, attributable log entry: who (or what system/application) acted, what record or data element was touched, when, from where, and under what authorization.
In this simulator, each ticket that exits the compliance gate is stamped into a scrolling audit ledger — a stand-in for the real event stream a certified EHR's audit log service would generate. The ledger entry for an amber (exception-covered) ticket carries additional weight: it needs to reference which of the eight exceptions was invoked and the individualized justification, not just the fact that the request was delayed.
Beyond passive logging, actors under the Cures Act framework may be required to attest to their information blocking practices — for example, eligible clinicians and hospitals attesting under CMS's Promoting Interoperability programs that they have not knowingly and unreasonably limited interoperability, and health IT developers attesting as part of Conditions and Maintenance of Certification requirements.
An attestation is only as strong as the audit trail behind it. A compliance program that can produce, on demand, the specific log entries supporting every exception invoked over a review period is in a fundamentally different legal position than one that can only assert "we believe we complied" without contemporaneous records.
In this simulator, Stage 4's ledger visualization is deliberately dense — it is meant to convey that a well-instrumented system produces a high volume of small, boring, individually unremarkable log lines, and that boring, complete, contemporaneous documentation is exactly what a defensible compliance posture looks like.
Audit logs and attestations do not prevent information blocking by themselves — they are what converts a legitimate exception into a defensible one. The same delayed release, identically justified, is a strong exception defense with a complete audit trail and an unsupported assertion without one.
Audit records need integrity protections comparable to the clinical data they describe — §170.315(d) criteria address encryption of audit data at rest and in transit, and expect logs to be resistant to retroactive tampering. A log that could plausibly have been edited after the fact to insert a missing exception justification carries far less evidentiary weight during an investigation.
Retention periods matter too: OIG and ONC/ASTP investigations of information blocking complaints can look back well beyond a typical operational reporting window, so audit trail retention policies are generally set to cover multi-year lookback periods, not just the current fiscal quarter.
Organizations frequently underinvest in this stage relative to Stages 1–3 — it feels like pure overhead until the moment a complaint or audit arrives, at which point it becomes the single most consequential artifact in the entire compliance program.
Every red (blocked) and undocumented amber outcome accumulates into an organization-level regulatory risk score. That score maps onto real financial and program exposure — CMS disincentives for providers, and OIG civil monetary penalties for health IT developers and information networks — and should feed directly back into policy changes that shrink the backlog and raise the compliant share over time.
Enforcement of information blocking splits along actor type. Health IT developers of certified health IT, health information networks, and health information exchanges face OIG civil monetary penalties of up to $1,000,000 per violation — a per-violation exposure that compounds quickly if a practice affected many requests over an extended period.
Health care providers face a different mechanism: rather than direct fines, ONC/ASTP refers provider information blocking determinations to CMS, which applies "appropriate disincentives" through existing programs such as Promoting Interoperability (for eligible hospitals and critical access hospitals) and the Merit-based Incentive Payment System (MIPS, for eligible clinicians) — reducing payment adjustments or reporting scores rather than issuing a direct fine.
Both tracks begin the same way in this simulator's narrative: a pattern of red (blocked) tickets, insufficiently justified amber tickets, or backlog that never clears becomes visible through complaints, audits, or TEFCA-participant reporting, and only then resolves into an actual penalty or disincentive determination.
The regulatory risk score in this simulator rolls up three underlying signals into a single 0–100 gauge: the blocked (red) share of recent tickets, the size and age of the current backlog, and — critically — whether the exception-invocation rate looks like a genuine case-by-case practice or a blanket policy applied indiscriminately.
A low score (roughly 0–30, "Low") reflects a high compliant share, a small backlog, and a moderate, well-documented exception rate. A mid score (30–60, "Medium") usually reflects growing backlog or a rising blocked share that has not yet become a pattern. A high score (60–85, "High") reflects a persistent blocked share or an exception rate so high it looks like avoidance rather than case-by-case judgment. A critical score (85+) reflects sustained, undocumented blocking exactly matching the fact pattern OIG and ONC/ASTP investigations are built to find.
Because both extremes of the exception-invocation-rate slider can raise risk — too low suggests undocumented refusals, too high suggests blanket misuse — the safest operating zone sits in a moderate middle band, not at either edge.
Risk scoring exists to move enforcement upstream: an organization that treats a rising score as an operational trigger for remediation — tightening the response-time policy, retraining staff on exception documentation, clearing backlog — resolves the underlying practice before a complaint is ever filed. Waiting for an actual ONC/ASTP referral or OIG inquiry to react is the highest-cost path in every scenario this simulator can express.
The Trusted Exchange Framework and Common Agreement (TEFCA) adds a nationwide backdrop to all of this: Qualified Health Information Networks (QHINs) connect participants under a common agreement designed to make exchange the default, low-friction path rather than the exception. Organizations that route more requests through QHIN-mediated, API-first exchange structurally reduce their own blocking risk, because standardized, automated fulfillment is much harder to delay inconsistently than manual, case-by-case processing.
Remediation, concretely, means feeding the outcomes of Stages 3 and 5 back into Stage 1 and 2 policy: shortening the response-time-policy target where technology allows it, auditing exception invocations for genuine individualized justification rather than blanket use, investing in the audit-log tooling from Stage 4 so every future exception is defensible, and tracking backlog depth as an operational KPI rather than an after-the-fact surprise.
The organizations that treat this as a continuous loop — intake, classify, release, log, score, remediate, repeat — are the ones whose risk score trends toward the low end over successive quarters rather than spiking reactively after each complaint.