Healthcare interoperability is not moving toward a single standard. Different workflows create different requirements, which is why Direct Secure Messaging, FHIR, TEFCA/QHINs, EHR-native exchange, and other interoperability approaches continue to coexist.
The better question is not which standard wins. It is which exchange model best supports each workflow—and where healthcare organizations need more than one.
Executive Summary
THE CORE IDEA
The market keeps framing interoperability as a race toward one standard—but different workflows create different requirements, so Direct, FHIR, TEFCA/QHINs, and EHR-native exchange continue to coexist.
- Direct Secure Messaging is built for trusted, push-based delivery to a known recipient: referrals, transitions of care, and clinical documents.
- FHIR is built for structured, API-based access to discrete data: patient access, analytics, automation, and application integration.
- The two solve different problems. Many enterprises need both—sometimes within the same end-to-end workflow.
- A durable strategy starts with the workflow, not the standard—and measures the outcome, not just the connection.
Any discussion that suggests healthcare interoperability is moving toward a single standard misses the operational reality of modern exchange: different workflows require different interoperability models.
FHIR adoption continues to expand. TEFCA and QHINs are changing national exchange patterns. EHR-native networks are supporting a growing range of workflows. At the same time, health systems, EHR teams, and technology providers depend on trusted ways to send referrals, discharge summaries, care transition documents, and other sensitive information to known recipients. The decisions are critical and complex.
Organizations are being asked to modernize data access, participate in national exchange frameworks, reduce dependence on fax, connect a growing ecosystem of applications, and preserve the clinical and administrative workflows that keep information moving.
None of this is surprising. What is surprising is that the conversation is still often framed as though healthcare is moving toward a single interoperability rail. Much of today’s discussion assumes the more FHIR expands, the less organizations will need Direct or other exchange models.
The market is not moving toward a single standard. Different workflows create different interoperability requirements. That’s why Direct, FHIR, TEFCA, QHINs, EHR-native exchange, and other interoperability approaches continue to coexist. The real question isn’t which standard wins. It’s how they work together.
A durable interoperability strategy begins by understanding the workflow: the participants, systems, trust model, direction of exchange, and what needs to happen after information arrives. From there, it aligns structured API access, trusted push-based exchange, and network-mediated exchange with the operational workflows each supports.
Direct Secure Messaging and FHIR are central to this discussion. They can overlap in some scenarios, but they solve different problems. Understanding those differences is essential to building an architecture that supports the full range of healthcare data exchange.
Four Assumptions Worth Retiring
What the industry conversation gets wrong about Direct and FHIR.
-
Assumption “The more FHIR expands, the less organizations will need Direct or other exchange models.”Operational Reality
The market is not moving toward a single standard. Different workflows create different interoperability requirements—that’s why Direct, FHIR, TEFCA, QHINs, and EHR-native exchange continue to coexist.
-
Assumption “More APIs should naturally mean fewer exchange methods.”Operational Reality
New interoperability methods are usually introduced because existing ones do not solve a particular problem well enough—not to displace what already works.
-
Assumption “Regulatory change signals a transition from Direct to FHIR.”Operational Reality
HTI-5 would adjust certification criteria while the Direct Project transport standard remains in regulation. These are meaningful policy signals for FHIR-based certification—they don’t speak to workflows or suggest a transition away from Direct.
-
Assumption “If an organization has FHIR, it no longer needs Direct.”Operational Reality
In many healthcare environments, both are needed—not because Direct replaces FHIR, but because they support different exchange patterns and operational needs.
Revisiting Where Direct and FHIR Fit
Most interoperability leaders already understand what Direct Secure Messaging and FHIR are. What’s becoming more important is understanding where each belongs as interoperability architectures become more layered. Those differences shape product, integration, and workflow design.
Direct Secure Messaging provides trusted, push-based exchange to a known recipient. FHIR provides structured, API-based access to healthcare data across systems, applications, and services.
Direct Secure Messaging and FHIR support different exchange patterns and operational requirements.
| Direct Secure Messaging | FHIR |
|---|---|
| Sends information securely to a known recipient | Makes structured healthcare data available through APIs |
| Supports push-based exchange | Supports query, retrieval, application integration, and data services |
| Carries messages, documents, and structured payloads | Organizes information into standardized, reusable resources |
| Operates through trusted endpoints and certificate-based exchange | Operates through API authorization, identity, and security frameworks |
| Critical to many referral, transition-of-care, and clinical document workflows | Well-suited to patient access, applications, analytics, and real-time data use |
Direct functions like a trusted digital courier. The sender knows where the information needs to go and delivers the message, document, or payload securely to a verified recipient. FHIR functions as a structured data and API layer. An authorized application, service, or system can request specific information, retrieve it in a standardized format, and incorporate it into another process.
The distinction is not merely technical. A referral packet, discharge summary, patient-facing application, analytics pipeline, and real-time clinical query do not have identical requirements. They involve different participants, different data, different trust relationships, and different actions after the exchange. Trying to force all of them through a single method can create complexity and gaps.
Direct and FHIR perform different jobs. Neither technology is trying to solve the other’s problem. That’s precisely why mature interoperability environments increasingly rely on both.
Why Healthcare Interoperability Keeps Getting More Layered
One of the biggest misconceptions in healthcare interoperability is that more APIs should naturally mean fewer exchange methods. In practice, that is rarely how enterprise architectures evolve. As organizations broaden their use of FHIR APIs, they are also investing in Direct Secure Messaging, TEFCA participation, QHIN connectivity, health information exchanges, EHR-native networks, and embedded workflow tools. The answer begins with the diversity of healthcare itself.
New interoperability methods are usually introduced because existing ones do not solve a particular problem well enough. Direct itself emerged because fax, mail, and courier-based exchange were too slow, manual, and difficult to secure at scale. FHIR, TEFCA, QHINs, and other approaches follow the same pattern: each adds capabilities for problems earlier methods were not designed to solve.
A patient requesting access to structured health information has different requirements than a referral coordinator sending documentation to another provider. A national record query is different than a time-sensitive message to a known recipient. Public health reporting, analytics, care coordination, prior authorization, and provider communication each introduce their own combinations of data, participants, permissions, and workflows. Interoperability is layered because the work and needs are layered.
That does not mean the industry should accept unnecessary fragmentation. Better orchestration, common trust frameworks, reusable APIs, embedded exchange, and more consistent standards can reduce complexity for users and implementers.
But simplifying the experience is not the same as asserting the underlying requirements are interchangeable.
Policy and security developments reinforce the need for precision. HTI-5 remains a proposed ASTP/ONC rule. If finalized as proposed, it would remove certain Direct-related certification criteria while retaining the underlying Direct Project transport standard in regulation. That distinguishes a shift in certification policy from the transport itself. ONC has said the transport remains widely utilized and continues to support interoperability. ONC also describes the proposal as establishing a foundation for future FHIR-based API requirements. These are meaningful policy signals that advance FHIR-based certification, but they do not speak to workflows or suggest a transition from Direct to FHIR.
FHIR underpins specific certified health IT capabilities and interoperability requirements, but it is not a standard that works in all situations or workflows.
The goal is not to eliminate exchange methods or find a single “best” standard, but rather to optimize workflows and secure data while reducing friction.
Where Direct Secure Messaging Fits
Direct Secure Messaging is purpose-built for trusted push-based exchange. It is particularly well suited when the sender knows the recipient and needs to deliver sensitive healthcare information securely, reliably, and within an established trust framework. That includes workflows such as:
- Referrals
- Transitions of care
- Discharge summaries and care documents
- Clinical document exchange
- Provider-to-provider communication
- Known-recipient document delivery
- Exchange between organizations that do not share an EHR or common API environment
- Secure delivery embedded within portals, CRMs, contact centers, and EHR-adjacent applications
The technical objective is typically to transmit a document or payload. The operational objective is usually more important: get the right information to the right organization—securely—in a form and channel that allows someone to act.
Consider a referral. The workflow does not end when clinical information leaves the sender’s system. The documentation must reach the appropriate recipient, and the receiving organization must be able to identify it, route it, review it, and continue the process securely. Direct is particularly effective in this type of known-recipient workflow because trusted delivery is part of the design. It also provides reach across organizational and technology boundaries—healthcare participants do not always share the same EHR ecosystem, national network, or API connection. Direct offers a standards-based way to exchange information without requiring a custom point-to-point integration for every messaging relationship.
A Health Information Service Provider, or HISP, supports that exchange by enabling trusted Direct connections between healthcare organizations, providers, applications, and systems. Direct becomes even more valuable when it is embedded into the applications and workflows people already use. In that model, the user does not have to treat secure exchange as a separate workflow. It becomes an enabling layer within an existing workflow.
Direct is strongest in referrals, transitions of care, clinical document delivery, and other low-friction push workflows where there is an identified recipient.
Where FHIR APIs Fit
FHIR, or Fast Healthcare Interoperability Resources, is designed to make healthcare data easier to structure, access, exchange, and reuse through APIs. It is typically the better fit when an application or system needs standardized access to discrete data. Common FHIR use cases include:
- Patient access
- SMART on FHIR applications
- Real-time or near-real-time queries
- Analytics and reporting, and digital health applications
- Structured system-to-system data exchange and EHR integration
- Automation using specific clinical or administrative data elements
Where Direct typically delivers a message, document, or payload, FHIR exposes structured resources. Those resources can represent patients, medications, observations, conditions, appointments, diagnostic reports, and many other healthcare data concepts. This makes FHIR valuable when the receiving application needs to process, display, analyze, or act on individual data elements. A patient-facing application might retrieve medication data through a FHIR API. An analytics platform might consume standardized observations. A clinical application might request a specific data point from an EHR instead of ingesting an entire document.
FHIR makes those interactions more consistent and programmable; what it does not do by itself is complete the surrounding workflow. Organizations must still address authorization, identity, trust, data quality, governance, endpoint access, implementation differences, and the action that follows the exchange.
A FHIR endpoint can make information available. It does not guarantee that the information reaches the right operational queue, closes a referral, or results in action. That distinction is central to why many organizations run both structured API access and trusted message delivery side by side.
If You Have FHIR, Do You Still Need Direct?
It’s one of the most common questions we hear. As organizations expand their use of FHIR APIs, it’s natural to ask whether Direct Secure Messaging becomes less important. In many healthcare environments, the answer is still yes: both are needed—not because Direct replaces FHIR, but because they support different exchange patterns and operational needs.
The Difference Becomes Clearer in Practice
Different exchange patterns become easier to distinguish when they are evaluated in the context of a real workflow.
- Strong Direct Use Case A care team sending a referral package to a known provider is a strong Direct use case.
- Strong FHIR Use Case An analytics application requesting discrete clinical data is a strong FHIR use case.
- Strong Direct Use Case A hospital delivering a discharge summary to a known outside organization is a strong Direct use case.
- Combined, Same Workflow A healthcare software provider may use FHIR to retrieve structured information and Direct to deliver documents or notifications within the same end-to-end workflow.
The better question is not whether an organization has FHIR. It’s whether FHIR alone satisfies every workflow the organization needs to support. Interoperability leaders should evaluate each scenario against several factors.
The Seven-Factor Evaluation Framework
Score every workflow against each factor before selecting an exchange method.
-
Is the recipient known in advance? Known counterparty versus open, query-based access.
-
Is the information document-based, structured, or both? Payload delivery versus discrete, reusable data elements.
-
Does the workflow need push or query access? Delivered to the recipient versus retrieved by the requester.
-
How are identity and trust established? Certificate-based endpoints versus API authorization frameworks.
-
Do all trading partners support the proposed method? A method only works if every participant can use it.
-
What system or team must act after the information arrives? The exchange is not complete until someone can act on it.
-
Does the new approach improve the workflow—or merely change the technical diagram? A modernization initiative can satisfy every technical requirement and still make the operational process harder. This is the factor that most often gets skipped—and the one that determines whether the project is judged a success six months later.
Where TEFCA and QHINs Fit
TEFCA and QHINs add a broader network-mediated option to the interoperability architecture. Most interoperability leaders already understand TEFCA’s goal of creating a common framework for network-to-network health information exchange. The more practical question is how that option changes the mix of existing exchange capabilities.
Like Direct and FHIR, TEFCA is not another competitor in the interoperability debate. It is another exchange model with its own strengths, constraints, and workflow fit.
TEFCA can create value when an organization needs broader network reach rather than delivery to one predetermined recipient. QHIN participation can provide a path for exchange across connected networks. That can change the routing model for some workflows. It does not make every point-to-point or API-based method unnecessary.
The Interoperability Stack Is Layered, Not Linear
Six exchange models operate concurrently across a mature healthcare interoperability architecture.
-
Direct Secure Messaging Trusted, push-based delivery to a known recipient.Push
-
FHIR APIs Structured, standardized access to discrete healthcare data.Query
-
TEFCA / QHINs Broader, network-mediated exchange across connected networks.Network
-
EHR-Native Networks Exchange within connected vendor ecosystems.Ecosystem
-
HIEs and Regional Networks Regional, community, or use-case-specific exchange.Regional
-
Workflow Platforms Coordinate the operational work around exchanged information.Orchestration
Each exchange model is matched to the workflow it fits best; most healthcare enterprises operate several at once.
Organizations may use several of these capabilities within the same enterprise, and sometimes within the same end-to-end process.
Network-based exchange and EHR-native interoperability can handle some retrieval-oriented and network-mediated exchange. Direct is the better fit for discrete, known-recipient push workflows such as referrals, transitions of care, and clinical document delivery. Most enterprises will operate several of these models at once, matching each to the workflows it serves best.
What “FHIR over Direct” Tells Us
FHIR over Direct is a useful example of the market moving beyond “either/or” thinking. At a high level, it uses Direct Secure Messaging as the trusted transport mechanism for FHIR-based content—resources, bundles, payloads, or references. FHIR contributes a structured data model; Direct contributes secure push delivery and an established trust framework.
The value is not that one standard absorbs the other. It is that the combination can address a workflow neither method necessarily solves as efficiently on its own—useful when an organization wants to exchange structured content but cannot assume every participant shares a common API connection, network relationship, or implementation environment.
It also highlights an important reality: interoperability problems are not limited to data representation. Organizations must also determine:
- Who is sending the information?
- Who is authorized to receive it?
- Is the endpoint trusted?
- Can the recipient process the payload?
- Will the information enter the correct workflow?
- Can the exchange scale across many organizations?
FHIR over Direct is not the answer for every use case. It is one example of how structured data and trusted delivery can be combined within a hybrid architecture. DirectTrust publicly uses the term and describes it as a way to send FHIR content securely through Direct messaging.
The larger lesson is more important than the specific implementation pattern.
When Should Healthcare Organizations Use Direct vs. FHIR?
The best interoperability decisions start with the workflow.
Match the exchange model to the requirements of the workflow.
| Workflow Need | Likely Fit |
|---|---|
| Send a message or document securely to a known recipient | Direct Secure Messaging |
| Retrieve structured healthcare data through an API | FHIR |
| Support patient-facing applications | FHIR, often SMART on FHIR |
| Deliver referral documentation to another provider or organization | Direct, or Direct embedded within a referral workflow |
| Exchange clinical information during a transition of care | Direct, EHR-native exchange, or network exchange, depending on the participants and workflow |
| Participate in broader national exchange | TEFCA/QHIN, where the exchange purpose and participants fit |
| Support analytics or automation using discrete data | FHIR |
| Deliver clinical documentation into an inbox or work queue | Direct |
| Combine structured content with trusted push delivery | Direct and FHIR, including FHIR over Direct |
| Modernize data access while preserving operational workflows | Hybrid interoperability strategy |
This analysis should happen at the workflow level, not only at the enterprise architecture level. An organization may reach different answers for patient access, referral management, clinical document exchange, public health reporting, and analytics. That is not inconsistency; it is recognizing the strengths and importance of different, complementary solutions.
Building a Hybrid Interoperability Strategy
For healthcare technology providers and implementers, this is particularly important. Customers do not need more independent tools. They need exchange capabilities that work within the experiences they already use. The purpose of interoperability is not simply to make information movable; it is to make that information useful.
The Bottom Line
Healthcare interoperability is not a single-rail problem. It is a layered set of capabilities for making sensitive information accessible, deliverable, trusted, and useful across different clinical, administrative, and technical workflows.
FHIR enables structured API access, modern applications, analytics, and reusable data services. Direct Secure Messaging provides trusted push-based exchange for referrals, transitions of care, clinical documents, and known-recipient workflows. TEFCA, QHINs, EHR networks, HIEs, and workflow platforms add further reach and capability.
No interoperability rail wins everywhere.
Healthcare organizations often need Direct for trusted push-based workflows and FHIR for structured API access, sometimes within the very same end-to-end process. A hybrid interoperability strategy gives healthcare organizations and technology providers a practical way to use each method where it performs best, so exchanged information is safe, timely, and valuable.
The future of interoperability is not one method replacing the rest. It is an architecture that makes the right method available for the right workflow, while reducing friction for the people and systems that depend on it.
Build Interoperability Around the Workflow—Not a Single Standard
DataMotion helps healthcare organizations choose and support the right exchange method for each workflow, whether that means Direct Secure Messaging, APIs, EHR integration, or a combination of approaches.
Frequently Asked Questions
What is the difference between Direct Secure Messaging and FHIR?
Direct Secure Messaging is designed for trusted, push-based delivery to a known recipient. FHIR is designed for structured, API-based access to discrete healthcare data. Direct commonly supports referrals, transitions of care, and document delivery, while FHIR commonly supports patient access, applications, analytics, automation, and system integration.
Does FHIR replace Direct Secure Messaging?
No. FHIR and Direct support different exchange patterns. Many healthcare organizations need both because a structured API connection does not automatically complete a known-recipient messaging, document-delivery, or operational workflow.
When should a healthcare organization use Direct instead of FHIR?
Direct is often the better fit when the recipient is known in advance and sensitive information must be delivered securely into an inbox, task, document, or work-queue process. Common examples include referrals, discharge documentation, transitions of care, and provider-to-provider communication.
Can Direct and FHIR be used in the same workflow?
Yes. A workflow may use FHIR to retrieve or structure healthcare data and Direct to deliver a document, payload, or notification securely to a known recipient. FHIR over Direct is one example of combining structured content with trusted push delivery.
Where do TEFCA and QHINs fit in a hybrid interoperability strategy?
TEFCA and QHINs provide a broader network-mediated exchange option. They can expand network reach for appropriate exchange purposes and participants, but they do not eliminate the need for every point-to-point, EHR-native, regional, or API-based method.
How should healthcare organizations choose an interoperability method?
Start with the workflow. Evaluate the participants, data type, trust model, direction of exchange, partner capabilities, receiving system, and action required after the information arrives. Then select the exchange model that improves the operational outcome—not merely the technical diagram.
Sources & Further Reading
- ASTP/ONC: HTI-5 proposed rule and supporting materials.
- ASTP/ONC: Direct Project transport standard and certification guidance.
- DirectTrust: FHIR over Direct resources.
- DataMotion: Healthcare interoperability and EHR integration content.
- DataMotion: Direct Secure Messaging and trusted exchange content.
- DataMotion: The Definitive Guide to Data Exchange: Managing Structured & Unstructured Data.
About the Author
Andrew McKenna
Andrew McKenna is a product and technology leader with more than 20 years of experience developing enterprise software, improving business processes, and transforming complex, manual systems into connected digital workflows. As VP of Product and Partnerships at DataMotion, he leads product strategy and development while helping build the technology and channel partnerships that expand how DataMotion’s solutions reach and serve customers. Since joining DataMotion in 2021, Andrew has helped strengthen the company’s product management function and advance solutions that make secure information exchange more seamless, efficient, and intuitive. His experience spans Fortune 500 data companies, financial institutions, and high-growth technology firms, including product leadership roles at Suuchi and Meritsoft.
