Direct Secure Messaging is a HIPAA-compliant, encrypted email protocol standard that enables authenticated healthcare providers to securely send protected health information (PHI) directly to a known, trusted recipient over the internet. It functions as a point-to-point replacement for fax, mail, or courier services by utilizing S/MIME certificates for message encryption and X.509 digital certificates for identity verification, ensuring that only the intended recipient can decrypt and read the clinical content.
Glossary
Direct Secure Messaging

What is Direct Secure Messaging?
A technical overview of the encrypted, point-to-point clinical messaging protocol designed to replace fax and mail for transmitting protected health information.
The protocol is governed by the DirectTrust network, which acts as a trust anchor by accrediting Health Information Service Providers (HISPs) that perform the encryption, decryption, and certificate management on behalf of provider organizations. Unlike query-based exchange models like FHIR, Direct Secure Messaging operates on a push architecture, making it ideal for transitions of care where a known sender must transmit a Consolidated CDA (C-CDA) document to a specific specialist or post-acute facility.
Core Characteristics of Direct Secure Messaging
Direct Secure Messaging is a HIPAA-compliant, encrypted email protocol standard that enables authenticated healthcare providers to securely send health information directly to a known, trusted recipient over the internet. It operates on a federated trust model using X.509 digital certificates.
Federated Trust Model
Direct operates on a federated trust framework rather than a centralized authority. Each participating organization operates its own Health Information Service Provider (HISP) , which acts as a certificate authority and message gateway. Trust is established through a web of bilateral agreements and cross-certification between HISPs, forming a trust bundle of accredited certificate authorities. This eliminates the need for a single national provider directory while ensuring every sender and receiver is strongly authenticated.
S/MIME Encryption & Digital Signatures
Direct messages are secured using Secure/Multipurpose Internet Mail Extensions (S/MIME) , which provides two critical protections:
- Encryption: Message content is encrypted with the recipient's public key, ensuring only the intended receiver can decrypt it
- Digital Signatures: The sender signs the message with their private key, providing non-repudiation and integrity verification
This cryptographic envelope wraps standard MIME content, allowing attachments like CCDA documents or PDFs to be transmitted securely.
Edge Protocol Delivery
Direct uses SMTP over TLS for transport, but adds the IMAP or POP3 retrieval requirement at the recipient's edge. The HISP-to-HISP transmission occurs via mutually authenticated TLS, while the final delivery to the end-user's inbox uses standard email protocols. This architecture ensures:
- Point-to-point encryption across every hop
- No message persistence on intermediary servers
- Compatibility with existing email clients like Outlook through the Direct Project specifications
Applicability Statement for Secure Health Transport
The Applicability Statement for Secure Health Transport is the core technical specification defining Direct message format and transport. It mandates:
- Use of RFC 5322 compliant messages with X.509 certificates
- SHA-256 hashing for digital signatures
- AES-128 or stronger symmetric encryption
- Mandatory TLS 1.2 or higher for all SMTP and IMAP connections
This specification ensures consistent implementation across all certified HISPs and EHR systems.
Direct Address Binding
Every Direct user is assigned a Direct Address that looks like a standard email address (e.g., [email protected]) but is cryptographically bound to an X.509 certificate. The HISP maintains a certificate directory mapping addresses to public keys. Before sending, the sender's HISP queries the recipient's HISP to retrieve the current valid certificate, ensuring:
- Certificate revocation checking for compromised keys
- Automatic key discovery without manual exchange
- Scalable addressing across organizational boundaries
Meaningful Use & Regulatory Context
Direct was developed under the ONC's Direct Project to satisfy Stage 2 Meaningful Use requirements for transitions of care. Key regulatory drivers include:
- CMS interoperability rule requiring hospitals to send event notifications
- TEFCA recognition of Direct as a valid exchange modality
- HIPAA Security Rule compliance through encryption and access controls
Direct remains a mandated capability in certified EHR technology, particularly for edge cases where FHIR-based exchange is unavailable.
Frequently Asked Questions
Direct Secure Messaging is a HIPAA-compliant, encrypted email protocol standard that enables authenticated healthcare providers to securely send health information directly to a known, trusted recipient over the internet. Below are answers to common questions about its architecture, trust framework, and clinical application.
Direct Secure Messaging is an interoperable, point-to-point communication protocol that uses S/MIME (Secure/Multipurpose Internet Mail Extensions) encryption over standard SMTP, IMAP, and POP3 email protocols to transmit protected health information (PHI). Unlike standard email, it mandates X.509 digital certificates for identity authentication and message encryption. When a provider sends a Direct message, their Health Information Service Provider (HISP) looks up the recipient's digital certificate in a DNS-based trust bundle, encrypts the payload with the recipient's public key, and signs it with the sender's private key. This ensures end-to-end confidentiality, message integrity, and non-repudiation—the recipient can cryptographically verify the sender's identity and that the message was not altered in transit. The protocol supports both SMTP for message submission and IMAP for retrieval, making it compatible with existing email clients like Outlook while adding the security layer required for clinical data exchange.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Direct Secure Messaging vs. FHIR vs. HL7 v2
A technical comparison of three core health data exchange standards: Direct Secure Messaging for point-to-point encrypted communication, FHIR for modern RESTful API access, and HL7 v2 for legacy event-driven messaging.
| Feature | Direct Secure Messaging | FHIR | HL7 v2 |
|---|---|---|---|
Primary Purpose | Push-based, point-to-point encrypted email for trusted providers | RESTful API for granular, on-demand access to discrete health data resources | Event-driven, transactional messaging for hospital system workflows |
Transport Protocol | SMTP, IMAP, POP3 over TLS 1.2+ | HTTP/HTTPS (REST) | MLLP over TCP/IP |
Message Format | S/MIME-encrypted XDM package with C-CDA payload | JSON, XML, Turtle (RDF) | Pipe-and-hat delimited ER7 format |
Exchange Pattern | Push only (store-and-forward) | Push and pull (CRUD operations) | Push only (acknowledgment-based) |
Authentication Model | X.509 digital certificates bound to a Direct address | OAuth 2.0 with SMART on FHIR scopes | None native; relies on VPN, firewall, or MSH segment fields |
Granularity | Document-level (entire CCD or referral) | Resource-level (single observation, medication, or condition) | Segment-level (ADT, ORM, ORU event bundles) |
Query Capability | |||
Real-Time Event Triggers |
Related Terms
Direct Secure Messaging operates within a broader framework of standards and protocols that enable seamless, compliant clinical data exchange.
Health Information Exchange (HIE)
An organization or technology platform that enables the secure electronic mobilization of clinical information across disparate healthcare information systems within a community, region, or hospital network. Direct Secure Messaging often serves as the transport backbone for HIE push notifications, delivering transition of care summaries directly to a known provider's inbox.
- Enables directed exchange: sending information to a specific, known recipient
- Supports query-based exchange: allowing providers to search and discover records
- Relies on master patient indexes to correctly match identities across systems
Consolidated CDA (C-CDA)
A standardized XML document architecture mandated in the U.S. that specifies the encoding, structure, and semantics of clinical documents like discharge summaries for exchange. Direct Secure Messaging frequently transmits C-CDA payloads as attachments, ensuring the receiving EHR can parse and ingest structured data rather than a flat PDF.
- Defines document types: Continuity of Care Document (CCD), Discharge Summary, Progress Note
- Uses LOINC codes for document type identification
- Requires SNOMED CT and RxNorm for coded clinical concepts within sections
Event Notifications (Admit/Discharge/Transfer)
Automated, real-time alerts sent via Direct Secure Messaging when a patient experiences a triggering clinical event, such as a hospital admission, discharge, or transfer. These ADT notifications are a cornerstone of accountable care, enabling primary care providers and care managers to act on transitions immediately.
- Reduces 30-day readmission rates by prompting timely follow-up
- Often contains a C-CDA summary of the encounter
- CMS requires hospitals to send electronic patient event notifications as a condition of participation

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us