TEFCA in 2026: Technical Integration Guide

The Trusted Exchange Framework and Common Agreement (TEFCA) has gone from an ambitious policy idea to the backbone of nationwide health data exchange in just over two years. Since its launch in December 2023, TEFCA has grown from a handful of connected organizations to more than 12,130 organizations exchanging data through 72,000+ unique connection points. Nearly 500 million health records have been exchanged through the network as of early 2026, up from roughly 10 million in January 2025---a staggering 4,900% increase in a single year.

For healthcare IT teams, the message is clear: TEFCA is no longer something you can watch from the sidelines. Whether you are a health system, a health information exchange, a payer, or a technology vendor, understanding how to connect to and operate within TEFCA is now a core competency. This guide covers everything you need to know to plan, architect, and execute a TEFCA integration in 2026.

What Is TEFCA?

TEFCA stands for the Trusted Exchange Framework and Common Agreement. It was established by the 21st Century Cures Act of 2016, which directed the Office of the National Coordinator for Health Information Technology (now the Assistant Secretary for Technology Policy, or ASTP) to develop a framework for trusted nationwide health data exchange.

The framework has two components:

• Trusted Exchange Framework (TEF): A set of non-binding principles for health information exchange, including standardized terms and conditions that govern how data is shared.
• Common Agreement (CA): A legally binding agreement that operationalizes the TEF. Organizations that sign the Common Agreement commit to a uniform set of technical, privacy, and security requirements.

The Sequoia Project serves as the Recognized Coordinating Entity (RCE), responsible for administering the Common Agreement, onboarding Qualified Health Information Networks (QHINs), and managing the day-to-day operations of TEFCA. The current version of the Common Agreement is version 2.1, published in November 2024, which introduced requirements for Facilitated FHIR exchange alongside the existing document-based modalities.

The core purpose of TEFCA is deceptively simple: create a single “on-ramp” to nationwide health data exchange. Before TEFCA, organizations that wanted to exchange data across networks had to negotiate individual agreements with each network, often navigating incompatible technical standards and legal frameworks. TEFCA replaces that fragmented landscape with a single agreement and a set of standardized exchange modalities.

Is TEFCA Mandatory?

This is one of the most common questions in healthcare IT, and the answer is nuanced. As of March 2026, TEFCA participation is technically voluntary. No federal regulation currently requires a healthcare organization to become a QHIN, Participant, or Sub-Participant.

However, several regulatory and market forces are making TEFCA participation a practical necessity:

HTI-2 Final Rule. Published by ASTP (formerly ONC), the HTI-2 Final Rule establishes governance and appeal rights for QHINs and lays the groundwork for more direct regulatory integration of TEFCA. While HTI-2 does not mandate TEFCA participation, it signals the federal government’s intent to make TEFCA a central component of the national interoperability strategy.

CMS Interoperability and Prior Authorization Final Rule (CMS-0057). This rule requires Medicare Advantage plans, Medicaid managed care plans, CHIP plans, and Qualified Health Plan issuers on the federal exchange to implement FHIR-based APIs for patient access and provider data exchange. Many payers are choosing to meet these requirements through TEFCA connectivity rather than building bespoke interfaces.

Competitive pressure. As more organizations join TEFCA, those that remain outside the network face a widening interoperability gap. Referral networks, care coordination agreements, and payer contracts increasingly expect TEFCA connectivity.

State-level mandates. Some states are exploring or implementing requirements for health information exchange participation that align with TEFCA. Organizations operating across state lines will find TEFCA participation simplifies compliance with a patchwork of state regulations.

The practical reality is that TEFCA is becoming a de facto requirement for most health systems, payers, and health IT vendors. Organizations that have not started planning for TEFCA connectivity by 2027-2028 will likely find themselves at a significant competitive and regulatory disadvantage.

The 11 Designated QHINs

As of early 2026, the RCE has designated 11 Qualified Health Information Networks. Each QHIN has signed the Common Agreement and completed the rigorous onboarding process, which includes demonstrating technical readiness, security compliance, and operational capacity.

Here is the current list of designated QHINs, along with their key characteristics:

