Cures Act Information Blocking Compliance for Health IT
A patient app asks for notes, a hospital wants a full record export and a partner wants an API, and every refusal or delay now needs a reason you can prove. Agnotic Technologies builds the request handling, reason codes and evidence that show your product does not block electronic health information.
Trusted by global innovators
























What is Cures Act information blocking?
Cures Act information blocking is a practice by a health care provider, certified health IT developer, or health information network or exchange that is likely to interfere with access, exchange or use of electronic health information, unless law requires it or an exception applies. Agnotic Technologies builds the software controls that show your product meets the rule.
Decision table
Which exception might apply to a request, and what must you log?
Most requests should simply be fulfilled. When one is not, or is fulfilled differently, the system has to record why. These are common scenarios we design for. Your counsel decides whether an exception applies; the software records the facts they need.
| Request scenario | Exception that may apply | What the system must log |
|---|---|---|
| A patient's app asks for clinical notes through the API | Usually none: release them. Withholding a note needs a documented basis, such as preventing harm | The request, the app, what was released, and any item withheld with its reason code and the clinician who decided |
| A provider asks for a full record export in a format you do not support | Manner exception: offer an alternative manner in the order the rule sets | Format requested, why it could not be met, alternatives offered and the requestor's answer |
| A request arrives during planned maintenance or an outage | Health IT performance exception, for no longer than necessary and applied consistently | The maintenance window, systems affected, notices sent and the time service was restored |
| A clinician believes releasing a result now could harm the patient | Preventing harm exception, based on an individualized judgment by a licensed health care professional | Who made the determination, the basis recorded, the data held back and for how long |
| The requested data cannot be separated from data you may not share | Infeasibility exception, segmentation condition | The reason, and the written response to the requestor within ten business days |
| A developer wants API access and you charge a fee or require a licence | Fees exception and licensing exception | The fee basis, the terms offered and evidence the same terms apply to similar requestors |
This table is engineering guidance, not legal advice. Agnotic Technologies builds the controls; your compliance team and counsel decide how each exception is used.
Who is an actor, and which data must flow?
The rule applies to three kinds of actor and to one defined set of data. Knowing which you are sets the knowledge standard you are judged by and the penalty you face.
Health care providers
Held to the standard of knowing a practice is unreasonable and likely to interfere. A provider found to have blocked faces disincentives applied by CMS, not an OIG fine.
Developers of certified health IT
Held to a knows or should know standard. The OIG can impose civil money penalties, so product decisions about exports, APIs and fees carry real risk.
Health information networks and exchanges
Held to the same knows or should know standard as developers. Network rules, onboarding terms and fees all fall within the rule.
Electronic health information
Electronic PHI that would be in a designated record set, whoever holds it. Psychotherapy notes and information compiled for legal proceedings are excluded.
Exceptions for not fulfilling a request
Preventing harm, privacy, security, infeasibility, health IT performance and protecting care access. Each has conditions that must all be met.
Exceptions for how a request is fulfilled
Manner, fees and licensing, plus the TEFCA manner exception for actors taking part in TEFCA. They govern format, price and terms rather than refusal.
App gallery
View AllWhich software controls show you are not blocking?
The rule is judged on practices, and practices leave traces in software. These are the controls we build so the traces exist and can be found.
Request intake log
Every request for EHI, from patients, apps, providers or partners, is logged with requestor, channel, scope and time, whether it arrives by API, portal or email.
Reason codes
Any delay, refusal or change of format needs a reason code tied to an exception, the person who chose it and a note, so nothing is withheld silently.
Response timers
Timers track open requests and the ten business day written response the infeasibility exception requires, with alerts before it lapses.
Release without artificial delay
Results and notes flow to the portal and API when final, and any hold is a documented, time-limited choice rather than a default setting.
Which rules define information blocking?
Short facts from the regulation, each linked to its primary source.
Information blocking is a practice that, unless required by law or covered by an exception, is likely to interfere with access, exchange or use of electronic health information. Developers, networks and exchanges are held to a knows or should know standard; providers to knowing the practice is unreasonable.
Source: 45 CFR 171.103 (eCFR)Electronic health information means electronic protected health information to the extent it would be included in a designated record set, excluding psychotherapy notes and information compiled in reasonable anticipation of a civil, criminal or administrative action.
Source: 45 CFR 171.102 (eCFR)An actor that does not fulfill a request under the infeasibility exception must, within ten business days of receiving the request, tell the requestor in writing why the request is infeasible.
Source: 45 CFR 171.204(b) (eCFR)The HHS Office of Inspector General may impose a civil money penalty of not more than $1,000,000 per violation for information blocking.
Source: 42 CFR 1003.1410 (eCFR)For health care providers that OIG finds have committed information blocking, CMS disincentives include not being a meaningful EHR user for eligible hospitals, critical access hospitals and MIPS eligible clinicians, and removal from the Medicare Shared Savings Program for at least one year for ACOs.
Source: 45 CFR 171.1001 (eCFR)
Which healthcare standards sit alongside information blocking work?
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Information blocking FAQs
Build compliantly
