Information Blocking Prohibition
The 21st Century Cures Act prohibition that makes interfering with health data access a federal offense — and the eight exceptions that define the boundaries of permissible restriction.
The information blocking prohibition at 45 CFR Part 171 (implementing 42 U.S.C. § 300jj-52) applies to three categories of actors: health IT developers of certified health IT, health information exchanges (HIEs), health information networks (HINs), and healthcare providers. A practice constitutes information blocking if the actor knows or should know it is unreasonable and is likely to interfere with the access, exchange, or use of electronic health information (EHI). EHI is defined as all individually identifiable health information in electronic form — broader than HIPAA's PHI as it includes information without a treatment relationship. ONC has established eight exceptions: Preventing Harm, Privacy (aligned to HIPAA and other privacy laws), Security, Infeasibility, Health IT Performance, Content and Manner, Fees, and Licensing. For each exception to apply, the actor must meet all conditions of the exception — partial compliance provides no safe harbor. Penalties for information blocking can reach $1 million per violation for health IT developers and HIEs/HINs; providers face referral to CMS for appropriate action.
The engineering implications of information blocking are pervasive. The Content and Manner Exception permits actors to respond to EHI requests using alternative content or manner (e.g., returning a summary rather than specific records) only temporarily and only when they are working toward full response capability — it is not a permanent carve-out for technical limitations. The Fees Exception permits charges for accessing EHI through non-certified API mechanisms but prohibits fees for certified API access under § 170.315(g)(10) unless specific conditions are met. The Security Exception permits implementing security measures that interfere with access only when the practice is consistent with published industry guidelines and applied consistently — security theater (blocking based on security justifications without genuine security basis) is not protected. Common engineering decisions that can constitute information blocking: deploying FHIR APIs with arbitrary rate limits that effectively prevent access, designing data export formats that are difficult to parse, requiring manual steps to initiate API access, or conditioning API access on signing agreements that restrict downstream use.
The information blocking prohibition creates a new enforcement dynamic for health IT vendors: ONC can receive complaints from any person, including competing vendors, patients, and advocacy organizations. ONC publishes complaint statistics, and enforcement actions create reputational exposure even when penalties are not assessed. The Privacy Exception is the most frequently invoked but most narrowly defined: it permits restrictions only when consistent with a directly applicable privacy law, and HIPAA's permissive standard (HIPAA "permits" many disclosures but does not require them) means that choosing not to disclose under a HIPAA permission does not automatically satisfy the Privacy Exception unless the restriction is required by state or federal law. For platforms aggregating data from multiple provider EHRs via FHIR APIs, the information blocking obligations of their upstream data sources create a complex web of obligations and rights that must be documented and contractually allocated.
We conduct information blocking risk assessments as part of health IT architecture reviews, systematically evaluating each data access restriction against the eight ONC exceptions and documenting the legal and technical basis for each practice. Our FHIR API implementations are built to maximize access by default — rate limits based on documented capacity constraints rather than policy preferences, authentication flows minimizing special effort, and API documentation publicly available. We build exception documentation templates that provide defensible records of which exception applies to each access restriction and why all conditions of the exception are satisfied.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.