QHIN	Organization Type	Primary Focus	Notable Reach
eHealth Exchange	National HIE network	Cross-network interoperability	100+ million patients; federal agencies including VA and DoD
CommonWell Health Alliance	Alliance of EHR vendors	Provider-to-provider exchange	Broad EHR vendor participation (athenahealth, MEDITECH, Oracle Health)
Kno2	Health IT company	Direct messaging and document exchange	Strong in small/mid-size provider market
KONZA National Network	State-designated HIE	Rural and underserved communities	Kansas-based with national reach
MedAllies	Health IT services	HIE and health IT infrastructure	Northeast US; strong in provider connectivity
Health Gorilla	Diagnostics network	Lab and diagnostic data exchange	300,000+ provider locations; diagnostics focus
Epic Nexus	EHR vendor network	Epic-to-Epic and cross-network exchange	Carequality backbone; 300M+ patient records
Availity	Revenue cycle / payer network	Payer-provider data exchange	2M+ providers connected; payer-side strength
Verato	Identity resolution	Patient matching and identity management	eMPI and identity services across networks
Surescripts	Prescription network	Medication data exchange	Virtually all US pharmacies; prescriber network
Oracle Health Information Network	EHR vendor network	Oracle Health (Cerner) ecosystem connectivity	Large hospital and health system footprint

Several additional organizations remain in the Candidate QHIN pipeline and are expected to receive designation in 2026 and beyond. The QHIN application process remains open on a rolling basis.

Choosing a QHIN

The QHIN you connect through matters. Different QHINs have different strengths, connectivity footprints, and pricing models. Key factors to evaluate include:

• Existing relationships. If your organization already connects to a network like eHealth Exchange or CommonWell, connecting through that network’s QHIN may be the fastest path.
• EHR vendor alignment. Epic customers may find that Epic Nexus provides the most seamless connectivity. Organizations on Oracle Health may gravitate toward the Oracle Health Information Network.
• Use case fit. If your primary need is payer-provider data exchange, Availity’s payer-side connectivity is a differentiator. If patient matching is your biggest challenge, Verato’s identity resolution capabilities may add value.
• Geographic reach. Some QHINs have stronger connectivity in specific regions. Evaluate which QHIN provides the best coverage for your referral network and patient population.

Connection Pathways

TEFCA defines three levels of participation, each with different technical requirements, legal obligations, and operational responsibilities.

QHIN (Qualified Health Information Network)

Becoming a QHIN is the most demanding pathway. QHINs sign the Common Agreement directly with the RCE and take on full responsibility for routing queries, managing Participants and Sub-Participants, and enforcing compliance. This pathway is appropriate for large health information exchanges, national networks, and major EHR vendors.

Requirements include:

• Full technical infrastructure for all supported exchange modalities
• 24/7 operational monitoring and incident response
• Comprehensive security program meeting TEFCA security requirements
• Ability to onboard and manage Participants and Sub-Participants
• Financial capacity for ongoing compliance and operations

Timeline: 6-12+ months from application to designation, depending on organizational readiness.

Participant

Participants connect to TEFCA through a QHIN under a Participant-QHIN Agreement. Participants take on moderate technical and compliance responsibilities and can onboard their own Sub-Participants. This pathway is appropriate for large health systems, regional HIEs, and technology vendors that serve multiple provider organizations.

Requirements include:

• Technical connectivity to the QHIN’s infrastructure
• Compliance with the Common Agreement’s privacy and security requirements
• Ability to support the exchange modalities offered by the QHIN
• Patient matching capabilities that meet TEFCA standards

Timeline: 3-6 months from agreement execution to go-live, depending on technical readiness and the QHIN’s onboarding process.

Sub-Participant

Sub-Participants connect through a Participant under a Sub-Participant Agreement. This is the lowest barrier to entry and is appropriate for individual hospitals, clinics, physician practices, and smaller technology vendors.

Requirements include:

• Technical connectivity to the Participant’s infrastructure (often through existing EHR or HIE connections)
• Compliance with applicable privacy and security requirements
• Support for the data elements and exchange modalities required by the Participant

Timeline: 1-3 months from agreement execution to go-live. In many cases, Sub-Participants can leverage existing technical infrastructure with minimal modifications.

Decision Framework

Use the following guidelines to determine which pathway is right for your organization:

• You should become a QHIN if you operate a health information exchange, run a national network, or are an EHR vendor that wants to offer TEFCA connectivity as a core service.
• You should become a Participant if you are a large health system, a regional HIE, or a technology vendor that serves multiple organizations and wants to manage your own TEFCA onboarding.
• You should become a Sub-Participant if you are a single hospital, clinic, practice, or vendor application that wants TEFCA connectivity with the least operational overhead.

