Healthcare compliance is no longer an abstract legal concern handled by a department down the hall. In 2026, it is an integration problem. The ONC Cures Act information blocking provisions are fully active. TEFCA (the Trusted Exchange Framework and Common Agreement) is operational with Qualified Health Information Networks exchanging data nationwide. CMS mandates for Patient Access APIs and Provider Directory APIs require FHIR-based endpoints that many organizations still do not have. And your integration engine sits at the center of all of it.
This guide is written for compliance officers who need to understand what their integration team must build, CTOs who need a technical roadmap for compliance, and health system executives who need to quantify the cost and timeline of getting compliant. We will cut through the regulatory jargon and focus on what you actually need to do with your integration infrastructure — specifically your Mirth Connect instance or equivalent integration engine — to meet the requirements of 2026 and beyond.
The stakes are real. Information blocking violations can result in penalties up to $1 million per violation under the Cures Act (ONC, 2024). CMS can impose conditions of participation penalties that threaten Medicare/Medicaid reimbursement. And reputational damage from a compliance finding can cost far more than the fine itself.
The Regulatory Landscape in 2026
Three overlapping regulatory frameworks now govern how healthcare organizations share electronic health information. Understanding how they interact is essential for building a compliant integration strategy.
The ONC Cures Act (21st Century Cures Act)
The information blocking provisions of the Cures Act, active since April 2021, prohibit healthcare providers, health IT developers, and health information exchanges from engaging in practices that are likely to interfere with the access, exchange, or use of electronic health information (EHI). Since October 2022, this applies to all EHI, not just the USCDI data set.
Key implications for integration teams:
- You must be able to respond to data requests from patients, providers, and payers without unreasonable delay.
- Your integration engine must support export of all EHI, not just the data elements you currently exchange.
- Technical limitations that prevent data sharing must be documented and defensible under one of the eight exceptions.
- Merely not having built an interface is not a valid defense if the technology to do so is available.
TEFCA: Trusted Exchange Framework and Common Agreement
TEFCA creates a nationwide infrastructure for health data exchange through a network of Qualified Health Information Networks (QHINs). Think of it as the interstate highway system for health data: QHINs are the highways, and healthcare organizations connect as participants or sub-participants through a QHIN.
TEFCA defines standardized exchange purposes:
- Treatment: Provider-to-provider data exchange for patient care.
- Payment: Data exchange to support claims and payment activities.
- Healthcare Operations: Quality reporting, population health, care coordination.
- Individual Access Services (IAS): Patient-directed data sharing to apps and services of their choosing.
- Public Health: Reporting to public health agencies.
- Government Benefits Determination: Data exchange for benefits eligibility.
For integration teams, TEFCA means your systems must be capable of receiving and responding to queries from external organizations through your QHIN. This is not optional if your organization participates in TEFCA, and participation is increasingly becoming a practical requirement for organizations that exchange data with multiple partners.
CMS Mandates
CMS has issued a series of final rules requiring specific FHIR-based APIs:
- Patient Access API (CMS-9115-F): Health plans must make claims and clinical data available to patients through a FHIR R4 API. Hospitals and providers must support patient access under the Cures Act.
- Provider Directory API: Health plans must maintain a FHIR-based provider directory accessible to patients and other plans.
- Payer-to-Payer API (CMS-0057-F): When a patient switches health plans, the new plan can request the patient's data from the old plan through a standardized FHIR API. Effective January 2026.
- Prior Authorization API (CMS-0057-F): Payers must support electronic prior authorization through FHIR-based APIs. Phased implementation through 2027.
What TEFCA Means for Your Integration Strategy
TEFCA is not a product you buy. It is a framework you participate in. Your integration strategy must account for how your organization connects to the TEFCA network and what data you need to be able to exchange.
Connecting Through a QHIN
Organizations do not connect directly to TEFCA. They connect through a Qualified Health Information Network. As of 2026, designated QHINs include organizations like CommonWell Health Alliance, eHealth Exchange, Epic's Carequality implementation, KONZA, MedAllies, and others. Your choice of QHIN depends on your existing network relationships and technical capabilities.
Most QHINs require participants to support FHIR R4 for data exchange. This means your integration engine must be able to:
- Receive inbound FHIR queries and return appropriate responses.
- Send outbound FHIR requests to retrieve data from other participants.
- Transform between your internal data formats and FHIR resources.
- Maintain audit logs of all exchanges for compliance reporting.
If your current integration architecture is purely HL7v2-based, you need a FHIR translation layer. This is where your integration engine — Mirth Connect or equivalent — becomes the compliance bridge. For background on how these standards relate, see our guide on interoperability standards in healthcare.
Information Blocking: What It Is and What It Is Not
Information blocking is any practice by a healthcare provider, health IT developer, or health information exchange that is likely to interfere with the access, exchange, or use of EHI, except as required by law or covered by one of the eight exceptions.
The Eight Exceptions
The ONC has defined eight exceptions. If your practice fits within one of these exceptions and meets all its conditions, it is not information blocking:
- Preventing Harm: You may restrict access if sharing would endanger a patient or another person. Requires a case-by-case determination by a licensed healthcare professional.
- Privacy: You may decline to share data if doing so would violate applicable privacy laws (HIPAA, state laws, patient consent). But you must share if privacy conditions are met.
- Security: You may implement security practices that limit access, provided they are tailored, applied consistently, and do not exceed what is necessary.
- Infeasibility: You are not required to share if it is technically infeasible, but you must demonstrate that you have made reasonable efforts and the infeasibility is not self-created.
- Health IT Performance: You may temporarily restrict access to maintain system performance or availability, provided the restriction is no broader than necessary.
- Content and Manner: You may offer data in a different format or through a different method than requested, provided you offer a reasonable alternative.
- Fees: You may charge reasonable fees for data access, provided they are based on objective, verifiable criteria and do not discriminate.
- Licensing: You may require licensing for interoperability elements, provided the terms are reasonable and non-discriminatory.
What Constitutes Blocking in Practice
For integration teams, the most common compliance risks are:
- Not building requested interfaces: A referral partner requests a data feed and you delay for months without a valid reason. This can constitute blocking.
- Restricting API access: Your EHR has a FHIR API capability, but you have not enabled or configured it. The capability exists but is not available.
- Excessive conditions: Requiring extensive legal agreements, excessive fees, or unreasonable technical requirements that effectively prevent sharing.
- Blocking by omission: Not having the technical infrastructure to share data when the technology is readily available. Ignorance or underinvestment is not a defense.
How Your Integration Engine Fits into Compliance
Your integration engine is the central nervous system of your health data exchange infrastructure. It touches every compliance requirement because it is the system that actually moves, transforms, and delivers data between systems.
Audit Trail Requirements
Every data exchange must be auditable. You must be able to answer: Who requested this data? When? What was sent? Was access granted or denied? Why?
Your integration engine provides the foundation for this audit trail:
- Message logs: Every message processed by Mirth Connect is logged with timestamps, source, destination, and status.
- Channel statistics: Message volumes, error rates, and processing times are tracked per channel.
- Error queues: Failed messages are preserved for investigation and reprocessing.
However, the default logging in most integration engines is insufficient for compliance. You need additional infrastructure for proper audit reporting. See our monitoring guide for details on building comprehensive logging.
FHIR Endpoint Requirements
CMS mandates require specific FHIR R4 endpoints. Your integration engine can serve as the FHIR translation layer between your internal systems and external FHIR consumers:
- Patient Access API: Expose patient data (conditions, medications, allergies, lab results, procedures) as FHIR resources accessible via RESTful API.
- Provider Directory: Maintain a FHIR-based directory of your organization's providers, locations, and services.
- Bulk Data Export: Support FHIR Bulk Data Export (
$export) for population-level data access requests.
What Mirth Connect Provides for Compliance
Mirth Connect has several features that directly support compliance requirements, though they require proper configuration and additional components.
Channel Audit Logs
Every message processed through a Mirth channel is logged. Channel statistics track message volumes, processing times, and error rates. With proper configuration, you can maintain a complete record of every data exchange.
FHIR Transformation Capability
Mirth Connect can transform between HL7v2 and FHIR R4 formats. This is critical for organizations that run HL7v2 internally but need FHIR endpoints for external compliance. The FHIR Connector (available in Mirth Connect 4.x) provides native FHIR client and listener capabilities. Understanding when you need both HL7 and FHIR is essential for planning your compliance architecture.
Message Routing and Filtering
Compliance requires that data requests are routed to the correct handler and that data is filtered based on consent, authorization, and applicable law. Mirth's routing and filtering capabilities provide the foundation for this, but business rules for consent and authorization must be implemented in your transformation logic.
Configurable Error Handling
When a data exchange fails, compliance requires that you document the failure and take reasonable steps to resolve it. Mirth's error handling channels, dead letter queues, and alerting capabilities support this requirement.
What You Still Need to Build
The integration engine provides the plumbing, but compliance requires additional components that most organizations must build or procure separately.
Consent Management
TEFCA and the Cures Act both require that data sharing respect patient consent preferences. This means:
- A consent management system that records patient preferences for data sharing.
- Integration between your consent system and your data exchange infrastructure so that consent is checked before data is released.
- Support for granular consent (e.g., share lab results but not mental health records) where required by state law.
- Audit logging of consent decisions (consent given, consent revoked, consent checked at time of exchange).
Compliance Reporting Dashboard
You need a dashboard that answers compliance questions at a glance:
- How many data requests were received this month? How many were fulfilled? How many were denied?
- What is the average response time for data requests?
- Are there pending requests that exceed the reasonable response window?
- Which data types are most frequently requested and exchanged?
- Are there patterns of access denial that might indicate blocking?
Patient Access Portal
Patients must be able to access their data through your FHIR API. This typically requires a patient-facing portal or app that authenticates patients and connects to your FHIR endpoints. SMART on FHIR is the standard authorization framework for patient access applications.
Security Infrastructure
FHIR API endpoints must be secured with:
- OAuth 2.0 / SMART on FHIR authorization.
- TLS 1.2+ encryption for all data in transit.
- Rate limiting and abuse prevention.
- API key management for system-to-system access.
- Audit logging of all access attempts (successful and failed).
Common Compliance Gaps
Based on ONC compliance assessments and industry audits, these are the most frequently cited gaps:
- No FHIR endpoints exposed: The EHR supports FHIR, but the organization has not configured or enabled the APIs. This is the most common gap and the easiest to close.
- No audit trail for data requests: The organization cannot demonstrate that it received a data request, processed it, and responded within a reasonable timeframe.
- Blocking by omission: The organization does not have the integration infrastructure to share data with certain partners and has not taken steps to build it.
- Consent not integrated with exchange: Consent preferences are recorded on paper or in a system that is not connected to the integration layer. Data is shared without consent checks or blocked without consent verification.
- Incomplete USCDI coverage: The organization can share some USCDI data elements but not all. Missing elements are not documented with a valid reason.
- No bulk data export capability: Required for population-level access requests and payer data exchange. Many organizations have not implemented the FHIR Bulk Data Export specification.
Cost of Non-Compliance
The financial exposure from non-compliance operates on multiple levels:
- Direct penalties: Information blocking violations can result in civil monetary penalties of up to $1 million per violation for health IT developers and health information exchanges. For providers, the penalty framework includes disincentive mechanisms through CMS programs.
- CMS program penalties: Non-compliance with CMS API mandates can affect conditions of participation, potentially impacting Medicare/Medicaid reimbursement — the financial lifeline for most healthcare organizations.
- OIG investigations: The Office of Inspector General (OIG) has authority to investigate information blocking claims. Investigations are costly even when they do not result in penalties.
- Reputational damage: Public reporting of compliance failures damages relationships with patients, referral partners, and payers.
- Lost business: Payers and referral partners increasingly require FHIR API capabilities as a condition of partnership. Organizations without these capabilities lose contracts.
A 2024 AMA survey found that 34% of health systems reported receiving at least one information blocking complaint from a patient or partner organization. Of those, 18% resulted in formal investigation or audit activity. The average cost of responding to an information blocking investigation was estimated at $85,000-$150,000 in legal fees, staff time, and remediation costs.
Practical Implementation Steps
Here is a quarterly roadmap for achieving compliance through your integration infrastructure:
Q1: Assessment and Quick Wins
- Audit current FHIR capabilities across all systems (EHR, integration engine, data warehouse).
- Identify and enable any FHIR endpoints that are available but not configured.
- Review and document all active data sharing agreements and integration interfaces.
- Implement audit logging for all data exchange transactions if not already in place.
- Assess USCDI coverage: which data elements can you share today?
Q2: FHIR API Development
- Deploy FHIR R4 endpoints for Patient Access API (if not provided by your EHR vendor).
- Build HL7v2-to-FHIR translation channels in Mirth Connect for data elements not natively available in FHIR from your EHR. For technical guidance, see turning HL7v2 streams into FHIR APIs.
- Implement SMART on FHIR authorization for patient-facing API access.
- Begin consent management system integration.
Q3: TEFCA Preparation
- Select a QHIN partner and begin onboarding process.
- Implement TEFCA-required exchange patterns (query/response, push notifications).
- Build compliance reporting dashboard.
- Test data exchange with QHIN partner in sandbox environment.
Q4: Monitoring and Optimization
- Deploy production TEFCA connectivity.
- Implement ongoing compliance monitoring with automated alerts for potential blocking scenarios.
- Conduct internal audit of all data exchange practices against information blocking criteria.
- Establish quarterly compliance review process.
Building interoperable healthcare systems is complex. Our Healthcare Interoperability Solutions team has deep experience shipping production integrations. We also offer specialized Healthcare AI Solutions services. Talk to our team to get started.
Frequently Asked QuestionsDoes TEFCA participation require us to share data with anyone who asks?
No. TEFCA defines specific exchange purposes (treatment, payment, operations, individual access, public health, government benefits). You only share data for authorized purposes, and all exchanges must comply with applicable law (HIPAA, state privacy laws). The eight information blocking exceptions still apply. However, you must be technically capable of responding to valid requests within a reasonable timeframe. For more context on how data exchange standards work together, see our article on true interoperability in fragmented data.
Can we use the "infeasibility" exception to delay compliance?
Technically yes, but the bar is high. You must demonstrate that you made reasonable efforts to comply, that the infeasibility is not self-created (i.e., you did not refuse to invest in the necessary technology), and that you are taking steps to resolve the infeasibility. "We have not budgeted for it" or "our vendor does not support it" are weak defenses if the technology is commercially available and within your financial means.
What happens if our EHR vendor does not support FHIR R4?
Your vendor's limitations do not absolve you of compliance obligations. You must take reasonable steps to fill the gap. This is where your integration engine becomes critical: Mirth Connect can serve as a FHIR translation layer, accepting HL7v2 or proprietary data from your EHR and exposing it as FHIR R4 endpoints. This is not a permanent solution — you should pressure your vendor for native FHIR support — but it demonstrates good faith compliance efforts.
How does information blocking apply to data we receive from other organizations?
If you receive data that a patient or authorized party then requests, you generally must make it available. You cannot refuse to share data simply because you received it from an external source. However, you should verify that sharing is consistent with the original consent and applicable privacy laws.
What is the realistic cost of achieving compliance for a mid-size health system?
For a mid-size health system (3-10 hospitals, 50-200 physicians), expect to invest $300,000-$800,000 in integration infrastructure for compliance over 12-18 months. This includes FHIR API development, consent management integration, audit infrastructure, TEFCA onboarding, and testing. Ongoing operational costs add $100,000-$200,000 per year for maintenance, monitoring, and compliance reporting. These costs are a fraction of the potential penalty exposure and are increasingly recognized as necessary operating expenses.
The Bottom Line
Compliance is an integration problem. TEFCA, the Cures Act, and CMS mandates all require that healthcare organizations exchange data electronically, in standardized formats, with documented audit trails, and without unreasonable barriers. Your integration engine — whether it is Mirth Connect, Rhapsody, or another platform — sits at the center of this compliance infrastructure.
The organizations that treat compliance as a one-time project will find themselves perpetually behind. Regulations are expanding: USCDI grows annually, TEFCA exchange purposes are broadening, and CMS is adding new API requirements with each rulemaking cycle. The organizations that build a flexible, well-governed integration architecture today will adapt to new requirements efficiently. Those that build the minimum viable compliance infrastructure will rebuild every time the regulations change.
Start with the assessment. Know what you have, know what you need, and build a roadmap that addresses the highest-risk gaps first. The regulatory timeline is clear. The requirements are published. The technology exists. The only question is whether your organization will invest in compliance proactively or reactively — and reactive compliance always costs more.
