Healthcare interoperability has three distinct regulatory frameworks that apply to API design, and they overlap in ways that create compliance complexity. The ONC's information blocking regulations (45 CFR Part 171) require that certified health IT systems make patient data available through standardised APIs without interfering with access. SMART on FHIR defines the authorisation framework those APIs must use. HIPAA defines the privacy and security requirements that govern the data the APIs expose. Satisfying all three simultaneously requires deliberate architecture decisions — and the failure modes are specific and well-documented.
Information Blocking: What It Actually Prohibits
The 21st Century Cures Act's information blocking prohibition is broader than most engineering teams realise. It prohibits practices that are likely to interfere with, prevent, or materially discourage access, exchange, or use of Electronic Health Information (EHI). The prohibition applies to health IT developers of certified health IT, health information exchanges, and health information networks. The most common engineering mistake that creates information blocking liability is response rate limiting or throttling that is not technically justified. If an API limits patient app requests for cost management reasons rather than technical necessity, that is potentially information blocking. Requiring patients to use the provider's own patient portal instead of a third-party app they prefer is also information blocking.
The $1 million per violation penalty for information blocking applies to health IT developers. This is distinct from HIPAA penalties, which apply to covered entities and business associates. A health IT vendor that designs APIs in ways that restrict patient data access can face information blocking penalties independent of HIPAA enforcement. Most FHIR API design reviews focus on technical correctness and security; few include an information blocking review. Both are required.
SMART on FHIR Authorization
SMART on FHIR defines the OAuth 2.0 authorization framework for FHIR APIs. ONC's certification criteria require support for SMART on FHIR for patient-facing apps. The critical compliance requirement is patient-granular authorization: a patient-authorised application must receive scopes limited to that patient's data, and the FHIR server must enforce those scope restrictions at the data layer. A common implementation gap is implementing SMART on FHIR at the application layer while the underlying FHIR server enforces access controls at the organisation level — the server accepts the token and returns all records matching search parameters without validating that the patient in the record matches the patient in the token scope. The access control enforcement must be at the FHIR server resource level, not the application level.
HIPAA and Information Blocking Together
HIPAA's minimum necessary standard requires that access to PHI be limited to the minimum necessary for the intended purpose. The information blocking rules require that access to EHI not be interfered with. The reconciliation is in the authorisation framework: SMART on FHIR scopes provide the mechanism to request and grant access to specific data elements, allowing the patient to authorise exactly the access the third-party app needs. The FHIR server enforces both HIPAA minimum necessary (by returning only what the authorised scope permits) and information blocking compliance (by not imposing additional restrictions beyond what the patient chose not to authorise).
Common FHIR API Designs That Create Information Blocking Liability
- Requiring patients to call a support number to obtain a "registration code" before authorising a third-party app — this creates a barrier to access
- Returning a 429 Too Many Requests response to patient-authorised apps at normal access rates without documented technical justification
- Requiring patient apps to use a proprietary API endpoint instead of the standard FHIR R4 endpoint
- Returning incomplete data from the standardised API endpoint while providing complete data through the provider's own portal — this is differential access
- Audit the FHIR API against information blocking criteria specifically — separate from the HIPAA security review
- Enforce SMART on FHIR scopes at the FHIR server resource level, not the application layer — verify this with scope-violation test cases
- Justify any rate limiting or throttling with documented technical grounds — cost management is not a valid justification under information blocking rules
- Test patient-authorised app workflows end-to-end including the authorization flow — do not test only the API responses
- Review response completeness against the EHI definition in 45 CFR 171.102 — the standardised API must return all EHI, not a subset
- Include an information blocking review in the pre-launch compliance checklist alongside the HIPAA security review
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.