Most healthcare organizations will connect as Sub-Participants through an existing QHIN or Participant. This is by design---TEFCA’s tiered structure allows the majority of organizations to benefit from nationwide connectivity without building and maintaining their own QHIN-level infrastructure.

Exchange Modalities

TEFCA supports three distinct modalities for exchanging health information. Each modality serves different use cases and has different technical requirements.

QHIN Query (Document-Based Exchange)

QHIN Query is the original and most widely implemented exchange modality. It is based on IHE profiles for cross-community document exchange:

• XCPD (Cross-Community Patient Discovery): Used to locate a patient across TEFCA-connected organizations. The initiating QHIN sends a patient demographics query, and responding QHINs return matching patient identifiers.
• XCA (Cross-Community Access): Once a patient is discovered, XCA is used to retrieve clinical documents. The standard document format is C-CDA R2.1 (Consolidated Clinical Document Architecture), which includes structured and semi-structured clinical data.

When to use QHIN Query:

• Treatment purposes where you need a patient’s longitudinal record from external organizations
• Transitions of care (hospital discharge to post-acute, referrals across health systems)
• Public health reporting and surveillance
• Payer operations that require clinical documentation

Technical requirements for QHIN Query:

• Implementation of IHE XCA and XCPD profiles
• Ability to produce and consume C-CDA R2.1 documents
• Patient matching algorithms capable of meeting TEFCA’s matching accuracy requirements
• Support for USCDI (United States Core Data for Interoperability) data elements within C-CDA documents

Facilitated FHIR

Facilitated FHIR is the newer, FHIR R4-based exchange modality introduced in Common Agreement version 2.0 and further refined in version 2.1. It enables RESTful API-based data exchange across TEFCA.

• FHIR R4 APIs: Data is exchanged using standard FHIR R4 resources conforming to US Core profiles.
• UDAP Security: Authentication and authorization use the HL7 FAST (FHIR at Scale Taskforce) UDAP Security Implementation Guide, including Trusted Dynamic Client Registration and JWT-based authentication.
• Resource-level access: Unlike document-based exchange, Facilitated FHIR allows querying for specific FHIR resources (e.g., a patient’s active medications or recent lab results) rather than retrieving entire documents.

When to use Facilitated FHIR:

• Application-to-application data exchange where you need specific data elements
• Real-time clinical decision support that requires current patient data
• Patient-facing applications that need to aggregate data from multiple sources
• Use cases where C-CDA documents contain more data than needed, and targeted FHIR queries are more efficient

Technical requirements for Facilitated FHIR:

• FHIR R4 server conforming to US Core Implementation Guide profiles
• Implementation of the HL7 FAST UDAP Security IG (required by January 1, 2026)
• Support for FHIR search parameters defined in the Facilitated FHIR SOP
• Certificate-based authentication using TEFCA-issued certificates

Message Delivery

Message Delivery is the third exchange modality, supporting push-based notifications and directed messaging.

• Direct messaging: Secure, point-to-point message delivery using the Direct Standard (based on S/MIME encrypted email)
• Event notifications: Push-based alerts for events like hospital admissions, discharges, and transfers (ADT notifications)

When to use Message Delivery:

• ADT event notifications to primary care providers and care managers
• Referral document delivery
• Public health case reporting
• Any use case where the sender knows the recipient and needs to push data proactively

Technical requirements for Message Delivery:

• Direct messaging infrastructure (Health Internet Service Provider, or HISP)
• Support for Direct Standard message formats
• Certificate management for encrypted message delivery

Technical Requirements Deep Dive

Regardless of which exchange modality you implement, there are several cross-cutting technical requirements that every TEFCA-connected organization must meet.

FHIR R4 Conformance

For organizations implementing Facilitated FHIR, FHIR R4 conformance is mandatory. This means:

• US Core Profiles: Your FHIR server must support the US Core Implementation Guide profiles. As of 2026, US Core 6.1 is the current version, aligning with USCDI v3. Key profiles include Patient, Condition, Observation (laboratory, vital signs, social history), MedicationRequest, AllergyIntolerance, Procedure, DiagnosticReport, DocumentReference, and Encounter.
• CapabilityStatement: Your FHIR server must publish a CapabilityStatement resource that accurately describes the resources, search parameters, and operations you support.
• Search parameters: You must support the search parameters defined in the US Core profiles and the Facilitated FHIR SOP. These include patient-based searches (e.g., GET /Observation?patient=123&category=laboratory) and date-based filtering.

