Information Blocking Rule & HIPAA: ONC Interoperability Guide

Regulatory Background

The Information Blocking Rule (21st Century Cures Act Section 4004) prohibits healthcare providers, health information networks, and health information exchanges from blocking or unreasonably interfering with the exchange or use of electronic health information (EHI). Administered by the Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS), the rule aims to promote healthcare interoperability and patient access to their electronic health information. The rule is closely integrated with HIPAA but creates separate regulatory obligations and enforcement mechanisms.

Legislative Intent

Congress enacted the information blocking provisions to address documented cases where healthcare organizations were restricting patient access to records or preventing data exchange with other healthcare providers as a business practice. The rule ensures that patients have unfettered access to their health information and that the healthcare system can exchange data efficiently.

                Key Context: While HIPAA governs privacy and security of health information, the Information Blocking Rule focuses on ensuring that health information is readily available and exchangeable. The two regulations complement each other: HIPAA protects how data is handled, while the Information Blocking Rule ensures the data is accessible.
            

Specific Information Blocking Provisions

Definition of Information Blocking

The rule prohibits practices, workflows, or technologies that reasonably result in:

Preventing access, exchange, or use of electronic health information (EHI)
Limiting the ability of individuals to access, exchange, or use their EHI
Interfering with interoperability or data exchange capabilities
Fragmenting or preventing the use of interoperable health information

Prohibited Practices

The rule specifically prohibits:

Unreasonable Fees: Charging excessive fees that prevent or substantially impede access to EHI
Delays: Delaying disclosure of EHI beyond reasonable timeframes
Technical Restrictions: Using technical means to prevent access or exchange
Fragmentation: Preventing the exchange of complete health records
Contractual Restrictions: Using contracts to prevent data exchange or interoperability
API Restrictions: Limiting access to or functionality of Application Programming Interfaces (APIs)
Standards Non-Compliance: Refusing to implement required interoperability standards

Required Interoperability Standards and Methods

Healthcare organizations must support specific standards for data exchange:

FHIR API Requirements

FHIR R4 Compliance: Implement Fast Healthcare Interoperability Resources (FHIR) Release 4 APIs
Patient Access: Enable patients to access their EHI via FHIR APIs
Third-Party Apps: Allow patient-authorized third-party applications to access EHI through APIs
Provider Directory: Maintain and make available provider information through FHIR format
Response Times: API requests must be responded to within specified timeframes (typically 30 seconds or less)

Electronic Exchange Standards

Direct Secure Messaging: Support Direct for secure point-to-point communication
RESTful APIs: Implement REST-based APIs for data exchange
HL7 Standards: Use Health Level 7 (HL7) messaging standards for clinical data exchange
CCDA Format: Support Clinical Document Architecture (C-CDA) for clinical summaries

Patient Right to Copies

Electronic Format: Provide EHI to patients in electronic, downloadable format
Format Options: Offer format options including standards-based formats (.txt, .pdf, HL7)
Timely Delivery: Deliver copies without unreasonable delay
No Unreasonable Fees: Charge reasonable fees only for actual copy costs

Enforcement and Exceptions

Enforcement Authority

Enforcement of the Information Blocking Rule is divided among federal agencies, with different mechanisms applying to health IT developers, health information networks and healthcare providers. Confirm which agency and which mechanism applies to your organization before relying on any specific enforcement path.

Penalties

Civil Monetary Penalties: Actors found to have engaged in information blocking may be subject to civil monetary penalties
Corrective Action: Corrective action plans may be required of certified health IT developers through the health IT certification program
Provider Disincentives: Healthcare providers found to have engaged in information blocking may be subject to established disincentives under federal healthcare programs
Published Determinations: Determinations of information blocking may be published by the enforcing agency

Exceptions to Information Blocking Prohibition

The rule provides limited exceptions when information blocking may be permissible:

Privacy and Security: Actions reasonably necessary to protect privacy or security, if documented
Legal Requirements: Actions required by applicable law (court orders, law enforcement requests)
Infeasibility: Inability to provide access due to technical infeasibility (with documentation)
Reasonable Licensing: Reasonable licensing of health IT capabilities
EHR Enforcement: Actions taken by certified EHR developer to protect EHR functionality

Burden of Proof

The regulation assumes information blocking occurred if practices reasonably result in blocking. The organization must prove the exception applies and was properly documented.

Implementation Guidance

System and Technology Assessment