C-CDA R2.1 Document Support

For organizations implementing QHIN Query, you must be able to produce and consume C-CDA R2.1 documents. Key document types include:

• Continuity of Care Document (CCD): The most common document type exchanged, containing a comprehensive patient summary.
• Discharge Summary: Generated at hospital discharge, summarizing the inpatient encounter.
• Referral Note: Used when referring a patient to another provider or specialist.
• Progress Note: Clinical notes from individual encounters.

Each document must include structured data for the USCDI data elements, including patient demographics, problems, medications, allergies, procedures, results, vital signs, immunizations, and clinical notes.

IHE Profiles

QHIN Query relies on several IHE (Integrating the Healthcare Enterprise) profiles:

• XCA (Cross-Community Access): Defines the queries and responses for retrieving documents across communities. Includes the CrossGatewayQuery and CrossGatewayRetrieve transactions.
• XCPD (Cross-Community Patient Discovery): Defines the patient matching queries. Uses the CrossGatewayPatientDiscovery transaction with HL7v3 messages.
• XDS.b (Cross-Enterprise Document Sharing): The underlying document sharing framework that XCA extends for cross-community use.
• MHD (Mobile access to Health Documents): A FHIR-based alternative to XDS.b that is gaining adoption for lighter-weight implementations.

Patient Matching and eMPI

Patient matching is arguably the most challenging technical aspect of TEFCA integration. When you send a query across TEFCA, responding organizations must accurately match the incoming demographics to their local patient records.

Key requirements:

• Deterministic and probabilistic matching algorithms
• Support for the TEFCA patient demographics fields: first name, last name, date of birth, sex, address, phone number, and (when available) SSN or insurance identifiers
• Configurable matching thresholds that balance sensitivity (finding true matches) with specificity (avoiding false matches)
• An enterprise Master Patient Index (eMPI) or equivalent that can reconcile identities across systems

Common challenges:

• Name variations (nicknames, married/maiden names, transliterations)
• Address changes due to patient relocation
• Duplicate records within your own system that may produce inconsistent match results
• Deceased patients and historical records

USCDI Data Elements

The United States Core Data for Interoperability (USCDI) defines the minimum set of data elements that must be supported. USCDI v3, which is current as of 2026, includes:

• Patient Demographics (name, date of birth, sex, race, ethnicity, preferred language, address)
• Allergies and Intolerances
• Assessment and Plan of Treatment
• Care Team Members
• Clinical Notes (consultation, discharge summary, history and physical, progress, procedure, imaging narrative)
• Clinical Tests (diagnostic imaging, clinical test results)
• Encounter Information
• Goals
• Health Concerns
• Health Insurance Information
• Immunizations
• Medications
• Problems (conditions/diagnoses)
• Procedures
• Provenance (author, timestamp)
• Vital Signs
• Social Determinants of Health (SDOH) assessments and goals
• Unique Device Identifier (UDI) for implantable devices

Security Requirements

TEFCA’s security framework is built on several layers of trust, authentication, and authorization.

HL7 FAST UDAP Security

The HL7 FAST (FHIR at Scale Taskforce) UDAP (Unified Data Access Profiles) Security Implementation Guide is the cornerstone of TEFCA’s security model for Facilitated FHIR. As of January 1, 2026, TEFCA requires adoption of the FAST UDAP Security IG for FHIR-based exchange.

Key components include:

• Trusted Dynamic Client Registration: When a TEFCA-connected application needs to access a FHIR server at another organization, it registers dynamically using a signed software statement backed by a TEFCA-issued certificate. This eliminates the need for manual client registration across thousands of organizations.
• JWT-based authentication: Access tokens are obtained using the OAuth 2.0 client credentials grant with a signed JWT assertion. The JWT is signed with the private key corresponding to the TEFCA certificate.
• Certificate trust chain: TEFCA maintains a certificate authority (CA) hierarchy. QHINs receive certificates from the TEFCA CA, and Participants and Sub-Participants receive certificates through their QHIN. This creates a chain of trust that enables any TEFCA-connected organization to verify the identity of any other.

OAuth 2.0 Authorization

For Facilitated FHIR exchange, authorization follows the OAuth 2.0 framework with TEFCA-specific extensions:

• Client credentials flow: Used for server-to-server (B2B) exchange, which is the primary pattern for TEFCA queries. The requesting application authenticates with a signed JWT and receives an access token scoped to the approved data access.
• Authorization code flow: Used when a user-facing application needs to access data through TEFCA. This flow involves user authentication and consent before granting access.
• Scopes: TEFCA defines specific OAuth scopes that correspond to the permitted exchange purposes (treatment, payment, healthcare operations, public health, etc.).

Certificate Management

Managing certificates is a critical operational requirement for TEFCA-connected organizations:

• Certificate issuance: Obtain your TEFCA certificate through your QHIN or directly from the TEFCA CA (for QHINs).
• Certificate rotation: Plan for regular certificate rotation. Implement automated certificate renewal processes to avoid service disruptions.
• Certificate revocation: Monitor for certificate revocation notifications and update your trust store accordingly.
• Key storage: Store private keys in hardware security modules (HSMs) or equivalent secure key management systems.

Implementation Timeline

The time required to connect to TEFCA varies significantly based on your chosen participation level and your organization’s current technical readiness. Here is what to expect for each pathway.

Sub-Participant via Existing QHIN (1-3 Months)

This is the fastest pathway and is available to organizations that already have a relationship with a QHIN or Participant.

• Month 1: Execute the Sub-Participant Agreement. Assess current technical capabilities against TEFCA requirements. Identify gaps in data completeness, patient matching, and security.
• Month 2: Implement required technical modifications. Configure your integration engine to connect to the Participant’s infrastructure. Conduct initial testing with the QHIN’s test environment.
• Month 3: Complete production testing. Go live with TEFCA exchange. Begin monitoring and optimizing query performance.

Participant Through a QHIN (3-6 Months)

• Months 1-2: Execute the Participant-QHIN Agreement. Complete the QHIN’s onboarding assessment. Begin technical implementation of required exchange modalities.
• Months 3-4: Implement patient matching, security (including UDAP if supporting Facilitated FHIR), and data mapping. Conduct integration testing with the QHIN.
• Months 5-6: Complete end-to-end testing across TEFCA. Onboard initial Sub-Participants if applicable. Go live and begin production exchange.

Becoming a QHIN (6-12+ Months)

• Months 1-3: Submit the QHIN application to the RCE. Begin building or adapting infrastructure for all required exchange modalities. Engage legal counsel for Common Agreement review.
• Months 4-6: Complete the RCE’s technical assessment and security review. Implement 24/7 operational monitoring and incident response capabilities. Begin interoperability testing with existing QHINs.
• Months 7-12: Complete the RCE’s full onboarding process, including operational readiness assessments. Achieve Designated QHIN status. Begin onboarding Participants and Sub-Participants.

Common Challenges

Based on our experience helping healthcare organizations prepare for and execute TEFCA integrations, these are the most common challenges teams encounter.

Patient Matching Accuracy

Patient matching across organizations is inherently difficult. Demographic data quality varies widely between organizations, and there is no universal patient identifier in the US healthcare system. Organizations should invest in robust probabilistic matching algorithms, data quality improvement initiatives (standardizing addresses, capturing complete demographics at registration), and ongoing monitoring of match rates and false positive/negative rates.

Data Quality and Completeness

TEFCA exchange is only as useful as the data that flows through it. Common data quality issues include incomplete problem lists, outdated medication records, missing structured data in C-CDA documents (data present in the EHR but not mapped to C-CDA sections), and inconsistent coding (mixing ICD-10, SNOMED CT, and local codes). Address these issues by auditing your outbound C-CDA documents and FHIR resources before going live.

Consent Management

TEFCA operates under a framework of Permitted Purposes---the legally recognized reasons for exchanging data (treatment, payment, healthcare operations, public health activities, etc.). However, state privacy laws vary significantly. Some states require explicit patient consent for certain types of data exchange (such as behavioral health or substance use disorder records under 42 CFR Part 2). Your implementation must account for these consent requirements and ensure that sensitive data categories are handled appropriately.

Testing Complexity

Testing a TEFCA integration requires coordinating with your QHIN, other QHINs, and their Participants. Unlike a point-to-point integration where you test with a single partner, TEFCA testing involves validating that your queries work correctly across the entire network. Use the QHIN’s test environment extensively, test with a representative sample of real (de-identified) patient scenarios, and plan for iterative testing cycles.

Vendor Coordination

If you rely on an EHR vendor or integration engine vendor for your TEFCA connectivity, coordinate early. Vendor timelines, feature availability, and configuration requirements can significantly impact your implementation schedule. Confirm that your vendor supports the specific exchange modalities and security requirements (especially UDAP) that your QHIN requires.