Interoperability Audit: Assess current systems for FHIR, Direct, and HL7 compliance
API Inventory: Document all APIs exposing EHI and verify FHIR compliance
Integration Review: Evaluate health information exchange (HIE) connections and standards used
Vendor Assessment: Verify EHR and technology vendors support required interoperability standards
Performance Testing: Test API response times and functionality

Policy and Procedure Development

Establish information blocking prevention policy
Document procedures for patient EHI access requests
Create procedures for third-party app authorization and API access
Develop fee structure policy (limiting fees to actual costs)
Document any exceptions claimed and supporting justification
Create policies for managing third-party developer access to APIs

Technical Implementation

Implement or upgrade to FHIR R4 compliant APIs
Ensure APIs support required clinical data elements
Implement authentication mechanisms protecting patient privacy
Configure APIs for acceptable response times (30 seconds or better)
Provide patient portal access to download EHI in multiple formats
Support Direct secure messaging for provider-to-provider exchange

Patient Access Process

Establish clear process for patients requesting EHI access
Provide multiple access methods (portal, API, media)
Offer data formats aligned with ONC standards
Provide rapid access without unreasonable delays
Charge only reasonable, cost-based fees
Allow patients to authorize third-party application access

Monitoring and Compliance

Monitor API usage and performance
Track patient access requests and fulfillment times
Review denial requests for valid exceptions
Audit fee assessments for reasonableness
Maintain documentation of all exceptions claimed
Conduct periodic reviews of interoperability capabilities

Exception Documentation

If claiming an exception to information blocking prohibition, documented must include:

Specific practice or policy claimed as exception
Detailed explanation of why exception applies
Supporting evidence and technical documentation
Dates of implementation and any changes
Person(s) responsible for maintaining compliance

Frequently Asked Questions

Does our organization need to implement a patient portal?

While the Information Blocking Rule doesn't explicitly require a patient portal, it requires that patients have electronic access to their EHI. A patient portal is a practical way to provide this access and is increasingly expected. Alternative methods include providing EHI on a USB drive, CD, or through email, but a portal is more patient-friendly and typically more practical. If your EHR vendor offers a patient portal, implementing it is advisable for compliance and avoiding information blocking accusations. The portal must allow patients to access, download, and transmit their EHI to third-party applications of their choice.

Can we charge for patient access to their EHI?

You can charge reasonable fees only for the actual cost of copying and delivering EHI. However, fees must not prevent or substantially impede access. For electronic copies in standard formats, fees should be minimal or nonexistent since the cost is negligible. For paper copies, you can charge for actual copying costs and postage. You cannot charge for "research," data compilation, or other inflated fees. If patients cannot afford fees, consider waiving them. Excessive fees that effectively prevent access violate the information blocking prohibition and can result in ONC enforcement actions and significant penalties.

What does FHIR compliance mean in practice?

FHIR (Fast Healthcare Interoperability Resources) Release 4 is a modern standard for exchanging healthcare data using REST APIs and JSON format. FHIR compliance means: (1) Your APIs conform to FHIR R4 specifications, (2) Clinical data elements are mapped to appropriate FHIR resources, (3) APIs respond within required timeframes, (4) APIs support standard authentication mechanisms, and (5) Patients and authorized third parties can access data through your FHIR APIs. Your EHR vendor should handle most of the technical FHIR implementation. Your role is ensuring your organization supports patient API access, configures your system to expose appropriate data, and monitors API availability and performance. Contact your vendor about their FHIR capabilities and timeline to full R4 compliance if not yet achieved.

How do we authorize third-party applications to access patient data?

The Information Blocking Rule requires supporting patient-authorized third-party application access to EHI. This means: (1) Patients can authorize apps (fitness trackers, personal health records, etc.) to connect to your APIs and access their data, (2) Your system uses standard authorization mechanisms like OAuth 2.0 to manage app access, (3) Patients retain control and can revoke app access at any time, (4) Your system requires patients to explicitly authorize each app before granting access, and (5) App access is limited to data the patient has authorized. Most modern patient portals support this through API app authorization features. Your EHR should provide developer documentation and tools for third parties to integrate with your FHIR APIs. Supporting third-party app integration demonstrates non-blocking compliance and provides value to patients by expanding their options for managing their health information.

Ensure Interoperability Compliance

Medcurity helps healthcare organizations assess information blocking risk, implement FHIR APIs, and ensure patient data accessibility in compliance with ONC requirements.

Assess Your Interoperability Status