How Mirth Connect Supports TEFCA

NextGen Mirth Connect (formerly Mirth Connect, also known as the Open Integration Engine) is widely used as the integration backbone for TEFCA connectivity. Its flexible channel-based architecture makes it well-suited for the multi-protocol, multi-format requirements of TEFCA exchange.

Channel Architecture for TEFCA

A typical Mirth Connect deployment for TEFCA includes several channel types:

• XCA/XCPD channels: For QHIN Query exchange, Mirth Connect channels handle the IHE XCA and XCPD transactions. Inbound channels receive cross-community queries from the QHIN and route them to the local document repository. Outbound channels initiate queries to the QHIN for external patient data.
• FHIR channels: For Facilitated FHIR exchange, Mirth Connect’s FHIR Listener and FHIR Sender connectors handle FHIR R4 API requests and responses. Channels can transform between internal data formats and FHIR resources, apply US Core profile validation, and route requests to appropriate backend systems.
• C-CDA assembly channels: Dedicated channels for assembling C-CDA documents from disparate data sources (EHR, lab system, pharmacy system, etc.). These channels pull data from multiple sources, apply C-CDA templates, and produce compliant documents for QHIN Query responses.
• Patient matching channels: Channels that receive XCPD patient discovery requests, query the local eMPI, and return matching patient identifiers.

FHIR Transformation

Mirth Connect’s transformation engine is particularly valuable for TEFCA implementations that must support both document-based and FHIR-based exchange:

• Transform C-CDA documents into FHIR Bundles for organizations transitioning from document-based to FHIR-based exchange
• Map between internal database schemas and FHIR resources
• Apply US Core profile constraints and validate outbound FHIR resources
• Handle FHIR search parameter parsing and response pagination

Security Integration

Mirth Connect supports the security infrastructure required for TEFCA:

• TLS mutual authentication for QHIN-to-QHIN and QHIN-to-Participant communication
• Certificate management for TEFCA-issued certificates
• OAuth 2.0 token handling for Facilitated FHIR authorization flows
• Audit logging that meets TEFCA’s accountability and transparency requirements

What Comes Next for TEFCA

TEFCA continues to evolve rapidly. Several developments are worth watching in 2026 and beyond:

• Expanded exchange purposes. The RCE is working on Standard Operating Procedures (SOPs) for additional exchange purposes beyond the initial set, including individual access services and benefits determination.
• Additional QHINs. Several Candidate QHINs are working through the onboarding process. As more QHINs come online, the network’s reach and redundancy will increase.
• FHIR maturity. Facilitated FHIR is still relatively new within TEFCA, and adoption is ramping up throughout 2026. Expect refinements to the Facilitated FHIR SOP and broader support from EHR vendors and integration platforms.
• Quality measurement. There is growing interest in using TEFCA for quality measurement data exchange, which could streamline reporting for value-based care programs.
• Public health connectivity. Public health agencies are increasingly connecting to TEFCA for surveillance, case reporting, and immunization data exchange, building on lessons learned during the COVID-19 pandemic.

Next Steps

If your organization is planning a TEFCA integration, here are the immediate actions to take:

1. Assess your current state. Inventory your existing interoperability capabilities---what exchange networks are you connected to, what standards do you support, and where are your gaps?
2. Choose your QHIN. Evaluate the 11 designated QHINs based on your use cases, existing relationships, and technical requirements.
3. Identify your participation level. Determine whether Sub-Participant, Participant, or QHIN is the right pathway for your organization.
4. Plan for UDAP security. If you will support Facilitated FHIR, begin implementing the HL7 FAST UDAP Security IG now.
5. Invest in patient matching. Improve your eMPI and data quality before connecting to TEFCA. Poor patient matching will undermine the value of your TEFCA connectivity.

Saga IT helps healthcare organizations plan, architect, and implement TEFCA integrations. Whether you need a readiness assessment, integration engine configuration, or end-to-end implementation support, our team has the expertise to get you connected.

• TEFCA Integration Services --- Our full TEFCA integration practice, from readiness assessment to production go-live.
• HIE Integration --- Health information exchange design, deployment, and optimization.
• FHIR API Integration --- FHIR R4 server development, US Core conformance, and API implementation.
• CMS Interoperability Compliance --- Meeting CMS-0057 and other federal interoperability requirements.
• Mirth Connect Services --- Integration engine deployment, channel development, and TEFCA channel architecture.